一篇文章掌握SpringCloud与SpringCloud Alibaba的区别
目录
一、SpringCloud组件的升级与替换
二、服务注册中心的比较
1、根据CAP理论对注册中心进行分类
2、Zookeeper通过Zab协议保证强一致性
3、Eureka保证高可用性
4、Nacos既支持AP模式又支持CP模式
三、服务调用框架的比较
1、Ribbon
2、OpenFeign
3、Dubbo
四、服务降级框架的比较
Hystrix和Sentinel的比较
一、SpringCloud组件的升级与替换
由于SpringCloud Netflix原先的一些组件进入停更维护状态，因此这些组件逐渐被SpringCloud Alibaba一些新技术所替代。
SpringCloud Alibaba，实际上对我们的SpringCloud2.x和1.x实现拓展组件功能。
1.Nacos=分布式配置中心+分布式注册中心=Eureka+Config。
2.目的是为了推广阿里的产品，如果使用了SpringCloud Alibaba，最好使用alibaba整个体系产品。
| 序号 | 组件 | SpringCloud | SpringCloud Alibaba |
|---|---|---|---|
| 1 | 服务注册中心 | Eureka | Zookeeper、Consul、Nacos（推荐） |
| 2 | 配置中心 | Config | Nacos |
| 3 | 服务总线（消息总线） | Bus | Nacos |
| 4 | 负载均衡 | Ribbon | LoadBalancer |
| 5 | 服务调用 | Feign | OpenFeign、Dubbo |
| 6 | 服务网关 | Zuul | Gateway |
| 7 | 服务降级（熔断降级） | Hystrix | Sentinel（流量控制、熔断降级、系统负载保护） |
| 8 | 服务跟踪（链路追踪） | Sleuth&Zipkin | SkyWalking |
| 9 | 分布式事务 | 无(第三方替代方案：2pc) | Seata |
| 10 | 分布式任务调度 | 无(第三方替代方案：xxl-job) | SchedulerX |
| 11 | 消息中间件 | 无(第三方替代方案：RabbitMQ) | RocketMQ |
| 12 | 批量任务 | Spring Cloud Task | Spring Cloud Task |
| 13 | 数据流 | Stream | 无 |
| 14 | 服务安全 | Security或(第三方替代方案：Shiro) | Security |
二、服务注册中心的比较
1、根据CAP理论对注册中心进行分类
-
保证CP（注重一致性）：Zookeeper、Consul
-
保证AP（注重可用性）：Eureka
-
既支持CP又支持AP：Nacos
2、Zookeeper通过Zab协议保证强一致性
因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像Zookeeper那
样使整个注册服务瘫痪。
-
所有的写请求必须经过leader节点传递给其他follower节点。
-
但是当leader节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。
-
3、Eureka保证高可用性
-
Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用，只不过查到的信息可能不是最新的(不保证强一致性)。
-
此外，Eureka还有自我保护机制：如果在15分钟内超过85%的节点都没有正常的心跳（短时间内丢失过多客户端），那么Eureka就认为客户端与注册中心出现了网络故障（如不是服务真的不可用了），此时会开启自我保护机制：
-
Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
-
Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)。
-
当网络稳定时，当前实例新的注册信息会被同步到其它节点中。
因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像Zookeeper那样使整个注册服务瘫痪。
4、Nacos既支持AP模式又支持CP模式
-
AP模式：不需要存储服务级别信息且服务实例是通过nacos-clinet注册，且能够保持心跳上报，可采用AP模式。如SpringCloud服务。AP模式下只支持注册临时实例。
-
CP模式：如需要在服务级别编辑或存储配置信息，则需使用CP模式，如K8S,DNS。AP模式下只支持注册持久化实例。
三、服务调用框架的比较
1、Ribbon
-
Ribbon是一套客户端负载均衡的工具，使用时需与RestTemplate配合使用。
-
使用是需要模拟http请求然后使用RestTemplate发送给其他服务，步骤比较繁琐。
-
负载均衡：支持轮询、随机、空闲策略、响应时间策略。
2、OpenFeign
-
同样使用HTTP协议进行通讯。
-
使用时只需创建一个接口并使用注解（@FeignClient)的方式配置， 即可完成对服务提供方的接口绑定，是对Ribbon+RestTemplate的进一步封装。
-
OpenFeign内部集成了 Ribbon，本质上是通过Ribbon完成负载均衡功能。
3、Dubbo
-
支持多种传输协议：Dubbo、Rmi、http、redis。适合数据量小、高并发和服务提供者远远少于消费者的场景。
-
负载均衡：支持随机、轮询、活跃度、Hash一致性，负载均衡的算法可以精准到某个服务接口的某个方法。
四、服务降级框架的比较
Hystrix和Sentinel的比较
-
Hystrix本身就是一个非常出色的熔断降级框架，Sentinel则是在Hystrix的基础上对其进行进一步的升级。
-
Sentinel使用更方便：Sentinel提供了一个非常简洁的控制台界面，在控制台界面中即可非常方便地配置限流降级规则。
-
-
-
-
-
-
-
-
