蚂蚁金服 API Gateway Mesh 思考与实践

本文整理自蚂蚁金服高级技术专家贾岛在 12 月 28 日 Service Mesh Meetup 杭州站现场分享。

MOSN 完成孵化， 启用独立 Group

2020.2019.12.18，MOSN 项目负责人、蚂蚁金服应用网络组负责人涵畅宣布 MOSN 完成从 SOFAStack 的孵化，将启用独立 Group 进行后续运做，欢迎你们共同建设社区。

MOSN 是一款使用 Go 语言开发的网络代理软件，做为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。MOSN 是 Modular Open Smart Network-proxy 的简称，能够与任何支持 xDS API 的 Service Mesh 集成，亦能够做为独立的4、七层负载均衡，API Gateway，云原生 Ingress 等使用。

项目地址：https://github.com/mosn/mosn

导语

在 Service Mesh 微服务架构中，咱们经常会听到东西流量和南北流量两个术语。蚂蚁金服开源的 Service Mesh Sidecar：MOSN（Modular Observable Smart Network）已经屡次与你们见面交流，以往的议题重点在东西流量的服务发现与路由，那么蚂蚁金服在南北流量上的思考是怎样的？

本次分享，将从蚂蚁金服 API 网关发展历程来看，Mesh 化的网关架构是怎样的、解决了什么问题、双十一的实践表现以及咱们对将来的思考。

今天的分享分为三个部分：

1. API Gateway Mesh 的定义：我在 Google 上搜了下 API Gateway Mesh 这个词，找到的都是 API Gateway vs Service Mesh，你们估计也会很好奇：这个词具体的定义是怎样的呢？因此咱们下面会作将 API Gateway 和 Service Mesh 作个对比，而后讲一下我我的对这个词有理解和思考。
2. API Gateway Mesh 在蚂蚁金服的实践：今年阿里巴巴核心系统 100% 云原生化，撑住了双11的世界级流量洪峰，这其中，蚂蚁金服的 Service Mesh 大放光彩，核心链路全上 Mesh，数万容器规模，咱们 API Gateway 在其中也承担了部分钱包链路和支付链路 100% 的请求。这个章节，我会从蚂蚁金服 API 网关的发展历程来看，咱们为何作 API Gateway Mesh，咱们的架构是如何的，以及咱们在过程当中的一些风险和考验。
3. 云原生下 API Gateway 的思考：你们如今都在讲云原生，可是真正实践云原生的过程当中，会越到各类各样的问题，怎么样的 API Gateway 方案和形态是最合适大家的业务的？在云原生的架构中，Service Mesh，API Gateway 都是最核心的组件之一，咱们对于云原生下的 API Gateway 在 Service Mesh 架构中的定位是如何思考的？还有，将来咱们的一些计划是怎样的？都会在这个章节跟你们分享一下。

API Gateway Mesh 的定义

上面这张图是一个云原生，南北+东西流量的架构图，这里面包含了核心的一些组件，我快速介绍一下：

• LBingress：负责 ssl 卸载、入口流量的负载均衡，一般会作一些简单的路由；
• API Gateway：负责更偏向业务的 API 验签、限流、协议转换、用户会话、负载均衡等逻辑；
• Sidecar in POD：业务系统中的 Sidecar，代理机房内东西流量的转发，通常走内部的 RPC（好比SOFARPC Dubbo Thrift SpringCloud），这里面的流量所有经过 Service Mesh 的 Sidecar Proxy 来承载，这个 Sidecar 负责路由（单元化灰度金丝雀），负载均衡、服务鉴权等等；
• Control Plane：流量控制「大管家」，云原生里目前最主流的方案是 Istio，负责路由策略、安全、鉴权等等下发和控制；

上面的架构你们都比较了解了，从上面的描述你们也看出来了，API Gateway 和 Service Mesh 的 Sidecar 不少能力都是相似的，好比都是一个网络代理，都具有负载均衡，都具有一些限流和鉴权能力。下面，咱们将作一个 API  Gateway 和 Service Mesh 的对比。

