阿里云服务网格ASM深度对接与实践指南

引言：云原生时代的服务网格与ASM

在微服务架构日益普及的今天，服务间通信的复杂性已成为开发与运维团队的头号挑战。传统的做法是将流量管理、熔断、重试、安全认证等逻辑硬编码到业务应用中，这不仅造成了大量重复劳动，还使得应用代码与基础设施逻辑紧密耦合，严重阻碍了迭代效率。服务网格的核心理念，正是将这些通用能力从应用层剥离，下沉至独立的、透明的基础设施层。阿里云服务网格（Alibaba Cloud Service Mesh，简称ASM）正是这一理念在阿里云上的最佳实践——一个全托管的、与开源Istio完全兼容的服务网格平台，旨在帮助用户以非侵入式的方式统一治理微服务。

相比社区自建Istio，ASM最大的优势在于其全托管架构。用户无需自行维护Istio控制平面的Istiod组件、无需操心证书轮换、无需手写复杂的EnvoyFilter补丁，ASM自动完成控制平面的部署、扩缩容、版本升级和故障自愈。同时，ASM天然打通了阿里云的基础设施生态：ACK容器服务、SLS日志服务、ARMS Prometheus监控、可观测链路OpenTelemetry版等都可以一键集成，让可观测性和安全策略的落地变得前所未有的轻松。

需要先登录阿里云控制台，点击：阿里云控制台

ASM核心架构：从控制平面到数据平面

理解ASM的工作原理，首先需要厘清服务网格的两大核心组件：控制平面和数据平面。ASM将Istio控制平面的所有组件——包括Istiod、Pilot、Citadel、Galley等——以托管服务的形式运行在阿里云内部的高可用集群中，用户不可见也无需管理。控制平面负责接收用户的声明式配置（如VirtualService、DestinationRule），将其转化为数据平面能够理解的规则，并负责服务发现、证书签发、配置分发等工作。

数据平面则由一组智能代理构成。ASM支持两种数据平面模式：Sidecar模式和Ambient模式。Sidecar模式是Istio社区的经典方案，每个业务Pod旁都会被注入一个Envoy代理容器，该代理劫持所有进出Pod的流量，执行控制平面下发的规则。Ambient模式是Istio 1.18版本后引入的轻量级方案，它不再需要为每个Pod注入Sidecar，而是在节点层面部署轻量级代理（ztunnel）和Waypoint代理，降低了资源开销和运维复杂度。在ASM企业版中，Sidecar模式支持ACK托管集群、专有集群、Serverless集群、边缘集群以及外部注册的Kubernetes集群，而Ambient模式仅支持ACK托管集群。

无论是哪种模式，ASM都确保了业务应用对服务网格完全无感知。开发者继续以原有的方式编写代码、调用服务，所有流量治理、安全加密、可观测性采集都透明地发生在代理层面，真正实现了基础设施与业务逻辑的解耦。

规格选择与计费策略：企业版还是旗舰版

ASM当前提供企业版和旗舰版两种商业规格，同时保留标准版作为免费入门版本。选择哪个规格，取决于生产环境的规模以及对高可用能力的诉求。企业版面向1,000个Pod以内的小型到中型生产环境，托管控制平面包含多副本Istiod以确保高可用，承诺服务等级协议支持。旗舰版则面向10,000个Pod以内的大规模生产环境，提供更强的性能和更高的扩展上限。

从计费角度看，ASM商业版实例按小时计费，计费周期为1小时，账单在周期结束后10至30分钟内出具并从账户中直接扣划。企业版的单价为0.98美元/小时，旗舰版为4.63美元/小时。需要特别注意的是，ASM的实例费用仅覆盖控制平面的运行成本，数据平面中Sidecar容器或Gateway Pod消耗的ECS计算资源、CLB负载均衡实例、VPC网络资源、SLS日志存储等云产品均按各自产品的标准计费规则额外收取费用。因此，在评估ASM成本时，务必将数据平面资源消耗纳入预算考量。

