全部产品

服务网格最佳实践之网关

更新时间:2020-09-30 11:05:35

本文结合无线网关的发展历程,解读进行 Service Mesh 改造的缘由和价值,同时介绍在双十一落地过程中如何保障业务流量平滑迁移至新架构下的 Mesh 网关。具体内容将从下述几个方面展开:

网关的演变历史

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

中心化网关

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

中心网关.png

流程说明

  1. 客户端连接到网关接入层集群 Spanner。
  2. Spanner 会把客户端请求转发到无线网关集群 Gateway。
  3. Gateway 提供通用能力如鉴权、限流等处理请求,并根据服务标识将请求路由到正确的后端服务;服务处理完请求,响应原路返回。

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

去中心化网关

去中心化网关示例

去中心网关.png

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

  • 转发逻辑:将 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网关.png

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

  • 客户端请求到 Spanner 后,Spanner 会根据服务标识转发请求到后端服务同一 Pod 中的 Mesh 网关。
  • Mesh 网关执行通用逻辑后,调用同机不同进程的业务服务,完成业务处理。

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

  • 研发效能:
    • 接入方便:业务无需引入繁杂的依赖和配置,即可接入 Mesh 网关。
    • 版本容易收敛、新功能推广快:新版本在灰度验证通过后,即可全网推广升级,无需维护和排查多版本带来的各种问题。
  • 业务稳定性:
    • 无损升级:业务系统无需感知网关的升级变更,且网关的迭代升级可以利用 MOSN 现有的特性进行细粒度的灰度和验证,做到无损升级。
    • 独立监测:由于和业务系统在不同进程,可以实时遥测 Mesh 网关进程的表现,并据此评估和优化,增强后端服务稳定性。
  • 异构系统接入:Mesh 网关相当于一个代理,对前端屏蔽后端的差异,支持 SOFARPC、Dubbo 和 gRPC 等主流 RPC 协议,并支持非 SOFA 体系的异构系统接入。

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

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

  • Mesh 化之后的请求处理流程不是同进程调用,比去中心化网关多了一跳,是否有性能损耗?
  • 如此大的改革之后,在上线过程中如何保障稳定性?

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

网关 Mesh 化

架构

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

spanner.png

说明

  • 蓝色箭头线是客户端请求的处理流程,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 层性能损耗分析图

性能.png

更多性能分析详情,请参考 蚂蚁金服 Service Mesh 深度实践

分析结论是:相较于复杂的业务逻辑,Mesh 的性能损耗在可接受的范围内,同时带来了快速获得收益的能力。Mesh 网关在此次接入过程中也做了 Session 精简化:

  • 内容精简:从 7k 字节降低到 650 字节。
  • 无解压缩:节省 GZip 的性能损耗。
  • 无线 PC 隔离:解决 Session 污染问题。

在带 Session 校验场景下,相较于去中心化网关,基准性能压测得出的结论是:QPS 提升近 1 倍,RT 下降约 15%。

双十一落地

本次双十一,Mesh 网关的落地情况如下:

  • 大促支付链路淘系支付 API 100% 引流。
  • 大促会员链路主战场应用 100% 引流。
  • 网关 Top API 5% 引流。

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

风险.png

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

开关 生效时机 作用
Mesh 百分比 立即 控制某个 API 的 Mesh 路由是否开启,支持百分比。
Label 自动感知 控制某台服务器的 Mesh 路由是否开启。
Zone Spanner Reload 控制某个 Zone 的 Mesh 路由是否开启。
MeshOnly Spanner Reload 控制某个应用 的 Mesh 路由是否开启。

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

切流规则.png

  • 去中心化网关服务:由 Port 1(Http)或 Port 2(Mmtp)端口提供服务。
  • Mesh 网关服务:由 Port 3(Http)或 Port 4(Mmtp)端口提供服务。

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