苏宁金融一站式API网关演进之路

Posted 2021-04-21 紫金支付极客

一、 网关简介

苏宁金融一站式API网关是面向公网的API托管服务

为各研发团队提供 API 的完整生命周期管理、服务契约管理、服务监控等功能。

可以使用API服务管理平台包装自身业务服务，将苏宁金融的数据服务、业务逻辑及功能组件安全可靠的开放给外部调用。

提供统一解决方案

动态代理、安全防护、流控降级、智能熔断、灰度发布、监控告警、API MOCK调试等。

具体功能将在后文中详细介绍。在详细介绍功能的同时，允许我先介绍一下苏宁金融API网关的演进路线，希望在阅读的过程中能了解到我们的设计思路。当然，我们的设计还有很多不足之处，也请各位大神指出，我们将会持续改进。

二、 网关起源：苏宁金融移动服务网关（1.0）

1、初代诞生

2013年，是互联网金融爆发的一年。“余额宝”、“零钱宝”等互联网理财产品在这一年诞生，以及蓬勃发展的第三方支付、虚拟货币的合法化等等，都将互联网金融一步步展露在人们的面前，因此2013年也被称为“互联网金融元年”。

移动APP作为互联网模式的新宠，自然也不会放慢脚步。所以在这一年，苏宁金融也上线了第一款移动应用——易付宝APP（现已更名为苏宁金融APP，下文我们称之为苏宁金融APP）。同时，我们也上线了第一个网关系统——苏宁金融移动服务网关。

但由于移动端在当时刚刚兴起，苏宁金融的大部分业务服务均是为PC端定制 ，并不能适应移动端需求的特性。在移动端还没成为主流的当时，要求所有服务系统去适配移动端特性无疑也是不现实的。所以网关系统为苏宁金融APP提供安全加密、协议转换、流控等网关通用能力的同时，还承载了移动端特有业务逻辑封装的职能。

所以与其说是网关，我们网关早期的系统定位更偏向于移动服务系统。

如上图所示，早期的网关系统职能大体分为三个部分：

网关基础服务: 提供安全防护、服务限流、服务开关、鉴权等网关基础服务。

移动应用服务: 提供移动特有功能服务。

金融业务服务: 封装各业务线微服务，并根据移动需求定制化封装。

但随着移动互联网的发展，移动应用的便捷性等优势慢慢体现，移动应用也逐渐成为互联网的趋势。各业务线的需求也开始往移动端倾斜，随之而来的，我们原网关设计的问题也逐渐暴露出来。

2、问题缺陷

系统职能模糊：早期的网关服务系统还承载了移动业务逻辑包装的职能，网关功能与移动服务糅合在一起，很难清晰的定义网关服务系统职能、明确系统分工。

业务耦合紧密：所有业务的逻辑均在同一服务系统，那么当某一业务出现问题，势必会对其他业务同时产生影响。

研发效率较低：由于具有移动服务端的职能，各业务线的移动端需求都会集中在移动网关服务系统，网关开发部的开发效率成为了产品迭代的“瓶颈”。

版本过渡依赖：同时由于各业务的需求均需网关做改造，致使各业务线的版本迭代过于依赖网关的版本周期。

面对如此多的问题，为了保证研发效率，提升产品迭代节奏，我们只能选择将系统拆分重构。

三、 拆分重构：苏宁金融路由网关（2.0）

比较严重的两个问题，是系统职能模糊及业务耦合紧密，这两个问题不解决，我们的系统只会越来越重，所以我们决定将系统拆分。并且为了彻底解决问题，我们决定将横向拆分及纵向拆分同时进行。

1、横向拆分，明确系统职能：

我们首先要做的，就是将网关与移动业务服务剥离。将移动业务服务下沉到网关下层，由各业务线研发团队提供完整API服务，移动应用服务单独搭建移动服务系统承载，并提供微服务接入网关。

同时，我们将网关也横向拆分为路由网关及API网关两层。

路由网关

位于网关平台最上层，利用nginx+Lua(OpenResty) 开发的高性能web应用。

Nginx的主要应用场景如负载均衡、反向代理、代理缓存等。而OpenResty是由nginx核心+很多第三方模块儿组成。最重要的是OpenResty集成了Lua库，开发人员可使用Lua编写脚本并部署于nginx运行，使nginx变成了一个web应用。

