浅聊 API 网关

作者：fanniemeng

背景

很多人一说API网关，都是从微服务架构开始说起，说其是现在微服务架构中必备的一个标配组件，其实在微服务概念流行之前，API网关的就已经诞生了，如银行、证劵等领域常见的前置机系统，解决访问认证、报文转换、访问统计等；而我今天的切入点是从API-centric的应用的兴起。

API-centric

随着移动应用apps的风靡，应用程序开发人员需要简单地访问后端功能和数据；将后台的功能具体化有助于apps与系统交互。对一个企业， APIs的地位从‘最好能够具有‘转变为’必须具备‘，APIs也已成为了主流。

那开发人员眼有中的API是什么样子的？

1.前端和后端真正的分离 前端专注于页面展示的开发，通过约定好的api和后端交互，以及对api结果的处理逻辑；后端专注于各类api实现，返回指定类型的数据（json,xml等），这样前端和后端可以作为独立的项目进行并行的开发，由于更加专注和独立，所以对于代码质量和开发效率都是有很大好处的；

2.为多平台提供服务 基于api的应用，由于独立性，对服务的对象没有要求，可以是web项目，可以是移动app，可以是其他别的系统等等，这些终端通过api调用进行数据交互和数据处理，所以适用性更广。

图1 API-Centric 应用

那再回来聊的主题API网关

它的作用在于提供统一的入口来访问内部的API, 隔离外部访问与内部系统。集成了非业务性的功能（如安全检查、频次限制、API监控、日志上报等），API生命期管理、请求的转发、合成、协议转换、服务发现等多种功能。从图2就可以看出API网关功能以及在业务所处的位置。

图2 API网关业务应用示意图

API网关需要考虑的因素

1. 性能问题

作为流量入口，所有请求经由网关，对请求进行检查及决策，通过验证后进行反向代理转发到后端的server进行处理，可想而知，这对性能的要求是特别高的，尤其针对互联网中海量的用户要与后端交互，如果不能保证性能，就只能通过堆机器来水平扩容，无疑会加大投入的设备成本；像目前业务已有不少高性能的方案，如有在JVM上，基于NIO框架 的SpringCloud Zuul、构建在Node.js事件循环，回调机制的 IBM、有基于Openresty事件驱动型、协程的KONG, ORANGE 、也有基于件驱动型、协程的Tyk 。

2.高可用

API网关不可用将会是致命的影响，要通过冗余部署、自愈、多维度监控告警，确保API网关7*24小时的稳定运行；

3.扩展性

API网关是业务性比较强的一个组件，如报文的转换、认证、验证等, 所以它提供了一个脚本架，业务可以自行去扩展及变动；

4.服务发现

后端服务的IP存在很大的变动性，尤其是微服务化后应用基于docker,对获取服务的位置提出了挑战，大家可能会提公司的Cl5,这个确实可以解决部分场景的服务发现，但如果是后端是在docker中，变动性比较大，cl5解决不了，这就要启用集群的服务发现了。

5.缓存处理

可用来缓存变化频率不大及大部分用户看到的共同数据，同时也可以用来处理后端故障迟迟无数据返回时将缓存数据返回，保障用户的体验。

6.服务调用

支持进程间同步及异步的通信模块，可根据后端server情况支持所需要的通信机制。

业界常用的API网关方案对比

图3 业界已有方案对比

这里看一个示例orange，通过对其内部实现进行分析，来看看其是如何实现API网关的功能?

Orange是基于openresty, 而openresty是寄生在nginx上，Nginx 性能极高，Nginx 先天的事件驱动型设计、全异步的网络 I/O 处理机制、极少的进程间切换以及许多优化设计，都使得 Nginx 天生善于处理高并发压力下的互联网请求。Nginx 的稳定性也在各大网站得到验证。官方提供的常用模块都非常稳定，每个 worker 进程相对独立，master 进程在 1 个 worker 进程出错时可以快速“拉起”新的 worker 子进程提供服务。支持热部署，可以不停机更新配置文件、更新日志文件、更新服务器程序版本。

而Openresty复用了nginx的诸多特性，同时暴露了nginx处理的各个阶段的钩子，业务可以灵活的在各阶段去挂载自己的业务，如下图4所示，orange将各个功能插件巧妙的挂载到nginx的各个执行阶段，如可在access阶段做身份验证、安全、流量控制等，在proxy阶段，转发流量做反向代理等等。

在规则增、修、删上这些方案大都提供API接口来实现，可通过curl API来实现规则的变换，为便捷操作这块大部分方案都配套有Dashboard管理操作界面，可直接在上面进行操作，其原理也是通过模拟发送API来实现。

图4 orange内部实现

而orange的流量刷选则是通过对相关参数进行正则匹配来实现，规则可以重叠生效，图5显示的就是orange的内部流量刷选规则。

图5 流量刷选规则

API网关的优点：

1. 给服务加一层安全保护 可在这一层做sql注入、CRSF攻击防范等WAF层面的安全保护；
2. 对外提供统一的通信协议，如HTTP或restful api, 屏蔽内部的通信协议 系统内部可采用自身熟悉的通信协议，如Protobuf 或RPC等；
3. 降低代码耦合度、降低开发成本 将非业务性功能如访问控制（黑白名单）、频次限制等集中在网关层处理，开发只需关注自己本业务的需求实现即可，降低了开发成本；
4. 可灵活灰度及新功能测试 通过细粒度的流量识别，进而反向代理，业务可灵活灰度及AB测试；
5. 服务发现 随着后端server变动甚至云化,对服务发现提出了新挑战，通过在API网关实现服务发现可以简化客户端的实现。
6. 减少客户端与后台server的交互 随着微服务化API更加细粒度，这势必会加大客户端对后台server的访问次数，如做一些返回数据合并，让客户端通过一次请求在API网关处合并需要的数据一次性返回等，但这一块业务性太强，像业界的方案很少有做一块的，大部分实现是在API网关后端加了一个BBF(backend for frontend)来做数据的整合；
7. 对API进行管理；

缺点：

得开发、部署、维护一个开可用的API网关组件；

总结：

不管是由于APIs的普及，还是作为微服务架构中的一员，实现API网关是很重要的。在具备对请求做决策判断后的转发、协议转换、路由等基本功能外还需要有良好可扩展性。在功能实现时要尽可能的跟业务层解耦。作为一个高可用、伸缩性强的组件，优缺点并存，但相对其带来的功能这些缺点是可以容忍的。