Spring Cloud 组件介绍和对比

一、服务发现：Nacos、Eureka

微服务架构里面的核心，负责微服务各个模块的服务注册和发现，各个微服务模块将自己的服务地址、端口号等元数据发送给注册中心，注册中心将此信息记录到服务列表中并通知发送给各个子模块中。

Nacos融合SpringCloud官方文档：https://nacos.io/zh-cn/docs/v2/ecology/use-nacos-with-spring-cloud.html

Eurka Spring官方文档：https://spring.io/projects/spring-cloud-netflix#overview

Spring Cloud Alibaba文档：https://github.com/alibaba/spring-cloud-alibaba/blob/2022.x/README-zh.md

二、远程服务调用(RPC)：Dubbo、Feign

协议

1. Dubbo
   支持多传输协议: Dubbo、Rmi、http,可灵活配置
2. Feign
   基于Http传输协议，短连接，性能比dubbo低

与Spring Cloud 集成

1. Dubbo
   在早期Dubbo是与Spring Cloud 集成有一些脱落,但是在Spring Cloud Alibaba 出现后，spring-cloud-starter-dubbo 与Spring Cloud完美集成
   
2. Feign
   Spring Cloud 最早支持的RPC框架，兼容性好
   

文档

Dubbo Apache文档：https://cn.dubbo.apache.org/zh-cn/overview/home/

Dubbo融合Nacos教程：https://nacos.io/zh-cn/docs/v2/ecology/use-nacos-with-dubbo.html

Feign：RestTemplate + Ribbon结合Eureka进行RPC调用。

三、负载均衡：Ribbon、Dubbo

Dubbo

Ribbon

Feign自身是没有负载均衡能力的,之前默认使用Ribbon作为负载均衡的组件,但是Netfix 已经不在维护了

新版本的Spring Cloud已经将Ribbon替换成Spring Cloud Load Balancer,Ribbon是客户端级别的负载均衡，不像dubbo支持客户端和服务端双向配置

四、网关：SpringCloud Gateway、Zuul、Kong

1.Kong 网关：Kong 的性能非常好，非常适合做流量网关，但是对于复杂系统不建议业务网关用 Kong，主要是工程性方面的考虑。官网：https://konghq.com/

2.Zuul1.x 网关：Zuul 1.0 的落地经验丰富，但是性能差、基于同步阻塞IO，适合中小架构，不适合并发流量高的场景，因为容易产生线程耗尽，导致请求被拒绝的情况

3.gateway 网关：功能强大丰富，性能好，官方基准测试 RPS (每秒请求数)是Zuul的1.6倍，能与 SpringCloud 生态很好兼容，单从流式编程+支持异步上也足以让开发者选择它了。官网教程：https://spring.io/projects/spring-cloud-gateway

4.Zuul 2.x：性能与 gateway 差不多，基于非阻塞的，支持长连接，但 SpringCloud 没有集成 zuul2 的计划，并且 Netflix 相关组件都宣布进入维护期，前景未知。教程：https://blog.csdn.net/fan521dan/article/details/105059573

综上，gateway 网关更加适合 SpringCloud 项目，而从发展趋势上看，gateway 替代 zuul 也是必然的。

五、配置中心：Consul、Nacos、Apollo

Consul

官网：https://www.consul.io/

中文文档：https://www.springcloud.cc/spring-cloud-consul.html

Apollo 和 Nacos 提供了更多开箱即用的功能，更适合用来作为配置中心。

Nacos 使用起来比较简单，并且还可以直接用来做服务发现及管理。Apollo 只能用来做配置管理，使用相对复杂一些。

官网：https://nacos.io/zh-cn/docs/v2/quickstart/quick-start.html

Apollo 在配置管理方面做的更加全面，就比如说虽然 Nacos 在 1.1.0 版本开始支持灰度配置，但 Nacos 的灰度配置功能实现的比较简单，Apollo 实现的灰度配置功能就相对更完善一些。不过，Nacos 提供的配置中心功能已经可以满足绝大部分项目的需求了。官网：https://github.com/apolloconfig/apollo/wiki/Apollo%E9%85%8D%E7%BD%AE%E4%B8%AD%E5%BF%83%E4%BB%8B%E7%BB%8D

六、分布式事务：seata

Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。

@GlobalTransactional注解来实现一个分布式事务。

具体的业务就是，我们自己有一个事务管理，当我们的业务在保存的时候出现问题，我们单据就会回滚，不会保存，然后我们会调用流程平台的代码（也就是Activiti），然后问题出现了，在调用的时候出现了问题，流程没有取到数据，我们因为因为出错所以就回滚了，但是Activiti捕捉了这个异常，并且成功发起的流程，这就导致了单据显示在用户的我发起的和代办中，我们就换一个注解实现全局事务GlobalTransactional。