API  Gateway vs Service Mesh 

从本质概念上来说，API Gateway 用一句话归纳：「Exposes your services as managed APIs」，将内部的服务以更加可控可管理的方式暴露出去，这里的关键词是「暴露」和「可控」。Service Mesh 用一句话归纳：「A infrastructure to decouple the application network from your service code」，一种将服务代码与应用网络解耦的基础设施，这里的关键词是「解耦」。

在流量上，API Gateway 是管理南北流量的，而 Servcie Mesh 中的 Sidecar 通常状况下是用来负载东西流量的Proxy。二者都具有负责均衡的能力，API Gateway 通常状况下是经过 lvs 、nginx 中心化的一个负载均衡器，咱们管这个叫硬负载；而 Service Mesh 通常状况下是经过服务发现，Sidecar 之间是点对点的调用，咱们叫软负载。

通讯协议上，API Gateway 通常对外接收开放的通讯协议，通常是 HTTP、gRPC 等，并且可能涉及到协议的转换，将 HTTP 转换成内部的 RPC 协议，而 Service Mesh 代理的内部流量通常是内部的私有 RPC 协议（WebService、Dubbo、SOFABolt、Thrift 等等）。在鉴权、流控、安全等控制流量的层面上，对于 API Gateway 来说都是强依赖的，这样才体现「可控」的特色，而 Service Mesh 代理的内部流量，因为通常处于内网环境，这些控制通常状况下都是弱依赖。

咱们对 Service Mesh 的真正理解

你们能够看到，API Gateway 和 Service Mesh 实际上有不少共同点，也有不少区别。那 API Gateway Mesh 究竟是如何定义的呢？那要介绍下，咱们对 Service Mesh 的真正理解！

Service Mesh 中的 Sidecar 就是这样一辆边车摩托车，Sidecar 将 Service Code 和内部通讯 RPC 逻辑解耦掉。可是 Sidecar 的座位上，不只仅能够坐「内部通讯的 RPC」，也能够将其余中间件放到这辆 Sidecar 中，API Gateway + Sidecar = API Gateway Mesh，咱们也能够把 MessageQueue Client 放在 Sidecar 中，就是 Message Mesh。

因此，你们看，其实 Service Mesh 是一种模式和架构，关键词就是「解耦」你的服务代码和你的「中间件」。

API Gateway Mesh 定义

因此 API Gateway Mesh 的定义是：An infrastructure to expose your services as a managed APIs in the form of a decoupled sidecar proxy，以解耦 Sidecar 的形式，将你的服务代码暴露成可控的 API 基础设施。

OK，到目前为止，API Gateway Mesh 的定义解释清楚了，可是咱们为何要这样架构咱们的 API Gateway？这样作解决了什么问题？解释这些问题，要从支付宝 API 网关的发展历程来看。

蚂蚁金服 API Gateway Mesh 实践

支付宝移动网关的前身

支付宝 APP 初版2009年发布的，2009年仍是功能机（Nokia Symbian）的天下，APP 移动端还不是流量的主入口，因此 APP 服务器的架构也是很简单的，全部业务代码都堆积在一个叫 Mobile 的系统中，对外提供 https restful 服务，这样的架构优势就是简单粗暴。随着时间的推迟，2013年移动互联网崛起，智能机（Android&iOS）普及开来，公司愈来愈多的业务转向移动端，一个 Mobile 系统已经成为研发的瓶颈，另外单体系统的稳定性问题也凸现出来。

2013年，公司提出「ALL IN」无线的战略，那个时候产生了移动微服务网关（2014年马丁大叔提出了微服务概念），主要是解决多业务团队协做的问题。

微服务网关架构

