引言
本文结合无线网关的发展历程，解读进行 Service Mesh 改造的缘由和价值，同时介绍蚂蚁金服在双十一落地过程中如何保障业务流量平滑迁移至新架构下的 Mesh 网关。分享将从如下三个方面展开：
网关的前世今生，解释网关为什么要 Mesh 化；
网关 Mesh 化，阐述如何进行 Mesh 化改造；
双十一落地，介绍在此过程中实现三板斧能力；
前世今生
蚂蚁金服无线网关当前接入数百个业务系统，提供数万个 API 服务，是蚂蚁金服客户端绝对的流量入口，支持的业务横跨支付宝、网商、财富、微贷、芝麻和国际 A+ 等多种场景。面对多种业务形态、复杂网络结构，无线网关的架构也在不断演进。
中心化网关
在 All In 无线的年代，随着通用能力的沉淀，形成了中心化网关 Gateway。
客户端连接到网关接入层集群 Spanner ；
Spanner 会把客户端请求转发到无线网关集群 Gateway；
Gateway 提供通用能力如鉴权、限流等处理请求，并根据服务标识将请求路由到正确的后端服务；服务处理完请求，响应原路返回；
2016 年新春红包爆发，蚂蚁森林等新兴业务发展壮大，网关集群机器数不断增长。这加剧了运维层面的复杂性，IT 成本也不能承受之重。同时，一些核心链路的业务如无线收银台、扫一扫等，迫切需要与其他业务隔离，避免不可预知的突发流量影响到这些高保业务的可用性。因此，2016 年下半年开始建设和推广去中心化网关。
去中心化网关
去中心化网关将原先集中式网关的能力进行了拆分：
转发逻辑：将 Gateway 中根据服务标识转发的能力迁移到 Spanner 上；
网关逻辑：将网关通用能力如鉴权、限流、LDC 等功能，抽成一个 mgw.jar 集成到业务系统中，与后端服务同 JVM 进程运行；
此时，客户端请求的处理流程如下：
客户端请求到 Spanner 后，Spanner 会根据服务标识转发请求到后端服务的 mgw 中；
mgw 进行通用网关能力处理，90% 的请求随即进行 JVM 内部调用；
去中心化网关与集中式网关相比，具有如下优点：
提升性能：
少一层网关链路，网关 jar 调用业务是 JVM 内部调用；
大促期间，无需关心网关的容量，有多少业务就有多少网关；
提高稳定性：
集中式网关形态下，网关出现问题，所有业务都会收到影响；
去中心化后，网关的问题，不会影响去中心化的应用；
但凡事具有两面性，随着在 TOP30 的网关应用中落地铺开，去中心化网关的缺点也逐步显现：
研发效能低：
接入难：需要引入 15+ pom 依赖、20+ 的配置，深度侵入业务配置；
版本收敛难：当前 mgw.jar 已迭代了 40+ 版本，当前还有业务使用的是初版，难以收敛；
新功能推广难：新能力上线要推动业务升级和发布，往往需要一个月甚至更久时间；
干扰业务稳定性：
依赖冲突，干扰业务稳定性，这种情况发生了不止一次；
网关功能无法灰度、独立监测，资源占用无法评估和隔离；
不支持异构接入：非 Java 应用，无法使用去中心化网关；
Mesh 网关
去中心化网关存在的诸多问题，多数是由于网关功能与业务进程捆绑在一起造成的。这引发了我们的思考：如果网关功能从业务进程中抽离出来，这些问题是否就可以迎刃而解了？这种想法，与 Service Mesh 的 Sidecar 模式不谋而合。因此在去中心化网关发展了三年后，我们再出发对蚂蚁金服无线网关进行了 Mesh 化改造，期望借此解决相关痛点。
Mesh 网关与后端服务同 Pod 部署，即 Mesh 网关与业务系统同服务器、不同进程，具备网关的全量能力。客户端请求的处理流程如下：
客户端请求到 Spanner 后，Spanner 会根据服务标识转发请求到后端服务同 Pod 中的 Mesh 网关；
Mesh 网关执行通用逻辑后调用同机不同进程的业务服务，完成业务处理；
对比去中心化网关的问题，我们来分析下 Mesh 网关所带来的优势：
研发效能：
接入方便：业务无需引入繁杂的依赖和配置，即可接入 Mesh 网关；
版本容易收敛、新功能推广快：新版本在灰度验证通过后，即可全网推广升级，无需维护和排查多版本带来的各种问题；
业务稳定性：
无损升级：业务系统无需感知网关的升级变更，且网关的迭代升级将可利用 MOSN 现有的特性进行细粒度的灰度和验证，做到无损升级；
独立监测：由于和业务系统在不同进程，可以实时遥测 Mesh 网关进程的表现，并据此评估和优化，增强后端服务稳定性；
异构系统接入：Mesh 网关相当于一个代理，对前端屏蔽后端的差异，将支持 SOFARPC、Dubbo 和 gRPC 等主流 RPC 协议，并支持非 SOFA 体系的异构系统接入；
至此，我们卖瓜自夸式地讲完了无线网关的前世今生，解释了为何要进行网关 Mesh 化。但细心的你想必怀疑：
Mesh 化之后的请求处理流程不是同进程调用，比起去中心化网关多了一跳，是否有性能损耗？
毕竟进行了大刀阔斧的变革，在上线过程中如何保障稳定性？接下来的章节将对上述问题进行解释。
Mesh 化
架构
首先，从架构层面详细介绍网关 Mesh 化所做的相关工作。依照 Service Mesh 的分层模型，Mesh 网关分为数据面和控制面。
解读：
蓝色箭头线是客户端请求的处理流程，Mesh 网关数据面在蚂蚁金服内部 MOSN 的 Sidecar 中；
绿色箭头线是网关配置下发过程，Mesh 网关控制面当前还是由网关管控平台来承载；
红色箭头线条是 MOSN Sidecar 的运维体系；
MOSN：
https://github.com/sofastack/sofa-mosn
数据面
采用 Go 语言实现了原先网关的全量能力，融合进 MOSN 的模型中，复用了其他组件已有的能力。 同时网络接入层 Spanner 也实现了请求分发决策能力。
数据转换
将客户端的请求数据转换成后端请求数据，将后端响应数据转换成客户端响应。利用 MOSN 协议层扩展能力，实现了对网关自有协议 Mmtp 的解析能力。
通用功能
授权、安全、限流、LDC 和重试等网关通用能力。利用 MOSN Stream Filter 注册机制以及统一的 Stream Send/Receive Filter 接口扩展而来。
请求路由
客户端请求按照特定规则路由到正确的后端系统。在网关层面实现 LDC 逻辑后，复用 MOSN RPC 组件的路由匹配能力。其中大部分请求都会路由到当前 Zone，从而直接请求到当前 Pod 的业务进程端口。
后端调用
支持调用多种类型的后端服务，支持对 SOFARPC、Chair 等后端，后期计划支持更多的 RPC 框架和异构系统。
控制面
为网关用户提供新增、配置 API 等服务的管控系统，可将网关配置数据下发至 Mesh 网关的 Sidecar 实例；
性能
大家比较关心的是多一跳对业务性能是否有影响？
这个是蚂蚁金服内部 MOSN 层面的性能损耗分析，具体分析参见敖小剑的「蚂蚁金服 Service Mesh 深度实践」。得出的结论是相较于复杂的业务逻辑，Mesh 的性能损耗在可接受的范围内，同时带来了快速获得收益的能力。同时 Mesh 网关在此次接入过程中做了 Session 精简化：
内容精简：从 7k 字节降低到 650 字节；
无解压缩：节省 GZip 的性能损耗；
无线 PC 隔离：解决 session 污染问题；
在带 Session 校验场景下，相较于去中心化网关，基准性能压测得出的结论是：QPS 提升近 1 倍，RT 下降约 15%。在此也感谢业务方在 Session 精简化改造过程中的理解和支持。
双十一落地
本次双十一，Mesh 网关的落地情况如下：
大促支付链路淘系支付 API 100% 引流；
大促会员链路主战场应用 100% 引流；
网关 Top API 5% 引流；
从上述引流情况可以看出，Mesh 网关支持多维度百分比引流。当然，新的架构体系在大促时落地，充满了各种风险。
为了做好风险管控，我们严格按照三板斧（可监控、可灰度、可回滚）的要求建设相关能力。当前的 Mesh 网关的路由具备 API 百分比、服务器、Zone 以及应用级别的开关能力，支持业务灰度和应急止血。
这里着重分享下 Mesh 网关 API 百分比分流策略。我们和网络接入层 Spanner 配合，开发了 Mesh 分流功能，实现了秒级生效的单个 API 百分比切流 Mesh 网关能力。某 API 配置了去中心化 x%，Mesh 化 y% 的切流规则时的流量示意图。
去中心化网关服务：由 port1（Http）或 port2（Mmtp）端口提供服务；
Mesh 网关服务：由 port3（Http）或 port4（Mmtp）端口提供服务；
其中百分比信息由业务方在 API 管控页面配置，随着 API 响应头带回 Spanner Worker，由 Worker 自主学习，按照对应的百分比做分流决策。同时实现了路由失败回退机制，优先级 service:去中心化端口>service:Mesh 端口>Gateway，由集中式网关进行兜底保证业务不失败。
最后
写了这么多，也到了本次分享的尾声。随着双十一落地和验证，后续我们会加快推进 Mesh 网关在蚂蚁金服落地节奏。期待 Service Mesh 在蚂蚁金服云化战略中发挥重要的作用。Mesh 网关也会持续迭代演进，融合云原生技术，支持南北和东西向流量。
艰难困苦，玉汝于成。
作者介绍：
陆鑫，花名悟尘，蚂蚁金服 Mesh 网关负责人，专注领域：无线网关、服务高可用。
本文转载自公众号金融级分布式架构（ID：Antfin_SOFA）。
原文链接：
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论 1 条评论