关于阿里云:传统微服务框架如何无缝过渡到服务网格-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 产品仍有须要欠缺的中央，但它曾经在市场验证中取得了前行的力量。服务网格的史诗故事才刚刚开始，欢送退出钉钉群交换探讨~