序言
API经济生态链已经在全球范围覆盖， 绝大多数企业都已经走在数字化转型的道路上，API成为企业连接业务的核心载体， 并产生巨大的盈利空间。快速增长的API规模以及调用量，使得企业IT在架构上、模式上面临着更多的挑战。关于如何承载现有快速发展的API生态链，本文接下来介绍API网关在其中扮演的角色。
先介绍一下API
应用编程接口（Application Programming Interface，简称：API），就是软件系统不同组成部分衔接的约定【维基百科】。简单的例子： 您每次登陆微信， 需要提供账号信息才能访问， 微信提供的这个认证载体就是一个API。 API已经无处不在，金融、IT、物联网等，发展趋势相当迅速， 无形之中贯穿着我们的生活。
纵观这几年的发展，API在不断的技术迭代中形成了几股共同的趋势：
-
API开放数量不断增加
这点毋庸置疑， 随着企业的数据化进展，微服务改造，不同领域的API层出不穷， 早在2014年ProgrammableWeb便预测API矢量可达到100,000到200,000， 并会不断增长。API开发数量的增加给边缘系统带来机会， 也随即演变了API网关的出现。大规模的API管理系统成为核心的发展趋势。图片来源：The API Economy Disruption and the Business of APIs，Nordic APIs -
API服务平台多样化
最初的API主要针对不同单体应用的网络单元之间信息交互， 现已演变到服务间快速通讯。随着人工智能EI， IOT的不断演进， 依赖API的平台不断更新， 如Web， Mobile， 终端等，未来将会出现更多的服务体系。
多样化平台 -
逐步替换原有企业的服务模式，API即商品
卖计算， 卖软件， 卖能力， 最终的企业的销售模式会逐步转变，能力变现， 释放数据价值，依托不同的API管理平台创造新的盈利。
API网关为何诞生
随着API的整体趋势发展， 每个历史时代都面临着不同的挑战， 架构也随之变化， 可以参考一下：
从最原始的“传输协议通讯” -> “简单的接口集成” -> “消息中间件” -> “标准REST”， 可以看到API的发展更趋向于简洁， 集成，规范化， 这也促使更多的系统边界组件不断涌现，在承载了万亿级的API经济的背景下， API网关应运而生。
Gartner 报告中提到： 如果没有合适的API管理工具， API经济不可能顺利开展。 同时提出了对于API管理系统的生命周期定义： planning（规划）, design（设计）， implementation（实施）， publication（发布），operation（运维）, consumption（消费）, maintenance（维护） and retirement of APIs（下架）【来源：Magic Quadrant for Full Life Cycle API Management，Gartner发表于2016-10-27】。
API网关贯穿整个流程，并提供丰富的管理特性。
- 高性能，可横向扩展
- 高可靠，业务不中断
- 插件化的API安全控制
- 灵活的数据编排
- 精细化流控
- API版本管理
- API数据分析
- 高效插件化路由算法
- 安全认证，防攻击
- API访问控制
- Swagger导入导出
- …
API网关的核心设计实践
提供一个可参考的高性能API网关架构， 在设计API网关的时候把整体分为两个平面， API Consumer使用的称之为数据平面， API Provider使用的称之为管理平面， 可在一定程度上对业务请求跟管理请求进行有效隔离。
先谈一下数据平面
API网关最核心设计理念： 保证数据面的业务不中断。由于对接API网关的服务是多样的， 客户API跟应用的设计不可控， 你很难能要求每个接入的服务以及客户端都具备容错能力， 特别是一些比较传统的业务。 这就要求网关尽量保证能正常处理每个请求， 且满足较高的SLA（Service-Level Agreement），现在业界的API网关分为几种： 直接使用云服务， Nginx系列， Golang系列， Java系列等， 选择比较多，如果想要自构建， 推荐使用Nginx系，主要考虑如下：
- 支持热重启
数据面的组件升级是一个高风险动作， 一旦出现异常就可能导致连接中断，系统异常， 除非你的前端LB（负载均衡）能具备快速排水的能力，当然即使如此，还是可能导致正在处理的请求被强制中断。所以数据面的热重启非常关键。 - 支持订阅式动态路由
API路由变化相对频繁，及时性也要求比较高， 如果采用定期同步方案， 一次性同步几万条的数据会拖慢你的系统， 因此增加一个订阅式的路由服务中心非常关键， 我们可以快速订阅ETCD中的路由数据并实时生效。而且只拿增量数据性能压力不会太大。 - 支持插件化管理
Nginx在插件方面提供了丰富的生态。不同的API，不同的用户所需要的处理流程不完全一致， 如果每个请求过来都按照相同流程处理，必定带来相关的冗余操作。 插件化管理可以在一定程度上提升性能，还能保障在升级过程中能快速添加处理链。 - 高性能的转发能力
API网关一般工作在多后端API反向代理模式，很多自研的API网关在性能上容易出现瓶颈，因此nginx优异的性能和高效的流量吞吐是其核心竞争力。 - 无状态可横向扩展：
API网关承载的是整个系统所有请求的集合，需要根据业务规模进行弹性伸缩，采用服务中心配合Nginx配置管理可以快速增删已有的集群，并同步到LVS，实现快速的横向扩展能力。
再说一下管理面
相对于数据面， 管理面的约束就没有那么明显了， 管理面考虑更多应该在于数据的存储跟展示能力。一开始就定义好API的规范至关重要， Swagger作为现在最为主流的API描述模式，拥有非常完整的生态，AWS的整个API网关模型就是参考Swagger来构建的。
核心架构实现
API网关的相关实现， 我们今天就流控和路由遍历进行说明，其他相关的核心设计后续的文章中会陆续提供。
精细化秒级流控
分钟级以上的流控，相对来说都比较好处理， 但是提升到秒级流控，对于系统的性能跟处理能力就是一个很大的挑战。网上的流控方案很多， 同步的，异步的各有优势， 但是都会遇到共同的问题： 性能与准确度。
以下是一种最为常见的流控方案（集群流控）， 使用Redis共享存储记录所有的流控请求并实时访问， 该架构存在一个很明显的问题：当集群数量跟请求量很大的时候，Redis的集群性能会成为很大的瓶颈。
我们重新设计了一套API流控架构， 混合使用多种流控方案， 按照业务需求自动调整。这里我们拆分为本地流控和集群流控。 对于流量敏感的应用，会要求流控精度越精确，计算及时性高，时间维度低（秒级）， 采用本地流控。对于时间周期长， 访问频率较低的API我们采用集群流控， 降低对共享存储的操作频率。
注：上图展示具体流控架构，与API网关的集成请参考本章节开头的API网关架构全景。
- 本地流控
即单机流控，适用流量敏感型业务。 API按照API-Core集群节点计算Hash值，确保每个API都能负载到其中一个集群节点上。 假设有A， B，C三台API-Core， 如果某个API计算的一致性hash值为A节点， 当请求发送到A节点时直接从这台节点转发，并记录一个流控值， 当请求发送到B/C节点的时候都会转发到A节点计算一个流控值再往后转发。 这样同一个API的流控请求就会全部记录到一台API-Core上。可以借助API-Core的单机流控能力。单机流控的算法也是插件化的，可以采用计数，漏桶等。
当然本地流控也会带来一定问题，当所有的API都负载到一个节点上，如果一个API的访问量特别大， 那就可能导致负载不太均匀。还有就是如果流控时间记录很长，比如12次/天， 计数时间周期太长了也不太适合本地流控。 - 集群流控
集群流控适用计数周期长， 流控精度要求不高的业务。跟本地流控相辅相成， 按照不同的业务选择不同的流控， 相关的流控处理流程跟上述的本地流控基本相同，但是会在本地会先缓存一段时间的流控数据再统一上报流控中心。
基于树形结构的路由遍历算法
API网关数据面的主要流程包含路由匹配算法， 路由的所有数据都会缓存在ETCD中，为提升数据面性能， 存储的结构至关重要。在存储过程中我们分为两部分： 域名树， URI树
从第一个树形结构中我们可以遍历到有以下几个域名： www.apig.com, test.com, *.apig.com, .com。 域名存储从最后一个“.”开始遍历。 举例：
匹配： www.test.com ， 先匹配com， 匹配成功继续遍历test， 匹配成功遍历www， 无www匹配失败。
匹配： test.apig.com, 先匹配com， 匹配成功继续遍历apig， 匹配成功遍历test， 无test， 遍历号， 匹配目标： *.apig.com
URL的匹配为前序匹配跟域名的匹配模式相反，但是遍历算法一致。
总结
业界主流的开源API网关架构很多， Kong,，Tyk， Zuul等，开源软件都有一个共同的特点： 量级，安全，运维分析相对匮乏， 而且真正要满足生产环境需求，还需要投入较高的研发成本。术业有专攻，找一个完善的API管理解决方案对于企业能力变现非常重要。
华为云API网关服务提供完整的API生命周期管理解决方案， 支持多种使用场景， 提供便捷的管理服务。让API的上线，发布，管理到最后售卖的流程不再复杂，快速完成企业能力变现。 欢迎前往体验： 华为云-API 网关
