SpringCloud - SpringCloud Netflix v.s Dubbo v.s SpringCloud Alibaba
一、SpringCloud Netflix v.s Dubbo
1.1 微服务核心架构要素PK
结论：Spring Cloud Netflix更胜一筹，在开发过程中只要整合Spring Cloud的子项目就可以顺利的完成各种组件的融合，而Dubbo缺少很多组件，需要借用第三方或者自己定制。
Dubbo只是实现了服务治理，而Spring Cloud子项目分别覆盖了微服务架构下的众多部件，而服务治理只是其中的一个方面。Dubbo提供了各种Filter，对于下述中“无”的要素，可以通过扩展Filter来完善。
从核心要素来看，Spring Cloud 更胜一筹，在开发过程中只要整合Spring Cloud的子项目就可以顺利的完成各种组件的融合，而Dubbo缺需要通过实现各种Filter来做定制，开发成本以及技术难度略高。
1.2 通讯协议PK
结论：Dubbo使用RPC通讯协议，Spring Cloud 使用HTTP协议的REST API。dubbo通信速度上略胜Spring Cloud。
性能比较
使用一个Pojo对象包含10个属性，请求10万次，Dubbo和Spring Cloud在不同的线程数量下，每次请求耗时（ms）如下：
点评：dubbo支持各种通信协议，而且消费方和服务方使用长链接方式交互，dubbo通信速度上略胜Spring Cloud，如果对于系统的响应时间有严格要求，长链接更合适。
说明：客户端和服务端配置均采用阿里云的ECS服务器，4核8G配置，dubbo采用默认的dubbo协议
1.3 服务调用方式/依赖方式PK
结论：
Dubbo的服务消费方，和服务提供方之间，有抽象接口的强依赖关系，但程序入侵少。
而SpringCloud Netflix的消费方和提供方之间通过Json方式交互，无接口依赖。从解耦方面来看，Springcloud更占优势，为跨平台调用奠定了基础。
Dubbo的服务调用方式
代码示例
“消费者module”想RPC“提供者module”里TickerServiceImpl的方法，需要在“消费者module”定义路径相同的接口名，然后辅以@Reference注解，就能拿到。
SpringCloud的服务调用方式
代码示例
完全不需要像RPC一样添加同路径名的接口，只要知道所求方法的请求路径和返回值，就能直接通过RestTemplate来访问。消费者 和 提供者 完全解耦！！！
二、SpringCloud Netflix v.s SpringCloud Alibaba
2.1 结论
Springcloud Netflix的部分项目停止开源，大部分项目进入了维护模式（停止更新），停更不停用的状态。
Springcloud Alibaba保持开源，正逐渐成为主流；并且搭配了完善的可视化界面，对国内用户的体验较为友好。
推荐使用Springcloud Alibaba
2.2 微服务核心架构要素PK
| SpringCloud Netflix | SpringCloud Alibaba | |
| API网关 | Zuul（停更） | 无 |
| HTTP,RPC框架 | Feign + Ribbon | Dubbo |
| 服务注册/发现 | Eureka（停更） | Nacos |
| 熔断降级 | Hystrix（停更） | Sentinel |
| 负载均衡(服务端) | Ribbon（停更） | |
| 声明式HTTP客户端 | Feign（停更） | |
| 配置中心 | Nacos | |
| 调用链监控 | ||
| 分布式事务 | 无 | Seata |
| 消息中间件 | 无 | RocketMQ |
2.3 为何抛弃 SpringCloud Netflix
Spring Cloud Netflix 的部分项目停止开源，大部分项目进入了维护模式（停止更新）。进入维护模式意味着什么呢？
- 进入维护模式意味着Spring Cloud Netflix 将不再开发新的组件了。我们都知道Spring Cloud 版本迭代算是比较快的，因而出现了很多重大ISSUE都还来不及Fix就又推另一个Release了。进入维护模式意思就是目前一直以后一段时间Spring Cloud Netflix提供的服务和功能就这么多了，不在开发新的组件和功能了。以后将以维护和Merge分支Full Request为主。
- 新组件功能将以其他替代平代替的方式实现
SpringCloud的Hoxton版本，和之前的版本相比，用新的组件替换掉了原来大部分的组件，老的组件现在处于 停更不停用 的状况。
详情见下图（× 的表示之前的组件，现在停更了的；√ 的表示新的替换后的组件）：
服务注册中心：
Eureka：官方停止更新，并且已经有更好的替代产品了，可以使用，但是官方已经不建议使用了（重度患者）。
Zookeeper：某些老系统，以前是用的Zookeeper + Dubbo，后来做技术升级，结果发现SpringCloud的Eureka停更了，然后就用了最少的技术切换，那么就用了Zookeeper做注册中心。
Consul：go语言开发的，也是一个优秀的服务注册框架，但是使用量较少，风头都被Nacos抢了。
Nacos：来自于SpringCloudAlibaba，在企业中经过了百万级注册考验的，不但可以完美替换Eureka，还能做其他组件的替换，所以强烈建议使用，是学习的重点。
服务调用：
Ribbon：也进入了维护状态，停止更新了，但是Spring官方还在使用（轻度患者）。
LoadBalancer：Spring官方推出的一个新的组件，打算逐渐取代掉Ribbon，但是现在还处于萌芽状态。
服务调用2：
Feign：Netflix 公司产品，也停止更新了。
OpenFeign：Spring社区等不了Netflix更新了，然后就自己做了一个组件，不用Feign了。
服务降级：
Hystrix：官网不推荐使用，但是中国企业中还在大规模使用。
Resilience4J：官网推荐使用，但是国内很少用这个。
Sentienl：来自于SpringCloudAlibaba，在中国企业替换Hystrix的组件，国内强烈建议使用。
服务网关：
Zuul：Netflix 公司产品，公司内部产生分歧，有的人想自己出一个Zuul2。
Zuul2：也是Netflix 公司准备出的产品，但是由于内部分歧，所以Zuul2已经胎死腹中了。
gateway：Spring社区自己出的网关组件，官方隆重介绍和极度推荐的网关服务组件。
服务配置：
Config：目前也在使用，风头被Nacos抢了。
Nacos：来自于SpringCloudAlibaba，后来居上，把Config给替换了。
服务总线：
Bus：SpringCloud原生的服务总线组件，现在风头也被Nacos抢了。
Nacos：来自于SpringCloudAlibaba，后来居上，把Bus给替换了。
综上可以看出，Nacos 是重中之重，一个组件就替换掉了原来的几个组件。
2.4 为何选择 SpringCloud Alibaba
参考文献
Spring Cloud Netflix项目进入维护模式 https://blog.csdn.net/u012437781/article/details/85258505
SpringCloud组件的停更和替换说明 https://www.cnblogs.com/y3blogs/p/13276504.html