Pod数的计算规则也值得关注。ASM根据服务发现的命名空间来计算管理的Pod数量，并自动排除istio-system、arms-prom、kube-node-lease、kube-public、kube-system等系统命名空间。当管理的Pod数量超出所选版本的支撑上限时，阿里云将不再承诺SLA保障，因此建议提前规划或预留规格升级空间。

版本机制与Istio兼容性：紧跟社区步伐

ASM本质上是Istio的商业托管版本，因此其版本机制与Istio社区高度同步。ASM原则上保持每三个月更新一次Istio大版本的频率，并在大版本发布后不定期推出补丁版本用于功能更新和漏洞修复。对于补丁级别的升级，系统会自动完成热更新，数据平面的Gateway和Sidecar代理版本保持不变，业务应用完全无感知。

用户在创建ASM实例时，控制台仅展示两个最新的大版本供选择，例如1.28和1.27。版本过期后，ASM不再提供安全补丁和问题修复，也不保证技术支持质量，因此定期升级版本是生产环境运维的必要工作。根据版本机制文档，ASM 1.28版支持ACK 1.28及更高版本，1.27版同样支持ACK 1.28及以上版本；而1.24版仅支持ACK 1.26至1.34版本区间。

在创建ASM实例之前，务必确认ACK集群的版本与所选ASM Istio版本之间的兼容关系，避免因版本不匹配导致数据平面注册失败或配置下发异常。

创建ASM实例：从控制台到网络规划

对接ASM的第一步是创建ASM实例。登录ASM控制台，在网格管理页面单击创建新网格，开始配置实例。网格名称用于标识实例，建议采用清晰的环境命名规范如prod-mesh或dev-mesh。规格字段选择企业版或旗舰版，地域要与后续添加的ACK集群保持在同一区域以避免跨地域网络延迟。Istio版本从可用的最新大版本中选择，通常建议选择最新稳定版以获得更长的支持生命周期。

网络配置是整个创建过程中最为关键的一环。Kubernetes集群字段会根据待添加集群的信息自动选择所属的专有网络VPC和交换机。如果尚未创建VPC，控制台提供一键创建入口。专有网络中的路由规则和网络安全组将由ASM自动创建和维护——安全组允许VPC入方向全部ICMP端口的访问，用于网格组件之间的健康检查。Istio控制面的访问和API Server的访问通过CLB负载均衡实例暴露。若开放API Server的公网访问，ASM会创建一个弹性公网IP绑定到私网CLB上；若不开放，则只能通过VPC内部网络使用KubeConfig连接和操作ASM实例。

一个完整的ASM实例创建过程会涉及以下资源的自动生成：安全组用于网格内部通信，VPC路由规则用于跨交换机流量转发，RAM角色和策略用于授权ASM访问用户账号下的CLB、VPC、日志服务等资源，以及私网CLB暴露Istiod的6443和15011端口供数据平面代理接入。整个创建过程通常需要几分钟，状态变更可以从网格管理页面实时观测。

添加集群到ASM实例：网络互通是关键

ASM实例创建完成后，下一步是将ACK集群添加到该实例中，以便托管集群内的服务。添加集群的核心前提条件是网络互通：建议待添加的集群与ASM实例处于同一VPC中。如果处于不同VPC，则必须通过云企业网将两个VPC网络打通。

添加操作十分简单。登录ASM控制台，单击目标实例名称，在左侧导航栏中找到Kubernetes集群菜单，单击添加按钮。在添加Kubernetes集群页面中，系统会自动筛选出与网格实例处于同一VPC或已通过CEN连通的集群。选中需要添加的集群后单击确定，ASM开始将集群注册到控制平面。注册过程中，请确保集群中运行的代理容器能够访问ASM实例暴露的Istio Pilot地址。如果ASM实例未开放Istio Pilot公网地址，那么集群节点必须能通过VPC路由访问到该地址。添加成功后，网格管理页面中的实例状态会从更新中变为运行中，Kubernetes集群页面会显示已添加集群的信息。

