托管式服务网络：云原生时代的应用体系架构进化

背景

回顾下应用服务架构体系的演进。从服务调用方与提供方的处理方式来看, 可以分为 3 个阶段。

第一个阶段是集中式负载均衡, 也就是说服务调用方是通过一个外部的负载均衡路由到对应的服务提供方。其优势显而易见, 对应用本身无侵入, 可以支持多语言多框架来开发实现应用本身, 负载均衡统一集中管理, 整个部署简单。但劣势也非常显著, 因为是集中式所以导致伸缩性受限, 同时这种集中式负载均衡的服务治理能力相对都较弱。

第二阶段是指微服务的分布式治理, 即服务调用方内置治理能力, 以 SDK 库的方式集成到应用中。带来的优势是整个伸缩性较好, 服务治理能力强, 但同时会注意到它的劣势, 包括对应用本身的侵入、因为依赖于 SDK 所以导致对多语言支持比较困难、分布式管理部署带来的复杂性等。

第三阶段就是现在的服务网格技术。通过把这些服务治理的能力 Sidecar 化，就能够把服务治理的能力与应用程序本身进行了解耦，可以较好地支持多种编程语言、同时这些 Sidecar 能力不需要依赖于某种特定技术框架。这些 Sidecar 代理形成一个网状的数据平面，通过该数据平面处理和观察所有服务间的流量。控制面对这些 Sidecar 代理进行统一管理。但因此带来了一定的复杂度。

下图是服务网格的架构图。前面提到, 在服务网格技术下, 每一个应用服务实例都会伴随了一个 Sidecar 代理, 业务代码不感知 Sidecar 的存在。这个 Sidecar 代理负责拦截应用的流量，并且提供流量治理、安全、可观测三大功能。

在云原生应用模型中，一个应用程序可能会包含若干个服务，每个服务又有若干个实例构成，那么这些成百上千个应用程序的 Sidecar 代理就形成了一个数据面, 也就是图中的数据平面层。

而如何统一管理这些 Sidecar 代理, 这就是服务网格中的控制平面部分要解决的问题。控制平面是服务网格的大脑，负责为数据平面的 Sidecar 代理下发配置, 管理数据面的组件如何执行, 同时也为网格使用人员提供统一的 API，以便较容易地操纵网格管理能力。

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

服务网格加持下的云原生应用基础设施

服务网格作为一种用来管理应用服务通信的基础核心技术, 为应用服务间的调用带来了安全、可靠、快速、应用无感知的流量路由、安全、可观测能力。

可以看到, 服务网格加持下的云原生应用基础设施带来了重要的优势, 分为六个方面。

优势之一：异构服务统一治理

• 多语言多框架的互通与治理、与传统微服务体系融合的双模架构

• 精细化的多协议流量控制、东西向与南北向流量的统一管理

• 统一的异构计算基础设施的自动服务发现

优势之二：端到端的可观测

• 日志、监控与跟踪融合的一体化智能运维

• 直观易用的可视化网格拓扑、基于颜色标识的健康识别体系

• 内置最佳实践、自助式网格诊断

优势之三：零信任安全

• 端到端 mTLS 加密、基于属性的访问控制 (ABAC)

• OPA 声明式策略引擎、全局唯一的工作负载身份（Identity）

• 带有仪表板的完整审计历史记录及洞察分析

优势之四：软硬结合性能优化

• 首个基于 Intel Multi-Buffer 技术提升 TLS 加解密的服务网格平台

• NFD 自动探测硬件特征, 自适应支持诸如 AVX 指令集、QAT 加速等特性

• 首批通过可信云服务网格平台以及性能评测先进级认证

优势之五：SLO 驱动的应用弹性

• 服务级别目标 (SLO) 策略

• 基于可观测性数据的应用服务的自动弹性伸缩

• 多集群流量突发下的自动切换与故障容灾

优势之六：开箱即用扩展&生态兼容

• 开箱即用的 EnvoyFilter 插件市场、WebAssembly 插件全生命周期管理

• 与 Proxyless 模式的统一融合, 支持 SDK、内核 eBPF 方式

• 兼容 Istio 生态系统, 支持 Serverless/Knative, AI Serving/KServe

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

