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

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

   数栈君   发表于 2023-11-16 10:45  152  0

序言


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



API 是什么


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


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


1.API 开放数量不断增加


毋庸置疑,随着企业的数据化进展,微服务改造,不同领域的
API 层出不穷,早在 2014 年 ProgrammableWeb 便预测 API 矢量可达到 100,000 到
200,000,并会不断增长。API 开发数量的增加给边缘系统带来机会,也随即演变了 API 网关的出现。大规模的 API
管理系统成为核心的发展趋势。


http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user1/article/742102469a236d9c69c90557e7499e5b..jpg
图片来源:The API Economy Disruption and the Business of APIs,Nordic APIs


2.API 服务平台多样化


最初的 API 主要针对不同单体应用的网络单元之间信息交互,现已演变到服务间快速通讯。随着人工智能 EI,IOT 的不断演进,依赖 API 的平台不断更新,如 Web,Mobile,终端等,未来将会出现更多的服务体系。


http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user1/article/19ca7f33a7110294af7ee3e703c9858e..jpg


3. 逐步替换原有企业的服务模式,API 即商品


卖计算,卖软件,卖能力,最终的企业的销售模式会逐步转变,能力变现,释放数据价值,依托不同的 API 管理平台创造新的盈利。



API 网关为何诞生


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


http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user1/article/e059bc94b40e54c99f3c8b44b4a16b14..jpg
图片来源: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 访问控制
  • Swagger 导入导出

API 网关的设计核心实践


提供一个可参考的高性能 API 网关架构,在设计 API 网关的时候把整体分为两个平面,API Consumer 使用的称之为数据平面,API Provider 使用的称之为管理平面,可在一定程度上对业务请求跟管理请求进行有效隔离。


http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user1/article/4e4e45d28d3d8f6502244bcd517bdebc..jpg


先谈一下数据平面


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 的集群性能会成为很大的瓶颈。


http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user1/article/8aab6c4a5c2e036b730bf245c696a3f1..jpg


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


http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user1/article/2a6babf767863ccd08e7ce8631c5c733..jpg
注:上图展示具体流控架构,与 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 树


http://dtstack-static.oss-cn-hangzhou.aliyuncs.com/2021bbs/files_user1/article/3db9ee74f0b11aeda67e93cdf943c983..jpg


从第一个树形结构中我们可以遍历到有以下几个域名:http://www.apig.com, test.com, *.apig.com, *.com。 域名存储从最后一个 “.” 开始遍历。举例:


匹配:http://www.test.com,先匹配
com,匹配成功继续遍历 test,匹配成功遍历 www,无 www 匹配失败。匹配:test.apig.com, 先匹配
com,匹配成功继续遍历 apig,匹配成功遍历 test,无 test,遍历 * 号,匹配目标:*.apig.com,URL
的匹配为前序匹配跟域名的匹配模式相反,但是遍历算法一致。



总结


业界主流的开源 API 网关架构很多,但是开源软件都有一个共同的特点:量级,安全,运维分析相对匮乏, 真正要满足生产环境需求,还需要投入较高的研发成本。术业有专攻,找一个完善的 API 管理解决方案对于企业能力变现非常重要。

免责申明:


本文系转载,版权归原作者所有,如若侵权请联系我们进行删除!

《数据治理行业实践白皮书》下载地址:https://fs80.cn/4w2atu

《数栈V6.0产品白皮书》下载地址:
https://fs80.cn/cw0iw1

想了解或咨询更多有关袋鼠云大数据产品、行业解决方案、客户案例的朋友,浏览袋鼠云官网:
https://www.dtstack.com/?src=bbs

同时,欢迎对大数据开源项目有兴趣的同学加入「袋鼠云开源框架钉钉技术群」,交流最新开源技术信息,群号码:30537511,项目地址:
https://github.com/DTStack

0条评论
社区公告
  • 大数据领域最专业的产品&技术交流社区,专注于探讨与分享大数据领域有趣又火热的信息,专业又专注的数据人园地

最新活动更多
微信扫码获取数字化转型资料
钉钉扫码加入技术交流群