电子商务|阿里巴巴服务网格技术三位一体战略背后的思考与实践( 五 ) 广州市

用户可以通过 ASM 控制台、OpenAPI、声明式云原生 API、数据面和控制面 Kubeconfig 使用服务网格技术。通过服务网格 ASM 在控制面和管控面的打磨，可以为运行在异构计算基础设施上的服务提供统一的网格化治理能力（Anywhere Service Mesh），从入口网关到数据面 Sidecar 注入，支持容器服务 ACK、Serverless kubernetes、边缘集群和外部注册 Kubernetes 集群，以及 ECS 虚拟机等多种基础设施。
服务网格 ASM 的功能设计
基于 ASM 的流量打标和标签路由实现全链路灰度。微服务软件架构下，业务新功能上线前搭建完整的一套测试系统进行验证是相当费人费时的事，随着所拆分出微服务数量的不断增大其难度也愈大。基于“流量打标”和“按标路由” 能力是一个通用方案，可以较好地解决测试环境治理、线上全链路灰度发布等相关问题。并且基于服务网格技术可以做到与开发语言无关，该方案适应于不同的 7 层协议，当前服务网格 ASM 已经支持 HTTP/gRpc 和 Dubbo 协议。在 ASM 中引入了全新的 TrafficLabel CRD 用于定义 Sidecar 所需透传的流量标签从哪里获取，全链路流量控制进行逻辑隔离，对流量进行打标（染色）和按标路由，通过使用服务网格 ASM ，无需每位技术研发人员部署一整套环境，实现多环境治理，大幅度降低研发成本。

服务网格 ASM 支持实现金丝雀发布。发布是整个功能更新到线上的最后一个环节，一些研发过程中累计的问题，在最后发布环节才会触发。同时发布本身也是一个复杂的过程，在发布过程中，往往容易出现一些错误操作或者遗漏关键操作。金丝雀发布配置灵活，策略自定义，可以按照流量或具体的内容进行灰度（比如不同账号，不同参数），出现问题不会影响全网用户。图中给应用打上环境标签，通过 TrafficLable 对用户流量比如对 http-header: user-id % 100 == 20 打上 gray 标签，同时通过 VirtualService 下发标签流量路由规则，所以 userId 为 120 的用户流量会被路由到 gray 灰度环境， userId 为 121 的用户流量被路由到 normal 正常环境。服务网格 ASM 实现的金丝雀发布支持按流量百分比路由，按请求特征（如 http header 方法参数等）路由，并且和服务网格入口网关完美集成，支持 HTTP/gRPC/Dubbo 协议。
除了使用流量打标和标签路由得实现全链路灰度和金丝雀发布，服务网格 ASM 也支持和 KubeVela 结合实现渐进式发布。 KubeVela 是一个开箱即用的、现代化的应用交付与管理平台，能够简化面向混合环境的应用交付过程；同时又足够灵活可以随时满足业务不断高速变化所带来的迭代压力。 KubeVela 后的应用交付模型 Open Application Model（OAM）是一个从设计与实现上都高度可扩展的模型，具有完全以应用为中心、可编程式交付工作流、与基础设施无关的特点。阿里云服务网格 ASM 支持结合 KubeVela 进行复杂的金丝雀发布流程可以将 KubeVela 定义的相关配置转化为流量治理规则下发到数据面。

阿里云服务网格 ASM 实现了零信任安全能力。在微服务网络中使用 HTTP 通信的交互并不安全，一旦内部的某个服务被攻陷，攻击者能够以该机器为跳板来攻击内网。服务网格 ASM 能够减小云原生环境中的被攻击面积，并提供零信任应用网络所需的基础框架。通过 ASM 管理服务到服务的安全性，可以确保服务网格的端到端加密、服务级别身份认证和细粒度授权策略。
相比传统的在应用程序代码中构建安全机制， ASM 零信任安全体系具有以下优势：
ASM Sidecar 代理的策略生命周期与应用程序保持独立，因此可以更轻松地管理这些 Sidecar 代理。ASM 支持动态配置策略，更新策略变得更加容易，更新立即生效而无需重新部署应用程序。ASM 提供了对附加到请求的终端用户凭据进行身份验证的能力，例如 JWT 。ASM 的集中控制架构使企业的安全团队可以构建、管理和部署适用于整个企业的安全策略。将身份验证和授权系统作为服务部署在网格中，如同网格中的其他服务一样，这些安全系统从网格中本身也可以得到安全保证，包括传输中的加密、身份识别、策略执行点、终端用户凭据的身份验证和授权等。策略控制面定义并管理多种类型的认证策略；网格控制面赋予网格中工作负载身份，并自动轮转证书；数据面的 Sidecar 代码执行策略。图中用户配置规则只允许交易服务发起调用订单服务，拒绝购物车服务调用订单服务。