MOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议、模块化、智能化、安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的简称，可以与任何支持 xDS API 的 Service Mesh 集成，亦可以作为独立的四、七层负载均衡、API Gateway、云原生 Ingress 等使用。 MOSN：https://github.com/mosn/mosn
在由 Istio 定义的 Service Mesh 体系中，服务治理相关逻辑由独立的 Sidecar 进程处理，如服务发现、故障注入、限流熔断等等。这些处理逻辑是 Service Mesh 着重要解决的问题。通常在谈论到 Service Mesh 时，会优先关注在这些点上，但是在落地过程中，有一个问题同等重要但往往容易被忽视。这个问题概括起来，就是流量是如何被导入到 Sidecar 的监听端口的。
在数据平面的 Sidecar 中拦截进出应用容器的流量，这一直以来就是 Istio Service Mesh 中一切功能的基础，如何实现透明高效的拦截也是 Service Mesh 设计中的一大难点，本文为大家介绍云原生网络代理 MOSN 是如何做到这一点的。如果服务注册/发布过程能够允许适当的修改，这个问题会得到极大的简化，比如Sidecar将服务发布方的监听地址修改为 127.0.0.1:20882，订阅方 Sidecar 监听本机 20882 端口，当订阅方访问 127.0.0.1:20882 时，流量就自然到达了本端 Sidecar。在这种情况下，无需在网络层面使用重定向技术就可以达到目的，具体的实现方法如下图。
如上图中，在发布服务时，Sidecar 将服务端原本的地址转换为 Sidecar 自身的端口；服务订阅时，订阅方获取到的端口则是本地 Sidecar 监听的端口。这一方案的优势很明显，逻辑都收敛在了 Sidecar 中，除了需要对 Sidecar 服务注册/发布流程进行改造外，不需要其他组件的参与，但是缺点也很明显，如果业务模型不存在注册中心，或者是服务发布/订阅 SDK 不能进行改造，这个方案就行不通了，而在 Mesh 落地场景中，这个条件恰恰较难满足。目前大多数业务的逻辑架构都不符合 Istio 定义的云原生体系，为了享受到 Service Mesh 在服务治理方面的优势，需要选择合适的流量劫持方案。一般而言，流量劫持工作在 L4 层，在进行劫持技术选型时需要考虑三个方面的问题：- 第一是环境适配，包括容器、虚拟机、物理机、内核、系统发行版等方面的考虑，确保劫持方案在运行环境中能够正常工作；
- 第二是控制灵活简单，包括如何维护劫持规则，劫持规则如何下发等；
- 第三是性能，确保在业务运行期间，劫持本身不会带来过大的开销；
下面将从这三个层面分析 MOSN 在落地过程中的一些思考。在环境适配性上，最容易想到的是 iptables，作为一项古典网络技术，iptables 使用简单，功能灵活，几乎所有现代生产级内核版本与 OS 发行版都默认具备使用条件，Istio 社区也使用 iptables 做流量透明劫持。
尽管环境适应性强，但是基于 iptables 实现透明劫持存在以下问题：- DNAT 模式下，需要借助于 conntrack 模块实现连接跟踪，在连接数较多的情况下，会造成较大的消耗，同时可能会造成 track 表满的情况。为了避免这个问题，可以使用 TProxy 取代 DNAT，但受限于内核版本，TProxy 应用于 outbound 存在一定缺陷；
- iptables 属于常用模块，全局生效，不能显式的禁止相关联的修改，可管控性比较差；
- iptables 重定向流量本质上是通过 loopback 交换数据，outbond 流量将两次穿越协议栈，在大并发场景下会损失转发性能；
针对 oubound 流量，还可以使用 hook connect 来实现，如图所示：无论采用哪种透明劫持方案，均需要解决获取真实目的 IP/端口的问题，使用 iptables 方案通过 getsockopt 方式获取，TProxy 可以直接读取目的地址，通过修改调用接口，hook connect 方案读取方式类似于 TProxy。由于 MOSN 落地的场景十分复杂，有容器与 VM 甚至物理机环境，有基于 K8s 的云原生应用，有基于注册中心的微服务，也存在单体应用，有些场景对性能要求非常高，有些则是够用即可，针对不同的场景，我们选择不同的劫持方案进行适配。如果应用程序通过注册中心发布/订阅服务时，可以结合注册中心劫持流量；在需要用到透明劫持的场景，如果性能压力不大，使用 iptables DNAT 即可，大并发压力下使用 TProxy 与 sockmap 改善性能。通常基于申明式体系构建的服务在部署时能够得到全局信息，而非申明式体系往往需要在运行期间进行动态的配置修改，由于缺乏全局信息，在运行期间很难获取到准确的服务间调用信息。在生成透明劫持规则时，我们需要明确哪些流量要被重定向到 Sidecar，否则一旦出错，而 Sidecar 又无法处理这部分流量时，将会使得 Sidecar 变成流量黑洞，比如，某一个容器内的 TCP 流量全部被重定向至 Sidecar，而该容器中存在一个使用私有协议承载应用数据的监控 Agent，而 Sidecar 不能识别该协议导致无法争取转发，只能选择丢弃。
通常情况下，为了确保 Sidecar 能够正确的转发流量，需要满足两个条件，首先是要能够正确识别协议，其次是需要配置转发规则，明确下一跳。对于不满足这两个条件的流量，不应将其重定向至 Sidecar。对于现有的非云原生应用，同时满足这两个条件的代价非常高，比如，某个虚拟机上运行了一个业务，同时还运行了收集 Metrics 的 Agent、日志采集工具、健康检查工具等等。而基于 L4 规则很难精确的将业务流量重定向至 Sidecar，如果多个业务混部，可能导致无法在 L4 层进行业务流量的区分。总结起来，为了精确的把流量引至 Sidecar，需要获得全局的调用关系，这一目标原本应该由 Service Mesh 来完成，而在流量劫持的场景下，却成为了 Service Mesh 的前提。为了使用 Service Mesh 而引入大量的部署运维开销是得不偿失的。在落地的过程中，MOSN 引入了多项手段来降低流量劫持的配置难度。我们将需要精确配置重定向规则的工作模式定义为精确匹配，与之相对应的是模糊匹配，即不要求精确区分出需要劫持的流量。降低配置难度的关键在于取消对于精确规则的依赖，在配置模糊规则的前提下，既做到对于关心的业务流量的治理，同时也不影响非业务流量的正常流程。我们采用 L4 规则与 L7 规则融合的方式下发模糊的匹配规则，此规则下除了包含关心的业务流量外，还可能包含预期之外的非业务流量。对于业务流量，Sidecar 根据相应的服务治理规则处理，而对于非业务流量，则保持其默认行为不变。在模糊匹配模式下，仅需要为关心的流量配置服务治理与转发规则，而无需关心 miss match 导致流量黑洞。在模糊匹配之外，MOSN 仍然保留了精确匹配能力，可以通过配置项禁用模糊匹配，能够兼容之前的工作模式。为了支持更加灵活的配置手段，在配置模糊匹配规则时，支持默认白名单与默认黑名单两种模式。默认黑名单模式适合业务场景简单，业务流量特征明显的场景，由于劫持逻辑的输入流量少，性能损耗小。默认白名单模式适合业务特征明显不明显的场景，由于劫持逻辑的输入流量多，可能存在一定的性能损耗，在这种模式下，可以显示加入黑名单排除相应的流量，比如通常业务不会使用除了 80 之外的小于 1024 的端口。MOSN 通过模糊规则匹配的手段极大降低了流量劫持的管理成本，在部署 Service Mesh 时，仅需要“大体上正确”即可，无需担心没有完全枚举流量规则而产生流量黑洞，而借助于 Service Mesh，可以得到全局的服务调用信息，进而能够对现有服务进行精细化的治理。iptables 存在一个固有问题是在匹配规则数量增多时，匹配消耗会随之增加，在规则数量较多的情况下，会对新建连接性能造成较大的影响，为了避免这种情况，可使用 ipset 降低匹配消耗。此外，在内核版本满足要求（4.16 以上）的前提下，通过 sockmap 可以缩短报文穿越路径，进而改善 outbound 方向的转发性能。
在讨论流量劫持的性能损耗时，需要结合具体的场景来看，比如某些场景中只有 iptables dnat 能够满足环境适配的要求，在这种情况下，需要考虑的是 iptables dnat 的数据面性能是否能够满足业务的需求。实际落地过程中，需要结合实际情况与运维难度选择劫持手段。本文主要为大家介绍云原生网络代理 MOSN 是如何实现透明高效的拦截的。降低劫持规则的管理成本，使得 Service Mesh 的引入不会造成额外的负担，在落地过程中，可以更加专注在业务逻辑上，能够充分满足多语言，多环境下的服务治理需求。
流量劫持技术的发展与 Service Mesh 的落地密切相关，后续我们将围绕环境适配性、低时延、低管理成本等方面持续演进，构建由 DNAT、TProxy、tc redirect、sockmap 等技术组成的多模单体底座，在不同内核环境、不同性能要求、不同管理成本的场景中自适应选取最合适的劫持技术，不断降低 Service Mesh 的接入成本。
如果大家对 MOSN 有问题以及建议，欢迎与我们交流，也非常欢迎加入 MOSN 开源社区的共建。
MOSN：https://github.com/mosn/mosn