当今用户对实时信息的需求日益强烈,股价、列车时刻等数据都需要在发生的第一时间送达。如何实时推送这些关键信息,是每家企业面临的共同挑战。传统做法是让应用定期轮询后端服务器来获取最新数据,但这种方式资源消耗大,效率低下。
更合理的设计是让 API 支持事件流推送,而非让客户端反复轮询。事件驱动 API,即异步 API,正是为此而生——在事件发生的瞬间,将关键信息主动推送给客户端应用。
什么是异步 API,它与 REST API 有何不同?
传统的请求/响应式 API(如 REST 和 SOAP)遵循一问一答的模式,而异步 API 可以对单次请求持续返回多个响应,并支持单向或双向通信。常见的异步 API 协议包括 WebSocket、WebHook、MQTT 和 Server-Sent Events(SSE)。这些协议通常在连接建立阶段使用 HTTP,后续消息则通过专用通道传输,标准的 HTTP 动词(GET、POST、PUT 等)在这些通道中并不适用。
异步 API 与 REST API 的另一个显著区别在于引入了事件骨干技术——即 Kafka、RabbitMQ 等消息中间件——以及主题(topic)机制。后端服务作为事件发布者,将事件发布到特定主题;客户端应用作为订阅者,订阅相应主题并接收事件,在收到事件后完成业务处理并呈现给用户。
安全控制、限流、流量整形、计费和数据分析,是企业将核心业务能力以 API 形式对外开放时必须重点考虑的方面。要解决这些问题,需要选择合适的 API 管理方案。然而,由于异步 API 与 REST API 在设计理念上存在根本差异,将传统管理系统直接用于异步 API 会带来一系列问题:现有安全机制不兼容、限流策略难以套用、分析数据难以采集。因此,必须选用真正支持事件驱动架构的 API 管理方案来应对这些挑战。
事件驱动 API 的安全控制
API 安全分为两个层面:认证和授权。认证解决的是”谁可以访问哪些资源”,授权解决的是”已认证的用户能否执行特定操作”。在传统 REST API 中,可以通过用户凭据、访问令牌、证书等方式完成认证,也可以通过 scope 对资源进行细粒度保护,并对每次调用做安全校验。
但在异步 API 中,通信是围绕主题和订阅展开的,数据经由专用消息通道传输,安全控制的实施难度大得多。一种可行的方案是在初始 HTTP 握手阶段完成认证——例如在建立 WebSocket 连接之前,对握手请求进行安全校验。授权层面,则可以限定客户端是否具备发布事件的权限。
限流、流量整形与计费
对外开放 API 的业务,最终目标往往是实现商业变现,核心需求是控制 API 的使用量(限制访问、控制带宽等)。传统 API 管理系统通过基于请求数量的策略(每秒/每分钟请求数、带宽等)对 REST/SOAP API 实施限流和计费,当客户端超出配额时予以封禁。
同时,限流策略也用于保护后端服务不被请求洪峰压垮。但在异步 API 场景中,数据由服务端主动推送,客户端是订阅方,传统限流策略无法直接适用,需要从服务端推送的角度重新定义策略。以下是几种适用于异步 API 的限流方式:
基于时间的限流:客户端订阅主题的时长有上限,超时后断开连接。
基于事件数量的限流:客户端最多只能接收 x 条事件,也可与时间限制组合使用,例如”每天最多接收 10000 条事件”。
基于背压的限流:当客户端处理速度跟不上事件推送速度时,网关需要将消息排队等待客户端就绪,这会给网关带来额外压力。在这种情况下,可以将该客户端从网关摘除,以保障网关的整体稳定性。
数据分析
数据分析对于任何以 API 为核心的业务都至关重要,它能提供 API 消费者数量、最热门资源、响应延迟、趋势分析等信息,支撑业务决策,是 API 管理产品不可或缺的能力。
在传统 REST/SOAP API 中,API 网关可以从请求和响应头中提取调用资源、后端延迟、地理位置等信息。但在异步 API 中,没有常规意义上的 HTTP 请求和响应,数据流通过独立通道传输(服务端到客户端,或客户端到服务端),分析数据的采集难度大幅提升。网关需要针对每个订阅者单独采集以下指标:
- 消息推送数量
- TPS 随时间的变化趋势
- 发布错误次数
- 后端(端点)健康状态
结语
事件驱动 API 已成为满足用户实时需求、提升使用体验的关键手段。由于异步 API 与 REST API 存在诸多根本性差异,直接套用标准 API 管理方案往往行不通。真正适合的管理方案,应当将传统 API 管理能力与事件驱动架构有机结合,从而切实扩大业务覆盖范围,提升 API 的采用价值。
原创文章,作者:余初云,如若转载,请注明出处:https://blog.jidcy.com/jsjc/2382.html
