Mesh 网关

具体内容将从下述几个方面展开：

• 网关的演变历史：解释网关为什么要 Mesh 化。

• 网关 Mesh 化：阐述如何进行 Mesh 化改造。

• 双十一落地：介绍在此过程中实现三板斧能力。

网关的演变历史

当前，蚂蚁集团的无线网关接入了数百个业务系统，提供数万个 API 服务，是蚂蚁集团客户端绝对的流量入口，支持的业务横跨支付宝、网商、财富、微贷、芝麻和国际 A+ 等多种场景。面对多种业务形态、复杂网络结构，无线网关的架构也在不断演进。

中心化网关

在 All In 无线的年代，随着通用能力的沉淀，形成了中心化网关 Gateway，示例如下：

流程说明：

1. 客户端连接到网关接入层集群 Spanner。

2. Spanner 会把客户端请求转发到无线网关集群 Gateway。

3. Gateway 提供通用能力如鉴权、限流等处理请求，并根据服务标识将请求路由到正确的后端服务；服务处理完请求，响应原路返回。

2016 年新春红包爆发，蚂蚁森林等新兴业务发展壮大，网关集群机器数不断增长。这加剧了运维层面的复杂性，IT成本也面临不能承受之重。同时，一些核心链路的业务如无线收银台、扫一扫等，迫切需要与其他业务隔离，避免不可预知的突发流量影响到这些高保业务的可用性。因此，2016 年下半年开始建设和推广去中心化网关。

去中心化网关

去中心化网关示例

去中心化网关将原先集中式网关的能力进行了拆分：

• 转发逻辑：将 Gateway 中根据服务标识转发的能力迁移到 Spanner 上。

• 网关逻辑：将网关通用能力如鉴权、限流、LDC 等功能，抽成一个 mgw JAR，集成到业务系统中，与后端服务 JVM 进程一起运行。

此时，客户端请求的处理流程如下：

• 客户端请求到 Spanner 后，Spanner 会根据服务标识转发请求到后端服务的 mgw 中。

• mgw 进行通用网关能力处理，90% 的请求随即进行 JVM 内部调用。

去中心化网关与集中式网关相比，具有如下优点：

• 提升性能：

  • 少一层网关链路，网关 JAR 调用业务是 JVM 内部调用。

  • 大促期间，无需关心网关的容量，有多少业务就有多少网关。

• 提高稳定性：

  • 集中式网关形态下，网关出现问题，所有业务都会受到影响。

  • 去中心化后，网关的问题，不会影响去中心化的应用。

但凡事具有两面性，随着在 TOP 30 的网关应用中落地铺开，去中心化网关的缺点也逐步显现：

• 研发效能低：

  • 接入难：需要引入 15 + 的 pom 依赖、20 + 的配置，深度侵入业务配置。

  • 版本收敛难：当前 mgw.jar 已迭代了 40+ 版本，但是，还有业务使用的是初版，难以收敛。

  • 新功能推广难：新能力上线要推动业务升级和发布，往往需要一个月甚至更久时间。

• 干扰业务稳定性：

  • 依赖冲突，干扰业务稳定性，这种情况发生了不止一次。

  • 网关功能无法灰度、独立监测，资源占用无法评估和隔离。

• 不支持异构接入：非 Java 应用，无法使用去中心化网关。

Mesh 网关

去中心化网关存在的诸多问题，多数是由于网关功能与业务进程捆绑在一起造成的。这引发了蚂蚁团队的思考：如果网关功能从业务进程中抽离出来，这些问题是否就可以迎刃而解了？这种想法，与 Service Mesh 的 Sidecar 模式不谋而合。因此在去中心化网关发展了三年后，我们再出发对蚂蚁集团无线网关进行了 Mesh 化改造，以期解决相关痛点。

Mesh 网关示例

Mesh 网关与后端服务同一个 Pod 部署，即 Mesh 网关与业务系统同服务器、不同进程，具备网关的全量能力。客户端请求的处理流程如下：

• 客户端请求到 Spanner 后，Spanner 会根据服务标识转发请求到后端服务同一 Pod 中的 Mesh 网关。

• Mesh 网关执行通用逻辑后，调用同机不同进程的业务服务，完成业务处理。

对比去中心化网关的问题，我们来分析下 Mesh 网关所带来的优势：

• 研发效能：

  • 接入方便：业务无需引入繁杂的依赖和配置，即可接入 Mesh 网关。

  • 版本容易收敛、新功能推广快：新版本在灰度验证通过后，即可全网推广升级，无需维护和排查多版本带来的各种问题。

• 业务稳定性：

  • 无损升级：业务系统无需感知网关的升级变更，且网关的迭代升级可以利用 MOSN 现有的特性进行细粒度的灰度和验证，做到无损升级。

  • 独立监测：由于和业务系统在不同进程，可以实时遥测 Mesh 网关进程的表现，并据此评估和优化，增强后端服务稳定性。

• 异构系统接入：Mesh 网关相当于一个代理，对前端屏蔽后端的差异，支持 SOFARPC、Dubbo 和 gRPC 等主流 RPC 协议，并支持非 SOFA 体系的异构系统接入。

至此，无线网关的演变历史已经说明完毕。

细心的读者可能有下述疑问：

• Mesh 化之后的请求处理流程不是同进程调用，比去中心化网关多了一跳，是否有性能损耗？

• 如此大的改革之后，在上线过程中如何保障稳定性？

下文将尝试回答上述疑问。

网关 Mesh 化

架构

依照 Service Mesh 的分层模型，Mesh 网关分为数据面和控制面，示例如下：

网关Mesh化分层模型图说明：

• 蓝色箭头线是客户端请求的处理流程，Mesh 网关数据面在蚂蚁集团内部 MOSN 的 Sidecar 中。

• 绿色箭头线是网关配置下发过程，Mesh 网关控制面当前还是由网关管控平台来承载。

• 红色箭头线是 MOSN Sidecar 的运维体系。

数据面

数据面，采用 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%。

双十一落地

2019 年双十一，Mesh 网关的落地情况如下：

• 大促支付链路淘系支付 API 100% 引流。

• 大促会员链路主战场应用 100% 引流。

• 网关 Top API 5% 引流。

从上述引流情况可以看出，Mesh 网关支持多维度百分比引流。当然，新的架构体系在大促时落地，充满了各种风险，图示如下：

为了做好风险管控，我们严格按照三板斧（可监控、可灰度、可回滚）的要求建设相关能力。当前 Mesh 网关的路由具备 API 百分比、服务器、Zone 以及应用级别的开关能力，支持业务灰度和应急止血。

这里着重分享下 Mesh 网关 API 百分比分流策略。通过和网络接入层 Spanner 配合，蚂蚁团队开发了 Mesh 分流功能，实现了秒级生效的单个 API 百分比切流 Mesh 网关能力。某 API 配置了 去中心化 x%，Mesh 化 y%，其切流规则生效时的流量，示意如下：

• 去中心化网关服务：由 Port 1（Http）或 Port 2（Mmtp）端口提供服务。

• Mesh 网关服务：由 Port 3（Http）或 Port 4（Mmtp）端口提供服务。

其中百分比信息由业务方在 API 管控页面配置，随着 API 响应头带回 Spanner Worker，由 Worker 自主学习后，按照对应的百分比做分流决策。同时实现了路由失败回退机制，优先级 Service:去中心化端口 > Service:Mesh 端口 > Gateway ，由集中式网关进行兜底保证业务不失败。