api到底代表着什么,api到底怎么用

2022-08-08 18:51:58 基金专题

　　为了提高系统的性能和可靠性，将应用服务拆分为微服务。API网关作为系统入口，逐渐成为标准。　　

　　今天，我们来看看API gateway的设计思路。我们需要承载哪些功能？以及如何选择一个流行的API网关？　　

　　什么是API网关？　　

　　既然我的使用需要API网关，那我们先来了解一下什么是API网关。　　

　　什么是 API 网关 　　

　　网关一词最早出现在网络设备中，比如两个独立的局域网通过路由器进行通信，中间的路由称为网关。　　

　　任何一个应用系统，如果需要被其他系统调用，就需要暴露API，将功能点一一表示出来。　　

　　如果两个系统中间通信，在系统之间加上一个中介者协助 API 的调用，这个中介者就是 API 网关。 　　

　　用于对接两个系统的API网关　　

　　当然，API 网关可以放在两个系统之间，同时也可以放在客户端与服务端之间。 　　

　　连接客户端和服务器的API网关　　

　　知道了API网关的基本定义，再来看看为什么要用它。　　

　　为何要使用 API 网关 　　

　　网关作为系统的唯一入口，意味着所有进入系统的请求都需要经过API网关。　　

　　当系统外的应用程序或客户端访问系统时，会遇到这样的情况：　　

　　如果传输协议不一致，系统需要转换协议。如果调用水平扩展的服务，它需要进行负载平衡。一旦请求流量超出系统所能承受的范围，就需要进行限流。对于每个请求和回复，系统将记录响应日志。也就是说，任何涉及到对系统的请求，可以从服务中提取出来的功能，都可以在网关上实现。　　

　　比如：协议转换、负载均衡、请求路由、流量控制等等。这些功能我们后面会一一介绍给你。　　

　　了解了API gateway的基本功能之后，再来看看它可以服务于哪些系统或者客户端。　　

　　API 网关服务定位 　　

　　网关具有处理请求的能力，从定位的角度可以分为五类：　　

　　面向 WebApp，的这部分系统主要基于网站和H5应用。通过前后端分离的设计，将大部分业务功能放在后端，前台Web App只显示页面内容。　　

　　MobileApp，的移动指的是iOS和Android，设计思路和WebApp基本相同。　　

　　区别在于API gateway需要做一些移动设备管理(MDM)。例如：设备注册、激活、使用、淘汰等。全生命周期管理。　　

　　由于移动设备的特殊性，我们在考虑移动设备请求时，需要考虑请求、设备和用户之间的关系。　　

　　通常，面向合作伙伴的 OpenAPI，系统会向合作伙伴提供接口。这些接口将全部开放或部分开发，有条件限制(时间、流量)的合作伙伴可以访问。因此，需要更加重视API网关的流量和安全性以及协议转换的管理。　　

　　企业内部可扩展 API，可以供企业内部其他部门或项目使用，也可以作为中台输出的一部分来支持其他系统。在这里，应该更多地考虑功能边界的划分、认证和授权。　　

　　面向 IOT 设备，将接收来自IOT设备的请求，尤其是工业传感器和其他设备。这里需要考虑协议转换和数据过滤。　　

　　API 网关架构 　　

　　既然谈了 API 网关的功能和定位，接下来说说它的架构： 　　

　　API系统架构图　　

　　API分为三个系统：　　

　　网关-Gateway-Core（核心）Gateway-Admin（管理）,的核心网关负责接收客户端请求、调度、加载和执行组件、将请求路由到上游服务器，以及处理返回的结果。　　

　　大部分功能都在这一层完成，如验证、认证、负载均衡、协议转换、服务路由和数据缓存等。如果没有其他两个子系统，也可以独立运行。　　

　　Gateway-Admin网关管理接口，可以执行API、组　　

件等系统基础信息的配置；例如：限流的策略，缓存配置，告警设置。

Gateway-Monitor 监控日志、生成各种运维管理报表、自动告警等；管理和监控系统主要是为核心系统服务的，起到支撑的作用。

API 网关技术原理

上面谈到了网关的架构思路，这里谈几点技术原理。平时我们在使用网关的时候，多注重其实现的功能。例如：路由，负载均衡，限流，缓存，日志，发布等等。

实际上这些功能的背后有一些原理我们可以了解，这样在应用功能的时候会更加笃定。下面是几个原理分享给大家。

协议转换

每个系统内部服务之间的调用，可以统一使用一种协议，例如：HTTP，GRPC。

假设每个系统使用的协议不同，那么系统之间的调用或者数据传输，就存在协议转换的问题了。如果解决这个问题呢？API 网关通过泛化调用的方式实现协议之间的转化。