咱们在这套网关架构中，设计了蚂蚁金服无线 RPC 协议（相似于 gRPC），支持客户端 iOS、Android 多语言 RPC 代码生成能力，屏蔽了网络通讯细节，加入了更多安全、鉴权、监控的能力。因为传统 Servlet 的线程模型与后端系统 RT 很敏感，咱们将 API Gateway 的通讯所有改为了 Netty 异步化。为了解决 HTTP 通讯在移动弱网下的不友好，咱们设计了基于 TCP 的私有长链接协议。这样一个架构支撑了3-4年的业务快速发展。

可是在2016年末，中心化的网关暴露出不少问题，好比：

• 网关更变风险的问题：网关的逻辑变动发布一旦有问题，将会影响全部业务；
• 业务分级隔离的问题：核心业务的 API 但愿和非核心业务的接口作资源上隔；
• 大促容量评估的问题：每一年双十一、新春红包活动，上万 API 接口的 QPS 很难评估，不一样 API 的 RT、BodySize、QPS 对于网关性能的影响都是不一样的，为了网关入口的稳定性，通常状况下，都会疯狂的扩容；

去中心化网关

基于上述的问题，咱们打算干掉形式上的网关，这样就引入了下一代的网关架构：去中心化网关。

咱们将中心化的网关进行了拆分，将逻辑简单的路由模块迁移到 spanner 负载均衡器上，将网关复杂的鉴权、LDC 路由、安全等逻辑抽象成一个 gateway.jar，业务集成这个 Jar 包就具有了网关的能力，这样业务系统之间作到了隔离，中心化的网关变动风险也不会影响到这些系统，这些系统自己就是一个「网关」，大促容量的问题也再也不是问题。

一个新的架构，解决了一些问题，可是也会引入一些新的问题。

去中心化架构平稳运行了2年，接入了30多个系统（全量系统在数百个），承载了60%-80%的流量，为何只接入30个系统？由于目前的去中心化网关架构存在不少问题，导入推广比较困难：

• 接入困难：gateway.jar 依赖了数十个 Jar，另外还存在配置，并且新的版本还在不停加新的依赖；
• Jar 包冲突：一个案例，gateway.jar 依赖 Netty 低版本，某个中间件升级间接升级了这个 Netty 版本，致使网关 Jar 的功能异常；
• 升级困难：最开始的时候，咱们有想过去中心化网关带来的版本多、升级难的问题，可是当时天真的认为，网关发展了这么多年，已经很稳定，不须要常常变动了，并且即便变动，让须要更新的系统升级一下就行了。可是事情老是想象的太美好：一旦有升级，业务方都要说：开发集成、回归测试，没时间！新功能没法普及，全网升级更本超级高；
• 异构系统支持：支付宝有部分业务是 Node.js 技术栈的，Node.js 中间件团队很是牛逼，花了1-2个月时间用 JavaScript 把网关的 Java 的代码翻译了一遍，可是后面放弃了更新了，新功能不可能所有 copy 一遍，成本过高，并且研发同窗没有成就感...

看到这里，你们是否是感受跟 Service Mesh 解决的问题差很少：解耦网关代码和业务代码、独立升级、支持异构系统。因此咱们将去中心化的网关 Jar 集成到 Service Mesh 的 Sidecar 中，引入了下一代网关架构：Mesh 化网关架构。

Mesh 化网关架构

总结一下：

• 微服务网关架构：解耦业务和网关；
• 去中心化网关架构：解决稳定性、业务分级隔离、大促容量评估等问题；
• Mesh 化网关架构：解决了去中心化升级难，异构系统支持等问题；

蚂蚁金服 API Gateway Mesh 架构

下面介绍下蚂蚁金服 API Gateway Mesh 的架构和落地过程当中的问题。

上图是 API Gateway Mesh 的架构图，其中有3个流：

• 数据流：业务数据经过 Spanner 直接转发到某个系统中 POD 的 Sidecar 中，通过网关内的各类检验逻辑，本地或转发请求到 SOFA 业务逻辑中；
• 控制流：通常 Service Mesh 中的控制面是 Istio 中的 Pilot 组件，可是因为原生 Pilot 组件在较大致量体况下性能不行，因此咱们目前没有走 Pilot，而是直接对接了网关后台管控；
• Ops 流：是运维的通道，经过 K8s operator sidecar 注入的方式，让业务具有网关 Mesh 的能力；

