传统微服务框架如何无缝过渡到服务网格 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/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：多语言业务互通

随着云原生化浪潮的到来，业务一般更加复杂多样，很多客户因为业务发展需要，采用了多语言甚至多套开发框架，不同的语言服