文章目录
- 技术选型考虑
- 为什么考虑SpringCloudAlibaba
- SpringCloudAlibaba和SpringCloud的区别及技术最终选型
开源微服务技术选型功能技术对比
SpringCloud | Dubbo | Motan | MSEC | |
功能 | 微服务完整方案 | 服务治理框架 | 服务治理框架 | 服务治理框架 |
通信方式 | Rest/Http | RPC | RPC/Hessian2 | Protocol buffer |
服务发现 | Eureka（AP）/Conusl/ZK | Nacos、ZK | ZK/Conusl | 只有服务发现 |
负载均衡 | Ribbon | 客户端负载 | 客户端负载 | 客户端负载 |
容错策略 | 6种容错策略 | 6种容错策略 | 2种容错策略 | 自动容错 |
熔断机制 | Hystrix | Sentinel | 无 | 提供过载保护 |
配置中心 | Spring Cloud Config | Nacos | 无 | 无 |
网关 | Zuul、Gateway | 无 | 无 | 无 |
服务监控 | Hystrix+Turbine | Dubbo+Monitor | 无 | Monitor |
链路监控 | Sleuth+Zipkin | 无 | 无 | 无 |
多语言 | Rest支持多语言 | Java | Java | Java、C++、PHP |
社区 | 高（背靠Spring） | 高（背靠阿里） | 一般 | 未知 |
技术选型考虑
技术选型时，对于中小型公司而言，使用 SpringCloud 会极大的减少开发成本，只需了解原理以及如何使用，就能进行开发。但是对于大型公司而言，更倾向使用Dubbo，比较灵活，可以很方便的拓展自主研发一些组件，虽然人力成本会增加，但是能全面的把控技术风险。
为什么考虑SpringCloudAlibaba
我们这里为什么选择SpringCloudAlibaba呢，主要因为SpringCloud的组件：服务注册与发现的 Eureka、服务限流降级的 Hystrix、网关 Zuul都已经停止更新了。当然，Spring这个我们Java界的老大哥也迅速给出了新的一套组件解决方案，如果想用还是可以继续用的，也只不过是权衡取舍的问题了，两套组件用哪一套更好？
SpringCloudAlibaba和SpringCloud的区别及技术最终选型
SpringCloudAlibaba实际上是对我们的SpringCloud组件增强功能，是SpringCloud的增强框架，可以兼容SpringCloud原生组件和SpringCloudAlibaba的组件。当然如果用了SpingCloudAlibaba还是建议使用阿里提供的这些组件的。
我在进行技术预研时对SpringCloud和SpringCloudAlibaba两套组件都一一进行了实验，最终还是选择了SpringCloudAlibaba，无论是开发架构的简单、方便程度还是技术社区的活跃度，还有就是它提供的一整套完整的解决方案生态：分布式事务、分布式任务调度、消息队列RocketMQ等等阿里系的一些组件还是挺完善强大的。
经过一系列的对比，最终选择的技术框架体系，基础的技术架构如图：
使用统一的微服务框架有一个比较严重的问题：框架更新成本很高。每次框架升级，都需要所有应用服务配合升级。当然，一般会使用兼容方案，留出一段并行时间等待所有应用服务升级。但是如果应用服务非常多时，升级时间可能会非常漫长。并且有一些很稳定几乎不更新的应用服务，其负责人可能会拒绝升级……因此，使用统一微服务框架需要完善的版本管理方法和开发管理规范。
