作者：王夕宁
本文内容根据作者在 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的示例 [ 1****0] 。
这个需求来历也是来自我们的实践客户, 客户的运用场景就是期望在服务网格技术之上工作 KServe 来完结 AI 服务。KServe 滑润工作于服务网格之上, 完结模型服务的蓝/绿和金丝雀安置、修订版别之间的流量分配等才干。支撑自动弹性的 Serverless 推理作业负载安置、支撑高可扩展性、根据并发的智能负载路由等才干。
总结
作为业界首个全保管Istio兼容的阿里云服务网格产品 ASM，一开始从架构上就坚持了与社区、业界趋势的共同性，控制平面的组件保管在阿里云侧，与数据面侧的用户集群独立。ASM 产品是根据社区Istio定制完结的，在保管的控制面侧供应了用于支撑精细化的流量处理和安全处理的组件才干。通过保管方式，解耦了 Istio 组件与所处理的K8s 集群的生命周期处理，使得架构更加灵活，提高了系统的可弹性性。
从 2022 年 4 月 1 日起，阿里云服务网格 ASM 正式推出商业化版别, 供应了更丰厚的才干、更大的规划支撑及更完善的技术保证，更好地满足客户的不同需求场景。
参考链接：
[1] ArgoCD：
developer.aliyun.com/article/971…
[2] Argo Rollouts：
developer.aliyun.com/article/971…
[3] KubeVela：
help.aliyun.com/document_de…
[4]阿里如此效流水线 Flow：
help.aliyun.com/document_de…
[5] Flagger：
docs.flagger.app/install/fla…
[6]微服务结构兼容：
developer.aliyun.com/article/974…
[7] Serverless 容器与根据流量方式的自动扩缩：
developer.aliyun.com/article/975…
[8] AI Serving：
developer.aliyun.com/article/971…
[9]零信任安全及 Policy As Code：
developer.aliyun.com/article/787…
[10] AI Serving的示例：
developer.aliyun.com/article/971…
