zuul网管

浅谈API网关(API Gateway)如何承载API经济生态链

2018-07-30  本文已影响0人  叶小枫

序言

​ API经济生态链已经在全球范围覆盖, 绝大多数企业都已经走在数字化转型的道路上,API成为企业连接业务的核心载体, 并产生巨大的盈利空间。快速增长的API规模以及调用量,使得企业IT在架构上、模式上面临着更多的挑战。关于如何承载现有快速发展的API生态链,本文接下来介绍API网关在其中扮演的角色。

先介绍一下API

​ 应用编程接口(Application Programming Interface,简称:API),就是软件系统不同组成部分衔接的约定【维基百科】。简单的例子: 您每次登陆微信, 需要提供账号信息才能访问, 微信提供的这个认证载体就是一个API。 API已经无处不在,金融、IT、物联网等,发展趋势相当迅速, 无形之中贯穿着我们的生活。

纵观这几年的发展,API在不断的技术迭代中形成了几股共同的趋势:

API网关为何诞生

​ 随着API的整体趋势发展, 每个历史时代都面临着不同的挑战, 架构也随之变化, 可以参考一下:

图片来源:API economy From systems to business services

​ 从最原始的“传输协议通讯” -> “简单的接口集成” -> “消息中间件” -> “标准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 Consumer使用的称之为数据平面, API Provider使用的称之为管理平面, 可在一定程度上对业务请求跟管理请求进行有效隔离。

整体架构图

先谈一下数据平面

​ API网关最核心设计理念: 保证数据面的业务不中断。由于对接API网关的服务是多样的, 客户API跟应用的设计不可控, 你很难能要求每个接入的服务以及客户端都具备容错能力, 特别是一些比较传统的业务。 这就要求网关尽量保证能正常处理每个请求, 且满足较高的SLA(Service-Level Agreement),现在业界的API网关分为几种: 直接使用云服务, Nginx系列, Golang系列, Java系列等, 选择比较多,如果想要自构建, 推荐使用Nginx系,主要考虑如下:

  1. 支持热重启
    数据面的组件升级是一个高风险动作, 一旦出现异常就可能导致连接中断,系统异常, 除非你的前端LB(负载均衡)能具备快速排水的能力,当然即使如此,还是可能导致正在处理的请求被强制中断。所以数据面的热重启非常关键。
  2. 支持订阅式动态路由
    API路由变化相对频繁,及时性也要求比较高, 如果采用定期同步方案, 一次性同步几万条的数据会拖慢你的系统, 因此增加一个订阅式的路由服务中心非常关键, 我们可以快速订阅ETCD中的路由数据并实时生效。而且只拿增量数据性能压力不会太大。
  3. 支持插件化管理
    Nginx在插件方面提供了丰富的生态。不同的API,不同的用户所需要的处理流程不完全一致, 如果每个请求过来都按照相同流程处理,必定带来相关的冗余操作。 插件化管理可以在一定程度上提升性能,还能保障在升级过程中能快速添加处理链。
  4. 高性能的转发能力
    API网关一般工作在多后端API反向代理模式,很多自研的API网关在性能上容易出现瓶颈,因此nginx优异的性能和高效的流量吞吐是其核心竞争力。
  5. 无状态可横向扩展:
    API网关承载的是整个系统所有请求的集合,需要根据业务规模进行弹性伸缩,采用服务中心配合Nginx配置管理可以快速增删已有的集群,并同步到LVS,实现快速的横向扩展能力。

再说一下管理面

相对于数据面, 管理面的约束就没有那么明显了, 管理面考虑更多应该在于数据的存储跟展示能力。一开始就定义好API的规范至关重要, Swagger作为现在最为主流的API描述模式,拥有非常完整的生态,AWS的整个API网关模型就是参考Swagger来构建的。

核心架构实现

API网关的相关实现, 我们今天就流控和路由遍历进行说明,其他相关的核心设计后续的文章中会陆续提供。

精细化秒级流控

​ 分钟级以上的流控,相对来说都比较好处理, 但是提升到秒级流控,对于系统的性能跟处理能力就是一个很大的挑战。网上的流控方案很多, 同步的,异步的各有优势, 但是都会遇到共同的问题: 性能与准确度。

以下是一种最为常见的流控方案(集群流控), 使用Redis共享存储记录所有的流控请求并实时访问, 该架构存在一个很明显的问题:当集群数量跟请求量很大的时候,Redis的集群性能会成为很大的瓶颈。

常见的共享存储的集群流控

​ 我们重新设计了一套API流控架构, 混合使用多种流控方案, 按照业务需求自动调整。这里我们拆分为本地流控和集群流控。 对于流量敏感的应用,会要求流控精度越精确,计算及时性高,时间维度低(秒级), 采用本地流控。对于时间周期长, 访问频率较低的API我们采用集群流控, 降低对共享存储的操作频率。

优化后的混合流控

注:上图展示具体流控架构,与API网关的集成请参考本章节开头的API网关架构全景。

基于树形结构的路由遍历算法

​ 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 网关

华为API网关
上一篇 下一篇

猜你喜欢

热点阅读