传统微服务框架如何无缝过渡到服务网格 ASM

作者：宇曾

背景

软件技术的发展历史，从单体的应用，逐渐演进到分布式应用， 特别是微服务理念的兴起，让大规模、高并发、低延迟的分布式应用成为可能。云原生时代下，微服务框架本身也在不断地进化和迭代演进。

微服务框架一般会涉及到以下几个知识点：

本文我们着重探讨以下三大微服务框架：

• SpringCloud
• Dubbo
• ServiceMesh （新生代）

这三款不同的框架对服务治理领域的功能点覆盖度弱有差异。本文不着重探讨这几个框架的谁优谁劣，主要来探讨下如何从传统的微服务框架 Dubbo 、SpringCloud 无缝过渡到 ServiceMesh 架构。当下 ServiceMesh 领域最火热的项目非 Istio 莫属。

阿里云服务网格 ASM 基于 Istio ，对 Istio 进行了云上托管和适配，并且新增了相关功能，以及大规模服务网格场景下的性能优化等。作为业内首个全托管 Istio 兼容的阿里云服务网格产品 ASM，一开始从架构上就保持了与社区、业界趋势的一致性，控制平面的组件托管在阿里云侧，与数据面侧的用户集群独立。ASM 产品是基于社区 Istio 定制实现的，在托管的控制面侧提供了用于支撑精细化的流量管理和安全管理的组件能力。通过托管模式，解耦了 Istio 组件与所管理的 K8s 集群的生命周期管理，使得架构更加灵活，提升了系统的可伸缩性。从 2022 年 4 月 1 日起，阿里云服务网格 ASM 正式推出商业化版本, 提供了更丰富的能力、更大的规模支持及更完善的技术保障，更好地满足客户的不同需求场景, 详情可见产品介绍：

https://www.aliyun.com/produc...

下面我们一起来看下传统微服务迁移到服务网格技术栈会有哪些已知问题，以及阿里云服务网格 ASM 又是如何无缝支持 SpringCloud 、Dubbo 这些服务的。

关注【阿里云云原生】公众号，回复关键词【0621】获取文中代码压缩包下载地址！

传统微服务迁移到服务网格的一些已知问题和场景

常见的几个问题

• 服务容器化后，服务 deployment 滚动更新，服务实例的 IP 是经常变化的，对应服务实例IP 同步到注册中心会有延迟，这个过程会导致部分业务请求出现 503。
• Istio 社区版本对非 HTTP 、gRPC 的其他 rpc 协议支持有限,无法提供统一形态的路由管理，以及相关治理能力。
• 因 Istio 本身设计的服务路由模型依赖服务间请求为 ServiceName 或 ClusterIp ，SpringCloud 服务没有办法直接 Mesh 化，Dubbo 服务因基于 interface 的服务调用设计，interace 在 Dubbo 协议请求的上下文有传递，虽然不受该模式的限制，但 Istio 社区版本对 Dubbo 路由的支持却没有对应的 RDS 支持，无法直接采用社区版本的 VirtualService 配置 Dubbo 路由。

除了以上一些常见问题，还有一些具体的业务场景在业务云原生化过程中经常遇到。

场景 1：容器集群内外服务如何互通

• 部分业务容器化，迁移到 Kubernetes 集群
• 仍旧有一些遗留服务需要在 ECS 云主机在部署

通过 ASM 对接注册中心，可以实现容器集群内外服务互通，并且保留服务治理能力。并且容器化业务服务通过 ASM 服务网格化托管，将服务治理能力下沉到 Sidecar ，方便业务快速获得 Istio 带来的声明式配置，进行流量管理、灰度发布等服务治理编排能力，同时天然获得了对接 Trace、Log、Metrics 可观察的三大件能力。

场景 2：多语言业务互通

随着云原生化浪潮的到来，业务一般更加复杂多样，很多客户因为业务发展需要，采用了多语言甚至多套开发框架，不同的语言服务之间如何进行互联互通，或者是否有一种统一的服务框架来管理这些多语言服务？

