Dubbo to Mesh 云原生架构改造方案解析

作者 | 腾讯云泛互云原生团队

责编 | 屠敏

头图 | CSDN 下载自东方 IC

出品 | CSDN（ID：CSDNnews）

Dubbo 是一款高性能的 Java RPC 框架，它除了拥有卓越的 RPC 能力，也同时具有微服务的一些治理能力，如：注册发现，负载均衡等，目前 Dubbo 是国内使用较多的微服务框架之一。

在云原生到来的今天，Service Mesh 的服务治理模式彻底解耦了业务逻辑和控制逻辑，通过 Sidecar 将服务发现，流量控制逻辑下沉到 iPaaS 层面，这种方式逐渐得到大家的关注和青睐。而 Dubbo 在流量治理方面存在一些短板，如灰度发布等目前没有完美的方式实现。

在这种环境下，国内有很多使用 Dubbo 的公司诞生了将 Dubbo 应用迁移到 Service Mesh 中的想法。本文便是对 Dubbo 迁移到 Service Mesh/Istio 的探讨。

Dubbo to Mesh 改造难点

在 Dubbo 应用向 Service Mesh 应用改造的过程中，可能会遇到以下这些难点：

• 服务名调用问题：Istio 通过对 K8S 服务名调用的拦截，实现了无侵入式的流量治理功能，因此 Isito 要求不同服务间的调用必须以服务名的方式进行。现有项目是否为服务名调用，成了不同类型的项目向 Istio 改造的最大障碍之一，例如 Dubbo 项目就不是服务名调用，而是 Interface 调用，这是第一个痛点问题。

• 注册中心问题：由于 Istio 目前只支持 K8S etcd、Consul 两种服务注册中心，其他注册中心（例如：Zookeeper）的对接以及跟 Istio 配置文件的集成及 xDS 协议数据的下发，成为了第二个痛点问题。

• 私有协议问题：由于当前 Istio 目前只支持 http、gRPC、tcp 三种协议，私有协议适配难度较高，即使在新版 Envoy 已经支持了 Dubbo 协议的情况下，还是需要通过 EnvoyFilter 下发专属 xDS 协议数据来支持 Dubbo 的服务调用及流量治理，这是第三个痛点问题。

Dubbo to Mesh 云原生架构改造方案

相比于自研 sidecar 或修改 Dubbo SDK 等重度方式，本文从不同的角度尝试两种改造方案：

• 方案1：Dubbo to Mesh 轻量化改造方案：该方案基于 Dubbo 本身提供的直连功能，通过修改 dubbo provider / consumer 配置文件，禁止 dubbo 的注册发现功能，通过配置 provider url 实现基于服务名发送请求。由于 Istio 1.5+ 版已提供了 dubbo 协议的支持，因而数据面 envoy 可对 dubbo 流量进行治理。

• 方案2：使用 SpringBoot 重构 Dubbo 的改造方案：该方案抛弃 Dubbo 框架，直接使用 SpringBoot 进行重构。脱离了框架的限制，项目代码更轻量，同时更自然的拥抱云原生。 

方案 1：Dubbo to Mesh 轻量化改造方案

1.1 改造思路

利用 Dubbo 本身的能力，修改配置文件以禁用 Dubbo 本身的注册发现，并通过指定服务名调用 Dubbo 服务。使用这种方法可以将Dubbo 应用快速部署到 Istio 集群中，不改变通信协议，并实现基于服务名的流量控制。本方案在 Istio 1.5+ 中实验通过。

1.2 改造步骤：

• Step 1. 改造 provider

禁用 registry，不订阅，不注册，也不进行检查。如下修改程序配置：

现在无需部署 zk （或其他注册服务），这个应用可以直接启动。

• Step 2. 改造 consumer

同样禁用 registry。 由于没有注册发现服务了，所以需要在消费端的配置文件中显式指定接口的服务地址，通常我们会指定为 provider 部署所在的服务器 ip，但在部署到 Istio 中，我们需要指定为部署的 Service 名称，由 CoreDNS 解析为实际的 IP，从而实现让 Istio 来管理路由。本示例中的 provider 应用部署的服务名是 hello-dubbo-provider， 所以我们显式指定 url="dubbo://hello-dubbo-provider:20880"。

除了以上通过配置文件修改调用地址，我们还可以通过在 JVM 启动参数中加入参数映射服务地址：

java -Dtencent.demo.DemoService=dubbo://hello-dubbo-provider:20880 ...

如果服务较多，可以使用文件映射服务和地址：

java -Ddubbo.resolve.file=services.properties ...