需要说明的是，ASM实例支持同时添加多个ACK集群，这些集群可以分布在不同的VPC甚至不同的地域，只要网络层面通过CEN打通即可。多集群添加完成后，ASM可以为这些集群提供统一的服务发现、流量管理和可观测性。

Sidecar自动注入：业务应用无感知接入

将集群添加到ASM实例之后，并不代表集群内的服务自动具备了网格能力——还需要将数据平面的Envoy代理注入到业务Pod旁。Sidecar自动注入通过Kubernetes的Admission Webhook机制实现。ASM会为每个注入范围内的Pod自动添加一个名为istio-proxy的容器，该容器劫持所有进出Pod的网络流量，执行流量路由、负载均衡、熔断、重试以及mTLS加密等策略。

默认情况下，只有启用了自动注入的命名空间内的Pod才会被注入Sidecar。用户可以通过为命名空间打上标签来控制注入策略，例如为命名空间default添加istio-injection=enabled标签即可启用自动注入。对于生产环境，通常建议在特定的命名空间（如应用的命名空间而非系统命名空间）上启用注入，以避免istio-system等控制平面命名空间内不必要的代理注入。

注入完成后，业务应用中的服务调用将由Envoy接管。ASM支持声明式的流量管理：通过创建VirtualService资源定义路由规则，通过DestinationRule资源定义负载均衡策略、熔断阈值和连接池配置。所有这些资源的变化会由控制平面的Istiod实时推送到每个数据平面的Envoy代理中，整个过程对业务应用完全透明。

一个典型的DestinationRule配置示例展示了连接池和熔断设置：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews-dr
spec:
  host: reviews
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 10
        http2MaxRequests: 1000
    outlierDetection:
      consecutiveErrors: 7
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

南北向网关与东西向网关：统一的流量入口

ASM网关是Istio中管理网格边缘流量的关键组件，分为南北向网关（处理外部到网格内部的入口流量）和东西向网关（处理网格内部服务之间的流量，即Waypoint代理）。ASM托管了网关的生命周期管理，用户无需手动部署网关Pod，只需通过控制台或YAML声明网关配置即可。

创建南北向网关时，用户需要指定网关名称、部署的集群、监听的端口和协议、以及是否启用TLS等参数。ASM支持将网关同时部署在多个集群中，并为每个集群中的网关Pod绑定独立的CLB实例。这样做的好处是，当某个集群发生故障时，可以通过DNS解析将流量切换到健康集群的网关入口，实现跨地域的高可用。ASM网关还支持优雅下线、HPA自动扩缩容、无损升级流量、TLS配置优化等高级特性。

对于南北向入口流量管理，ASM与Gateway API的集成尤其值得关注。ASM全面支持Kubernetes Gateway API规范，并已被Conformance Reports收录。用户可以通过Gateway API资源替代传统的Istio Gateway资源来管理入口流量，以下示例展示了一个监听80端口的南北向网关配置：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: prod-gateway
  namespace: istio-system
spec:
  gatewayClassName: istio
  listeners:
  - name: http
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: All

东西向网关（Waypoint代理）是Ambient模式下的核心组件。在默认命名空间下创建Waypoint网关后，可以通过为命名空间添加istio.io/use-waypoint=waypoint标签，将访问该命名空间下所有服务的流量都通过Waypoint代理进行管理。Waypoint还可以作为出口网关，将外部服务注册为ServiceEntry，并使所有对该服务的访问经过Waypoint，以便施加重试、超时、熔断、访问控制和可观测采集等策略。

多集群统一网关与跨地域容灾

