开源微服务如何选型？Spring Cloud、Dubbo、gRPC、Istio 详细对比

作者：刘军

不论您是一名开发者、架构师、CTO，如果您曾深度参与在微服务开发中，那么相信您一定有过开源微服务框架或体系选型的疑问：Apache Dubbo、Spring Cloud、gRPC 以及 Service Mesh 体系产品如 Istio，到底应该选型哪一个？这篇文章对这几个框架进行了详细的说明，并在选型方面给了一定的指导意见，相信能给微服务开发者带来一定的帮助。

需要注意的是，这篇文章的作者有深度 Apache Dubbo 社区参与经验，因此整篇文章是以 Dubbo 为基础展开的，通过将 Dubbo 与其他组件之间的联系与差异客观、透明的展现出来，来向读者呈现几款开源产品的优势和适用场景。整篇文章中有部分内容突出了 Apache Dubbo 项目的优势，请大家在阅读过程中保持对这点的认识，但它总体上并不影响我们从总体上了解每个产品并获得具有价值的选型指导。

Dubbo 与 Spring Cloud

从上图我们可以看出，Dubbo 和 Spring Cloud 有很多相似之处，它们都在整个架构图的相同位置并提供一些相似的功能。

Dubbo 和 Spring Cloud 都侧重在对分布式系统中常见问题模式的抽象（如服务发现、负载均衡、动态配置等）， 同时对每一个问题都提供了配套组件实现，形成了一套微服务整体解决方案，让使用 Dubbo 及 Spring Cloud 的用户在开发微服务应用时可以专注在业务逻辑开发上。
Dubbo 和 Spring Cloud 都完全兼容 Spring 体系的应用开发模式， Dubbo 对 Spring 应用开发框架、Spring Boot 微服务框架都做了很好的适配，由于 Spring Cloud 出自 Spring 体系，在这一点上自然更不必多说。

虽然两者有很多相似之处，但由于它们在诞生背景与架构设计上的巨大差异，两者在性能、适用的微服务集群规模、生产稳定性保障、服务治理等方面都有很大差异。

Spring Cloud 的优势在于：

同样都支持 Spring 开发体系的情况下，Spring Cloud 得到更多的原生支持。
对一些常用的微服务模式做了抽象如服务发现、动态配置、异步消息等，同时包括一些批处理任务、定时任务、持久化数据访问等领域也有涉猎。
基于 HTTP+JSON 的通信模式，对于开发、测试、上下游体系接入等更友好，成本更低。
Spring Cloud 官方具有相对完善的入门文档和演示 demo 和 starters，包括书籍资料等，让开发者上更易于上手。

Spring Cloud 的问题有：

只提供抽象模式的定义不提供官方稳定实现，开发者只能寻求类似 Netflix、Alibaba、Azure 等不同厂商的实现套件，而每个厂商支持的完善度、稳定性、活跃度各异。
有微服务全家桶却不是能拿来就用的全家桶，demo 上手容易，但落地推广与长期使用的成本并不低。
欠缺服务治理能力，尤其是流量管控方面如负载均衡、流量路由方面能力都比较弱。
编程模型与通信协议绑定 HTTP，在性能、与其他 RPC 体系互通上存在障碍。
总体架构与实现更适用于小规模微服务集群实践，当集群规模增长后就会遇到地址推送效率、内存占用等各种瓶颈的问题，但此时迁移到其他体系却很难实现。
微服务实践场景的高阶问题需要用户自行解决，比如优雅停机、启动预热、服务测试，再比如双注册、双订阅、延迟注册、服务按分组隔离、集群容错等。

而针对以上这些点，都是 Dubbo 的优势所在：

完全支持 Spring & Spring Boot 开发模式，同时在服务发现、动态配置等基础模式上提供与 Spring Cloud 对等的能力。
是企业级微服务实践方案的整体输出，Dubbo 考虑到了企业微服务实践中会遇到的各种问题如优雅上下线、多注册中心、流量管理、异常实例隔离等，因此其在生产环境的长期维护成本更低。
在通信协议和编码上选择更灵活，包括 RPC 通信层协议如 Triple(gRPC、HTTP/1 兼容)、TCP 二进制协议、REST等，序列化编码协议 Protobuf、JSON、Hessian2 等，支持单端口多协议。
Dubbo 从设计上突出服务服务治理能力，如权重动态调整、标签路由、条件路由等，支持 Sidecar、Proxyless 等多种模式接入 Service Mesh 体系。
高性能的 RPC 协议编码与实现。
Dubbo 是在超大规模微服务集群实践场景下开发的框架，可以做到百万实例规模的集群水平扩容，应对集群增长带来的各种问题。
Dubbo 提供 Java 外的多语言实现，使得构建 Java、Go、Node.js、Rust、Web 等多语言异构的微服务体系成为可能。

如果您的目标是构建企业级应用，并期待在未来的持久维护中能够更省心、更稳定，我们建议你能更深入的了解 Dubbo 的使用和其提供的能力。

Dubbo 与 gRPC

关于这两款开源产品之间的差异，我们可以从产品定位和协议对比两个方面来展开：

产品定位上的区别

Dubbo 与 gRPC 最大的差异在于两者的定位上：

gRPC 定位为一款 RPC 框架，Google 推出它的核心目标是定义云原生时代的 rpc 通信规范与标准实现；
Dubbo 定位是一款微服务开发框架，它侧重解决微服务实践从服务定义、开发、通信到治理的问题，因此 Dubbo 同时提供了 RPC 通信、与应用开发框架的适配、服务治理等能力。

