1 网关简介
苏宁金融一站式API网关是面向公网的API托管服务
为各研发团队提供 API 的完整生命周期管理、服务契约管理、服务监控等功能。
可以使用API服务管理平台包装自身业务服务，将苏宁金融的数据服务、业务逻辑及功能组件安全可靠的开放给外部调用。
提供统一解决方案
动态代理、安全防护、流控降级、智能熔断、灰度发布、监控告警、API MOCK调试等。
具体功能将在后文中详细介绍。在详细介绍功能的同时，允许我先介绍一下苏宁金融API网关的演进路线，希望在阅读的过程中能了解到我们的设计思路。当然，我们的设计还有很多不足之处，也请各位大神指出，我们将会持续改进。
2 网关起源：苏宁金融移动服务网关（1.0）
2.1初代诞生
2013年，是互联网金融爆发的一年。“余额宝”、“零钱宝”等互联网理财产品在这一年诞生，以及蓬勃发展的第三方支付、虚拟货币的合法化等等，都将互联网金融一步步展露在人们的面前，因此2013年也被称为“互联网金融元年”。
移动APP作为互联网模式的新宠，自然也不会放慢脚步。所以在这一年，苏宁金融也上线了第一款移动应用——易付宝APP（现已更名为苏宁金融APP，下文我们称之为苏宁金融APP）。同时，我们也上线了第一个网关系统——苏宁金融移动服务网关。
但由于移动端在当时刚刚兴起，苏宁金融的大部分业务服务均是为PC端定制 ，并不能适应移动端需求的特性。在移动端还没成为主流的当时，要求所有服务系统去适配移动端特性无疑也是不现实的。所以网关系统为苏宁金融APP提供安全加密、协议转换、流控等网关通用能力的同时，还承载了移动端特有业务逻辑封装的职能。
所以与其说是网关，我们网关早期的系统定位更偏向于移动服务系统。
如上图所示，早期的网关系统职能大体分为三个部分：
网关基础服务: 提供安全防护、服务限流、服务开关、鉴权等网关基础服务。
移动应用服务: 提供移动特有功能服务。
金融业务服务: 封装各业务线微服务，并根据移动需求定制化封装。
但随着移动互联网的发展，移动应用的便捷性等优势慢慢体现，移动应用也逐渐成为互联网的趋势。各业务线的需求也开始往移动端倾斜，随之而来的，我们原网关设计的问题也逐渐暴露出来。
2.2问题缺陷
系统职能模糊：早期的网关服务系统还承载了移动业务逻辑包装的职能，网关功能与移动服务糅合在一起，很难清晰的定义网关服务系统职能、明确系统分工。
业务耦合紧密：所有业务的逻辑均在同一服务系统，那么当某一业务出现问题，势必会对其他业务同时产生影响。
研发效率较低：由于具有移动服务端的职能，各业务线的移动端需求都会集中在移动网关服务系统，网关开发部的开发效率成为了产品迭代的“瓶颈”。
版本过渡依赖：同时由于各业务的需求均需网关做改造，致使各业务线的版本迭代过于依赖网关的版本周期。
面对如此多的问题，为了保证研发效率，提升产品迭代节奏，我们只能选择将系统拆分重构。
3 拆分重构：苏宁金融路由网关（2.0）
比较严重的两个问题，是系统职能模糊及业务耦合紧密，这两个问题不解决，我们的系统只会越来越重，所以我们决定将系统拆分。并且为了彻底解决问题，我们决定将横向拆分及纵向拆分同时进行。
3.1横向拆分，明确系统职能：
我们首先要做的，就是将网关与移动业务服务剥离。将移动业务服务下沉到网关下层，由各业务线研发团队提供完整API服务，移动应用服务单独搭建移动服务系统承载，并提供微服务接入网关。
同时，我们将网关也横向拆分为路由网关及API网关两层。
路由网关
位于网关平台最上层，利用Nginx+Lua(OpenResty) 开发的高性能web应用。
Nginx的主要应用场景如负载均衡、反向代理、代理缓存等。而OpenResty是由nginx核心+很多第三方模块儿组成。最重要的是OpenResty集成了Lua库，开发人员可使用Lua编写脚本并部署于nginx运行，使nginx变成了一个web应用。
而路由网关主要利用了nginx的动态代理机制，根据请求接口地址动态路由到API网关不同业务集群或灰度集群。
当网关后台操作路由规则配置发生变化时会将配置持久化于redis，同时将规则配置信息推送至nginx代理服务器。
当用户发送请求时，路由网关（OpenResty）中部署的Lua脚本则根据从 redis读取的路由规则将流量切换分流，达到灰度或A/B Test的目的。同时路由规则可以支持多种维度，如按比例、用户标识、请求终端类型、终端版本等，可以覆盖多种使用场景。
路由方案示意
API网关
介于路由网关与服务层之间，为适配苏宁技术架构的中间件及组件特性，如RSF协议、zedis组件等。所以我们没有选择市面上主流的如zuul、kong以及spring Cloud gateway等网关组件，在学习了主流网关的功能及思路之后，我们选择自研编写更适用苏宁金融技术架构体系的网关。相对于路由网关，API网关的职责则更具体一些，如请求校验、服务流控、服务鉴权、apimock等等功能均在这一层实现，而且功能还在持续扩展中。
应用架构图示意
为了方便我们API网关功能的持续扩展，以及实现请求与处理者之间的解耦，我们采用了责任链模式：
将每个处理逻辑独立为一个handler处理器，并通过handerManager进行初始化并控制各处理器的执行顺序。在各处理器职责分类并排序后，将所有处理逻辑组织成了有序的执行队列。在API网关其他功能扩展时，可以高效快速的植入，而不会影响正常公共逻辑。
3.2纵向拆分，业务线解耦合
虽然API网关提供的基础功能相同，但是为了避免接入网关的各业务线互相影响，我们网关根据不同的业务类型也做了一次纵向拆分。在分布式集群架构的基础上，按API服务业务类型分配不同集群组，进行服务部署隔离。降低各业务线服务互相之间由于发布、大促所产生的问题可能带来的影响，解除各业务线之间的耦合，保证网关的高可用性。
按业务线隔离部署的另一个好处是，网关也可以根据不同业务的访问量及特性做定向扩容。当用户发送请求时，由路由网关根据网关平台的路由规则做动态代理到不同的集群的API网关。
3.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共享等问题。
服务提供方提供完整数据及业务逻辑服务。
跨域问题：
跨域是指a页面想获取b页面资源，如果a、b页面的协议、域名、端口、子域名不同，或是a页面ip地址，b页面为域名地址，所进行的访问行动都是跨域的，而浏览器为了安全问题会限制跨域访问，跨域请求可以正常发出，但返回结果会被浏览器拦截。
解决方案：
方案一：配置白名单：设置Access-Control-Allow-Origin属性，仅在白名单内的域名可以跨域访问网关接口。（需针对H5访问做定制校验）
方案二：通过注解@CrossOrigin设置为任何域名均可以跨域访问，但调用API接口需校验请求方身份。（与非H5访问方案一致）
方案三：nginx反响代理：前端应用的nginx服务器配置反向代理监听域名访问，当识别到特殊路径服务，将请求分发到对应的网关服务器。
安全问题：
前后端的分离，也带来一些安全问题。所以与网关的交互方案参考了原来与移动端的安全加密方案。
1、提供JS版本的加密方法库及配套demo，可支持RSA/AES/国密算法加密。
2、考虑到前端的代码都是暴露在外面并不是特别安全，所以如果H5页面是内嵌于苏宁金融APP的话， 我们还提供加密组件sdk供前端h5调用，同时公钥存储于组件内部。前端只需传入明文及秘钥标识即可完成加密，进一步保证安全性。
对小程序的支持：
采用标准Oauth2.0协议认证流程，提供完整的小程序接入解决方案，可以快速高效的搭建苏宁金融的任意小程序。
4 主动转型：苏宁金融一站式API网关平台（2.5）
网关的拆分重构，明确了系统定位、解除了各业务线的耦合，但是之前提到的
研发效率低、版本过渡依赖的问题不能仅仅通过拆分系统得到有效解决。所以我们在完成网关拆分重构后，将重点转向了API服务管理，在提升服务端研发效率的同时，于金融各平台深度合作，致力于打造金融一站式API网关平台。
4.1服务配置化，提升研发效率
既然网关职责已经明确，API网关提供标准化的通用网关能力，那么网关所提供的API服务就可以通过配置来生成。
所以我们提供了API服务管理平台，可以通过可视化界面完成API的生命周期管理，可以极大的提升网关API开发效率。
4.2管理规范化，解除版本依赖
既然服务可以通过配置来实现，那么配置工作也就可以不集中在网关管理员身上。所以我们将API权限下放到各业务线研发团队，由网关管理员审核接入服务申请，并为服务分配服务业务类型（集群组）。各研发团队可随时配置API服务并上线，完全解除了研发线对网关的版本依赖。
并且明确了岗位职责权限，规范化了服务管理的流程，各业务岗位各司其职。
4.3平台集中化，提供一站式服务：
在做API服务管理平台架构设计的时候，我们发现API服务管理平台很多规划的功能与现有的金融平台有重合。如
金融魔客平台：提供接口契约管理及mock案例管理等功能；
金融流控平台：提供多级、多维度流控组件及流控组阈值配置平台；
紫金大盘监控平台：提供服务性能监控、服务异常统计等功能；
虽然平台很全面，但是服务端开发人员，需登录不同的平台才能完成服务相关配置和管理。
为了避免系统重复建设，由专业的团队做专业的事情，我们放弃了重新搭建的想法，而是选择与已有平台深度合作。同时为了避免API服务管理员使用过多的平台，操作没有衔接性和连贯性。API服务管理平台将这些平台的配置界面融合嵌入，通过唯一的服务管理入口，即可完成各平台的全部配置工作，达到一站式服务的目的：
截止目前，已接入网关的业务服务有近20组，已注册API服务400多个，其他业务服务还在持续接入中，下图为目前已接入网关核心服务分布占比：
5 未来规划：苏宁金融开放API网关平台（3.0）
虽然目前我们的网关平台已经基本成型，但是比起业界主流的网关组件还有很多不足。比如目前我们的服务只能通过平台注册，欠缺服务发现的功能，以及我们还在规划中的服务编排、A\B Test等功能。所以我们也对网关平台的3.0版本进行了重点需求规划。
服务开放：
目前我们的网关提供还是对内体系API，近期我们将于金融开放平台融合，提供完整开放API解决方案：开放平台提供商户签约及流程，由网关暴露API服务供第三方调用。
以及其他功能规划
閱讀更多 IT說 的文章
