文｜王发康 （诨名：毅松 ）
蚂蚁集团技能专家、MOSN 项目核心开发者
深耕于高功能网络服务器研制，现在专心于云原生 ServiceMesh、Nginx、MOSN、Envoy、Istio 等相关领域。
本文 5574 字 阅览 14 分钟
前言
从单体到分布式，处理了日益增长的事务在单体架构下的系统臃肿问题；从分布式到微服务，处理了服务化后的服务办理问题；从微服务到服务网格，处理了运用和基础设施耦合下的研制效能及稳定性问题。
从微服务架构的演进历史来看，任何架构都不是一成不变，总是跟着运用在不同阶段的痛点以及周边技能的开展而持续演进，而服务网格 （ServiceMesh） 概念从提出到出产落地至今已 6 年多了，那它的下一代架构应该是什么样？对此业界也有不同的声响 Service Mesh 的下一站是 Sidecarless 吗[1] ，本文首要介绍蚂蚁在这方面的探究和实践，终究怎么帮事务降本增效，提高安全保证水位。
一、 问题及应战
谈起 ServiceMesh，咱们的脑海中应该会呈现出下面这幅图，即 ServiceMesh 的 Sidecar 形状，它非常好的处理了运用和基础设施耦合下的系列问题，为事务的提效及稳定性等方面然禹功不行没。
可是跟着 ServiceMesh 的规模化增大，Sidecar 架构也随之露出了一些劣势，比如运用和 Sidecar 资源耦合导致彼此抢占、生命周期绑定，导致运用扩缩容触及额定 Sidecar 容器的创立及毁掉开支、Sidecar 数量跟着运用 Pod 数等比添加，导致其资源无法充沛复用等。
引证 redhat.com/architect/why-when-service-mesh
1.1 资源耦合
Sidecar 形状尽管从代码维度是解耦了基础设施与运用的耦合，可是在资源方面现在仍然是和运用 Pod 绑定在一起，这就导致其资源办理成为一个难题。对此蚂蚁 ServiceMesh 在 Sidecar 资源办理[2] 进行改进，处理了初期的资源分配及办理。但跟着事务的开展也露出一些危险，一方面 Sidecar 和运用彼此抢占 CPU 或许导致引发时延毛刺问题，另一方面固定的 1/4 内存资源或许无法满意机房规模增大引发的网络衔接数膨胀等系列问题。
1.2 生命周期绑定
Sidecar 和运用属于同一个 Pod，而 K8s 是以 Pod 为最小单位进行办理的。这导致运用在扩缩容操作时会触及额定 Sidecar 容器的创立及毁掉开支，而 Sidecar 中的进程是基础设施软件本不应该跟着运用的毁掉而毁掉。
1.3 资源复用不充沛
Sidecar 数量跟着运用 Pod 数等比添加，而 Sidecar 上运转的都是基础设施通用才能，这将导致 Sidecar 中运用无关逻辑的 CPU 和内存等开支都在每个 Pod 中重复消耗。另外关于一些天性经过软件会集优化或硬件会集卸载的计数也无法充沛施展。
1.4 安全及事务侵入性
Sidecar 同运用同属一个 Pod，这无论关于 Sidecar 仍是运用本身都是增大了安全攻击切面，另一方面 Sidecar 形状的服务办理也不算是彻底事务无感的，至少要做一次 Sidecar 的注入，然后重启运用 Pod 才生效。
二、思考及分析
关于上述 Sidecar 形状下的四个痛点：资源耦合、生命周期绑定、资源复用不充沛、安全及事务侵入性，其实归根结底仍是其架构导致。
假如将 Sidecar 从运用 Pod 中剥离出来，关于资源耦合、生命周期绑定、安全侵入性问题都会方便的处理，而资源复用粒度取决于剥离后布置的会集化程度。关于剥离后的会集化程度也并不是越会集越好，因为中心化后会添加交互时延以及才能的完整性缺失，所以在中心化和 Sidecar 化之间做一次折中，即经过 Node 化布置形状来处理，这样既能够做到同 Node 上的 Mesh 资源复用，又能够做到网络交互不跨 Node 的相关优化。
尽管处理了 Sidecar 形状下的痛点，可是 Node 化后也引入了一些新的 “问题”。关于问题咱们需要用辩证的眼光去看待，有时问题的背后或许是一个新时机。
比如 Sidecar 形状下的服务发现都是 Pod 等级，跟着 Pod 规模的增大其服务条目成倍速添加，假如 Node 化后服务发现运用 Node IP 这样是不是能够本钱的缩减服务条目，亦到达网络衔接数的复用及收敛。
– 阻隔性、多租户： 多个运用同享 Mesh 后，触及的一些运用维度的配置、内存、CPU 等资源怎么彼此阻隔，另外关于 Sidecar 中各种基础设施组件假如本身来支撑多租户，则改造本钱是不行预估的。
– 服务 pub/sub： 之前 Sidecar 形状下，Sidecar 和 APP 的 IP 是同一个 （Container 网络形式） ，Node 化后 IP 变成 Daemonset 容器的 IP，服务发现应怎么办理？以及 Pod 和 Node 之间的流量怎么办理。
– 运维及安全合规
a. Node 化后触及到 Daemonset 本身以及运用维度的配置晋级发布流程怎么管控，一起呈现毛病时怎么缩小爆破半径；
b. Node 化后触及到的安全合规问题怎么保证，如网络连通性怎么阻隔、身份等；
c. Node 化后，Daemonset 所占用的机器本钱怎么规划 （超卖？独占？） 以及各个运用的资源消耗怎么计算。
三、计划介绍
将运用 Pod 中的 Sidecar 下沉到 Node，以 Daemonset 方法在每个 Node 布置。咱们将该 Daemonset 命名为 NodeSentry，其定位是作为 Node 的网络基础设施，承载网络安全、流量办理、Mesh 下沉、衔接收敛等 Node 相关网络办理渠道。
本文首要介绍 NodeSentry 承载 Mesh 下沉相关计划，Node 化后需要数据面 Proxy 能够高效、稳定的承载多个 Pod 的流量办理。这就要求数据面 Proxy 具有高处理功能及高研制效能，为此咱们在 2021 年就其做了相关技能布局 MOSN2.0，具体介绍见 敞开云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态[3] 。
Mesh 下沉至 NodeSentry 其架构如上图所示，在新的架构下不仅能处理 Sidecar 形状的痛点，一起也具有了如下收益：
– 资源解耦：解耦运用和基础设施的资源配额，多运用的 Mesh 资源池化、削峰填谷；
– 资源复用：同 Node 同运用 Mesh 同享，ingress 方向衔接收敛 、egress 方向衔接同享、Node 级粒度 cache 命中率更高等；
– Node 服务发现体系：处理注册中心等基础设施服务端压力以及调用端的内存消耗；
– 提高发动速度：新架构下运用无需每次都发动 Mesh 的容器及镜像下载、SDK 初始化同享等额定操作；
– 会集优化：云原生 L7 网络协议栈，软硬件结合功能优化，支撑 IPV6，蚂蚁卡，RDMA or QUIC 等；
– 解耦运用和网络： 同 Zero Trust Networking[4] 相关技能结合完结全局调度，有限互通等。
3.1 微阻隔/多租户
利用 MOSN 2.0 的高功能网络处理才能，在其之上以动态库的方法拉起各个运用的 Mesh 实例 （注：多个 Mesh 实例和 MOSN 2.0 是在同一个进程中，如下图所示） 。
在资源上做到各个 Mesh 实例之间 runtime 等级的微阻隔 （如 GC、P、信号等资源） ；在配置方面经过对 runtime 环境变量的绑架做到各个运用实例的差异化；在稳定性上经过绑架 runtime exit 来防止 APP1 的 Mesh 实例挂掉影响 APP2，缩小爆破半径等。
一起也经过单进程多实例的方法支撑了基础设施组件的多租户才能，更多细节见一种进程内的多租户插件阻隔与通讯技能[5] 。微阻隔及多租户架构，如下图所示，当流量从 MOSN 2.0 进来后，经过一定的战略路由到各个运用的 Mesh 实例进行后续处理。
3.2 同运用 Mesh 同享
关于同一个 Node 上同一个运用的多个 Pod 能够同享 NodeSentry 上面的 ServiceMesh 实例，如下图所示运用 A 和 B 各自两个 Pod 分别同享 NodeSentry 上的 2 个 Mesh 实例。
这样既处理了不同运用 Mesh 差异 （如证书等配置、身份信息） ，又到达资源同享，防止同一个运用依靠的资源屡次初始化开支。当然同享后的收益也不止这些，比如网络衔接复用收敛、资源池化削峰填谷以及下降基础设施服务端压力等等。
3.3 流量绑架
流量转发这块分为 ingress 和 egress 场景 （注：基于 APP 侧视角） ，从 Sidecar 演进为 Node 形状后，运用 Pod 和 Mesh 之间的流量转发途径发生了改变。为了屏蔽该改变对事务的感知，咱们经过流量绑架组件将其 Pod 流量绑架到 NodeSentry 上然后分发到对应的 Mesh 实例进行后续的处理。
关于流量绑架组件现在因为蚂蚁这边的容器有多种形状 （runc、runsc、rund 等） 所以单纯的 ebpf 或 tproxy 计划并不适用，当时阶段咱们是经过在运用容器中注入相关的环境变量来显现指定流量转发到 Node 上，未来关于流量绑架这块咱们会经过战略路由的方法来更透明的支撑流量绑架及身份办理。
3.4 资源办理
关于 NodeSentry 资源这块，现在阶段咱们是小规模试点阶段，相关资源是和同 Node 上的 Daemonset 同享的，可是跟着接入运用的增多，这块资源是需要有一定保证的。当时业界 ambient-mesh[6] 经过将 L7 进一步从 Daemonset 剥离到中心化 Gateway 经过 HPA[7] 的思路来处理容量问题。
如下介绍的是 NodeSentry 后续怎么经过 VPA[8] 计划进行 Daemonset 的容量规划。在运用扩容时 NodeSentry 资源如下做 VPA 弹性办理，缩容流程相似：
1、在扩容 Mesh Node 化运用时，Kubectlscheduler 选择资源满意 A+B 的 Node 执行 Pod 调度。
– 代表运用本身需要的资源
– 代表该运用在 mesh 上需要消耗的资源
2、满意条件的 Node 在创立运用 Pod 的一起触发 NodeSentry 资源进行 VPA 弹性扩容。
3.5 运维办理
从 Sidecar 下沉为 Node 形式后，咱们在运用发布运维流程上也做了一些适配，用来屏蔽其流程的改变导致的运维本钱及用户体会问题。
关于运用扩缩容、运用重启、MOSN 重启、MOSN 版本晋级等运维操作经过 Container Lifecycle Hooks[9] 提供的 postStart 和 preStop hook 点嵌入相关交互流程完结 NodeSentry 上的 Mesh 实例办理。
另外一块是 NodeSentry 本身底座晋级，现在是经过 K8s console 触发 Node 上的相关运用关流，然后进行 NodeSentry 晋级，待其过程安排妥当后再康复 APP 引流。该流程尽管能够做到流量无损，但或许会导致个别运用的容量问题，这个咱们后续会经过运用层协议支撑 goaway 等计划来更优雅地做到底座的无损晋级。
四、事务效果
当时 NodeSentry 正在试点阶段，其架构如下图所示。将某运用的 Sidecar 下沉到 NodeSentry 后运用发动提速 37%。
关于 Mesh 资源复用，现在一组 Mesh 裸发动内存占用 200MB~ ，经过亲和调度后现在可做到同运用同 Pod 的 Mesh 复用度为 3~ 即每个 Node 可节约 2~ 个裸 Mesh 占用的资源，一起 Mesh 复用后相关的网络衔接数也是成倍减少。并且跟着接入的运用增多，复用的 Mesh 也会增多，资源节约也会更为客观。
五、未来展望
NodeSentry 承载 Mesh 下沉仅仅开始，接下来除了支撑更多的运用接入，也会支撑更多场景下沉，比如 ODP、Cache、Message 等，一起在计划上也会持续演进，做到更稳定、易用、安全、事务无感。
另外经过 NodeSentry 一致收口 Node 网络流量做相关安全审计、办理、会集优化等，进一步为事务降本增效、提高安全保证水位，结合身份体系，共同构建零信任网络。
MOSN 团队秉着规范、敞开的态度，也将其底层通用才能贡献给 Envoy 官方[10]，方便开发者在 Envoy 之上运用 GoLang 来开发事务相关插件，然后取得高研制效能及高处理功能。一起接下来咱们也会在其规范之上打通 MOSN L4/L7 filter 处理框架，让用户更方便地运用 MOSN filter 及更清爽研制体会。
参阅文档
[1] Service Mesh 的下一站是 Sidecarless 吗:mp.weixin.qq.com/s/v774kTV46…
[2] 蚂蚁 ServiceMesh 在 Sidecar 资源办理：www.sofastack.tech/blog/servic…
[3] 敞开云原生 MOSN 新篇章 — 融合 Envoy 和 GoLang 生态：www.sofastack.tech/blog/openin…
[4] Zero Trust Networking：en.wikipedia.org/wiki/Zero_t…
[5] 一种进程内的多租户插件阻隔与通讯技能：www.soopat.com
[6] ambient-mesh：istio.io/latest/blog…
[7] HPA：kubernetes.io/docs/tasks/…
[8] VPA：www.kubecost.com/kubernetes-…
[9] Container Lifecycle Hooks：kubernetes.io/docs/concep…
[10] Envoy’s L7 Go extension API：github.com/envoyproxy/…
了解更多
MOSN Star 一下✨： github.com/mosn/mosn/
本周推荐阅览
Service Mesh 的下一站是 Sidecarless 吗？
社区文章｜MOSN 构建 Subset 优化思路共享
cgo 机制 – 从 c 调用 go
怎么看待 Dapr、Layotto 这种多运转时架构？
