华山论剑：微服务框架-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则显得稍逊下来。