作者：王夕宁
本文内容基于作者在 2022 年云原生产业大会上的演讲内容整顿而成。
背景
回顾下应用服务架构体系的演进。从服务调用方与提供方的解决形式来看, 能够分为 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/…
[2] Argo Rollouts：
https://developer.aliyun.com/…
[3] KubeVela：
https://help.aliyun.com/docum…
[4] 阿里云云效流水线 Flow：
https://help.aliyun.com/docum…
[5] Flagger：
https://docs.flagger.app/inst…
[6] 微服务框架兼容：
https://developer.aliyun.com/…
[7] Serverless 容器与基于流量模式的主动扩缩：
https://developer.aliyun.com/…
[8] AI Serving：
https://developer.aliyun.com/…
[9] 零信赖平安及 Policy As Code：
https://developer.aliyun.com/…
[10] AI Serving 的示例：
https://developer.aliyun.com/…