SpringCloud、Dubbo 和 Istio 微服务框架

原文地址：https://segmentfault.com/a/1190000010953144

微服务框架潮流，当前该如何选择 SpringCloud、Dubbo or Istio？

在 Kubernetes 容器云平台于众多企业里遍地实施开花后，迅速结出的果实：应用微服务化当仁不让的居于首位。众所周知，基于容器平台构建后端服务，可以更加迅速的实现业务微服务化，与之而来的框架选型讨论也迅速火热了起来。

微服务框架选型之争

选项其实很多，这里挑选一些讨论火热、或者主流的来对比，仅供参阅。

• 主流微服务框架：SpringCloud、Dubbo
• 新锐微服务框架：Istio

1、框架背景对比

（1）Spring Cloud，来源于 Spring Source ，具有 Spring 社区的强大背书外，还有 Netflix 强大的后盾与技术输出。Netflix 作为一家成功实践微服务架构的互联网公司，在几年前就把几乎整个微服务框架栈开源贡献给了社区，这些框架开源的整套微服务架构套件是 Spring Cloud 的核心。

• Eureka:　服务注册发现框架；
• Zuul:　服务网关；
• Karyon:　服务端框架；
• Ribbon:　客户端框架；
• Hystrix: 服务容错组件；
• Archaius: 服务配置组件；
• Servo: Metrics组件；
• Blitz4j: 日志组件。

（2）Dubbo 是一个分布式服务框架，是国内互联网公司开源做的比较不错的阿里开放的微服务化治理框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。 其核心部分包含（官网）:

• 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式；
• 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持；
• 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

Dubbo 也是采用全 Spring 配置方式，透明化接入应用，对应用没有任何 API 侵入，只需用 Spring 加载 Dubbo的配置即可，Dubbo 基于 Spring 的 Schema 扩展进行加载。当然也支持官方不推荐的 API 调用方式。

（3）Istio 作为用于微服务服务聚合层管理的新锐项目，是 Google、IBM、Lyft（海外共享出行公司、Uber劲敌） 首个共同联合开源的项目，提供了统一的连接，安全，管理和监控微服务的方案。

目前首个测试版是针对 Kubernetes 环境的，社区宣称在未来几个月内会为虚拟机和 Cloud Foundry 等其他环境增加支持。 Istio 将流量管理添加到微服务中，并为增值功能（如安全性，监控，路由，连接管理和策略）创造了基础。

• HTTP、gRPC 和 TCP 网络流量的自动负载均衡；
• 提供了丰富的路由规则，实现细粒度的网络流量行为控制；
• 流量加密、服务间认证，以及强身份声明；
• 全范围（Fleet-wide）的策略执行；
• 深度遥测和报告。

2、开源社区活跃度对比

开源社区情况：现如今企业在采用云计算首选开源，而选择一个开源框架，社区的活跃度将作为重要参考选项。

查看下在 Github 上的更新时间，截止 2017 年 8 月 31 日：

• Spring Cloud ：Spring Cloud · GitHub → 所有项目均更新于『1 小时』内。
• Dubbo ：Dubbo · GitHub → 核心项目最近更新于『一个月乃至数月』前。
• Istio：Istio · GitHub → 所有项目均更新于『30 分钟』内。

可见，项目在社区活跃度上，Istio > Spring Cloud > Dubbo，结合稳定性来看，对于使用 Java 系开发业务较多的企业，Spring Cloud 是相对更优的选择，对于更多企业来说，与语言几乎无绑定的 Istio 也是可以好好期待一下其在社区的发展。

总结：结合项目背景、提供功能、社区更新活跃度，SpringCloud 是目前阶段最为稳妥的可执行微服务框架方案，Istio 作为支持对于 Kubernetes 的优先支持来讲，也是一个值得关注的方案。目前对比来看，Dubbo 则显得稍逊下来。