实际上就是将不同的协议转换成“通用协议”，然后再将通用协议转化成本地系统能够识别的协议。

这一转化工作通常在 API 网关完成。通用协议用得比较多的有 JSON，当然也有使用 XML 或者自定义 JSON 文件的。

不同的协议需要转化成共同语言进行传输

链式处理

设计模式中有一种责任链模式，它将“处理请求”和“处理步骤”分开。每个处理步骤，只关心这个步骤上需要做的处理操作，处理步骤存在先后顺序。

消息从第一个“处理步骤”流入，从最后一个“处理步骤”流出，每个步骤对经过的消息进行处理，整个过程形成了一个链条。在 API 网关中也用到了类似的模式。

Zuul 网关过滤器链式处理

下面以 Zuul 为例，当消息出入网关需要经历一系列的过滤器。这些过滤器之间是有先后顺序的，并且在每个过滤器需要进行的工作也是各不一样：

PRE：前置过滤器，用来处理通用事务，比如鉴权，限流，熔断降级，缓存。并且可以通过 Custom 过滤器进行扩展。ROUTING：路由过滤器，在这种过滤器中把用户请求发送给 Origin Server。它主要负责：协议转化和路由的工作。POST：后置过滤器，从 Origin Server 返回的响应信息会经过它，再返回给调用者。在返回的 Response 上加入 Response Header，同时可以做 Response 的统计和日志记录。ERROR：错误过滤器，当上面三个过滤器发生异常时，错误信息会进到这里，并对错误进行处理。异步请求

所有的请求通过 API 网关访问应用服务，一旦吞吐量上去了，如何高效地处理这些请求？

拿 Zuul 为例，Zuul1 采用：一个线程处理一个请求的方式。线程负责接受请求，然后调用应用返回结果。

如果把网络请求看成一次 IO 操作的话，处理请求的线程，从接受请求，到服务返回响应，都是阻塞状态。

同时，如果多个线程都处在这种状态，会导致系统缓慢。因为每个网关能够开启的线程数量是有限的，特别是在访问的高峰期。

每个线程处理一个请求

为了解决这个问题，Zuul2 启动了异步请求的机制。每个请求进入网关的时候，会被包装成一个事件，CPU 内核会维持一个监听器，不断轮询“请求事件”。

一旦，发现请求事件，就会调用对应的应用。获取应用返回的信息以后，按照请求的要求把数据/文件放到指定的缓冲区，同时发送一个通知事件，告诉请求端数据已经就绪，可以从这个缓冲获取数据/文件。

这个过程是异步的，请求的线程不用一直等待数据的返回。它在请求完毕以后，就直接返回了，这时它可以做其他的事情。

请求数据被 CPU 内核获取，并且发送到指定的数据缓冲区时，请求的线程会接到“数据返回”的通知，然后就直接使用数据，不用自己去做取数据的操作。

异步请求处理，CPU 处理数据以后通知请求端

实现异步处理请求有两种模式，分别是：

ReactorProactor

Reactor 工作原理流水图

Reactor：通过 handle_events 事件循环处理请求。用户线程注册事件处理器之后，可以继续执行其他的工作（异步），而 Reactor 线程负责调用内核的 Select 函数检查 Socket 状态。

当有 Socket 被激活时（获取网络数据），则通知相应的用户线程，执行 handle_event 进行数据读取、处理的工作。

Proactor 工作原理流水图

Proactor：用户线程使用 CPU 内核提供的异步 IO 发起请求，请求发起以后立即返回。CPU 内核继续执行用户请求线程代码。

此时用户线程已将 AsynchronousOperation（异步处理）和 CompletionHandler（完成获取资源）注册到内核。之后操作系统开启独立的内核线程去处理 IO 操作。

当请求的数据到达时，由内核负责读取 Socket（网络请求）中的数据，并写入用户指定的缓冲区中。

最后内核将数据和用户线程注册的 CompletionHandler 分发给内部 Proactor，Proactor 将 IO 完成的信息通知给用户线程（一般通过调用用户线程注册的完成事件处理函数），完成异步 IO。

API 网关实现功能

说起对 API 网关的使用，我们还是对具体功能更加感兴趣。让我们一起来看看它实现了哪些功能。

负载均衡

当网关后面挂接同一应用的多个副本时，每次用户的请求都会通过网关的负载均衡算法，路由到对应的服务上面。例如：随机算法，权重算法，Hash 算法等等。

如果上游服务采取微服务的架构，也可以和注册中心合作实现动态的负载均衡。

当微服务动态挂载（动态扩容）的时候，可以通过服务注册中心获取微服务的注册信息，从而实现负载均衡。

Nginx+Lua+服务注册中心实现动态负载均衡

路由选择

这个不言而喻，网关可以根据请求的 URL 地址解析，知道需要访问的服务。再通过路由表把请求路由到目标服务上去。

