SpringCloud与SpringCloudAlibaba的比较

一. SpringCloud组件的升级与替换

过去两年里,由于SpringCloud Netflix原先的一些组件进入停更维护状态，因此这些组件逐渐被一些新技术所替代

项目	替换前	替换后
服务注册中心	Eureka	Zookeeper、Consul、Nacos（推荐）
配置中心	Config	Nacos
服务总线	Bus	Nacos
负载均衡	Ribbon	LoadBalancer
服务调用	Feign	OpenFeign、Dubbo
服务网关	Zuul	gateway
服务降级	Hystrix	Sentinel

二. 服务注册中心的比较

根据CAP理论对注册中心进行分类：

• 保证CP（注重一致性）：Zookeeper、Consul
• 保证AP（注重可用性）：Eureka
• 既支持CP又支持AP：Nacos

Zookeeper通过Zab协议保证强一致性：

• 所有的写请求必须经过leader节点传递给其他follower节点。
• 但是当leader节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证高可用性：

• Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用，只不过查到的信息可能不是最新的(不保证强一致性)。
• 此外，Eureka还有自我保护机制：如果在15分钟内超过85%的节点都没有正常的心跳（短时间内丢失过多客户端），那么Eureka就认为客户端与注册中心出现了网络故障（如不是服务真的不可用了），此时会开启自我保护机制：

1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中

因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

Nacos既支持AP模式又支持CP模式：

• AP模式：不需要存储服务级别信息且服务实例是通过nacos-clinet注册，且能够保持心跳上报，可采用AP模式。如SpringCloud服务。AP模式下只支持注册临时实例
• CP模式：如需要在服务级别编辑或存储配置信息，则需使用CP模式，如K8S,DNS。AP模式下只支持注册持久化实例。

三. 服务调用框架的比较

Ribbon:

• Ribbon是一套客户端负载均衡的工具，使用时需与RestTemplate配合使用
• 使用是需要模拟http请求然后使用RestTemplate发送给其他服务，步骤比较繁琐。
• 负载均衡：支持轮询、随机、空闲策略、响应时间策略

OpenFeign

• 同样使用HTTP协议进行通讯
• 使用时只需创建一个接口并使用注解（@FeignClient)的方式配置， 即可完成对服务提供方的接口绑定，是对Ribbon+RestTemplate的进一步封装
• OpenFeign内部集成了 Ribbon，本质上是通过Ribbon完成负载均衡功能

Dubbo

• 支持多种传输协议：Dubbo、Rmi、http、redis。适合数据量小、高并发和服务提供者远远少于消费者的场景
• 负载均衡：支持随机、轮询、活跃度、Hash一致性，负载均衡的算法可以精准到某个服务接口的某个方法。

四. 服务降级框架的比较

1. 关于服务降级的概念

• 服务雪崩：多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的”雪崩效应”.
• 服务熔断：熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回"错误的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。如Hystrix默认发现5秒内20次调用失败就会启动熔断机制。
• 服务降级：某个服务故障后，向调用方返回一个符合预期的、可处理的备选响应（Fallback)。发生降级的场景：程序运行异常、服务调用超时、服务熔断、线程池/信号量被打满
• 服务限流：限制服务的请求速率

2. Hystrix和Sentinel的比较

• Hystrix本身就是一个非常出色的熔断降级框架，Sentinel则是在Hystrix的基础上对其进行进一步的升级
• Sentinel使用更方便：Sentinel提供了一个非常简洁的控制台界面，在控制台界面中即可非常方便地配置限流降级规则
• Sentinel功能更丰富：Sentinel除了降级和熔断功能外，还可以配置限流规则、热点规则、系统规则，且规则的配置项更多更精确，使用更加灵活
  

参考文章：https://blog.csdn.net/qq_41889508/article/details/89526874?utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control&dist_request_id=1619604578378_82005&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control