【Spring Cloud】Spring Cloud 概述

Spring Cloud 概述

1. 认识微服务

下图表了服务架构从单体应逐渐转变为微服务应的过程

在这里插入图片描述

1.1 单体架构

很多创业公司早期或者传统企业会把业务的所有功能实现都打包在个项, 这就是单体架构

业务的所有功能实现都打包在个war包或者Jar包中, 这种式就称为单体架构

如Spring课程中的博客系统,前端+后端+数据库实现, 都在个项中, 这种架构就称为单体架构

以家都很熟悉的电商系统为例, 电商系统包括: 管理, 商品管理, 订单管理, 付管理, 库存管理, 物流管理等等, 项早期我们会把这些模块都写在个web项中, 然后统部署到个Web服务器中

在这里插入图片描述
这种架构开发简单, 部署简单, 个项就包含了所有的功能, 省去了多个项之间的交互和调消耗.直接部署在个服务器即可

1.2 集群和分布式架构

当站的量越来越, 需求也会越来越多, 流量也会越来越, 服务可能就会临以下问题:

  • 后端服务器的压就会越来越, 负载越来越, 甚出现法访问的情况
  • 业务场景逐渐复杂. 为了满的需求, 单体应也会越来越. 各个业务代码之间的耦合度也会越来越. 任何个问题, 都需要整个项重新构建, 发布
  • 个微的问题, 可能会导致整个应挂掉

我们从两个进优化:

  • 横向: 添加服务器, 把单台机器变成多台机器的集群.
  • 纵向: 把个应, 按照业务进拆分, 拆分为多个项. 此架构也称为垂直架构.

在这里插入图片描述
以单体结构规模的项为单位进垂直划分. 也就是将个项拆分成个个单体结构项. 项和项之间相对较独, 接多为数据同步功能

集群和分布式
  • 集群(cluster)是将个系统完整的部署到多个服务器上, 每个服务器都能提供系统的所有服务, 多个服务器通过负载均衡调度完成任务. 每个服务器称为集群的节点(node)

  • 分布式是将个系统拆分为多个系统,多个系统部署在多个服务器上,多个服务器上的系统协同合作完成个特定任务.

在这里插入图片描述

集群和分布式区别和联系

  1. 从概念上. 集群是多个计算机做同样的事, 分布式是多个计算机做不同的事
  2. 从功能上. 集群的每个节点功能是相同的, 并且可以替代的. 分布式也是多个节点组成的系统, 但是每个节点完成的业务是不同的, 个节点出现问题, 这个业务就不可访问了.
  3. 从关系上. 分布式和集群在实践中, 很多时候是互相配合使的. 如分布式的某个节点, 可能由个集群来代替. 分布式架构多是建在集群上的. 所以实际的分布式架构设计中并不会把分布式和集群单独区分, 是统称: 分布式架构.

1.3 微服务架构

从上图中可以看出, 按照业务进拆分后, 会有些重复的功能开发, 如订单系统, 电商平台和付系统都会涉及.

在分布式架构下, 当部署的服务越来越多, 重复的代码就会越来越多, 服务的调关系也会越来越复杂.我们可以把些通的, 会被多个上层服务调的共享业务, 提取成独的基础服务, 组成个个微的服务. 这就是微服务.

在这里插入图片描述
简单来说, 微服务就是很的服务. 到个服务只对应个单的功能, 只做件事. 这个服务可以单独部署运

微服务之间可以采REST和RPC协议进通信.

从这个度来看, 微服务架构是分布式架构的种拓展, 这种架构模式下它拆分粒度更, 服务更独.可以理解为: 微服务是种经过良好架构设计的分布式架构案.

分布式架构&微服务架构

分布式: 服务拆分, 拆了就.

微服务: 指常微的服务, 更细粒度的垂直拆分, 通常指不能再拆的服务

分布式架构侧重于压的分散, 强调的是服务的分散化. 微服务侧重于能的分散, 更强调服务的专业化和精细分. 从实践的度来看, 微服务架构通常是分布式服务架构, 反之则未必成. 所以, 选择微服务通常意味着需要解决分布式架构的各种难题

1.4 微服务带来的挑战

随着产品的复杂性和流量的增加, 技术架构也在不断的发变化. 不论是早期的单体架构, 还是现在泛使的微服务架构, 都是为了更好的服务产品, 解决问题

微服务架构带来好处的同时, 也临着些挑战, 从单体服务转向微服务意味着管理更加复杂. 接下来我们从优势和挑战两个分析下微服务架构.

优势
  • 易开发和维护. 每个微服务负责的业务较清晰, 体量, 开发和维护成本降低
  • 容错性. 个服务发故障, 可以使故障隔离在单个服务中, 不影响整体服务故障
  • 扩展性好. 每个服务都是独运的, 我们可以结合项实际情况进扩展, 按需伸缩
  • 技术选型灵活. 每个微服务都是单独的团队来运维, 可以根据业务特点和团队特点, 选择适合的技术栈
挑战