在 services.properties 中可指定多个服务：

tencent.demo.DemoService=dubbo://hello-dubbo-provider:20880
tencent.demo.DemoService2=dubbo://hello-dubbo-provider:20880
tencent.demo.DemoService3=dubbo://hello-dubbo-provider3:20880

本地调试一下，在 hosts 中映射一下。 

127.0.0.1 hello-dubbo-provider

现在启动 consumer，不出意外，完美运行。

现在我们可以通过 yaml 的部署，轻松将应用部署到 Istio 集群中。本方案在 Isito 1.5.6 和 1.6.1 中实验通过。 详细的实验过程可以参考 腾讯云“云+社区”的文章《Dubbo to Istio / Dubbo Mesh 极简改造指南》。

1.3 方案总结

通过简单的两处的修改，我们便实现禁用 Dubbo本身的注册发现，并交由 Istio 来管理。 通过 Dubbo 本身的能力，修改配置文件和依赖包，我们还可以将 Dubbo 应用的通信方式修改为 http。

实验证明：不改造 dubbo 框架和业务逻辑的情况下（只改配置文件和依赖包），可以实现 如下目标：1 基于 TCP 的流量操控，可以根据 Service 来控制流量。2 基于 HTTP 的流量操控，可以控制到 Service 和 interfaceName（Dubbo 中 interfaceName 是写在 url 里面的，可以通过 uri 匹配规则进行流量操控）。

在调用链追踪方面， Dubbo 本身并没有 OpenTracing，在不修改 Dubbo SDK 的情况下，仍需要使用 Dubbo 原来的方式来实现。

方案 2：使用 SpringBoot 重构 Dubbo 的改造方案

2.1 改造思路：

此方案充分利用 Dubbo 项目原有的代码结构，删除Dubbo原有的注册发现、Dubbo协议、Dubbo服务配置等功能，将一个 Dubbo 项目改造成一个 SpringBoot + K8S + Istio 的项目，代码修改范围可控，改造方式最彻底。

• 由于改造 Dubbo SDK、Isito控制面、Envoy 数据面，让 Dubbo 去适配 Service Mesh 的技术难度较大，而且即使改造成功也需要通过 EnvoyFilter 下发专属 xDS 协议数据的形式来支持 Dubbo 服务间调用的流量治理，使得这种方式与原生 Istio 的使用方式差距较大。

• 所以我们选择了一条将 Dubbo 项目改造成 SpringBoot + K8S + Istio 项目的更简单的路，充分利用现有 Dubbo 项目的代码结构，将代码修改量降到一个可控的范围内。

• 由于 Dubbo 项目 facade 模块的作用与 Spring Cloud Feign 模块的作用十分相似（模块内都是一些 interface，需要服务端 xxxServiceImpl 去实现各个 interface，消费端通过 @Resource 注解的方式引入 interface 并直接调用），使得 Dubbo 最复杂的服务间调用方式有了解决的方案。

• 此次改造只是利用了 Dubbo 项目的代码结构，Dubbo 原有的注册中心、Dubbo 协议等功能全部都会被去掉，也就是改造后的项目跟 Dubbo 已经没有任何关系了，所以注册中心、Dubbo私有协议这两个痛点问题也就不存在了。

• K8S 会接管服务注册发现、服务编排等工作，Istio 会接管服务治理、调用链监控、服务安全等工作，改造后的项目是一个标准的 Service Mesh 项目。

2.2 改造步骤：

Step 1. 依赖修改

• 在根 pom.xml 中引入 SpringBoot parent，增加 spring-cloud-dependencies import 引用。

• 删除所有 dubbo 相关引用。

• 虽然 pom 文件改动很大，但属于一次性改动，改造工作量较小。

Step 2. dubbo-facade 项目改造

• pom.xml 增加 spring-cloud-starter-openfeign 引用。

• 删除所有 Dubbo 相关引用、Dubbo 相关配置文件。

• Dubbo 原有 facade 接口是标准的 JAVA 接口定义，与 Feign Restful 接口定义十分类似。这里可以在原有的 facade 接口基础上增加 @FeignClient、@RequestMapping 等注解，将一个普通的 facade 接口改造成一个 Feign Restful 接口，后续会使用 Feign 这个 Restful 框架来处理服务间调用等问题。

