为了提升应用迭代效率，应用架构正在由单体架构向微服务架构转型。但服务的拆分带来的数量激增、调用关系复杂等问题，使服务治理的复杂度大幅提升，给微服务架构的落地造成了较大障碍。

ServiceMesh 在此背景下便应运而生了，网格化的方案使得服务间的调用关系、各微服务的状态一目了然，让服务治理变得事半功倍，深受用户地喜爱。然而一个新架构的落地总是会面临各种问题，本文将挑选笔者认为当前 ServiceMesh 落地最主要的三个问题展开讨论。

一.架构选型

1.Sidercar 架构

1.1.架构介绍

一说起 ServiceMesh 这个概念，Istio 几乎会在很多人口中成为它的代名词，可见其强大的影响力。众多商业容器云厂商也是基于开源 Istio 的基础上做一些控制面及安全方面的增强，作为商业产品销售。而 Istio 从技术上来说便是典型的 Sidercar 架构，如下图所示。

Sidercar 架构是指业务容器和代理容器同处于一个 Pod 内，业务容器的进出向流量全部由代理容器代理。业务容器负责业务逻辑本身，代理容器负责服务的治理，包括负载均衡、mTLS、网格信息传递、流控、熔断、访问控制等。业务容器与代理容器的关系用 Sidercar（边车）来形容也是十分贴切的，就像大家看过很多抗日题材的影视剧中鬼子常用的那种挎斗摩托车。

1.2.架构优势

1）.粒度精确

Sidercar 业务容器与代理容器共生的架构先天具备服务精确治理的优势，每一个业务容器独享一个代理容器为其服务，对业务的治理粒度足够精确。针对每一个业务都可以配置适合其需求的业务治理策略，可以更精确的解决业务问题。

2）.安全性

每个业务容器均独享一个代理容器，防止了代理共享导致的业务越权等问题。并可以利用代理容器配置相关的访问控制、安全策略等，安全性得到了保障。

3）.与应用解耦

无需应用进行针对性的开发与适配。

4）.技术栈成熟

Sidercar 的技术栈目前来讲是各种 ServiceMesh 架构中发展最成熟，应用最广泛的。并且，各大商业厂商的产品也大多基于 Sidercar 架构优化，加入了管理、功能、安全等增强项，对该架构落地有重要意义。

1.3.架构缺陷

1）.延时

从拓扑上而言，每个业务容器之间完成一次单向的互访需要经过两次代理容器，而非直接访问。在大量微服务频繁互访的背景下，这种架构大幅度提升了访问延时。针对一些延时敏感类业务如券商的交易系统等，这一点是很致命的。

2）.资源占用

从资源占用角度讲，每个业务容器都有一个代理容器。当微服务的拆分粒度较细时，代理容器的部署数量将会非常大，甚至会出现代理容器的资源占用大于业务容器的情况。

3）.管理难度

同第二点指出的，大规模部署不仅带来资源占用上的挑战，管理难度同样会大幅度增加，代理容器的监控、排障等会比以往困难许多。

2.per-Node 架构

2.1.架构介绍

per-Node 架构顾名思义即为每个 Node 一个代理，相比 Sidercar 架构代理的粒度更粗，代表的产品有 traefik 和 linkerd1.0 等。

2.2.架构优势

1）.延时降低

相比 Sidercar 架构的两次代理，per-Node 架构仅需一次代理，延时有着大幅度的降低。

2）.资源节约

每个 Node 的业务共享一个代理，代理应用对资源的占用大幅度降低。

3）.与应用解耦

无需应用进行针对性的开发与适配。

4）.管理难度降低

整个集群代理应用的规模得到了大幅度的降低，监控排障的运维管理的难度也得到了改善。

2.3.架构缺陷

1）.安全性

不同业务共享一个代理可能会出现不同业务越权、故障影响范围大等安全问题。

2）.资源抢占

Node 级别部署的代理无法像 Sidercar 架构那样针对不同业务使用 cgroup 进行针对性的 CPU 等资源限制，某个业务资源占用过高可能会影响到其他业务的正常运行。

3.ProxyLess 架构