Dubbo 不绑定特定的通信协议，即 Dubbo 服务间可通过多种 RPC 协议通信并支持灵活切换。因此，你可以在 Dubbo 开发的微服务中选用 gRPC 通信，Dubbo 通过 Triple 协议可以做到完全兼容 gRPC，并将 gRPC 通信协议为内置原生支持的协议之一。

协议上的区别

Triple 协议是 Dubbo3 设计的基于 HTTP 的 RPC 通信协议规范，它完全兼容 gRPC 协议，支持 Request-Response、Streaming 流式等通信模型，可同时运行在 HTTP/1 和 HTTP/2 之上。

Dubbo 框架提供了 Triple 协议的多种语言实现，它们可以帮助你构建浏览器、gRPC 兼容的 HTTP API 接口：你只需要定义一个标准的 Protocol Buffer 格式的服务并实现业务逻辑，Dubbo 负责帮助生成语言相关的 Server Stub、Client Stub，并将整个调用流程无缝接入如路由、服务发现等 Dubbo 体系。Go、Java 等语言的 Triple 协议实现原生支持 HTTP/1 传输层通信，相比于 gRPC 官方实现，Dubbo 框架提供的协议实现更简单、更稳定，帮助你更容易的开发和治理微服务应用。

针对某些语言版本，Dubbo 框架还提供了更贴合语言特性的编程模式，即不绑定 IDL 的服务定义与开发模式，比如在 Dubbo Java 中，你可以选择使用 Java Interface 和 Pojo 类定义 Dubbo 服务，并将其发布为基于 Triple 协议通信的微服务。

上面提到 Triple 完全兼容 gRPC 协议，那既然 gRPC 官方已经提供了多语言的框架实现，为什么 Dubbo 还要通过 Triple 重新实现一遍那？核心目标主要有以下两点：

首先，在协议设计上，Dubbo 参考 gRPC 与 gRPC-Web 两个协议设计了自定义的 Triple 协议：Triple 是一个基于 HTTP 传输层协议的 RPC 协议，它完全兼容 gRPC 的同时可运行在 HTTP/1、HTTP/2 之上。
其次，Dubbo 框架在每个语言的实现过程中遵循了符合框架自身定位的设计理念，相比于 grpc-java、grpc-go 等框架库，Dubbo 协议实现更简单、更纯粹，尝试在实现上规避 gRPC 官方库中存在的一系列问题。

使用 Dubbo 框架并开启 Triple 协议，可以底层兼容 gRPC 协议的微服务，开发者基于 Dubbo 提供的 API 和配置开发服务，并基于 dubbo 的服务治理能力治理服务。同时相比于原生 gRPC 协议，Triple 协议通过支持 cURL、浏览器的直接访问让调试、前端接入更简单。

curl \
    --header "Content-Type: application/json" \
    --data '{"sentence": "Hello Dubbo."}' \
    https://host:port/org.apache.dubbo.sample.GreetService/sayHello

Dubbo 与 Istio

Service Mesh 服务网格是近年来在云原生背景下诞生的一种微服务架构，在 Kubernetes 体系下，服务网格让微服务开发中的更多能力如流量拦截、服务治理等下沉并成为基础设施，让微服务开发、升级更轻量。Istio 是 Service Mesh 的开源代表实现，它从部署架构上分为数据面与控制面，从这一点本质上与 Dubbo 总体架构是基本一致的，Istio 带来的主要变化在于：

数据面，Istio 通过引入 Sidecar 实现了对服务流量的透明拦截，Sidecar 通常是与 Dubbo 等开发的传统微服务组件部署在一起。
控制面，将之前抽象的服务治理中心聚合为一个具有统一实现的具体组件，并实现了与底层基础设施如 Kubernetes 无缝适配。

Dubbo 已经实现了对 Istio 体系的全面接入，可以用 Istio 控制面治理 Dubbo 服务，而在数据面部署架构上，针对 Sidecar 引入的复杂性与性能问题，Dubbo 还支持无代理的 Proxyless 模式。除此之外，Dubbo Mesh 体系还解决了 Istio 架构落地过程中的很多问题，包括提供更灵活的数据面部署架构、更低的迁移成本等。

从数据面的视角，Dubbo 支持如下两种开发和部署模式，可以通过 Istio 等控制面组件实现对数据面服务的治理。

Proxy 模式，Dubbo 与 Envoy 一起部署，Dubbo 作为编程框架 & 协议通信组件存在，流量管控由 Envoy 与 Istio 控制面交互实现。
Proxyless 模式，Dubbo 进程保持独立部署，Dubbo 通过标准 xDS 协议直接接入 Istio 等控制面组件。

从控制面视角，Dubbo 可接入原生 Istio 标准控制面和规则体系，而对于一些 Dubbo 老版本用户，接下来社区会联合企业用户共同推出社区版本平滑迁移方案。

总结

这篇文章以 Dubbo 为出发点，向我们详细介绍了 Spring Cloud、Dubbo、gRPC、Istio 等几个框架产品以及它们各自的优势与差异，相信对我们微服务技术选型能带来一定的帮助。但正如我们开篇提到的，本文是从 Apache Dubbo 摘录的一些核心要点，因此整篇文章是以 Dubbo 为基础展开的，文章中有部分内容突出了 Apache Dubbo 项目的优势。后续我们将陆续以更多的不同维度展开，为大家带来更多维度的产品对比与指导。