托管式服务网格 ASM 在成为多种异构类型计算服务统一管理的基础设施中, 提供了统一的流量管理能力、统一的服务安全能力、统一的服务可观测性能力、以及基于 WebAssembly 实现统一的代理可扩展能力, 以此构筑企业级能力。

服务网格技术的下一站如何发展

Sidecar Proxy 与 Proxyless 模式的融合一句话来总结的话，就是同一个控制面, 支撑不同的数据面形态。同一个控制面就是指使用 ASM 托管侧组件作为统一的标准形式的控制入口, 这个控制面运行在阿里云侧，属于 hosted 托管模式。

而数据面支持 Sidecar Proxy 与 Proxyless 模式的融合, 其中数据面的组件虽然不是 hosted 托管模式, 但是也是 managed 模式, 也就是说这些组件的生命周期也是由 ASM 统一来管理, 包括分发到数据面、升级、卸载等。

具体来说, 在 Sidecar Proxy 模式下, 除了当前标准的Envoy代理之外, 我们的架构可以比较容易地支持其他 Sidecar, 譬如说 Dapr Sidecar, 当前微软 OSM+Dapr 就是采用了这种双 Sidecar 模式。

在 Proxyless 模式下, 为了提升 QPS 降低时延, 可以使用 SDK 方式, 譬如 gRPC 已经支持 xDS 协议客户端, 我们的 Dubbo 团队也在这条路上。我想今年我和北纬团队双方是可以一起在这个点上进行一些突破实现。

另外一个 proxyless 模式, 就是指- 内核 eBPF + Node 级 Proxy 方式。这个模式是对 sidecar 模式的一个根本性改变, 一个节点只有一个 Proxy，并且能力 offload 到节点上。这部分我们今年也会有些产品落地。

围绕服务网格技术, 业界存在着一系列以应用为中心的生态系统, 其中, 阿里云托管服务网格 ASM 支持了以下多种生态系统。列举如下：

现代化软件开发的生命周期管理和 DevOps 创新

服务网格的核心原则（安全性、可靠性和可观察性）支持了现代化软件开发的生命周期管理和 DevOps 创新, 为在云计算环境下如何进行架构设计、开发、自动化部署和运维提供了灵活性、可扩展性和可测试性能力。由此可见, 服务网格为处理现代软件开发提供了坚实的基础，任何为 Kubernetes 构建和部署应用程序的团队都应该认真考虑实施服务网格。

DevOps 的重要组成部分之一是创建持续集成和部署 (CI/CD)，以更快更可靠地向生产系统交付容器化应用程序代码。在 CI/CD Pipeline 中启用金丝雀或蓝绿部署可为生产系统中的新应用程序版本提供更强大的测试，并采用安全回滚策略。在这种情况下，服务网格有助于在生产系统中进行金丝雀部署。当前阿里云服务网格 ASM 支持了与 ArgoCD、Argo Rollout、KubeVela 以及云效、Flagger 等系统的集成实现了应用的蓝绿或金丝雀发布, 具体如下：

ArgoCD[1] 职责主要是监听 Git 仓库中的应用编排的变化，并集群中应用真实运行状态进行对比，自动/手动去同步拉取应用编排的变更到部署集群中。如何在阿里云服务网格 ASM 中集成 ArgoCD 进行应用程序的发布、更新，简化了运维成本。

Argo Rollouts[2] 提供了更强大的蓝绿、金丝雀部署能力。在实践中可以将两者结合来提供基于 GitOps 的渐进式交付能力。

KubeVela[3] 是一个开箱即用的、现代化的应用交付与管理平台。使用服务网格 ASM 结合 KubeVela 可以实现应用的渐进式灰度发布，达到平缓升级应用的目的。

阿里云云效流水线 Flow[4] 提供了基于阿里云服务网格 ASM 完成 Kubernetes 应用的蓝绿发布。

Flagger[5] 是另外一种渐进式交付工具，可自动执行在 Kubernetes 上运行的应用程序的发布过程。它通过在测量指标和运行一致性测试的同时，逐渐将流量转移到新版本，降低了在生产中引入新软件版本的风险。阿里云服务网格 ASM 已经支持通过 Flagger 实现这种渐进式发布能力。

微服务框架兼容[6]

