本文为大家介绍云原生网络代理 MOSN如何实现透明高效的拦截，这是Service Mesh 设计中的一大难点。
网站建设哪家好，找创新互联公司！专注于网页设计、网站建设、微信开发、微信小程序定制开发、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了翁源免费建站欢迎大家使用！
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:15001，订阅方Sidecar监听本机 15001 端口，当订阅方访问 127.0.0.1:15001 时，流量就自然到达了本端Sidecar。在这种情况下，无需在网络层面使用重定向技术就可以达到目的。
服务发布订阅修改逻辑框图
流量转发流程图
如上图中，在发布服务时，Sidecar 将服务端原本的地址转换为 Sidecar 自身的端口；服务订阅时，订阅方获取到的端口则是本地Sidecar 监听的端口。这一方案的优势很明显，逻辑都收敛在了 Sidecar 中，除了需要对 Sidecar 服务注册/发布流程进行改造外，不需要其他组件的参与，但是缺点也很明显，如果业务模型不存在注册中心，或者是服务发布/订阅 SDK 不能进行改造，这个方案就行不通了，而在 Mesh 落地场景中，这个条件恰恰较难满足。
目前大多数业务的逻辑架构都不符合 Istio 定义的云原生体系，为了享受到 Service Mesh 在服务治理方面的优势，需要选择合适的流量劫持方案。一般而言，流量劫持工作在 L4 层，在进行劫持技术选型时需要考虑三个方面的问题：
下面将从这三个层面分析 MOSN 在落地过程中的一些思考。
在环境适配性上，最容易想到的是 iptables，作为一项古典网络技术，iptables 使用简单，功能灵活，几乎所有现代生产级内核版本与 OS 发行版都默认具备使用条件，Istio 社区也使用 iptables 做流量透明劫持。
iptables 流量劫持原理图
尽管环境适应性强，但是基于 iptables 实现透明劫持存在以下问题：
针对 oubound 流量，还可以使用hook connect 来实现，如图所示：
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仍然保留了精确匹配能力，可以通过配置项禁用模糊匹配，能够兼容之前的工作模式。
MOSN 流量劫持模糊匹配逻辑框图
为了支持更加灵活的配置手段，在配置模糊匹配规则时，支持默认白名单与默认黑名单两种模式。默认黑名单模式适合业务场景简单，业务流量特征明显的场景，由于劫持逻辑的输入流量少，性能损耗小。默认白名单模式适合业务特征明显不明显的场景，由于劫持逻辑的输入流量多，可能存在一定的性能损耗，在这种模式下，可以显示加入黑名单排除相应的流量，比如通常业务不会使用除了 80 之外的小于 1024 的端口。
MOSN 通过模糊规则匹配的手段极大降低了流量劫持的管理成本，在部署 Service Mesh 时，仅需要“大体上正确”即可，无需担心没有完全枚举流量规则而产生流量黑洞，而借助于 Service Mesh，可以得到全局的服务调用信息，进而能够对现有服务进行精细化的治理。
iptables 存在一个固有问题是在匹配规则数量增多时，匹配消耗会随之增加，在规则数量较多的情况下，会对新建连接性能造成较大的影响，为了避免这种情况，可使用 ipset 降低匹配消耗。此外，在内核版本满足要求（4.16 以上）的前提下，通过 sockmap 可以缩短报文穿越路径，进而改善 outbound 方向的转发性能。
在讨论流量劫持的性能损耗时，需要结合具体的场景来看，比如某些场景中只有 iptables dnat能够满足环境适配的要求，在这种情况下，需要考虑的是iptables dnat的数据面性能是否能够满足业务的需求。实际落地过程中，需要结合实际情况与运维难度选择劫持手段。
创新互联面向全国提供域名注册、虚拟主机、云服务器、服务器托管与租用，如需了解，请联系QQ:171356849微信：zh18159893430 咨询，谢谢！