API Gateway Mesh 的底座是蚂蚁金服开源的 MOSN Sidecar Proxy，咱们基于 MOSN 的模块化扩展能力，升级了一层 Gateway Core Module，包括核心的 Server、Router、Pipeline、Service、Config 等核心模型，集成了 Lua、JavaScript 等动态脚本加强网关的动态能力，基于 MOSN 的协议扩展能力，轻松地实现了蚂蚁金服的 MMTP 私有协议。在 Gateway Core 的上线，经过插拔不一样的 Filter 和 Config，扩展出不一样场景的网关产品，如蚂蚁金服的无线网关、开放平台网关、金融云网关等等。控制面上咱们支持多种形式的配置下发通道，包括 Istio 的 XDS、Amdin RestAPI，K8s ConfigMap 等等。

MOSN：https://github.com/mosn/mosn

新技术的上线，绝对不是一件简单的事！

• 功能：由于 MOSN 是基于 Go 语言研发的，因此咱们要将 Java 技术栈转向 Go，但不只仅是照搬 Java 代码，根据 Go 的语言特色，不只作好功能，更好作好性能；
• 性能：最终线上压测，咱们发现 Mesh 版本比原来的 Java 版本还有必定的性能提高，缘由在于咱们将序列化方式从 Hessian 改为了 Protobuf，另外 Java 的线程模式切换到 Go 的 goroutine 也带来了必定的性能提高；
• 运维：运维更想偏于 K8s 云原生的方向；
• 风险：已知的风险都不是风险，怎么下降未知的风险？

互联网公司与传统软件公司最大的区别就是敏捷，咱们会将更多的精力放在三板斧的实现上。一般，咱们为了作一个功能可能花了30%的工做量，可是要花70%的工做量来作灰度、回滚、监控的建设。

在 API Gateway Mesh 上线的过程当中，咱们如何作灰度和快速回滚的？

这里，我举一个例子，Spanner 为新网 Sidecar 切流的流程。咱们支持经过百分比切流，能够作到慢速度的灰度和快速的回滚。另外，MOSN 的 Sidecar 注入不是一次性全集群接入的，咱们经过 Label 打标的方式，支持集群部分单机集成 MOSN 的切流验证。

云原生下 API Gateway 的思考

云原生南北向流量方案

上面介绍的是蚂蚁金服在实践 API Gateway Mesh 的一些经验，接下来，我想跟你们分享，云原生下一些标准的南北向流量解决方案的选择问题。

上图是业界主流的3种南北向方案，第一种是 K8s Ingress，功能比较简单；第二种是 Istio Gateway，具有了比 Ingress 更多的路由等功能；第三种是功能更增强大的 API Gateway，能够更加精细化的管控接口和流量，能够根据本身业务的特色选择适合本身的南北向流量产品。

云原生下 MOSN 的多面性

下面，介绍下 MOSN 的多面性。

前面讲过 Service Mesh 的 Sidecar，不只仅只用于南北流量的 RPC，实际上它能够作全部流量的 Sidecar。

将来，MOSN 的定位就是云原生全功能网络代理，能够和 LB 部署在一块儿做为 LB Sidecar；能够独立部署做为中心化网关；能够和业务 POD 部署做为去中心化网关或 MessageQueue Client；也能够做为跨云通讯网关。

Service Mesh 已来，还不赶忙上车！以上就是本期的所有分享内容。

做者介绍

靳文祥（花名贾岛），蚂蚁金服高级技术专家贾岛，2011年毕业后加入支付宝无线团队，一直从事移动网络接入、API 网关、微服务等相关的研发工做，目前负责蚂蚁金服移动网络接入架构设计与优化。

本期回顾视频以及分享 PPT 查看地址

https://tech.antfin.com/community/activities/1056/review/962

公众号：金融级分布式架构（Antfin_SOFA）