其他
蚂蚁金服 Service Mesh 大规模落地系列 - 网关篇
引言
网关的前世今生,解释网关为什么要 Mesh 化; 网关 Mesh 化,阐述如何进行 Mesh 化改造; 双十一落地,介绍在此过程中实现三板斧能力;
前世今生
客户端连接到网关接入层集群 Spanner ; Spanner 会把客户端请求转发到无线网关集群 Gateway; Gateway 提供通用能力如鉴权、限流等处理请求,并根据服务标识将请求路由到正确的后端服务;服务处理完请求,响应原路返回;
转发逻辑:将 Gateway 中根据服务标识转发的能力迁移到 Spanner 上; 网关逻辑:将网关通用能力如鉴权、限流、LDC 等功能,抽成一个 mgw.jar 集成到业务系统中,与后端服务同 JVM 进程运行;
客户端请求到 Spanner 后,Spanner 会根据服务标识转发请求到后端服务的 mgw 中; mgw 进行通用网关能力处理,90% 的请求随即进行 JVM 内部调用;
提升性能:
少一层网关链路,网关 jar 调用业务是 JVM 内部调用; 大促期间,无需关心网关的容量,有多少业务就有多少网关;
提高稳定性:
集中式网关形态下,网关出现问题,所有业务都会收到影响; 去中心化后,网关的问题,不会影响去中心化的应用;
研发效能低:
接入难:需要引入 15+ pom 依赖、20+ 的配置,深度侵入业务配置; 版本收敛难:当前 mgw.jar 已迭代了 40+ 版本,当前还有业务使用的是初版,难以收敛; 新功能推广难:新能力上线要推动业务升级和发布,往往需要一个月甚至更久时间;
干扰业务稳定性: 依赖冲突,干扰业务稳定性,这种情况发生了不止一次; 网关功能无法灰度、独立监测,资源占用无法评估和隔离; 不支持异构接入:非 Java 应用,无法使用去中心化网关;
客户端请求到 Spanner 后,Spanner 会根据服务标识转发请求到后端服务同 Pod 中的 Mesh 网关; Mesh 网关执行通用逻辑后调用同机不同进程的业务服务,完成业务处理;
研发效能:
接入方便:业务无需引入繁杂的依赖和配置,即可接入 Mesh 网关; 版本容易收敛、新功能推广快:新版本在灰度验证通过后,即可全网推广升级,无需维护和排查多版本带来的各种问题;
业务稳定性:
无损升级:业务系统无需感知网关的升级变更,且网关的迭代升级将可利用 MOSN 现有的特性进行细粒度的灰度和验证,做到无损升级; 独立监测:由于和业务系统在不同进程,可以实时遥测 Mesh 网关进程的表现,并据此评估和优化,增强后端服务稳定性;
异构系统接入:Mesh 网关相当于一个代理,对前端屏蔽后端的差异,将支持 SOFARPC、Dubbo 和 gRPC 等主流 RPC 协议,并支持非 SOFA 体系的异构系统接入;
Mesh 化之后的请求处理流程不是同进程调用,比起去中心化网关多了一跳,是否有性能损耗? 毕竟进行了大刀阔斧的变革,在上线过程中如何保障稳定性?
Mesh 化
蓝色箭头线是客户端请求的处理流程,Mesh 网关数据面在蚂蚁金服内部 MOSN 的 Sidecar 中; 绿色箭头线是网关配置下发过程,Mesh 网关控制面当前还是由网关管控平台来承载; 红色箭头线条是 MOSN Sidecar 的运维体系;
内容精简:从 7k 字节降低到 650 字节; 无解压缩:节省 GZip 的性能损耗; 无线 PC 隔离:解决 session 污染问题;
双十一落地
大促支付链路淘系支付 API 100% 引流; 大促会员链路主战场应用 100% 引流; 网关 Top API 5% 引流;
开关 | 生效时机 | 作用 |
Mesh 百分比 | 立即 | 控制某个 API 的 Mesh 路由是否开启,支持百分比 |
Label | 自动感知 | 控制某台服务器的 Mesh 路由是否开启 |
Zone | Spanner Reload | 控制某个 Zone 的 Mesh 路由是否开启 |
MeshOnly | Spanner Reload | 控制某个应用的 Mesh 路由是否开启 |
去中心化网关服务:由 port1(Http)或 port2(Mmtp)端口提供服务; Mesh 网关服务:由 port3(Http)或 port4(Mmtp)端口提供服务;
最后
蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇 蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇 蚂蚁金服 Service Mesh 大规模落地系列 - 消息篇 蚂蚁金服 Service Mesh 大规模落地系列 - 核心篇 Service Mesh 落地负责人亲述:蚂蚁金服双十一四大考题