对于部署在多个ACK集群中的同一应用，ASM提供了统一入口网关的能力。用户可以将一个ASM网关配置为同时部署在多个集群中，此时ASM会在每个目标集群中创建网关Pod和对应的Service资源，并为每个Service挂载一个独立的CLB实例，因此多集群网关会对外暴露多个IP地址。

多集群网关的配置可以在创建时直接选择多个部署集群，也可以通过将单集群网关修改为多集群网关来实现。以下YAML展示了如何创建一个覆盖两个ACK集群的入口网关：

apiVersion: istio.alibabacloud.com/v1beta1
kind: IstioGateway
metadata:
  name: ingressgateway-multi-cluster
  namespace: istio-system
spec:
  clusterIds:
  - c87e370627c3f4e62ac77a7*********
  - c877e9b78610a419e833f22*********
  gatewayType: ingress
  ports:
  - name: http-0
    port: 80
    protocol: HTTP
    targetPort: 80

在多集群场景下，跨地域的容灾是另一个关键能力。ASM提供了基于地理位置感知的流量管理功能，支持跨地域流量分布和跨地域故障转移。当某个地域的服务不可用时，ASM可以自动将流量切换到健康地域的服务实例上。更进一步，ASM可以与全局流量管理服务结合，通过DNS解析将域名分别解析到多个集群入口网关的IP地址，并在某个地域故障时将故障IP从DNS中剔除，实现地域级的容灾切换。

可观测性体系：日志、指标与链路追踪三级配置

服务网格的价值不仅在于流量治理，更在于它为微服务架构带来的端到端可观测能力。ASM提供了统一的可观测配置功能，涵盖日志、监控指标和链路追踪三个维度。用户可以通过ASM控制台在全局、命名空间或指定工作负载三个层级上自定义可观测配置，例如日志输出格式、指标维度、是否启用特定监控指标、链路追踪采样率等。

在日志方面，ASM数据平面的Envoy代理会将访问日志输出到容器标准输出，用户可以通过日志服务或kubectl logs命令查看。ASM支持自定义日志格式和日志过滤，帮助用户从海量日志中快速筛选出关键信息。在监控指标方面，ASM集成了可观测监控Prometheus版，开通ARMS后可以一键为ACK集群安装Prometheus监控插件，并通过预定义的仪表板监控服务网格的众多性能指标。

链路追踪是分布式应用中排查性能瓶颈的利器。ASM集成了阿里云可观测链路OpenTelemetry版，Envoy代理自动生成和发送Span信息。但需要注意的是，为了让这些Span能够正确关联到同一个追踪链路中，应用程序需要在跨服务调用时传播特定的HTTP标头。ASM支持B3传播器和W3C Trace Context传播器两种标头格式。ASM在1.18.0.124版本之前默认采用B3传播器，之后默认采用W3C Trace Context传播器。

以下Python代码示例展示了如何在应用中提取和传播B3追踪标头：

def getForwardHeaders(request):
    headers = {}
    span = get_current_span()
    carrier = {}
    tracer.inject(
        span_context=span.context,
        format=Format.HTTP_HEADERS,
        carrier=carrier
    )
    headers.update(carrier)
    incoming_headers = ['x-request-id']
    for ihdr in incoming_headers:
        val = request.headers.get(ihdr)
        if val is not None:
            headers[ihdr] = val
    return headers

以下Java代码片段展示了如何从HTTP请求中接收B3追踪标头：

@GET
@Path("/reviews/{productId}")
public Response bookReviewsById(
    @PathParam("productId") int productId,
    @HeaderParam("x-b3-traceid") String xtraceid,
    @HeaderParam("x-b3-spanid") String xspanid,
    @HeaderParam("x-b3-parentspanid") String xparentspanid) {
    // 业务处理逻辑
}

