Spring Cloud概述

最新推荐文章于 2025-07-11 13:18:47 发布

李小白66

最新推荐文章于 2025-07-11 13:18:47 发布

阅读量1.4k

点赞数 49

CC 4.0 BY-SA版权

分类专栏： SpringCloud 文章标签： spring cloud java 微服务

本文链接：https://blog.csdn.net/2201_75880772/article/details/148290388

SpringCloud 专栏收录该内容

1 篇文章

订阅专栏

1. 什么是微服务

引入

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

单体架构

概念: 很多创业公司早期或者传统企业会把业务的所有功能实现都打包在⼀个项⽬, 这就是单体架构. 业务的所有功能实现都打包在⼀个war包或者Jar包中, 这种⽅式就称为单体架构

比如我们的电商系统

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

集群和分布式框架

引入

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

1> 后端服务器的压⼒就会越来越⼤, 负载越来越⾼, 甚⾄出现⽆法访问的情况

2> 业务场景逐渐复杂. 为了满⾜⽤⼾的需求, 单体应⽤也会越来越⼤. 各个业务代码之间的耦合度也会越来越⾼. 任何⼀个问题, 都需要整个项⽬重新构建, 发布.

3> ⼀个微⼩的问题, 可能会导致整个应⽤挂掉

解决方案

1> 横向: 添加服务器(集群)

2> 纵向: 把一整块业务划分为不同的模块(分布式)

举例: 一开始一台机器承担1000个用户, 后来发展为一万个用户

1> 横向: 扩容机器, 从一台机器扩容到10台机器, 每个机器负责1000个用户

2> 纵向: 按照功能进行划分

以单体结构规模的项⽬为单位进⾏垂直划分. 也就是将⼀个⼤项⽬拆分成⼀个⼀个单体结构项⽬. 项⽬和项⽬之间相对⽐较独⽴, 接⼝多为数据同步功能.

集群和分布式

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

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

例子:

⼀个饭店只有⼀个厨师, 这个厨师负责备菜, 洗菜, 切菜, 炒菜.

随着这个饭店的⽣意越来越好, 这个厨师忙不过来了, 饭店⼜请了⼀个厨师, 新厨师和⽼厨师做⼀样的事情, 也是洗菜, 切菜, 炒菜. 这两个厨师的关系就是集群.

为了让厨师专⼼炒菜, 饭店⼜请了⼀个配菜师, 负责备菜, 洗菜, 切菜. 厨师和配菜师的关系就是分布式.

后来⼀个配菜师也忙不过来了, ⼜请了⼀个配菜师, 这两个配菜师的关系就是集群.

总之: 集群就是我一个结点能够完整的完成所有的业务, 不同集群结点都能这么完成

分布式是我不同的结点一起完成一个业务, 不同结点负责的内容是不同的 (此处一个结点就是一个服务器)

集群和分布式的区别

1. 从概念上. 集群是多个计算机做同样的事(可以相互替代), 分布式是多个计算机做不同的事(不能相互替代)

2. 从功能上. 集群的每⼀个节点功能是相同的, 并且可以替代的. 分布式也是多个节点组成的系统, 但是每个节点完成的业务是不同的, ⼀个节点出现问题, 这个业务就不可访问了.

3. 从关系上. 分布式和集群在实践中, 很多时候是互相配合使⽤的. ⽐如分布式的某⼀个节点, 可能由⼀个集群来代替. 分布式架构⼤多是建⽴在集群上的. 所以实际的分布式架构设计中并不会把分布式和集群单独区分, ⽽是统称: 分布式架构.

微服务框架

引入

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

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

简单来说, 微服务就是很⼩的服务. ⼩到⼀个服务只对应⼀个单⼀的功能, 只做⼀件事. 这个服务可以单独部署运⾏,
从这个⻆度来看, 微服务架构是分布式架构的⼀种拓展, 这种架构模式下它拆分粒度更⼩, 服务更独⽴.可以理解为: 微服务是⼀种经过良好架构设计的分布式架构⽅案.

分布式架构vs微服务架构

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

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

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

比如: 职业划分

分布式: 前端,后端,测试,运维

微服务: 后端分为系统开发, 数据开发, 策略开发...

不同架构的介绍

根据拆分粒度的大小(从大到小)

单体架构->垂直架构->分布式架构->微服务架构

举例

微服务带来的挑战

引入

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

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

优势

1> 易开发和维护. 每个微服务负责的业务⽐较清晰, 体量⼩, 开发和维护成本降低.

