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

2019 年 10 月 21 日

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

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


API 是什么


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


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


01 API 开放数量不断增加


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



API 发展趋势


02 API 服务平台多样化


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



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


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


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), 为此我们选择了 Nginx+openresty,主要考虑如下:


1.支持热重启


数据面的组件升级是一个高风险动作, 一旦出现异常就可能导致连接中断,系统异常, 除非你的前端 LB(负载均衡)能具备快速排水的能力,当然即使如此,还是可能导致正在处理的请求被强制中断。所以数据面的热重启非常关键。


2.支持订阅式动态路由


API 路由变化相对频繁,及时性也要求比较高, 如果采用定期同步方案, 一次性同步几万条的数据会拖慢你的系统, 因此增加一个订阅式的路由服务中心非常关键, Openresty 自研可以快速订阅 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 按照 Nginx 集群节点计算 Hash 值,确保每个 API 都能负载到其中一个集群节点上。 假设有 A, B,C 三台 Nginx, 如果某个 API 计算的一致性 hash 值为 A 节点, 当请求发送到 A 节点时直接从这台节点转发,并记录一个流控值, 当请求发送到 B/C 节点的时候都会转发到 A 节点计算一个流控值再往后转发。 这样同一个 API 的流控请求就会全部记录到一台 Nginx 上。可以借助 Nginx 的单机流控能力。单机流控的算法也是插件化的,可以采用计数,漏桶等。


当然本地流控也会带来一定问题,当所有的 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 的上线,发布,管理到最后售卖的流程不再复杂,快速完成企业能力变现。



本文转载自公众号中间件小哥(ID:huawei_kevin)。


原文链接:


https://mp.weixin.qq.com/s/TOcnwX3ByMVpRBI5Yn97iQ


2019 年 10 月 21 日 11:56487

评论

发布
暂无评论
发现更多内容

第八周作业

熊桂平

极客大学架构师训练营

架构师训练营 2 期 - 第四周总结

Geek_no_one

极客大学架构师训练营

架构师训练营第 1 期 -Week8 - 课后练习

鲁小鲁

极客大学架构师训练营

【架构师训练营第 1 期 08 周】 学习总结

Bear在挨踢

极客大学架构师训练营

第四周--学习总结

Mr_No爱学习

架构师训练营第八周总结

月殇

极客大学架构师训练营

已经 2020 年了,真的要继续 RoR 么?

escray

面经 面试经历 101次面试

第八周作业

橘子皮嚼着不脆

第八周总结

Geek_ac4080

Week4 作业

evildracula

学习 架构

架构师训练营第八周作业

Shunyi

极客大学架构师训练营

数据库SQL:视图

大规模数据处理学习者

极客时间架构 1 期:第8周 性能优化(二) - 学习总结

Null

架构师训练营第 1 期 -Week8 - 性能优化二学习总结

鲁小鲁

极客大学架构师训练营

week08学习总结

追风

架构师一期

第一次电话面试

escray

面经 面试经历 101次面试

手把手教你在Idea中使用Git

jiangling500

git GitHub IDEA

[架构师训练营第 1 期] 第八周学习总结

猫切切切切切

极客大学架构师训练营

架构师训练营第 8 周课后练习

叶纪想

Week 8 作业02

Croesus

架构第八周总结

Geek_Gu

极客大学架构师训练营

第八周作业

TheSRE

极客大学架构师训练营

架构师训练营第 1 期 - 第 8 周 - 命题作业

wgl

极客大学架构师训练营

系统架构 - 学习总结笔记

Xuenqlve

判断两个单向链表是否合并

Jacky.Chen

架构师训练营第八周命题作业

一马行千里

极客大学架构师训练营 命题作业

架构师1期week08作业

FG佳

架构师一期

架构师训练营第 1 期 week8 总结

张建亮

极客大学架构师训练营

第四周作业

孤星

Week4 系统架构

evildracula

学习 架构

极客时间架构 1 期:第8周 性能优化(二) - 命题作业

Null

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