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

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+ 中实验通过。