背景
软件技术的发展，从单体的应用，逐渐演进到分布式应用， 特别是微服务理念的兴起，让大规模、高并发、低延迟的分布式应用成为可能。 云原生时代下，微服务框架本身也在不断地进化和迭代演进。
微服务框架一般会涉及到以下几个知识点：
本文我们着重探讨以下三大微服务框架：
- 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/product/servicemesh
下面我们一起来看下传统微服务迁移到服务网格技术栈会有哪些已知问题，以及阿里云服务网格ASM 又是如何无缝支持SpringCloud 、Dubbo 这些服务的。
传统微服务迁移到服务网格的一些已知问题和场景
常见的几个问题
- 服务容器化后，服务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/document_detail/383257.html
但该方案因为需要理解具体的服务订阅协议，目前仅支持Nacos, 不支持其他非Nacos 注册中心，虽然我们提供了一些服务注册中心迁移的方案, 因为各方面的原因，用户可能不太想修改代码适配注册中心。基于此，我们提供了方案2 可以适配支持任意注册中心。
方案2：通过Reverse DNS Filter 反向查找得出ServiceName
方案1 目前仅能支持Nacos , 不少用户看到后纷纷反馈是否可以支持Eureka、ZooKeeper等服务注册中心，基于此，我们推出了如下通用解决方案：
因为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 依然存在大量的用户，因此阿里云服务网格对Dubbo 也提供了深度支持，以下提到的Dubbo 都是只Dubbo2 版本。
Dubbo 用户大多数使用Nacos 或者 ZooKeeper 注册中心，ASM 产品层面目前支持MSE Nacos 注册中心。
只需要简单地在ASM 设置菜单下关联MSE Nacos 实例即可发现对应Nacos 下的服务信息。
支持Dubbo + Nacos 服务迁移到ASM
整体架构图如下：
可以参照文档实现Dubbo + Nacos + ASM 实现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: zookeeperkubectl 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 产品仍有需要完善的地方，但它已经在市场验证中获得了前行的力量。服务网格的史诗故事才刚刚开始，欢迎加入钉钉群交流探讨~