当网关后台操作路由规则配置发生变化时会将配置持久化于redis，同时将规则配置信息推送至nginx代理服务器。

当用户发送请求时，路由网关（OpenResty）中部署的Lua脚本则根据从 redis读取的路由规则将流量切换分流，达到灰度或A/B Test的目的。同时路由规则可以支持多种维度，如按比例、用户标识、请求终端类型、终端版本等，可以覆盖多种使用场景。

路由方案示意

API网关

介于路由网关与服务层之间，为适配苏宁技术架构的中间件及组件特性，如RSF协议、zedis组件等。所以我们没有选择市面上主流的如zuul、kong以及spring Cloud gateway等网关组件，在学习了主流网关的功能及思路之后，我们选择自研编写更适用苏宁金融技术架构体系的网关。相对于路由网关，API网关的职责则更具体一些，如请求校验、服务流控、服务鉴权、apimock等等功能均在这一层实现，而且功能还在持续扩展中。

应用架构图示意

为了方便我们API网关功能的持续扩展，以及实现请求与处理者之间的解耦，我们采用了责任链模式：

将每个处理逻辑独立为一个handler处理器，并通过handerManager进行初始化并控制各处理器的执行顺序。在各处理器职责分类并排序后，将所有处理逻辑组织成了有序的执行队列。在API网关其他功能扩展时，可以高效快速的植入，而不会影响正常公共逻辑。

2、纵向拆分，业务线解耦合

虽然API网关提供的基础功能相同，但是为了避免接入网关的各业务线互相影响，我们网关根据不同的业务类型也做了一次纵向拆分。在分布式集群架构的基础上，按API服务业务类型分配不同集群组，进行服务部署隔离。降低各业务线服务互相之间由于发布、大促所产生的问题可能带来的影响，解除各业务线之间的耦合，保证网关的高可用性。

按业务线隔离部署的另一个好处是，网关也可以根据不同业务的访问量及特性做定向扩容。当用户发送请求时，由路由网关根据网关平台的路由规则做动态代理到不同的集群的API网关。

3、标准协议，适用多终端

服务协议标准化：提供标准网关https+OAuth2.0协议rest风格API，在移动APP提供服务的基础上，也可为H5、微信小程序等提供API服务。

服务契约标准化： 之前服务API的服务契约定义规则五花八门，可读性较差，经常对调用方产生困惑。例：

API接口路径定义：

API服务路径风格不统一、规范不一致、可读性较差，如

xxxx.suning.com/account/getAccount

xxxx.suning.com/loan/loaninfo/queryloan

...

API通用参数定义：

一些各系统均可能使用的通用参数，参数名定义不同，很容易对调用方产生困惑。

会员编号：accountNo、userNo、userNum...

响应码：responseCode、resCode、errorCode…

…

API响应码定义：

响应码风格不统一、缺乏唯一性、同一响应码含义不同、不同响应码含义相同…

成功：0000，true、000000…

失败：5000,false,xxx_9999

接入统一API网关后，对这些定义都制定了标准化规范，提升了服务可读性、降低服务接入成本。

接口路径定义规则标准：

xxxx.suning.com/{业务类型}/{服务组}/{api服务名称}

接口路径在服务管理员配置好服务信息后自动生成，无需服务管理员重新定义。

例：xxxx.suning.com/basic/account/getAccount

xxxx.suning.com/trade/loan/getLoan

公共参数统一标准：

通过网关暴露API服务的一些公共参数制定了统一规范，同时为适配下游微服务不同定义，可以配置参数映射。

响应码统一标准：

通过网关暴露API服务的响应码制定了统一规范，同时为适应下游微服务不同定义，可以配置响应码及响应文案映射。

前后端分离：

提供完成的前后端分离解决方案，明确前端开发及后端开发职责。

前端应用独立部署，前端开发人员关注页面跳转、页面渲染等逻辑，通过ajax请求调用网关API获取页面数据。

API网关提供网关通用能力，同时针对前端应用解决跨域访问及跨域cookie共享等问题。

服务提供方提供完整数据及业务逻辑服务。

跨域问题：

解决方案：

方案一：配置白名单：设置Access-Control-Allow-Origin属性，仅在白名单内的域名可以跨域访问网关接口。（需针对H5访问做定制校验）

方案二：通过注解@CrossOrigin设置为任何域名均可以跨域访问，但调用API接口需校验请求方身份。（与非H5访问方案一致）

