目录
在了解 Spring Cloud 之前,我们先来了解下什么是微服务,以及微服务的发展史.在架构发展的过程中,项⽬开发遇到了哪些问题,以及 Spring Cloud 是⽤来解决什么问题的.
认识微服务
下图表⽰了服务架构从单体应⽤逐渐转变为微服务应⽤的过程
单体架构
很多创业公司早期或者传统企业会把业务的所有功能实现都打包在⼀个项⽬,这就是单体架构.
业务的所有功能实现都打包在⼀个 war 包或者 Jar 包中,这种⽅式就称为单体架构
以⼤家都很熟悉的电商系统为例,电商系统包括:⽤户管理,商品管理,订单管理,⽀付管理,库存管理,物流管理等等,项⽬早期我们会把这些模块都写在⼀个 web 项⽬中,然后统⼀部署到⼀个 Web 服务器中
这种架构开发简单,部署简单,⼀个项⽬就包含了所有的功能,省去了多个项⽬之间的交互和调⽤消耗.直接部署在⼀个服务器即可.
集群和分布式架构
当⽹站的⽤户量越来越⼤,需求也会越来越多,流量也会越来越⼤,服务可能就会⾯临以下问题:
• 后端服务器的压⼒就会越来越⼤,负载越来越⾼,甚⾄出现⽆法访问的情况
• 业务场景逐渐复杂.为了满⾜⽤户的需求,单体应⽤也会越来越⼤.各个业务代码之间的耦合度也会越来越⾼.任何⼀个问题,都需要整个项⽬重新构建,发布.
• ⼀个微⼩的问题,可能会导致整个应⽤挂掉
我们从两个⽅⾯进⾏优化:
• 横向（集群）:添加服务器,把单台机器变成多台机器的集群.
• 纵向（分布式）:把⼀个应⽤,按照业务功能进⾏拆分,拆分为多个项⽬.此架构也称为垂直架构.
以单体结构规模的项⽬为单位进⾏垂直划分.也就是将⼀个⼤项⽬拆分成⼀个⼀个单体结构项⽬.项⽬和项⽬之间相对⽐较独⽴,接⼝多为数据同步功能.
集群和分布式
• 集群(cluster)是将⼀个系统完整的部署到多个服务器上,每个服务器都能提供系统的所有服务,多个服务器通过负载均衡调度完成任务.每个服务器称为集群的节点(node)
• 分布式是将⼀个系统拆分为多个⼦系统，多个⼦系统部署在多个服务器上，多个服务器上的⼦系统 协同合作完成⼀个特定任务.
集群和分布式区别和联系
1. 从概念上.集群是多个计算机做同样的事,分布式是多个计算机做不同的事
2.从功能上.集群的每⼀个节点功能是相同的（同样的代码部署在不同的服务器上）,并且可以相互替代.分布式也是多个节点组成的系统,但是每个节点完成的业务是不同的,⼀个节点出现问题,这个业务就不可访问了.
3. 从关系上.分布式和集群在实践中,很多时候是互相配合使⽤的.⽐如分布式的某⼀个节点,可能由⼀ 个集群来代替.分布式架构⼤多是建⽴在集群上的.所以实际的分布式架构设计中并不会把分布式和集群单独区分,⽽是统称:分布式架构.
微服务架构
简单来说,微服务就是很⼩的服务.⼩到⼀个服务只对应⼀个单⼀的功能,只做⼀件事.这个服务可以单独部署运⾏（大多数的微服务只提供个位数的接口，有的甚至只提供一个接口）
微服务之间可以采⽤ REST 和 RPC 协议进⾏通信.
从这个⻆度来看,微服务架构是分布式架构的⼀种拓展,这种架构模式下它拆分粒度更⼩,服务更独⽴.可 以理解为:微服务是⼀种经过良好架构设计的分布式架构⽅案.
分布式架构&微服务架构
分布式:服务拆分,拆了就⾏.（哪怕服务拆分得不细致，但只要对原来的一整个服务进行拆分了就是分布式）
微服务:指⾮常微⼩的服务,更细粒度的垂直拆分,通常指拆得不能再拆的服务
分布式架构侧重于压⼒的分散,强调的是服务的分散化.微服务侧重于能⼒的分散,更强调服务的专业化和精细分⼯，从实践的⻆度来看,微服务架构通常是分布式服务架构,反之则未必成⽴.所以,选择微服务 通常意味着需要解决分布式架构的各种难题.
微服务的优势和带来的挑战
优势
- 易开发和维护：每个微服务负责的业务⽐较清晰,体量⼩,开发和维护成本降低.
- 容错性⾼：⼀个服务发⽣故障,可以使故障隔离在单个服务中,不影响整体服务故障.
- 扩展性好：每个服务都是独⽴运⾏的,我们可以结合项⽬实际情况进⾏扩展,按需伸缩.
- 技术选型灵活：每个微服务都是单独的团队来运维,可以根据业务特点和团队特点,选择适合的技术栈.
挑战
虽然微服务具备很多的优势,但由于服务数的增加,服务治理也是我们⾯临的巨⼤挑战.
- 服务依赖.随着服务的数量增多,服务之间的关系也会变得更加复杂.⼀个服务的更改,需要考虑对其他服务的影响.
- 运维成本,⼀个业务流程会涉及多个微服务共同完成,有更多的服务需要编译,部署,运⾏,甚⾄可能是不同的编程语⾔,不同的运⾏环境,当然也需要集群来处理故障转移等.这对于运维⼈员⽽⾔,挑战 是巨⼤的.
- 开发和测试.⼀个业务流程可能涉及多个微服务共同完成,服务调⽤引⼊⽹络延迟,不可靠的⽹络,如 何进⾏容错处理等问题.这对开发和测试⽽⾔,难度也会提升.
- 服务监控.在⼀个单体结构中,很容易实现服务的监控.因为所有功能都在⼀个服务中,微服务架构 下,不仅需要对整个链路进⾏监控,还需要对每⼀个服务实现监控.
- 负载均衡.微服务架构中的服务实例数量可能⾮常庞⼤，因此需要有效的服务发现和负载均衡机制来管理请求流量和保证⾼可⽤性
微服务解决方案- Spring Cloud
什么是 Spring Cloud
Spring Cloud 提供了⼀些可以让开发⼈员快速构建分布式服务的⼯具,⽐如配置管理,服务发现,熔断, 智能路由等.他们可以在任何分布式环境中很好的⼯作.
简单来说, Spring Cloud 就是分布式微服务架构的⼀站式解决⽅案,是微服务架构落地的多种技术的集合.
我自己理解： Spring Cloud 相当于一个工具箱，它提供了许多进行分布式微服务开发的工具，而且这些工具都采用 Spring 的风格封装，上手难度低
包含有哪些技术呢？比如：
- 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 就是这些微服务的⼤管家.
Spring Cloud 版本
Spring Cloud 是⼀个由很多⼦项⽬（用于微服务开发的工具）组成的庞⼤项⽬,这些⼦项⽬由各个公司来维护的,所以发布阶段也是不同的.
为了管理主项⽬和⼦项⽬的依赖关系,以及为了避免和⼦项⽬版本的冲突,主项⽬版本命名并没有采⽤ 和⼦项⽬数字版本化的形式,⽽是采⽤了英⽂名称.
这个英⽂版本名称也⽐较有趣,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 中的微服务开发工具时，一定要注意工具和 Spring Cloud 的版本是否对应，在官网可以查 Spring Cloud 版本对应的工具版本，版本不对应，可能会出现很多莫名其妙的问题
Spring Cloud 和 SpringBoot 的关系
Spring Cloud 中的所有⼦项⽬都依赖 SpringBoot,所以 SpringBoot 和 SpringCloud 的版本之间也存在⼀定的对应关系
⽐如SpringBoot 3.2.X 对应的 SpringCloud 版本是 2023.0.X 如果我们有⼀个 SpringBoot 项⽬,我们希望在这个项⽬中添加 SpringCloud 的⼀些组件,需要根据当前项⽬的 SpringBoot 版本,选择 SpringCloud 的版本(当然,新项⽬不存在这个问题)
注意：实际上我们在使用 SpringCloud 时，上要注意和 SpringBoot 的版本相匹配，下要注意和微服务组件的版本相匹配
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 公司不更新这些微服务开发的组件后，Spring 团队便自己开发了具有相同功能的组件供程序员使用。
Spring Cloud Alibaba
Spring Cloud Alibaba 是阿⾥巴巴集团下的开源组件和云产品在 Spring Cloud 规范下的实现.
虽然 Spring Cloud Alibaba⽬前并不是 Spring Cloud 官⽅推荐的默认⽅案,但是Spring Cloud Alibaba 是阿⾥中间件团队主导的⼀个新⽣项⽬，正处于⾼速迭代中.甚⾄在 Alibaba 的开源组件还没有织⼊ SpringCloud ⽣态之前,就已经在各⼤公司⼴泛使⽤了.
官⽅⽹站：https://sca.aliyun.com/docs/2022/overview/what-is-sca/
如果说 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 实现对⽐
1608
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
