共计 5885 个字符，预计需要花费 15 分钟才能阅读完成。
文|王发康 （花名：毅松）
蚂蚁团体技术专家、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 吗:https://mp.weixin.qq.com/s/v774kTV46dxBc6_n2c5A_w
[2] 蚂蚁 ServiceMesh 在 Sidecar 资源管理：https://www.sofastack.tech/blog/service-mesh-practice-in-production-at-ant-financial-part3-operation
[3] 开启云原生 MOSN 新篇章 — 交融 Envoy 和 GoLang 生态：https://www.sofastack.tech/blog/opening-a-new-chapter-of-cloud-native-mosn-converging-envoy-and-golang-ecosystems
[4] Zero Trust Networking：https://en.wikipedia.org/wiki/Zero_trust_security_model
[5] 一种过程内的多租户插件隔离与通信技术：http://www.soopat.com
[6] ambient-mesh：https://istio.io/latest/blog/2022/introducing-ambient-mesh
[7] HPA：https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale
[8] VPA：https://www.kubecost.com/kubernetes-autoscaling/kubernetes-vpa
[9] Container Lifecycle Hooks：https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks
[10] Envoy’s L7 Go extension API：https://github.com/envoyproxy/envoy/pull/22573
理解更多
MOSN Star 一下✨： https://github.com/mosn/mosn/
本周举荐浏览
Service Mesh 的下一站是 Sidecarless 吗？
社区文章|MOSN 构建 Subset 优化思路分享
cgo 机制 – 从 c 调用 go
如何对待 Dapr、Layotto 这种多运行时架构？