• 由于 Feign 本身是自带了 Ribbon 负载均衡，服务访问者经过负载均衡后会找到服务提供者的一个 IP+Port 进行调用，这与 K8S Service 要求的服务名调用的方式相冲突，所以必须想办法去掉 Feign 自带的负载均衡。好在 @FeignClient 可以手工指定一个固定的调用地址，这里可以把这个地址设置成 K8S Service 的 name 名称，从而实现了通过 Feign 对 K8S Service 服务名调用的能力。此部分需要每个 facade 接口增加注解一次，改造工作量相对可控。

• 由于 Feign 要求接口使用 Restful 格式，所以接口中的每个抽象方法都必须添加 @RequestMapping、@GetMapping、@PostMapping 等注解暴露成一个 Restful 资源地址。此部分改造涉及到每个 facade 接口的每个抽象方法，是整个方案里改动量最大的一部分。

• 此部分整体改造工作量取决于原有的 Dubbo 项目包含多少个 facade 接口，以及每个 facade 包含多少个抽象方法。

Step 3. dubbo-provider 项目改造

• pom.xml 增加 spring-boot-starter-web、spring-cloud-starter-openfeign 等引用，同时增加 SpringBoot mainClass 标准启动项配置。

• 删除所有 Dubbo 相关引用、Dubbo 相关配置文件。

• 增加 SpringBoot 启动类，增加 @SpringBootApplication、@EnableFeignClients 两个注解，配置 dubbo-provider 服务端口号。

• xxxServiceImpl 服务实现类上增加 @RestController 注解，提供 consumer Restful 访问的能力。这个需要每个服务实现类都加上 @RestController 注解，不要遗漏。

• 此部分大都属于一次性改动，改造工作量相对可控。

Step 4. dubbo-consumer 项目改造

• pom.xml 增加 spring-boot-starter-web、spring-cloud-starter-openfeign 等引用，同时增加 SpringBoot mainClass 标准启动项配置。

• 删除所有 Dubbo 相关引用、Dubbo 相关配置文件。

• 增加 SpringBoot 启动类，增加 @SpringBootApplication、@EnableFeignClients（需要配置 basePackages 扫描包路径） 两个注解，并配置 dubbo-consumer 服务端口号。

• 此部分大都属于一次性改动，改造工作量相对可控。

Step 5. 将改造后的项目部署到 K8S + Istio

• 创建 dubbo-provider K8S Deployment、K8S Service（ClusterIP），提供集群内访问服务。

• 创建 dubbo-consumer K8S Deployment、K8S Service（ClusterIP），提供集群内访问服务。

• 创建 istio ingressgateway、VirtualService，提供公网访问入口，并进行流量治理测试。

经过上面几步操作，我们成功的将一个 Dubbo 项目改造成了一个 Service Mesh 项目，并在 K8S + Istio 集群中部署成功、测试通过。

详细的实验过程可以参考 腾讯云“云+社区”的文章《如何将一个 Dubbo 项目改造成一个 Service Mesh 项目？》：https://cloud.tencent.com/developer/article/1635721。

2.3 Dubbo to Mesh 改造过程中的迁移态方案

• 在 service mesh 和未做 mesh 化改造的 dubbo 服务之间，添加 MeshGate 业务网关。

• 业务网关会在 dubbo 注册中心进行注册和订阅，向 mesh 外提供 dubbo-rpc 调用服务，向 mesh 内提供 http/rest 接口服务。

2.4 方案总结

当然，真实业务系统中的架构复杂度是远高于这个 Demo 的，实际改造的工作量要比改造这个 Demo 大得多。但笔者以为：Dubbo 的服务治理功能和 Istio 是重复的，并且随着云原生的 Java 框架兴起，以及 Spring 对云原生/Native 的支持，最终的 Dubbo 迁移到 Mesh 的改造都会走到这个路径。

两种改造方案的适用场景及优缺点

最后总结一下本文中两种方案各自的适用场景及优缺点：

作者简介：腾讯云泛互云原生团队基于腾讯云的技术和产品能力，致力于帮助企业客户推广及落地微服务、容器、服务网格、大数据、DevOps、AI等技术产品，有效提升客户的研发及运维效率。目前服务的客户主要有：快手、知乎、KEEP、小红书、微盟等。

更多精彩推荐

☞TensorFlow 2.0 发布以来，又有哪些最新进展？| AI ProCon 2020
☞疫情之下 SaaS 市场两极分化，SaaS 厂商如何突围严峻形势？
☞马斯克，带动大盘的男人：财报一出市值飙升 840 亿！
☞用 Python 可以实现侧脸转正脸？我也要试一下！
☞重大事故！线上系统频繁卡死，凶手竟然是 Full GC ？
☞以太坊第五年，未来该往哪走？
点分享点点赞点在看