ASM 服务网格针对以上客户的相关场景，以及遇到常见问题，基于 Istio 社区版本进行了功能扩展，可以支持 SpringCloud 、Dubbo 服务无缝迁移服务网格，也就是业务不需要进行任何代码修改，即可天然享受服务网格提供的能力，以下我们对 SpringCloud 和 Dubbo 分别进行具体的解析说明。

管理 SpringCloud 服务

SpringCloud 服务通信是采用 HTTP 协议，Istio 对 HTTP 协议的支持非常友好，我们只需要解决 Istio 如何管理 SpringCloud 服务即可，也就是解决 SpringCloud 服务请求如何适配 Istio 依赖的 Servicename 或者 ClusterIp 问题。

简单地说，就是服务网格因为采用 Sidecar 模式，需要知晓请求发出的流量目标服务是谁，并且这个信息需要在 Http 请求的 Host 字段下进行声明。

方案 1：采用 EnvoyFilter + Lua 方式

核心实现是通过 EnvoyFilter 下配置了一段 Lua 逻辑修改了服务订阅请求的返回，将服务订阅返回的目标 IP 地址修改为对应的服务名。具体 Demo 例子可以参考 ASM Help 文档: 

https://help.aliyun.com/docum...

但该方案因为需要理解具体的服务订阅协议，目前仅支持 Nacos, 不支持其他非 Nacos 注册中心，虽然我们提供了一些服务注册中心迁移的方案,  因为各方面的原因，用户可能不太想修改代码适配注册中心。基于此，我们提供了方案2 可以适配支持任意注册中心。

方案 2：通过 Reverse DNS Filter 反向查找得出 ServiceName

方案 1 目前仅能支持 Nacos , 不少用户看到后纷纷反馈是否可以支持 Eureka、ZooKeeper 等服务注册中心，基于此，我们推出了如下通用解决方案：

btw, 因为 Istio 天然支持 gRPC 协议，而 Dubbo3 新版协议 triple 基于 gRPC , Dubbo3 服务可以比较优雅的上 Mesh，

如上方案也适用于 Dubbo3 服务。

小结：通过以上两个方案（推荐使用方案 2） 我们解决了 SpringCloud 服务适配 Istio 路由模型的问题，从此 SpringCloud 就可以享受 Istio 全量的能力了，而且无需进行任何代码修改。

当然，如果用户愿意修改代码，我们更推荐客户去除原有的 SpringCloud 下的类似负载均衡、熔断、限流等相关注解，因为在 Mesh 场景下，原有的能力已经没有必要了。

方案2 ReverseDNS Filter 方案已在ASM 1.13 版本内置，预计6月底发布上线

管理 Dubbo 服务

这里我们说到 Dubbo 服务指的是 Dubbo2，Dubbo3 采用如上类似方案即可，我们也在对接 Dubbo3 社区，支持 Dubbo3 的 Proxyless Mesh 模式。目前 Dubbo2 依然存在大量的用户，因此阿里云服务网格对 Dubbo2 也提供了深度支持，以下提到的 Dubbo 都是只 Dubbo2 版本。

Dubbo 用户大多数使用 Nacos 或者 ZooKeeper 注册中心，ASM 产品层面目前支持 MSE Nacos 注册中心。

只需要简单地在 ASM 设置菜单下关联 MSE Nacos 实例即可发现对应 Nacos 下的服务信息。

支持 Dubbo + Nacos 服务迁移到 ASM

整体架构图如下：

相关文档：

• 托管 Dubbo 服务
• 管理 Dubbo 服务流量
• Dubbo 服务的虚拟服务参数说明
• 集成自建 Prometheus 实现 Dubbo服务可观测性