支持 Spring Boot/Cloud 应用无缝迁移至服务网格进行统一纳管和治理, 提供了融合过程中出现的典型问题解决能力, 包括容器集群内外服务如何互通、不同的语言服务之间如何进行互联互通等常见场景。

Serverless 容器与基于流量模式的自动扩缩[7]

Serverless 和 Service Mesh 是两种流行的云原生技术，客户正在探索如何从中创造价值。随着我们与客户深入研究这些解决方案，问题经常出现在这两种流行技术之间的交集以及它们如何相互补充上。我们能否利用 Service Mesh 来保护、观察和公开我们的 Knative 无服务器应用程序？在一个托管的服务网格 ASM 技术平台上支持基于 Knative 的 Serverless 容器, 以及基于流量模式的自动扩缩能力, 从中可以替换如何通过托管式服务网格来简化用户维护底层基础设施的复杂度, 让用户可以轻松地构建自己的 Serverless 平台。

AI Serving[8]

Kubeflow Serving 是谷歌牵头发起的一个基于 Kubernetes 支持机器学习的社区项目，它的下一代名称改为 KServe, 该项目的目的是可以通过云原生的方式支持不同的机器学习框架，基于服务网格实现流量控制和模型版本的更新及回滚。

零信任安全及 Policy As Code[9]

在使用 Kubernetes Network Policy 实现三层网络安全控制之上，服务网格 ASM 提供了包括对等身份和请求身份认证能力、Istio 授权策略以及更为精细化管理的基于 OPA(Open Policy Agent) 的策略控制能力。

具体来说, 构建基于服务网格的零信任安全能力体系包括了以下几个方面：

零信任的基础：工作负载身份；如何为云原生工作负载提供统一的身份；ASM 产品为服务网格下的每一个工作负载提供了简单易用的身份定义，并根据特定场景提供定制机制用于扩展身份构建体系, 同时兼容社区 SPIFFE 标准；
零信任的载体：安全证书，ASM 产品提供了如何签发证书以及管理证书的生命周期、轮转等机制，通过 X509 TLS 证书建立身份，每个代理都使用该证书。并提供证书和私钥轮换；
零信任的引擎：策略执行，基于策略的信任引擎是构建零信任的关键核心，ASM 产品除了支持 Istio RBAC 授权策略之外，还提供了基于 OPA 提供更加细粒度的授权策略；
零信任的洞察：视化与分析，ASM 产品提供了可观测机制用于监视策略执行的日志和指标，来判断每一个策略的执行情况等；

改造为云原生应用带来的业务价值非常多，其中一个就是弹性扩缩容，它能够更好地应对流量峰值和低谷，达到降本提效的目的。服务网格 ASM 为应用服务间通信提供了一种非侵入式的生成遥测数据的能力, 指标获取不需要修改应用逻辑本身。

根据监控的四个黄金指标维度（延迟、流量、错误和饱和度），服务网格 ASM 为管理的服务生成一系列指标, 支持多个协议, 包括 HTTP，HTTP/2，GRPC，TCP 等。

此外, 服务网格内置了 20 多个监控标签, 支持所有 Envoy 代理指标属性定义、通用表达式语言 CEL, 支持自定义 Istio 生成的指标。

同时，我们也在探索拓宽服务网格驱动的新场景，这里举一个AI Serving的示例[10] 。

这个需求来源也是来自我们的实际客户, 客户的使用场景就是希望在服务网格技术之上运行 KServe 来实现 AI 服务。KServe 平滑运行于服务网格之上, 实现模型服务的蓝/绿和金丝雀部署、修订版本之间的流量分配等能力。支持自动伸缩的 Serverless 推理工作负载部署、支持高可扩展性、基于并发的智能负载路由等能力。

总结

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

从 2022 年 4 月 1 日起，阿里云服务网格 ASM 正式推出商业化版本, 提供了更丰富的能力、更大的规模支持及更完善的技术保障，更好地满足客户的不同需求场景。

参考链接：

[1] ArgoCD：

https://developer.aliyun.com/article/971976

[2] Argo Rollouts：

https://developer.aliyun.com/article/971975

[3] KubeVela：

https://help.aliyun.com/document_detail/337899.html

[4] 阿里云云效流水线 Flow：

https://help.aliyun.com/document_detail/160071.html

[5] Flagger：

https://docs.flagger.app/install/flagger-install-on-alibaba-servicemesh