一篇文章掌握SpringCloud与SpringCloud Alibaba的区别

由于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

因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像Zookeeper那

样使整个注册服务瘫痪。

所有的写请求必须经过leader节点传递给其他follower节点。
但是当leader节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。
3、Eureka保证高可用性
Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用，只不过查到的信息可能不是最新的(不保证强一致性)。
此外，Eureka还有自我保护机制：如果在15分钟内超过85%的节点都没有正常的心跳（短时间内丢失过多客户端），那么Eureka就认为客户端与注册中心出现了网络故障（如不是服务真的不可用了），此时会开启自我保护机制：
Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)。
当网络稳定时，当前实例新的注册信息会被同步到其它节点中。

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

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