云原生时代,API 网关为何如此重要?

2022-10-18 09:58 浏览量:477

API 是各个不同的应用程序和系统之间互相调用和传输数据的标准方式。在很多的开发团队中都是使用 API-first 的模式,围绕着 API 来进行产品的迭代,包括测试、Mock、文档、API 网关、Dev Portal 等,这就是 API 全生命周期管理(Full Life Cycle API Management)。

 

API 解决的问题

 

在 API 出现之前,数据的传输和交换并没有标准的方式,大多数情况下是通过数据库、Excel 表格、文本,或者是 FTP,不同的系统和程序通过各种五花八门的方式来沟通。这些混乱的背后,隐藏了巨大的开发成本和安全隐患:权限控制、数据精细管控、限流限速、审计等,都只能用笨重的方式来解决。这就是计算机世界中的“巴别塔”(Tower of Babel),因此只有解决了不同语言开发的系统以及不同存储方案带来的问题,才有机会构建足够复杂的产品。

而 API 的出现,则成功地解决了巴别塔问题,开发者只需要关心其他系统对外暴露的 API 即可,无需关心底层实现和细节。

我们熟知的手机 App、网络游戏、视频直播、远程会议和 IoT 设备,都离不开终端设备与服务端的连接和数据传输,这些都是通过 API 完成的。

 

为什么需要 API 网关

 

API 网关是 API 全生命周期管理的关键基础组件,负责生产环境中 API 的配置、发布、版本回滚、安全、负载均衡等。API 网关是所有终端流量的入口,负责把终端的 API 请求路由到正确的上游服务进行处理,然后再把返回的数据返回给原始请求方,同时保证整个过程的安全、可靠和低延迟。

在最开始 API 数量不多的情况下,API 网关往往是一个由 Web Server 和上游服务两部分拼接而成的虚拟组件:由 Apache 和 NGINX 等组件完成最简单的路由转发、反向代理和和负载均衡,其他功能比如身份认证、限流限速等,则依靠上游服务自身进行实现。

但随着 API 的数量越来越多,喜欢“偷懒”的开发者们发现了一个严重的问题:他们需要在不同的上游服务中,重复实现身份认证、限流限速、日志等通用的功能,这不仅会浪费开发资源,而且一旦需要修改这部分的代码,就需要修改很多代码,这是版本管理和升级维护的噩梦。怎么办呢?聪明的开发者们很快就找到了解决方案:把这些通用的功能抽象到一个统一的组件中,把上述的两层结构改为一层结构,从上游的逻辑代码中剥离与业务无关的功能,然后增强 Apache 和 NGINX 这类组件。这就是第一代 API 网关的诞生过程。

让 API 网关承载更多非业务逻辑的功能,这就是 API 网关一直以来的进化方向。在这个过程中,前端开发者和后端开发者们,为了让产品能够更快的迭代,就对 API 网关提出了越来越多的需求,并不仅仅局限于负载均衡、反向代理、身份认证等传统功能,还在 gRPC、GraphQL、可观测性等方面提出了很多新的功能。

 

API 网关的作用

 

为了让 API 网关更灵活高效,开发者们在底层上也做了非常多创新,比如:

功能插件化。随着 API 网关上承载的功能越来越多,如何让这些功能之间更好的隔离以及让二次开发变得更加简单?插件,是完美的解决方案。因此,现在主流的 API 网关均采用插件来实现各种功能,比如在 Apache APISIX 中叫做 Plugins,在 Envoy 中则称之为 Filters,它们的含义是相同的。插件化可以让网关的开发者不再关心底层实现,用较少的开发资源就可以实现一个新的功能。

数据面和控制面的分离。在第一代 API 网关的实现中,数据面和控制面是在同一个进程中实现的,这样足够简单,但也带来了很大的安全隐患。由于数据面是直接对外提供服务的,如果被黑客入侵,就有机会获取到控制面的数据(比如 SSL 证书)和控制权,造成更大的破坏。因此,现在大部分的开源 API 网关,都是将两者分别部署的,中间通过关系型数据库或者 etcd 来进行配置的管理和同步。

以 Apache APISIX 为例,下面的架构图,诠释了以上两个创新:

 

云原生时代下的挑战

过去十年,IT 领域最大的技术变革就是云原生。诞生于 2013 年的 Docker 拉开了云原生的帷幕,从此裸金属、虚拟机开始被容器所替代,单体架构开始被微服务所替代。但是云原生并不是简单的技术革命,其背后的推动力主要来自互联网产品的快速发展和激烈竞争,云原生相关的技术生逢其时,迅速流行并替代了之前的很多技术组件和方案。

具体到 API 网关在云原生中的挑战,主要来自以下两个方面:

单体架构到微服务的转型

在微服务架构逐渐被开发者认可和落地后,该架构释放了巨大的技术红利:每个微服务可以按照自己的节奏进行升级和发布,不需要担心与其他服务的耦合。产品的迭代因此变得敏捷,每天都可以进行几十次甚至几百次的发布。

但与此同时,微服务的发展也带来了一些副作用,比如:

API 和微服务的数量从最初的几十个,增长到几千个,甚至几万个;

出现故障时如何快速定位是哪一个 API 引起的?

如何保证 API 的安全?

如何做到服务熔断和服务降级?

API 网关无法独立解决安全性、可观察性、灰度发布等问题。它需要与 Prometheus、Zipkin、Skywalking、Datadog、Okta 等众多开源项目和 SaaS 服务合作,为企业提供更好的解决方案。

动态和集群化管理

容器和 Kubernetes 的普及,让动态成为所有云原生基础组件的标准特性。在 Kubernetes 的环境中,容器在不断的生成和销毁,弹性伸缩成为一个必选项而不是可选项。