方案三：nginx反响代理：前端应用的nginx服务器配置反向代理监听域名访问，当识别到特殊路径服务，将请求分发到对应的网关服务器。

安全问题：

前后端的分离，也带来一些安全问题。所以与网关的交互方案参考了原来与移动端的安全加密方案。

1、提供JS版本的加密方法库及配套demo，可支持RSA/AES/国密算法加密。

2、考虑到前端的代码都是暴露在外面并不是特别安全，所以如果H5页面是内嵌于苏宁金融APP的话， 我们还提供加密组件sdk供前端h5调用，同时公钥存储于组件内部。前端只需传入明文及秘钥标识即可完成加密，进一步保证安全性。

对小程序的支持：

采用标准Oauth2.0协议认证流程，提供完整的小程序接入解决方案，可以快速高效的搭建苏宁金融的任意小程序。

四、 主动转型：苏宁金融一站式API网关平台（2.5）

网关的拆分重构，明确了系统定位、解除了各业务线的耦合，但是之前提到的研发效率低、版本过渡依赖的问题不能仅仅通过拆分系统得到有效解决。

所以我们在完成网关拆分重构后，将重点转向了API服务管理，在提升服务端研发效率的同时，于金融各平台深度合作，致力于打造金融一站式API网关平台。

1、服务配置化，提升研发效率

既然网关职责已经明确，API网关提供标准化的通用网关能力，那么网关所提供的API服务就可以通过配置来生成。

所以我们提供了API服务管理平台，可以通过可视化界面完成API的生命周期管理，可以极大的提升网关API开发效率。

2、管理规范化，解除版本依赖

既然服务可以通过配置来实现，那么配置工作也就可以不集中在网关管理员身上。所以我们将API权限下放到各业务线研发团队，由网关管理员审核接入服务申请，并为服务分配服务业务类型（集群组）。各研发团队可随时配置API服务并上线，完全解除了研发线对网关的版本依赖。

并且明确了岗位职责权限，规范化了服务管理的流程，各业务岗位各司其职。

3、平台集中化，提供一站式服务：

在做API服务管理平台架构设计的时候，我们发现API服务管理平台很多规划的功能与现有的金融平台有重合。如

金融魔客平台：提供接口契约管理及mock案例管理等功能；

金融流控平台：提供多级、多维度流控组件及流控组阈值配置平台；

紫金大盘监控平台：提供服务性能监控、服务异常统计等功能；

虽然平台很全面，但是服务端开发人员，需登录不同的平台才能完成服务相关配置和管理。

为了避免系统重复建设，由专业的团队做专业的事情，我们放弃了重新搭建的想法，而是选择与已有平台深度合作。同时为了避免API服务管理员使用过多的平台，操作没有衔接性和连贯性。API服务管理平台将这些平台的配置界面融合嵌入，通过唯一的服务管理入口，即可完成各平台的全部配置工作，达到一站式服务的目的：

截止目前，已接入网关的业务服务有近20组，已注册API服务400多个，其他业务服务还在持续接入中，下图为目前已接入网关核心服务分布占比：

五、 未来规划：苏宁金融开放API网关平台（3.0）

虽然目前我们的网关平台已经基本成型，但是比起业界主流的网关组件还有很多不足。比如目前我们的服务只能通过平台注册，欠缺服务发现的功能，以及我们还在规划中的服务编排、AB Test等功能。所以我们也对网关平台的3.0版本进行了重点需求规划。

服务开放：

目前我们的网关提供还是对内体系API，近期我们将于金融开放平台融合，提供完整开放API解决方案：开放平台提供商户签约及流程，由网关暴露API服务供第三方调用。

以及其他功能规划

作者简介：

王鑫，苏宁金融网关产品技术开发部经理，曾从事联通boss运营支撑计费系统及江苏移动游戏基地MDSP研发工作，入苏宁以来一直从事移动服务端及API网关技术研发多年。精通移动服务的安全、性能优化等领域，以及微服务架构实践，目前主要负责苏宁金融会员及互联网研发中心API网关技术规划、架构设计及研发工作。

王清平，苏宁金融资深架构师，精通微服务架构模式，熟悉Java领域技术架构。在广告、营销、电商领域的技术研发、架构设计等方面拥有多年实战经验，擅长提升系统的高可用，高性能，扩展性等能力。现在主要负责苏宁金融会员及互联网研发中心的应用架构与技术架构工作。