ASM 在 Istio 社区版本的 VirtualService 基础上扩展支持了 Dubbo 路由，一个较为复杂的配置样例如下：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: demoservice0
spec:
  hosts:
  - providers:com.alibaba.edas.DemoService0
  dubbo:
  - routes:
    - match:
      - method:
          nameMatch:
            exact: "sayHello"
          argc: 1
          args:
          - index: 1
            strValue:
              patterns:
              - exact: "jack"
            type: java.lang.String
      route:
      - destination:
          subset: v1
        weight: 100
    - match:
      - method:
          nameMatch:
           exact: "sayHello"
          argc: 1
          args:
          - index: 1
            strValue:
              patterns:
              - exact: "lily"
            type: java.lang.String
        headers:
         app:
          patterns:
            - exact: "consumer1"
      route:
      - destination:
          subset: v2
        weight: 100
    services:
    - prefix: providers:com.alibaba.edas.DemoService0

Dubbo 路由的具体 Spec 定义和例子说明请参考如上 Dubbo 服务治理系列文档

支持 Dubbo  + ZooKeeper

对于 Dubbo 开源用户，除了 Nacos 外，也有较多用户使用 ZooKeeper 注册中心，但 ZooKeeper 目前官方并未提供针对 Istio 服务发现能力，也就是 Istio 依赖的 MCP over XDS  协议的支持。

MCPBridge 组件解决了这个问题，在阿里云服务网格 ASM 场景下，具体实现方案如下：

因注册中心的多样性，后续MCPBridge 将会提交给开源社区，欢迎大家一起来维护。

用户可以通过下载 MCPBridge Helm 安装包，手动安装 MCPBridge 到业务部署所在的 ACK 集群。

安装方法很简单，下载完成后解压 Helm 安装包，然后在目录下执行：

helm install -f values.yaml mcp-bridge .

安装完成后，mcp-bridge 会通过 SLB 提供一个 VPC 内网地址，需要将 Istiod 对应的 ConfigSource 关联该地址。ASM 此功能目前白名单开放中，需要提工单或者加文章结尾的群联系产品运维人员。

安装完成后，接着我们就可以给它配置上游注册中心地址为 ZooKeeper  ，若环境没有可用的 ZooKeeper 服务器，可以通过阿里云 mse ZooKeeper 快速创建一个，如下：

给 MCPBridge 组件配置它需要关联的注册中心很简单，只需要创建一个 MCPBridge CR 即可，具体配置格式如下：

文件：zk-mcpbridge.yaml

apiVersion: istio.aliyun.cloud.com/v1
kind: McpBridge
metadata:
  name: default
  namespace: istio-system
spec:
  registries:
  - domain: mse-7e74ff00-zk.mse.aliyuncs.com   ### zookeeper 地址
    name: zookeeper
    port: 2181
    type: zookeeper

kubectl apply -f zk-mcpbridge.yaml  生效后，MCPBridge 组件就会自动同步 ZooKeeper 下dubbo 节点下的服务信息到 istiod 了。

若想体验 MCPBridge 支持 Dubbo  + ZK 的具体示例，可以下载测试示例: dubbo-zk-demo.tar.gz

文件包下面包含了上面 McpBridge 这个 yaml 配置以及测试用的 dubbo demo 服务例子。

root@service-mesh-test011122063081:~/test/mcpbridge/dubbo-zk-demo# tree .
.
├── dubbo-services.yaml                    ## dubbo + zk注册中心测试服务例子
├── zk-mcpbridge.yaml                      ## mcpbridge zk 配置，需要对应修改zk地址
└── zk-registry-service-alias.yaml         ## zk地址的服务别名，需要对应修改zk地址

接下来我们简要说明下如何来使用这个 Demo 例子。

当把 dubbo-zk-demo.tar.gz下载并解压完成后，我们首先需要将 yaml 下 zk 地址 "mse-7e74ff00-zk.mse.aliyuncs.com"  修改为实际对应的 zk 服务地址（该地址需要确保 MCPBridge 组件可以访问），地址修改完成后，在 dubbo-zk-demo 文件目录下执行如下命令：