虽然微服务具备很多的优势, 但由于服务数的增加, 服务治理也是我们临的巨挑战.

  • 服务依赖. 随着服务的数量增多, 服务之间的关系也会变得更加复杂. 个服务的更改, 需要考虑对其他服务的影响.
  • 运维成本. 个业务流程会涉及多个微服务共同完成, 有更多的服务需要编译, 部署, 运, 甚可能是不同的编程语, 不同的运环境, 当然也需要集群来处理故障转移等. 这对于运维员, 挑战是巨的.
  • 开发和测试. 个业务流程可能涉及多个微服务共同完成, 服务调引络延迟, 不可靠的络, 如何进容错处理等问题. 这对开发和测试, 难度也会提升
  • 服务监控. 在个单体结构中, 很容易实现服务的监控. 因为所有功能都在个服务中, 微服务架构下, 不仅需要对整个链路进监控, 还需要对每个服务实现监控.
  • 负载均衡. 微服务架构中的服务实例数量可能常庞,因此需要有效的服务发现和负载均衡机制来管理请求流量和保证可性

在这里插入图片描述
选择微服务架构的话, 以上这些问题都需要我们解决, 我们是研发还是选择市场上较成熟的技术拿来呢

全球的互联公司都在积极尝试的微服务落地案. 在Java领域, 最引注的就是Spring Cloud了

2. 微服务解决案- Spring Cloud

2.1 什么是Spring Cloud

Spring Cloud 提供了些可以让开发员快速构建分布式服务的具, 如配置管理, 服务发现, 熔断,智能路由等. 他们可以在任何分布式环境中很好的作.

简单来说, Spring Cloud 就是分布式微服务架构的站式解决案, 是微服务架构落地的多种技术的集合

如:

  • Distributed/versioned configuration 分布式版本配置
  • Service registration and discovery 服务注册和发现
  • Routing 路由
  • Service-to-service calls 服务调
  • Load balancing 负载均衡
  • Circuit Breakers 断路器
  • Distributed messaging 分布式消息

Spring Cloud 并不是Spring 团队研发的框架, 它只是把些较优秀的解决微服务架构中常问题的开源框架基于SpringCloud规范进了整合, 并基于SpringBoot的格,对这些组件进封装, 屏蔽掉了复杂的配置和实现原理. 为开发者提供了开箱即的微服务开发体验.
这些开源技术的框架是由各个公司来维护的. Spring Cloud 就是这些微服务的管家.

2.2 Spring Cloud版本

Spring Cloud 是个由很多项组成的庞项, 这些项由各个公司来维护的, 所以发布阶段也是不同的.

为了管理主项和项的依赖关系, 以及为了避免和项版本的冲突, 主项版本命名并没有采和项数字版本化的形式, 是采了英名称

这个英版本名称也较有趣, Spring Cloud 采了英国伦敦地铁站的名称来命名,并由地铁站名称字A-Z依次类推的形式来发布迭代版本

在这里插入图片描述
但英版本号太复杂了, 从 Hoxton 版本之后, Spring Cloud的版本就变成了2020.0.0 这样的期版本号了

在这里插入图片描述

Spring Cloud和SpringBoot的关系

Spring Cloud中的所有项都依赖SpringBoot, 所以SpringBoot 和Spring Cloud的版本之间也存在定的对应关系

在这里插入图片描述
如SpringBoot 3.2.X对应的SpringCloud版本是2023.0.X

如果我们有个SpringBoot项, 我们希望在这个项中添加SpringCloud的些组件, 需要根据当前项的SpringBoot版本, 选择SpringCloud的版本(当然, 新项不存在这个问题)

2.3 Spring Cloud实现案

在Spring Cloud的规范下, 有很多实现, 其中最为出名的是

  • Spring Cloud Netflix
  • Spring Cloud Alibaba
Spring Cloud Netflix

Spring Cloud Netflix是 Netflix OSS(Netflix Open Source Software)在Spring Cloud规范下的实现

包含的组件及其主要功能致如下:

  • Eureka: 服务注册和发现
  • Zuul: 服务关
  • Ribbon: 负载均衡
  • Feign: 服务调组件
  • Hystrix: 断路器, 提供服务熔断和限流
  • Hystrix Dashboard: 监控板

在很的段时间, Spring Cloud 度被泛指 Spring Cloud Netflix. Spring Cloud直以来把Netflix OSS 套件作为其官默认的站式解决案. 然, Netflix公司在2018年前后宣布其核组件Hystrix、Ribbon、Zuul等均进维护状态, Spring Cloud 也被迫宣布删除这些维护模块

spring-cloud-netflix 并没有从Spring Cloud的依赖中完全删除, 只是从2020.0版本起, 他只管理Eureka.

Spring Cloud Netflix 在很多公司都有规模使, 旦停更新, 短期看影响不, 但期显然是不合适的, Spring Cloud官也提供了些替换建议

在这里插入图片描述

Spring Cloud Alibaba

Spring Cloud Alibaba 是阿巴巴集团下的开源组件和云产品在Spring Cloud规范下的实现.

虽然Spring Cloud Alibaba前并不是Spring Cloud官推荐的默认案, 但是Spring Cloud Alibaba是阿中间件团队主导的个新项,正处于速迭代中. 甚在Alibaba的开源组件还没有织SpringCloud态之前, 就已经在各公司泛使了.

如果说Spring Cloud Netflix 是 Spring Cloud 的第代实现, 那么Spring Cloud Alibaba 也可以看做是Spring Cloud 的第代实现, 主要由 Nacos、Sentinel、Seata 等组件组成

在这里插入图片描述
Spring Cloud Alibaba 吸收了 Spring Cloud Netflix 微服务框架的核架构思想, 并进了性能改进. Spring Cloud Netflix 进停更维护后, Spring Cloud Alibaba 逐渐代替它成为主流的微服务框架

Spring Cloud 实现对

在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值