2> 容错性⾼. ⼀个服务发⽣故障, 可以使故障隔离在单个服务中, 不影响整体服务故障.

3> 扩展性好. 每个服务都是独⽴运⾏的, 我们可以结合项⽬实际情况进⾏扩展, 按需伸缩.(哪个接口用的多就多配置几个机器来跑这个接口)

4> 技术选型灵活. 每个微服务都是单独的团队来运维, 可以根据业务特点和团队特点, 选择适合的技术栈.(哪个语言适合哪个微服务就用哪个语言)

挑战

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

• 服务依赖. 随着服务的数量增多, 服务之间的关系也会变得更加复杂. ⼀个服务的更改, 需要考虑对其他服务的影响.

• 运维成本. ⼀个业务流程会涉及多个微服务共同完成, 有更多的服务需要编译, 部署, 运⾏, 甚⾄能是不同的编程语⾔, 不同的运⾏环境, 当然也需要集群来处理故障转移等. 这对于运维⼈员⽽⾔, 挑战是巨⼤的.

• 开发和测试. ⼀个业务流程可能涉及多个微服务共同完成, 服务调⽤引⼊⽹络延迟, 不可靠的⽹络, 如何进⾏容错处理等问题. 这对开发和测试⽽⾔, 难度也会提升.

• 服务监控. 在⼀个单体结构中, 很容易实现服务的监控. 因为所有功能都在⼀个服务中, 微服务架构下, 不仅需要对整个链路进⾏监控, 还需要对每⼀个服务实现监控.

• 负载均衡. 微服务架构中的服务实例数量可能⾮常庞⼤，因此需要有效的服务发现和负载均衡机制来管理请求流量和保证⾼可⽤性

选择微服务架构的话, 以上这些问题都需要我们解决, 我们是⾃⼰研发还是选择市场上⽐较成熟的技术拿来⽤呢?

全球的互联⽹公司都在积极尝试⾃⼰的微服务落地⽅案. 在Java领域, 最引⼈注⽬的就是Spring Cloud解决微服务出现的问题了

2. 微服务解决方案- Spring Cloud

什么是Spring Cloud

官方网站: spring.io/projects/spring-cloud/

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

简单来说, Spring Cloud 就是分布式微服务架构的⼀站式解决⽅案, 是微服务架构落地的多种技术的集合.
Spring Cloud 并不是Spring 团队研发的框架, 它只是把⼀些⽐较优秀的解决微服务架构中常⻅问题的开源框架基于SpringCloud规范进⾏了整合, 并基于SpringBoot的⻛格,对这些组件进⾏封装, 屏蔽掉了复杂的配置和实现原理. 为开发者提供了开箱即⽤的微服务开发体验.

这些开源技术的框架是由各个公司来维护的. Spring Cloud 就是这些微服务的⼤管家.

例子: Spring Cloud 发现哪个框架处理微服务很好就把它集成了进来

Spring Cloud版本

Spring Cloud 是⼀个由很多⼦项⽬组成的庞⼤项⽬, 这些⼦项⽬由各个公司来维护的, 所以发布阶段也是不同的.(比如上面的套餐,有版本1,2. 然后套餐1对应的电视是版本1, 套餐2对应的电视的版本是2)

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

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

• Angel

• Brixton

• Camden

• Dalston

• Edgware

• Finchley

• Greenwich

• Hoxton

但英⽂版本号太复杂了, 从 Hoxton 版本之后, Spring Cloud的版本就变成了2020.0.0 这样的⽇期版本号了

• 2020.0.x aka Ilford

• 2021.0.x aka Jubilee

• 2022.0.x aka Kilburn

• 2023.0.x aka Leyton

Spring Cloud和SpringBoot的关系
Spring Cloud 对应的Spring Boot的版本

⽐如SpringBoot 3.2.X对应的SpringCloud版本是2023.0.X

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

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官⽅也提供了⼀些替换建议.

Netflix	推荐替代品	说明
Hystrix	Resilience4j	Hystrix也推荐⼤家使⽤Resilience4j代替⾃⼰
Hystrix Dashboard / Turbine	Micrometer + Monitoring System	说⽩了，监控这件事交给更专业的组件去做
Ribbon	Spring Cloud Loadbalancer	忍不住了，Spring终究亲⾃出⼿
Zuul 1	Spring Cloud Gateway	忍不住了，Spring终究亲⾃出⼿
Archaius 1	Spring Boot外部化配置 + Spring Cloud配置	⽐Netflix实现的更好、更强⼤

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 等组件组成.