官网：https://github.com/seata/seata

七、分布式消息系统

RocketMQ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。

官网：https://rocketmq.apache.org/

八、服务熔断：Hystrix、Sentinel

什么是 Hystrix？

在分布式环境中，不可避免地会遇到所依赖的服务挂掉的情况，Hystrix 可以通过增加 延迟容忍度 与 错误容忍度，来控制这些分布式系统的交互。Hystrix 在服务与服务之间建立了一个中间层，防止服务之间出现故障，并提供了失败时的 fallback 策略，来增加你系统的整体可靠性和弹性。

Hystrix 做了那些事情？

1. 引入第三方的 client 类库，通过延迟与失败的检测，来保护服务与服务之间的调用（网络间调用最为典型）
2. 阻止复杂的分布式系统中出现级联故障
3. 快速失败与快速恢复机制
4. 提供兜底方案（fallback）并在适当的时机优雅降级
5. 提供实时监控、报警与操作控制

Hystrix能干嘛？

1. 服务降级
2. 服务熔断
3. 服务限流
4. 接近实时的监控

Sentinel 具有以下特征:

1.丰富的应用场景： Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、实时熔断下游不可用应用等。

2.完备的实时监控： Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。

3.广泛的开源生态： Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。

4.完善的 SPI 扩展点： Sentinel 提供简单易用、完善的 SPI 扩展点。您可以通过实现扩展点，快速的定制逻辑。例如定制规则管理、适配数据源等。

官网：https://github.com/alibaba/spring-cloud-alibaba/wiki/Sentinel

九、链路追踪：Spring Cloud Sleuth + zipkin

微服务架构是一个分布式架构，它按业务划分服务单元，一个分布式系统往往有很多个服务单元。由于服务单元数量众多，业务的复杂性，如果出现了错误和异常，很难去定位。主要体现在，一个请求可能需要调用很多个服务，而内部服务的调用复杂性，决定了问题难以定位。所以微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与，参与的顺序又是怎样的，从而达到每个请求的步骤清晰可见，出了问题，很快定位。

举几个例子：

  1.在微服务系统中，一个来自用户的请求，请求先达到前端A（如前端界面），然后通过远程调用，达到系统的中间件B、C（如负载均衡、网关等），最后达到后端服务D、E，后端经过一系列的业务逻辑计算最后将数据返回给用户。对于这样一个请求，经历了这么多个服务，怎么样将它的请求过程的数据记录下来呢？这就需要用到服务链路追踪。

  2.分析微服务系统在大压力下的可用性和性能。

Zipkin可以结合压力测试工具一起使用，分析系统在大压力下的可用性和性能。

Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了 zipkin，你只需要在pom文件中引入相应的依赖即可。

Sleuth与Zipkin关系

spring cloud提供了spring-cloud-sleuth-zipkin来方便集成zipkin实现（指的是Zipkin Client，而不是Zipkin服务器），该jar包可以通过spring-cloud-starter-zipkin依赖来引入。

Zipkin

1.Zipkin是什么

Zipkin分布式跟踪系统；它可以帮助收集时间数据，解决在microservice架构下的延迟问题；它管理这些数据的收集和查找；Zipkin的设计是基于谷歌的Google Dapper论文。

每个应用程序向Zipkin报告定时数据，Zipkin UI呈现了一个依赖图表来展示多少跟踪请求经过了每个应用程序；如果想解决延迟问题，可以过滤或者排序所有的跟踪请求，并且可以查看每个跟踪请求占总跟踪时间的百分比。

2.为什么使用Zipkin

随着业务越来越复杂，系统也随之进行各种拆分，特别是随着微服务架构和容器技术的兴起，看似简单的一个应用，后台可能有几十个甚至几百个服务在支撑；一个前端的请求可能需要多次的服务调用最后才能完成；当请求变慢或者不可用时，我们无法得知是哪个后台服务引起的，这时就需要解决如何快速定位服务故障点，Zipkin分布式跟踪系统就能很好的解决这样的问题。

3.Zipkin原理

针对服务化应用全链路追踪的问题，Google发表了Dapper论文，介绍了他们如何进行服务追踪分析。其基本思路是在服务调用的请求和响应中加入ID，标明上下游请求的关系。利用这些信息，可以可视化地分析服务调用链路和服务间的依赖关系。

对应Dpper的开源实现是Zipkin，支持多种语言包括JavaScript，Python，Java, Scala, Ruby, C#, Go等。其中Java由多种不同的库来支持

Spring Cloud Sleuth是对Zipkin的一个封装，对于Span、Trace等信息的生成、接入HTTP Request，以及向Zipkin Server发送采集信息等全部自动完成。Spring Cloud Sleuth的概念图见上图。