可观测配置还支持Telemetry资源对象进行声明式管理。ASM内置最佳实践：在istio-system命名空间内只允许存在一个名为default的Telemetry资源对象用于全局配置，每个命名空间下也只允许一个选择器为空的Telemetry对象。如果要为特定工作负载覆盖配置，可以通过在工作负载所在命名空间中创建带有selector的Telemetry对象来实现。

高级流量治理：Hash Tagging实现全链路灰度

基于权重的流量切分只能按请求百分比进行分流，无法保证同一个用户的多次请求始终访问同一个服务版本。这在需要保持会话一致性的场景下会引发严重问题：一个用户在某次请求中获得v2版本的响应，下次刷新却进入了v1版本，导致用户体验割裂。ASM的Hash Tagging插件正是为解决这一痛点而生。

Hash Tagging插件的工作流程分为四步：首先在入口网关上根据稳定的用户标识符为每个请求打上标签，然后通过ASMHeaderPropagation机制将该标签在整个调用链中传递，随后每个下游服务读取标签并根据标签路由到对应的服务版本，最终实现多个服务版本在同一调用链上同时并行运行的效果。Hash Tagging插件允许不同的服务以完全独立的灰度比例进行发布，互不干扰。

这一特性的典型应用场景是复杂微服务环境中的多团队并行发布。例如，团队A需要将app-a的v2版本暴露给10%的用户，同时团队B需要将app-c的v3版本暴露给50%的用户来修复一个紧急缺陷。传统的基于权重的灰度无法同时满足这两个独立的灰度比例，而Hash Tagging插件可以在入口网关为每个请求附加多个独立的标签，每个需要灰度的服务都通过匹配自己的标签来路由到正确的版本，最终实现多团队在同一个调用链上独立、并行地发布版本。

零信任安全架构：mTLS与身份认证

ASM为微服务架构落地零信任安全模型提供了完整的基础设施支撑。零信任安全的核心原则是所有访问都必须经过强身份认证、基于上下文的授权、加密传输，并且所有访问行为都必须被记录和监控。ASM通过Istio的安全功能天然实现了这些目标。

ASM支持通过一键式操作开启相互TLS，实现网格内服务间通信的端到端加密。当mTLS启用时，Envoy代理会为所有服务间的通信建立加密通道，并自动为通信双方颁发和轮换证书，业务应用无需任何改造。同时，ASM支持基于Kubernetes Service Account的身份认证和基于AuthorizationPolicy的细粒度访问控制，可以实现服务级的白名单策略和基于JWT的用户身份认证。

ASM还将身份认证和授权系统作为服务部署在网格中，这些安全系统从网格本身也能获得安全保证，包括传输加密、身份识别、策略执行点以及终端用户凭证的认证和授权。这种架构确保安全系统本身不会成为整个网格中最薄弱的环节。

生态集成：Knative、KServe与Serverless网关

ASM与阿里云容器服务ACK及ACK Serverless的Knative Serving能力紧密集成，简化了在多集群环境中部署和管理Serverless应用服务的过程。对于涉及自动扩缩容和按需计费需求的场景，Knative on ASM提供了一站式解决方案。用户只需在Knative页面的组件管理下单击一键部署Knative，在服务网关处选择ASM即可完成集成。部署成功后，ASM网关为Knative提供Revisions流量分发，支持gRPC服务、超时和重试、TLS认证以及外部认证授权等高级功能。

ASM Serverless网关是ASM推出的全新网关形态，更适合应对突发流量场景。与传统部署于ACK数据平面集群之上的ASM网关不同，ASM Serverless网关以Serverless形式单独部署，完全由ASM管理，具备独立于ACK Kubernetes集群的高可用性。其核心优势包括高稳定性、高弹性以及低成本，特别适合流量具有明显波峰波谷特征的应用场景。

ASM还与KServe等AI服务框架集成，支持在服务网格中部署和治理机器学习推理服务，为AI场景下的流量路由、灰度发布和可观测性提供了统一的基础设施层。

ACK One Fleet统一多集群管理

