关于spring-cloud:开源微服务如何选型Spring-CloudDubbogRPCIstio-详细对比

1次阅读

共计 4301 个字符，预计需要花费 11 分钟才能阅读完成。

不管您是一名开发者、架构师、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 都齐全兼容 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 最大的差别在于两者的定位上：

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

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 等管制面组件实现对数据面服务的治理。

模式，Dubbo 与 Envoy 一起部署，Dubbo 作为编程框架 & 协定通信组件存在，流量管控由 Envoy 与 Istio 管制面交互实现。
Proxyless 模式，Dubbo 过程放弃独立部署，Dubbo 通过规范 xDS 协定间接接入 Istio 等管制面组件。

从管制面视角，Dubbo 可接入原生 Istio 规范管制面和规定体系，而对于一些 Dubbo 老版本用户，接下来社区会联结企业用户独特推出社区版本平滑迁徙计划。

这篇文章以 Dubbo 为出发点，向咱们具体介绍了 Spring Cloud、Dubbo、gRPC、Istio 等几个框架产品以及它们各自的劣势与差别，置信对咱们微服务技术选型能带来肯定的帮忙。但正如咱们开篇提到的，本文是从 Apache Dubbo 摘录的一些外围要点，因而整篇文章是以 Dubbo 为根底开展的，文章中有局部内容突出了 Apache Dubbo 我的项目的劣势。后续咱们将陆续以更多的不同维度开展，为大家带来更多维度的产品比照与领导。

作者：刘军