SpringCloud是什么
聊SpringCloud之前先聊聊微服务
1、微服务是什么
微服务架构是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦
微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。
**概念：**把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
**定义：**围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。
**本质：**用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。
2、微服务架构的演变
微服务架构不是一下就出来的，而是经过市场的发展，技术的升级而逐渐出现的。
2.1、单体应用
单体应用就是将所有的功能都打包成一个独立的单元。当网站访问量很小是，只需要一个应用，将所有功能部署到一起，以便减少部署节点和成本。
特点：
- 所有的功能都集成在一个项目 中
- 所有的功能打包成war包部署到服务器
- 应用与数据库分开部署
- 通过部署应用集群和数据库集群来提高系统的性能
优点：
- 开发简单。一个IDE就可以快速构建单体应用。
- 便于共享。单个文档包含所有的功能，传递共享很方便。
- 易于测试。一旦部署，所有的服务或特性就可以使用了，简化了测试过程，没有额外的依赖。
- 容易部署。项目就一个war包，Tomcat安装好了之后，丢进去就可以运行。
缺点：
- 妨碍持续交互，就是说产品上线后，如果后期需要修改代码，则需要对整个项目进行重新打包，再次上传到服务器。
- 不够灵活，就是随着时间推移，功能越来越多，那么在编译打包部署项目的时候，就会很慢，降低了团队开发的灵活性。
- 技术栈受限，就是说一旦确定了使用一种语言，就不能使用别的语言，不能混合别的语言，需要考虑各语言之间的兼容性。
- 可靠性差，就说是，一旦一个地方出了问题，整个项目就会崩掉。
- 伸缩性差，就比如说，在某个场景下某功能并发量会很大，需要加机器，但是如果是单体应用，整个应用是一体的，就需要对整个应用都加机器，造成不必要的性能浪费。、
- 技术债务，就是说，单体应用写代码的时候不会分的很细，什么技术都使用了，写在了一起，耦合度很高，后期维护什么的很不方便，原本两天就能完成的工作，就会变得很麻烦。
2.2、垂直应用
将单体应用的每个功能拆分文为项目独立存在。
特点：
- 以单体结构规模的项目为单位进行垂直划分，就是将一个大项目拆分成一个一个单体结构项目。
- 项目与项目之间存在数据冗余，耦合性较大，比如上图中三个项目都存在用户信息。
- 项目之间的接口多为数据同步功能，如：数据库之间的数据库，通过网络接口进行数据库同步。
优点：
- 架构简单、开发成本低
- 避免单体无线扩张，就是说单体应用越开发功能越多，但是垂直应用不会，垂直应用本来就是每个功能独立拆分出来的，后期如果要要新增功能，直接独立为一个新的项目就行。
- 系统拆分，流量分担，解决并发问题。单体应用都是在一起的，而垂直应用是拆分开的，对服务器来说，不会像单体应用一样有那么大的压力。
- 可以针对不同的功能进行升级，不用像单体应用一样，一处改动，就需要对整个项目进行编译打包数据。
- 系统间相对独立。各个功能是分开的，一个功能出现问题，最多就是该功能无法使用，而不会造成整个大项目的崩溃。
缺点：
- 垂直应用各个之间是独立了，相同功能代码都需要重复编写，代码冗余。
- 系统之间相互调用，IP如果发生改变，调用系统需要手动更改。各个功能之间的调用是根据IP和端口连接调用的，如果一个功能的ip或者端口发生了改变，则调用该功能的项目都要手动更改为新的ip或者端口。
- 伸缩性依旧很差，如果要加机器，还要对整个拆分后的项目进行增加。成本高。
2.3、SOA面向服务架构
特点：
- 基于 SOA 的架构思想将重复公用的功能抽取为组件，以服务的形式给各系统提供服务。
- 各项目（系统）与服务之间采用 WebService、RPC 等方式进行通信。
- 使用 ESB 企业服务总线作为项目与服务之间通信的桥梁。
优点：
- 重复的功能抽取为服务，提供开发效率
- 采用该ESB，减少系统中的接口耦合
- 可以针对不同的服务特点指定集群优化方案。
缺点：
- 系统与服务器的界限模糊
- 服务器的拆分粒度比较大，系统与服务之间耦合较高
- 涉及多种中间件，对开发人员技术栈要求比较高
- 服务关系复杂，运维，测试，部署变得困难
2.4、微服务架构
优点：
- 团队独立。
- 技术独立。（去中心化）??
- 前后端分离
- 数据库分离
- 微服务拆分粒度更细
- 团队新人可以更快的投入生产
- 可以使用不同的语言
- 适用于互联网时代，产品迭代周期短
缺点：
- 微服务过多，服务治理成本高，不利于维护。
- 分布式系统开发技术成本高（网络问题，容错问题，调用关系，分布式事务…）
- 可能会有异步通信
- 运维，部署…
2.5、总结
微服务就是SOA发展出来的产物，他是一种比较现代化更细粒度的SOA实现方式。微服务是一种架构风格，架构就是为了解耦，实际开发使用的还是分布式。
3、微服务设计原则
3.1、AKF拆分原则
通常有一个理念就是：通过机器可以解决容量和可用性问题（一台不行就两台）。
《The Art of Scalability》一书提出了一个系统的可扩展模型——AKF 可扩展立方。这个立方体中沿着三个坐标轴设置分别为 X，Y，Z。
一个叫 AKF 的公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式，可以将一个单体系统，进行无限扩展。
Y轴
就是微服务的拆分模式，按照功能拆分。
X轴
水平复制，一台机器不行，就再来一台机器…
Z轴
分区，为了更好的使用体验，进行分区，在每个地区（例如：华南区、华东区…）都建立一套自己的服务器，各个地区之间是相互隔离又是完整的。
3.2、前后端分离原则
3.2.1未分离
代表技术：Servlet+JSP+JavaBean
在前后端不分离的应用模式中，前端看到的页面都是由后端控制的。例如JSP就是未分离的，需要在前端页面中写Java代码。可以想象，在前端中写后端代码是一个多么操蛋的事情。
<body>
<%
request.setCharacterEncoding("utf-8");
String username = request.getParameter("username");
System.out.print(username);
%>
</body>
3.2.2、半分离
代表技术：：SSH、SSM、Freemarker…
半分离，例如Freemarker模板引擎， 在发起请求的时候，后端返回携带Model数据，然后前端通过模板引擎解析获数据。这种方式虽然不用在前端写后端代码，但是要获取后端返回的数据还需要使用模板引擎的语法去解析数据。
3.2.3、已分离
代表技术：Node.js前端开发框架。VueJS，ReactJS，AngularJS
已分离的应用模式中，后端仅仅返回前端所需要的数据（通常是JSON格式），而不再进行其它操作，具体返回的JSON数据怎么使用，由前端开发者安排。这样就可以做到前后端分离，前端和后端，各自做自己要实现的功能，后端写完后只需要给个接口给前端即可。
总结
前后端技术分离，可以由各自的开发团队来对各自的领域进行优化，这样前端的用户体验优化效果更好。
前后端分离模式下，前后端交互界面更清晰，就剩下了接口模型，后端的接口简洁明了，更容易维护。
前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支持多个前端：例如：微信 h5 前端、PC 前端、安卓前端、IOS 前端。
3.3、无状态服务
如果一个数据需要被多个服务共享才能完成一笔交易，那么这个数据被称为状态。进而依赖这个"状态"数据的服务被称为有状态服务，反之称为无状态服务。
3.4、Restful通信风格
IP:PORT/接口
- JSON报文，轻量级，人机均可阅读
- HTTP无状态，加密又可以依附HTTPS
- 有一套约定俗成的接口设计风格
3.5、CAP原则与BASE理论
- C：一致性，分布式项目中，各个节点的数据最终要保持一致。
- A：可用性，分布式项目的任意节点，在一定的时间内返回有效数据，数据可以是成功或者失败
- P：分区容错，多分区存储数据
CAP原则指的是，在构建分布式项目时，只能满足其中两项，三者不可兼得。业界的人花了两年时间论证该信息。
分析：分布式项目，必然会设计数据分区的问题。肯定需要P，那么项目肯定是CP或者AP。
BASE理论其实核心就是：最终一致性。
这里简单说明，具体在Eureka注册中心中描述。
4、微服务架构带来的问题
客户端如何访问服务?
后台有N个服务，前台就需要管理N个地址，一个服务的下线/升级/扩容，前端都要从新部署
所以，一般在后台N个服务和客户端之间会有一个代理(API Gateway)，作用：
- 提供统一入口
- 聚合后台服务，节省流量，提供用户体验
- 提供安全、流控、过滤、缓存、路由、监控…
服务之间如何通信?
同步通信：
- Restful
- RPC
异步通信：
- MQ
这么多服务如何查找?
利用注册中心机制，将服务集群注册到注册中心，然后把服务的状态推送到各个节点，比如动态的服务扩容、服务的下线等。通过心跳机制检测服务是否可用。
服务挂了怎么办？
服务容错手段：
- 请求缓存：支持将一个请求与返回结果做缓存处理
- 请求合并：将相同的请求进行合并然后调用批处理接口
- 请求限流：当请求过多时，可以采取限流措施，降低机器的负载压力
- 服务隔离：限制调用分布式服务的资源，某一个调用的服务出现问题不会影响其它服务调用
- 服务熔断：牺牲局部服务，保证整体系统稳定性的措施
- 服务降级：服务熔断后，客户端调用自己本地方法返回缺省值
5、微服务架构技术生态体系
5.1、服务网关
所有的API调用接入到API网关层，由网关层统一提供入口和输出，屏蔽底层的微服务。
一个网关的基本功能有：统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后，各个 API 服务提供团队可以专注于自己的的业务逻辑处理，而 API 网关更专注于安全、流量、路由等问题。
5.2、服务调用
微服务架构中，通常存在多个服务之间的远程调用。目前主流的远程调用技术有基于 HTTP 的 RESTful 接口和基于 TCP 的 RPC 协议。以上两种都属于同步通信，还有基于队列模式的异步通信。
- REST：一种HTTP调用的格式，更标准，更通用，无论哪种语言都支持HTTP协议。
- RPC：进程间的通信共享，允许像调用本地服务一样调用远程服务。RPC框架的主要目标就是让远程服务调用更简单更透明。RPC 框架负责屏蔽底层的传输方式、序列化方式和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。
| 比较项 | REST | RPC |
|---|---|---|
| 通讯协议 | HTTP | 一般使用 TCP |
| 性能 | 略低 | 较高 |
| 灵活度 | 高 | 低 |
| 应用 | 微服务架构 | SOA 架构 |
5.3、负载均衡
服务高可用的保证手段，为了保证高可用，每一个微服务都需要部署多个服务实例来提供服务，此时就需要根据不同的负载均衡策略对服务进行调用。
5.4、服务容错
微服务中，一个请求经常会设计到调用多个服务，如果其中某个服务不可用，没有做服务容错的话，极有可能会造成一连串的服务不可用，这就是服务雪峰效应。最终的结果就是，一个服务不可用，导致一系列服务不可用。
造成雪崩的原因有三点：
- 服务提供者不可用(硬件故障、程序BUG、缓存击穿、用户大量请求等)
- 重试加大流量(用户重试，代码逻辑重试)
- 消费者服务不可用(同步等待造成的资源浪费)
没法预防雪崩效应的发生，只能尽可能去做好容错。服务容错的三个核心思想是：
- 不被外界环境影响
- 不被上游请求压垮
- 不被下游响应拖垮
5.5、链路追踪
随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要对一次请求涉及的多个服务链路进行日志记录，性能监控等等。单纯的理解链路追踪，就是指一次任务的开始到结束，期间调用的所有系统及耗时（时间跨度）都可以完整记录下来。
5.6、配置中心
微服务系统中，每个微服务不仅仅只有代码，还需要连接其他资源，例如数据库的配置或功能性的开关 MySQL、Redis 、Security 等相关的配置。除了项目运行的基础配置之外，还有一些配置是与业务有关系的，比如说七牛存储、短信和邮件相关，或者一些业务上的开关。
但是随着微服务系统的不断迭代，整个微服务系统可能会成为一个网状结构，这个时候就要考虑整个微服务系统的扩展性、伸缩性、耦合性等等。其中一个很重要的环节就是配置管理的问题。
常规配置管理方案的缺点：
- 硬编码（需要修改代码，繁琐，风险大）
- properties 或者 yml（集群环境下需要替换和重启）
- xml（重新打包和重启）
常规配置管理有很大的缺点，所以采用 Spring Cloud Config 或 Consul 或 Apollo 或 Nacos 等配置中心集中式的来管理每个服务的配置信息。
5.7、安全认证
从单体应用架构到分布式应用架构再到微服务架构，应用的安全访问在不断的经受考验。为了适应架构的变化、需求的变化，身份认证与鉴权方案也在不断的变革。面对数十个甚至上百个微服务之间的调用，如何保证高效安全的身份认证？面对外部的服务访问，该如何提供细粒度的鉴权方案？
David Borsos 在伦敦的微服务大会上提出了四种解决方案：
5.7.1、单点登录(SSO)
这种方案意味着每个面向用户的服务都必须与认证服务交互，这会产生大量非常琐碎的网络流量和重复的工作，随着微服务应用的增多，这种方案的弊端会更加明显。
5.7.2、分布式Session方案
分布式会话方案原理主要是将关于用户认证的信息存储在共享存储中，且通常由用户会话作为 Key 来实现的简单分布式哈希映射。当用户访问微服务时，用户数据可以从共享存储中获取。这种方案的缺点在于共享存储需要一定保护机制，因此需要通过安全链接来访问，这时解决方案的实现就通常具有相当高的复杂性了。
5.7.3、客户端Token方案
令牌在客户端生成，由身份验证服务进行签名，并且必须包含足够的信息，以便可以在所有微服务中建立用户身份。令牌会附加到每个请求上，为微服务提供用户身份验证，这种解决方案的安全性相对较好，但身份验证注销是一个大问题，缓解这种情况的方法可以使用短期令牌和频繁检查认证服务等。对于客户端令牌的编码方案，David Borsos 更喜欢使用 JSON Web Tokens（JWT），它足够简单且库支持程度也比较好。
5.7.4、客户端Token与API网关结合
这个方案意味着所有请求都通过网关，从而有效地隐藏了微服务。 在请求时，网关将原始用户令牌转换为内部会话 ID 令牌。在这种情况下，注销就不是问题，因为网关可以在注销时撤销用户的令牌。
5.7.5、总结
微服务架构下，更倾向于 David Borsos 所建议的 JWT 方案，将 OAuth2 和 JWT 结合使用，OAuth2 一般用于第三方接入的场景，管理对外的权限，所以比较适合和 API 网关结合，针对于外部的访问进行鉴权（当然，底层 Token 标准采用 JWT 也是可以的）。
JWT 更加轻巧，在微服务之间进行认证&鉴权已然足够，并且可以避免和身份认证服务直接打交道。当然，从能力实现角度来说，类似于分布式 Session 在很多场景下也是完全能满足需求，具体怎么去选择鉴权方案，还是要结合实际的需求来。
6、微服务架构技术支持
6.1、Spring Cloud
Spring Cloud Netflix Eureka：服务注册中心。Spring Cloud Zookeeper：服务注册中心。Spring Cloud Consul：服务注册和配置管理中心。Spring Cloud Netflix Ribbon：客户端负载均衡。Spring Cloud Netflix Hystrix：服务容错保护。Spring Cloud Netflix Feign：声明式服务调用。Spring Cloud OpenFeign(可替代 Feign)：OpenFeign 是 Spring Cloud 在 Feign 的基础上支持了 Spring MVC 的注解，如 @RequesMapping等等。OpenFeign 的 @FeignClient 可以解析 SpringMVC 的 @RequestMapping 注解下的接口，并通过动态代理的方式产生实现类，实现类中做负载均衡并调用其他服务。Spring Cloud Netflix Zuul：API 网关服务，过滤、安全、监控、限流、路由。Spring Cloud Gateway(可替代 Zuul)：Spring Cloud Gateway 是 Spring 官方基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关，Spring Cloud Gateway 旨在为微服务架构提供一种简单而有效的统一的 API 路由管理方式。Spring Cloud Gateway 作为 Spring Cloud 生态系中的网关，目标是替代 Netflix Zuul，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。Spring Cloud Security：安全认证。Spring Cloud Config：分布式配置中心。配置管理工具，支持使用 Git 存储配置内容，支持应用配置的外部化存储，支持客户端配置信息刷新、加解密配置内容等。Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与 Spring Cloud Config 联合实现热部署。Spring Cloud Stream：消息驱动微服务。Spring Cloud Sleuth：分布式服务跟踪。Spring Cloud Alibaba Nacos：阿里巴巴开源产品，一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。Spring Cloud Alibaba Sentinel：面向分布式服务架构的轻量级流量控制产品，把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。Spring Cloud Alibaba RocketMQ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。Spring Cloud Alibaba Dubbo：Apache Dubbo™ 是一款高性能 Java RPC 框架，用于实现服务通信。Spring Cloud Alibaba Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。Spring Cloud Alibaba OSS：阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。Spring Cloud Alibaba SchedulerX：阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。Spring Cloud Alibaba SMS：覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。
6.2、其它
RibbitMQ：RabbitMQ 是部署最广泛的开源消息中间件。是实现了高级消息队列协议（AMQP）的开源消息中间件。Kafka：Kafka 是由 Apache 软件基金会开发的一个开源流处理平台，由Scala和Java编写。Kafka 是一种高吞吐量的分布式发布订阅消息系统。Redis：Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的使用 ANSI C 语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库，并提供多种语言的 API。MongoDB：MongoDB 是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。它支持的数据结构非常松散，是类似 json 的 bson 格式，因此可以存储比较复杂的数据类型。Elasticsearch：Elasticsearch 是一个基于 Lucene 的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于 RESTful web 接口。Elasticsearch 是最受欢迎的企业搜索引擎，其次是 Apache Solr，也是基于 Lucene。MySQL：MySQL 是一种开放源代码的关系型数据库管理系统（RDBMS），免费、简单、占资源少、强大好用。Oracle：世界上最昂贵的数据库，一般金融系统使用居多。FastDFS：FastDFS是一个开源的轻量级分布式文件系统，它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。HDFS：Hadoop 生态组件，可以支持千万级的大型分布式文件系统。XX-JOB：轻量级分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。TX-LCN：分布式事务解决防范，LCN 并不生产事务，LCN 只是本地事务的搬用工（事务的协调工）。LCN 是一个高性能的分布式事务框架，兼容 Dubbo、Spring Cloud，支持 RPC 框架拓展，支持各种 ORM 框架、NoSQL、负载均衡、事务补偿。Zipkin：Twitter 公司开发贡献的一款开源的分布式实时数据追踪系统（Distributed Tracking System），基于 Google Dapper 的论文设计而来，其主要功能是聚集各个异构系统的实时监控数据。Skywalking：Apache Skywalking 是一个开源的，用于收集、分析，聚合，可视化来自于不同服务和本地基础服务的数据的可观察的平台。特别为分布式系统而设计的数据观察和监控系统。Apollo：携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。ConfigKeeper：随行付架构部基于 Spring Cloud 研发的分布式配置中心。与 Spring Boot、Spring Cloud 应用无缝兼容。JWT：JSON Web Token（JWT）是一个非常轻巧的规范。这个规范允许我们使用 JWT 在用户和服务器之间传递安全可靠的信息。Nginx：Nginx 是一款轻量级的 Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，其特点是占有内存少，并发能力强，中国大陆使用 Nginx 网站用户有：百度、淘宝、腾讯、京东、新浪、网易等。Git：开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。Docker：Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux 或 Windows 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。Kubernetes：Kubernetes，简称 k8s，是用 8 代替 8 个字符“ubernete”而成的缩写。Kubernetes 脱胎于 Google 的 Borg 系统，是一个开源的功能强大的容器编排系统，用于管理云平台中多个主机上的容器化的应用，实现了容器集群的自动化部署、扩容以及运维的开源平台。Kubernetes 的目标是让部署容器化的应用简单并且高效。Git：版本控制工具Docker：开源应用容器K8s：容器管理
7、SpringCloud
SpringCloud是一个服务治理平台，是若干的框架的集合，提供了全套的分布式系统解决方案。包含服务注册与发现、配置中心、服务网关、智能路由、负载均衡、断路监控跟踪、分布式消息队列等等。
SpringCloud通过SpringBoot风格的封装，屏蔽掉了复杂的配置和实现原理。最终给开发者留出了一套简单易懂、容易部署的分布式系统开发啊工具包。开发者可以快速的启动服务或构建应用，同时能够快速和云平台资源进行队列。微服务是可以独立部署、水平扩展、独立访问（或者有独立的数据库）的服务单元，Spring Cloud 就是这些微服务的大管家，采用了微服务这种架构之后，项目的数量会非常多，Spring Cloud 做为大管家需要管理好这些微服务，自然需要很多小弟来帮忙。
Spring Cloud的优点
- 集大成者，Spring Cloud包含了微服务架构的方方面面。
- 约定大于配置，基于注解，没有配置文件。
- 轻量级组件，Spring Cloud整合的组件大多比较轻量级，且都是各自领域的佼佼者。
- 开发简便，Spring Cloud 对各个组件进行了大量的封装，从而简化了开发。
- 开发灵活，Spring Cloud 的组件都是解耦的，开发人员可以灵活按需选择组件。
Spring Cloud的缺点
- 项目结构复杂，每个组件或者每个服务器都需要创建一个项目。
- 部署门槛高，项目部署需要配合Docker等容器技术进行进群部署，学习成本高。
7.1、Spring Cloud Netflix 第一代
Netflix是美国的一家公司，提供流媒体播放。
针对多种 Netflix 组件提供的开发工具包，其中包括 Eureka、Ribbon、Feign、Hystrix、Zuul、Archaius 等。
Netflix Eureka：一个基于 Rest 服务的服务治理组件，包括服务注册中心、服务注册与服务发现机制的实现，实现了云端负载均衡和中间层服务器的故障转移。Netflix Ribbon：客户端负载均衡的服务调用组件。Netflix Hystrix：容错管理工具，实现断路器模式，通过控制服务的节点，从而对延迟和故障提供更强大的容错能力。Netflix Feign：基于 Ribbon 和 Hystrix 的声明式服务调用组件。Netflix Zuul：微服务网关，提供动态路由，访问过滤等服务。Netflix Archaius：配置管理 API，包含一系列配置管理 API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。
7.2、Spring Cloud Alibaba 第二代
和Spring Cloud一样，Spring Cloud Alibaba也是一套微服务解决方案。Spring Cloud Alibaba致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必须组件，方便开发者通过Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。
依托 Spring Cloud Alibaba，只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。
阿里开源组件
Nacos：阿里巴巴开源产品，一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。Sentinel：面向分布式服务架构的轻量级流量控制产品，把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。RocketMQ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。Dubbo：Apache Dubbo™ 是一款高性能 Java RPC 框架，用于实现服务通信。Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。
阿里商业化组件
Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。Alibaba Cloud OSS：阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。Alibaba Cloud SchedulerX：阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。Alibaba Cloud SMS：覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。
7.2.1、常用组件
Spring Cloud Netflix Eureka：服务注册中心。Spring Cloud Zookeeper：服务注册中心。Spring Cloud Consul：服务注册和配置管理中心。Spring Cloud Netflix Ribbon：客户端负载均衡。Spring Cloud Netflix Hystrix：服务容错保护。Spring Cloud Netflix Feign：声明式服务调用。Spring Cloud OpenFeign(可替代 Feign)：OpenFeign 是 Spring Cloud 在 Feign 的基础上支持了 Spring MVC 的注解，如 @RequesMapping等等。OpenFeign 的 @FeignClient 可以解析 SpringMVC 的 @RequestMapping 注解下的接口，并通过动态代理的方式产生实现类，实现类中做负载均衡并调用其他服务。Spring Cloud Netflix Zuul：API 网关服务，过滤、安全、监控、限流、路由。Spring Cloud Gateway(可替代 Zuul)：Spring Cloud Gateway 是 Spring 官方基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关，Spring Cloud Gateway 旨在为微服务架构提供一种简单而有效的统一的 API 路由管理方式。Spring Cloud Gateway 作为 Spring Cloud 生态系中的网关，目标是替代 Netflix Zuul，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。Spring Cloud Security：安全认证。Spring Cloud Config：分布式配置中心。配置管理工具，支持使用 Git 存储配置内容，支持应用配置的外部化存储，支持客户端配置信息刷新、加解密配置内容等。Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与 Spring Cloud Config 联合实现热部署。Spring Cloud Stream：消息驱动微服务。Spring Cloud Sleuth：分布式服务跟踪。Spring Cloud Alibaba Nacos：阿里巴巴开源产品，一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。Spring Cloud Alibaba Sentinel：面向分布式服务架构的轻量级流量控制产品，把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。Spring Cloud Alibaba RocketMQ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。Spring Cloud Alibaba Dubbo：Apache Dubbo™ 是一款高性能 Java RPC 框架，用于实现服务通信。Spring Cloud Alibaba Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。
7.3、Spring Cloud版本说明
SpringCloud不是使用数字命名版本号，而是使用的英文单词(地铁站名字)命名，是为了避免总版本号与子项目的版本号混淆。
7.3.1、命名规则
采用伦敦的地铁站名称来作为版本号的命名，根据首字母排序，字母顺序靠后的版本号越大。
Spring 官方详细的版本查看接口：https://start.spring.io/actuator/info
7.3.2、发布计划
| 版本号 | 版本 | 说明 |
|---|---|---|
| BUILD-XXX | 开发版 | 开发团队内部使用 |
| M | 里程碑版 | MileStone，M1 表示第 1 个里程碑版本，一般同时标注 PRE，表示预览版 |
| 版 | 候选发布版 | Release Candidate，正式发布版的前一个观察期，不添加新功能，主要着重于除错 |
| SR | 正式发布版 | Service Release，SR1 表示第 1 个正式版本，一般同时标注 GA，表示稳定版本 |
| GA | 稳定版 | 经过全面测试并可对外发行称之为GA（General Availability） |
7.3.3、子项目版本说明
例如：Spring Cloud Alibaba 2.1.0.RELEASE
- 主版本号。当功能模块有较大更新或者整体架构发生变化时，主版本号会更新。
- 1：次版本号。次版本表示只是局部的一些变动。
- 0：修改版本号。一般是 bug 的修复或者是小的变动。
- RELEASE：希腊字母版本号。标注当前版本的软件处于哪个开发阶段。
7.3.4、希腊版本字母说明
- Base：设计阶段。只有相应的设计没有具体的功能实现。
- Alpha：软件的初级版本。存在较多的 bug。
- Bate：表示相对 Alpha 有了很大的进步，消除了严重的 bug，还存在一些潜在的 bug。
- Gamma：是 Beta 版做过一些修改，成为正式发布的候选版本（Release Candidate）
- Release：该版本表示最终版。