对于同时管理多个ACK集群的企业用户，ACK One Fleet实例提供了更高效的统一管理方式。用户可以在ACK One Fleet实例中开启服务网格功能，将服务网格控制面与Fleet实例绑定，然后通过Fleet实例将多个关联集群添加到同一个服务网格中。这种方式进一步简化了多集群场景下ASM实例与ACK集群的管理关系，特别适合需要统一应用分发和跨集群流量治理的企业级场景。

当Fleet实例中的服务网格开启后，用户可以直接在Fleet层面定义流量管理规则，这些规则会自动下发给所有关联集群中的数据平面代理，实现一致性的跨集群流量治理策略。结合跨地域容灾能力，Fleet实例+ASM的组合为大规模分布式系统提供了完整的多集群管理方案。

服务升级与生命周期管理

ASM实例的版本升级是保证网格安全性和稳定性的必要操作。升级可以通过ASM控制台完成：在网格管理页面单击目标实例右侧操作列下的规格变更或版本升级即可。ASM原则上保持三个月一次的大版本迭代频率，用户应密切关注版本过期时间，在过期前完成升级。

从集群中移出ASM的操作同样需要谨慎。当某个集群不再需要使用服务网格时，用户可以在Kubernetes集群页面选中待移出的集群并单击移出。移出后，该集群将无法使用服务网格，但在移出前已经运行的Sidecar容器不会被自动清理，需要用户手动删除相关资源的注入标签并重启Pod来完全恢复原状。

ASM实例本身也支持删除操作，删除时会自动清理创建时生成的安全组、VPC路由规则、RAM角色和CLB资源，但需要注意删除ASM实例不会影响数据平面集群和其中的业务应用，只是网格治理能力将从集群中被移除。

问答

问：ASM的Sidecar自动注入会影响业务应用的性能吗？
答：Envoy代理会引入一定的CPU和内存开销，但通常远低于业务应用的资源消耗。在常规配置下，每个Sidecar容器大约消耗0.1到0.5个CPU核心和几十MB到几百MB的内存。对于高吞吐场景，可通过调整Sidecar资源配额和开启Sidecar资源限流来优化。

问：ASM企业版和旗舰版在流量治理能力上有哪些核心区别？
答：企业版支持Sidecar模式下的多集群跨地域管理，最多管理1,000个Pod；旗舰版支持最大10,000个Pod，在控制平面性能、并发配置下发速度、大规模服务发现等方面有显著优化，适合超大规模生产环境使用。

问：添加跨VPC的ACK集群到ASM实例后，入口网关无法访问，如何排查？
答：首先确认云企业网是否已正确配置并成功打通VPC网络；其次检查ASM实例创建时是否开放了Istio Pilot公网地址，若未开放则集群节点须通过VPC内部网络访问Pilot；最后检查安全组规则是否允许来自集群节点CIDR的入方向访问。

问：如何在不重启Pod的情况下更新ASM的流量治理规则？
答：ASM的流量治理规则通过Istio CRD资源定义，更新VirtualService或DestinationRule后，控制平面的Istiod会自动将新规则推送到所有数据平面的Envoy代理中，整个过程Pod无需重启，业务应用完全无感知。

问：ASM支持哪些类型的Kubernetes集群接入？
答：在Sidecar模式下，ASM支持ACK托管集群、ACK专有集群、ACK Serverless集群、ACK边缘集群、ACS容器计算服务集群以及外部注册的Kubernetes集群。在Ambient模式下，仅支持ACK托管集群。

问：ASM Serverless网关与传统ASM网关相比，成本优势体现在哪里？
答：传统ASM网关部署于ACK集群中，需要预先分配ECI实例资源，在流量低谷时仍然占用计算资源并产生费用。ASM Serverless网关按实际流量自动弹性伸缩，没有流量时网关Pod可缩容至零，大幅降低了流量波动场景下的计算成本。