kubectl create ns dubbo 
kubectl label ns dubbo istio-injection=enabled
kubectl apply -f .

然后再通过命令 kubectl get pods -n dubbo 查看确认对应 dubbo 服务 consumer 、provider 是否启动成功，

root@service-mesh-test011122063081:~/test/mcpbridge# kubectl get pods -n dubbo
NAME                                    READY   STATUS    RESTARTS   AGE
dubbo-consumer-zk-5cd8f6c6bf-bscd2      2/2     Running   0          83m
dubbo-provider-zk-v1-54cd888957-k7bg4   2/2     Running   0          83m
dubbo-provider-zk-v2-cf58ccc79-sg94l    2/2     Running   0          83m

启动成功后，我们回到 Zookeeper 下，可以看到已经有服务注册信息报上来了：（dubbo 节点下）

接着，我们将 consumer 服务映射到 ASM 网关下进行测试访问，通过 ASM 控制台我们可以快速地创建一个 ASM 网关，若是采用 CICD 或者 GitOps 等方案，也可以直接通过创建 IstioGateway Yaml 的方式来创建。

网关实体创建成功后（gateway deployment、svc 等)，我们还需要配置逻辑网关，只需要两步即可；

• 创建一个网关规则（istio 下的 gateway CRD)， 声明一个逻辑网关，以及这个逻辑网关（test-gateway) 绑定的具体域名和声明端口以及协议类型
• 配置网关路由，将 /sayHello 请求转发给 dubbo-consumer-zk.dubbo.svc.cluster.local 目标服务

网关规则和网关路由可以参考如下 Yaml, 我们只需将这个 Yaml 保存为本地文件，然后在 asm 集群下 kubectl apply 即可。

---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: test-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: consumerhttp
spec:
  hosts:
  - "*"
  gateways:
  - test-gateway
  http:
  - match:
    - uri:
        prefix: /sayHello
    route:
    - destination:
        host: dubbo-consumer-zk.dubbo.svc.cluster.local ##对应consumer服务的k8s service name
        port:
          number: 17080

网关规则和路由配置生效后，我们可以通过浏览器或者终端命令方式：

curl http://$INGRESS_GATEWAY_IP/sayHello/world  来访问前面部署的 Dubbo demo 服务，执行如下命令，可以看到执行后输出的相关结果：前后请求两次负载均衡到了 Provider 的 v1 、v2 版本。

 #export INGRESS_GATEWAY_IP=YOUR_GATEWAY_IP
 
 #curl http://$INGRESS_GATEWAY_IP/sayHello/world
 
 V2 Gray1: hello world - 172.22.32.143:20880
 
 #curl http://$INGRESS_GATEWAY_IP/sayHello/world
 
 V1 Gray1: hello world - 172.22.32.39:20880

更多流量管理、灰度发布、可观测例子可以参考 Istio 以及 ASM 下 Dubbo 服务治理的相关文档来配置。

总结

针对传统微服务框架 SpringCloud 和 Dubbo, 阿里云服务网格 ASM 针对客户常用的场景需求以及遇到的问题，基于 Istio 进行扩展支持，可以无缝兼容管理 SpringCloud 、Dubbo 服务，并提供 Istio 原生的服务治理能力。

阿里云服务网格 ASM 作为托管服务网格的先行者，已经收获了大量的用户落地，这些用户更加坚定了我们做这个产品的信心。服务网格不再是成堆的 buzzword，而是真真实实应用到生产环境，处理服务治理领域一个又一个的技术问题。回归本质，服务网格还是要解决真真切切的业务问题。

服务网格社区在蓬勃发展，ASM 产品仍有需要完善的地方，但它已经在市场验证中获得了前行的力量。服务网格的史诗故事才刚刚开始，欢迎加入钉钉群交流探讨~