在服务网格技术使用之前，为了更快更灵活地进行业务创新, 我们常常会把现有应用进行现代化改造,把单体应用程序分拆为分布式的微服务架构。

对这些微服务治理的实现,往往是以代码库的方式把这些服务治理的逻辑构建在应用程序本身中，这些代码库中包括了流量管理、熔断、重试、客户端负载均衡、安全以及可观测性等这样的一些功能。这些代码库随着功能的不断增强,版本也随之变更，因为版本不同导致的冲突问题处处可见。

此外，库的版本一旦变更，即使你的应用逻辑并没有任何变化，整个应用也要随之全部变更。由此可见, 随着应用的增长和团队数量的增加，跨服务一致地使用这些服务治理功能会变得非常复杂。

通过把这些服务治理的能力Sidecar化，就能够把服务治理的能力与应用程序本身进行了解耦，可以较好地支持多种编程语言、同时这些Sidecar能力不需要依赖于某种特定技术框架。这就是我们常说的面向Sidecarproxy的架构模式。

与此同时，容器编排技术的更加成熟，也加速了Sidecar代理的普及与使用的便捷。Kubernetes作为一个出色的容器部署和管理平台、Istio作为应用服务治理的平台，两者的结合成为了将这些应用服务通信能力下沉到基础设施的载体。

在云原生应用模型中，一个应用程序可能会包含数百个服务，每个服务又有数百个实例构成，那么这些成百上千个应用程序的Sidecar代理如何统一管理，这就是服务网格中定义的控制平面部分要解决的问题。作为代理，Envoy非常适合服务网格的场景，但要发挥Envoy的最大价值，就需要使它很好地与底层基础设施或组件紧密配合。

这些Sidecar代理形成一个网状的数据平面，通过该数据平面处理和观察所有服务间的流量。数据平面扮演了一个用来建立、保护和控制通过网格的流量的角色。

负责数据平面如何执行的管理组件称为控制平面。控制平面是服务网格的大脑，并为网格使用人员提供公开API，以便较容易地操纵网络行为。

启用服务网格之后, 开发人员、运维人员以及SRE团队将以统一的、声明的方式解决应用服务管理问题。

作为业内首个全托管Istio兼容的服务网格产品ASM，一开始从架构上就保持了与社区、业界趋势的一致性，控制平面的组件托管在阿里云侧，与数据面侧的用户集群独立。ASM产品是基于社区开源的Istio定制实现的，在托管的控制面侧提供了用于支撑精细化的流量管理和安全管理的组件能力。通过托管模式，解耦了Istio组件与所管理的K8s集群的生命周期管理，使得架构更加灵活，提升了系统的可伸缩性。