有时候因为网络原因，服务可能会暂时的不可用，这个时候我们希望可以再次对服务进行重试。

Zuul 作为 API 网关将请求路由到上游服务器

例如：Zuul 与 Spring Retry 合作完成路由重试。

流量控制

限流是 API 网关常用的功能之一，当上游服务超出请求承载范围，或者服务因为某种原因无法正常使用，都会导致服务处理能力下滑。

这个时候，API 网关作为“看门人”，就可以限制流入的请求，让应用服务器免受冲击。

限流实际上就是限制流入请求的数量，其算法不少，有令牌桶算法，漏桶算法，连接数限制等等。这里我们就介绍三个常用的，一般通过 Nginx+Lua 来实现。

令牌桶限流

统一鉴权

访问应用服务器的请求都需要拥有一定权限，如果说每访问一个服务都需要验证一次权限，这个对效率是很大的影响。可以把权限认证放到 API 网关来进行。

目前比较常见的做法是，用户通过登录服务获取 Token，把它存放到客户端，在每次请求的时候把这个 Token 放入请求头，一起发送给服务器。

API 网关要做的事情就是解析这个 Token，知道访问者是谁（鉴定），他能做什么/访问什么（权限）。

说白了就是看访问者能够访问哪些 URL，这里根据权限/角色定义一个访问列表。

如果要实现多个系统的 OSS（Single Sign On 单点登录），API 网关需要和 CAS（Central Authentication Service 中心鉴权服务）做连接，来确定请求者的身份和权限。

熔断降级

当应用服务出现异常，不能继续提供服务的时候，也就是说应用服务不可用了。作为 API 网关需要做出处理，把请求导入到其他服务上。

或者对服务进行降级处理，例如：用兜底的服务数据返回客户端，或者提示服务暂时不可用。

同时通过服务注册中心，监听存在问题的服务，一旦服务恢复，随即恢复路由请求到该服务。

例如：Zuul 中提供了 ZuulFallbackProvider 接口来实现熔断，它提供两个方法，一个指明熔断拦截的服务 getRoute，一个指定返回内容 ClientHttpResponse。

我们通过自定义的 Fallback 方法，并且将其指定给某个 Route 来实现该 Route 访问出问题的熔断处理。

主要继承 ZuulFallbackProvider 接口来实现，ZuulFallbackProvider 默认有两个方法，一个用来指明熔断拦截哪个服务，一个定制返回内容。

API 网关熔断降级

发布测试

在发布版本的时候会采用：金丝雀发布和蓝绿发布。作为 API 网关可以使用路由选择和流量切换来协助上述行为。这里以金丝雀发布为例，看看 API 网关如何做路由转换的。

假设将 4 个服务从 V1 更新到 V2 版本，这 4 个服务的流量请求由 1 个 API 网关管理。

那么先将一台服务与 API 网关断开，部署 V2 版本的服务，然后 API 网关再将流量导入到 V2 版本的服务上。

这里流量的导入可以是逐步进行的，一旦 V2 版本的服务趋于稳定。再如法炮制，将其他服务替换成 V2 版本。

金丝雀发布一般先发 1 台，或者一个小比例，例如 2% 的服务器，主要做流量验证用，也称为金丝雀（Canary）测试（灰度测试）

其来历是，旷工下矿洞前，先放一只金丝雀探查是否有毒气，金丝雀发布由此得名。

金丝雀测试需要完善的监控设施配合，通过监控指标反馈，观察金丝雀的健康状况，作为后续发布或回滚的依据。

如果金丝测试通过，则把剩余的 V1 版本全部升级为 V2 版本。如果金丝雀测试失败，则直接回退金丝雀，发布失败。

缓存数据

我们可以在 API 网关缓存一些修改频率不高的数据。例如：用户信息，配置信息，通过服务定期刷新这个缓存就行了：

用户请求先访问 API 网关，如果发现有缓存信息，直接返回给用户。如果没有发现缓存信息，回源到应用服务器获取信息。另外，有一个缓存更新服务，定期把应用服务器中的信息更新到网关本地缓存中日志记录

通过 API 网关上的过滤器我们可以加入日志服务，记录请求和返回信息。同时可以建立一个管理员的界面去监控这些数据。

日志服务简图

日志记录了以后，可以做很多功能扩展。我们整理了以下几点供大家参考：

报表分析：针对服务访问情况，提供可视化展示。实时查询：了解实时关键信息，例如：吞吐量，并发数。在秒杀活动的时候，会特别关注。异常告警：针对关键参数进行监控，对于统计结果支持阈值报警，对接阿里云通知中心、短信、钉钉进行告警。日志投递：将日志进行归档，存放到文件库或者数据仓库中，以便后期分析。