想象一个场景:一家互联网电商公司做了一次促销,大量的用户在一个小时内涌入,促销结束后就会离开。对于传统架构的公司来说,他们需要事先采购一批物理服务器,来应对这些高峰时候的 API 流量;但是对于云原生架构的公司来说,就可以随时使用公有云上的弹性资源,根据 API 请求的数量,自动的调整网络、计算、数据库等资源的规模即可。那么伴随着容器弹性伸缩而来的技术挑战如下:

上游服务不断更换 IP 地址和端口;

IP 黑白名单的频繁更新;

服务健康的及时检测和异常处理;

API 的频繁发布;

服务注册和发现的及时性;

SSL 证书的热更新和自动轮转。

想要解决上述这些挑战,均需要依赖于动态。以 NGINX 为代表的第一代 API 网关,动态能力是非常弱的。因为 NGINX 是本地静态配置文件驱动的,所以变更任何配置都需要重启 NGINX 服务才能生效,这在云原生时代是不能被企业接受的。这就是第一代 API 网关的技术痛点之一。

在中国,有一家类似微软 Office 365 的 SaaS 办公软件公司 -- WPS,他们有数百台物理机在运行着 Apache APISIX,有近万核 CPU 在处理来自客户端的 API 请求,每天处理数百亿次 API 请求。

在这个超大规模的 API 网关环境下,开发者不可能去逐个修改每一个 API 网关的配置然后 Reload,他们希望有一个统一的控制台来操作整个集群。可惜的是,第一代 API 网关诞生的年代,并没有这么大的实例规模,也就没有考虑集群管理的需求。

 

下一代 API 网关的发展

 

上述挑战和痛点,逐渐催生了新一代的 API 网关。

和第一代 API 网关不同的是,云原生时代诞生的下一代 API 网关是在开源社区的驱动下快速成长的。借助社区和众多开源贡献者的力量,这些 API 网关有机会形成一个正向的迭代和进化:

更快速的收集一线开发者及用户的需求和痛点

在开源项目中尝试解决这些问题

开源项目变得更加好用,吸引更多开发者使用

于是,我们看到下一代 API 网关突破了传统网关的负载均衡和反向代理的定位,而是承担起了 API 和流量的连接、调度、过滤、分析、协议转换、治理、集成等更多的职责。

支持更低成本的二次开发

同时,让开发者能够以更低的成本进行二次开发,也成为了下一代 API 网关的亮点。集成是 API 网关的重要功能之一,对于下游是协议解析和各种协议的转换,包括 GraphQL、gRPC、Dubbo 等;对于上游是集成 Okta、Keycloak、Datadog、Prometheus 等身份认证、可观测性服务,以及公司内部的认证、日志、审计等服务。API 网关不可能覆盖集成过程中所有的组件,这时候不可避免地需要开发者通过插件的方式进行二次开发,来满足自己的业务需求。不同的 API 网关提供了不同的二次开发的编程语言和开发方式,Apache APISIX 和 Kong 都可以使用 Lua 来编写原生插件,Envoy 是使用 C++ 编写原生插件。同时,Apache APISIX 还可以使用 Go、Python、Node、Java 和 Wasm 来编写插件,这些主流的开发语言已经可以覆盖绝大部分开发者了。

开发者不必去学习 Lua 和 C++,就可以使用自己熟悉的编程语言在下一代 API 网关上进行开发,这让基础组件的开发变得更加简单。开源和易于二次开发,是下一代的 API 网关最重要的特点,它把更多的选择权留给了开发者自身,同时,开发者也可以更加放心的在多云、混合云的环境下使用 API 网关,不用担心被云供应商锁定。

 

基于双十一的 API 网关流量处理场景

 

这里,我们用一个具体的例子来解释下现代 API 网关的作用。

在双十一时,电商都会有各种各样的商品促销活动,这段时间的 API 请求量是平时的几十倍。让我们先来看下如果没有 API 网关将会是怎样的技术架构:

可以看到,在 Order 和 Payment 服务中,身份认证和日志记录功能是重复的。一个电商的服务,一般会有数千个不同的服务组成,这时候就会有大量的代码和功能是重复开发的。

下面是增加了 API 网关之后的架构图:

从上图可以看到,我们在 API 网关层统一了公共的服务,后端服务只需要关心自身业务,为弹性伸缩提供了更多可能。

当促销开始时,客户端大量 API 请求涌入 API 网关的时候,后端服务需要进行快速的弹性伸缩,为了保障关键业务不受突发流量的影响,我们需要在 API 网关上识别恶意爬虫并实现限流限速、服务降级和熔断。此时,我们可以暂时关闭部分服务,比如商品评价、快递查询等。

但是库存信息、购买功能、支付功能等核心业务是绝对不能出现故障的,因此我们需要通过 K8s 来管理容器服务,再生成更多的服务副本来保证它的正常运行。此时 API 网关需要将客户端的 API 请求路由到新生成的副本服务,并且自动移除出现故障的服务,如下图所示。

 

总结
 

 

API 网关并不是一个新的基础中间件,而是在产品快速迭代和技术架构的变迁中,变得越来越重要。而下一代云原生 API 网关的出现则解决了企业用户在集群管理,动态,生态,可观测性以及安全性等方面的痛点。

API 网关不仅可以处理 API 的流量,也可以来处理 Kubernetes Ingress 和服务网格的流量,进一步降低开发者的学习成本,帮助企业更好的统一管理流量。

来源:CSDN

作者 | 温铭,Apache APISIX PMC主席 

上一篇:大数据背景下政务数据共享交换平台主要问题的探讨

下一篇:5 种主流API网关技术选型

分享到-微信
X

为什么选择龙石数据?