3.1.架构介绍

proxyless 区别于上述的 Sidercar 与 per-Node 架构，它不采用单独的代理应用。典型的 proxyless 方案有 SDK、agent、ebpf 内核处理等方式。

3.2.架构优势

1）.低延时

没有了代理应用导致的延时，应用整体的访问延时可以得到有效降低。

2）.稳定性提升

代理功能与业务或内核合为一体，而不增加代理应用这一可能的故障点，整体系统的稳定性得到了提升。

3）.运维难度降低

无需单独运维代理程序。

3.3.架构缺陷

1）.增加开发成本

ServiceMesh 作为应用治理的基础组件，架构上最好与应用解耦，让应用开发人员能专注应用逻辑的开发。而 SDK 与 agent 的形式均需要应用开发人员参与应用治理，会增加开发人员的开发、学习和运维成本。

2）.逆技术潮流

SDK 与 agent 需要与应用耦合，ebpf 需要在内核处理很多逻辑，这二者与应用开发与治理解耦，业务逻辑在应用层处理的技术潮流相悖。

4.小结

综上所述，Sidercar、per-Node、proxyless 架构各有优劣。在 Servicemesh 技术快速发展的当下，百花齐放的架构对整个技术的发展完善是十分有利的。然而，不区分场景与业务需求而单纯的褒贬某一种架构都是不可取的。

在代理网格技术还没兴起的时候，以 springcloud、dubbo 为代表的微服务治理框架（proxyless）已经有了较大规模的应用。虽然其具备与应用耦合性高，仅适用 JAVA 技术栈等缺陷，但对当时已经完成改造的微服务应用而言，已经经历了框架学习与业务改造。目前的运转已经标准化，且具备低延时、高稳定性的优势，在当前阶段再以 proxyless 向 sidercar 转变缺乏有价值的驱动力。

但新建的应用应当考虑与代理与业务解耦、兼容非 JAVA 技术栈、降低开发难度、代理升级等问题，主动拥抱 Sidercar 或 per-Node 架构，并与业务场景（如低延时场景等）结合进行选型，解决相关问题，将不同架构的优势发挥出来。

二.原微服务框架如何过渡

一般一项新技术/方案要落地，在客户侧不会是从零开始，与之前技术的兼容过渡是必须考虑的问题。而对于 ServiceMesh 落地，在 Sidercar 架构表现出与业务解耦、广泛兼容技术栈等价值时，与之前已经广泛落地的 springcloud、dubbo 为代表的微服务治理框架如何兼容过渡就是 ServiceMesh 落地的一个关键问题。

面对新老两种微服务治理框架，业界主流厂商都在提倡“双模引擎”的概念，所谓双模即 Sidercar 模式与传统 SDK/agent 模式，以下引用了蚂蚁金服的图说明。

为了便于两种架构微服务的统一管理，SDK、agent、Sidercar 一般都是采用同一家厂商，但厂商 SDK 的设计也要考虑到与之前 Springcloud、Dubbo 尽量减少差别，降低开发人员的学习成本。

双模架构是对新型 Sidercar 架构的拥抱与传统架构的兼容，可针对不同的场景与业务需要灵活进行选择，两种架构的微服务之间通过统一的注册中心还可实现服务注册与发现，便于不同架构的微服务互访。

三.多集群问题

首先讲一下为什么需部署在单数据中心也存在同样要多集群，在 K8S 场景下如果将某个业务只部署在单个集群中便存在单点故障风险，仅的问题。而客户的很多业务的对连续性有很高的要求，例如金融行业对业务的 RTO 和 RPO 有着明确的要求，这就要求我们在架构设计的时候充分考虑系统的高可用设计来保障业务的连续性。

而开源的 ServiceMesh 方案更注重单集群内的治理，对多集群多活场景没有直接给出完善的解决方案，下图所示便是笔者建议的一个多集群多活的解决方案。集群入口的 Ingress 负责集群内业务南北向流量调度，L7 应用网关负责跨集群多活调度，L4 流量网关负责给 L7 网关做负载，最外侧的智能 DNS 负责跨数据中心的流量引流。