推送与拉取 API 架构

虽然拉式架构的一些缺点可以通过分布式处理系统来缓解，但即使这样，也很快就会变成一种非常昂贵、资源密集的选择

是的，如果 100 万个客户端开始轮询每 100 个 msc 以获取更新。

如果有新的更新，这意味着什么？没有数据？还是 broker=producer 宕机了？

轮询更新的整个过程通常需要数百毫秒

过去几年，互联网用户数量激增，处理如此巨大的流量对应用程序开发人员来说是一个巨大的挑战。选择合适的服务器和客户端通信架构，对于确保流量保持在可控水平至关重要。

在本文中，您将了解网络通信的推送和拉取架构，以及推送架构如何限制应用程序服务器上的负载，从而提高性能。

网络通信架构

网络通信主要有两种方法——推送和拉取。

• 拉取：通常称为轮询，在互联网上尤为常见。客户端（例如：用户、Web 浏览器或应用程序等）请求信息，服务器响应所请求的信息。这就像查看昨天足球比赛的比分：信息是静态的，无需频繁更新（或任何更新）。客户端请求信息，服务器提供信息，然后交换就结束了。

• 推送：这是一种架构，数据一旦可用就会立即通过连接向上游推送。一种基于推送的传输方式称为WebSocket，它是一种持久的双向连接，客户端和服务器都可以通过它推送数据。它是实时网络的基础之一，也是许多流行聊天和其他实时平台的基础技术。人们经常在手机上遇到推送式通信，特别优惠、通知和比分更新通常会直接发送到他们的设备上。

了解推送和拉取 API 之间的区别非常重要，这样您才能为您的服务选择正确的架构。

拉取 API 架构

如果您的客户端应用需要了解服务器端是否有任何新信息，最简单的（即使并非总是最佳的）方法就是调用并询问，这基本上就是拉取 API 的工作原理。它们是一种网络通信，客户端应用通过请求更新来发起通信。服务器接收请求、验证、处理，并将适当的响应发送回客户端。

整个轮询更新过程通常需要数百毫秒。如果请求过多，可能会降低服务器速度甚至使其过载，从而导致用户体验不佳、客户投诉甚至经济损失。因此，为了控制流量，许多公司通常使用速率限制来限制客户端请求相同信息的频率。

虽然“拉式”架构的一些缺点可以通过分布式处理系统来缓解，但即使如此，它很快就会变成一种非常昂贵且资源密集型的选择。如果您需要能够频繁地传达更新，那么“推式”架构可能是更好的选择。

推送 API 架构

推送 API 最强大的用例是，您拥有经常更改的时间敏感数据，并且客户端需要在数据更改时立即更新。

推送 API 允许服务器在有新数据可用时向客户端发送更新，而无需客户端明确请求。当服务器收到新信息时，它会将数据推送到客户端应用程序，无需客户端发出请求。这使得它成为一种更高效的数据通信标准，尤其适用于经常变化的数据。

拉取 API 与推送 API

• 在拉取 API 中，客户端请求信息。在推送 API 中，服务器在信息可用时发送信息。
• 拉式架构是请求驱动的：客户端发送请求，服务器做出相应响应。推式架构是事件驱动的：服务器在有更新可用时将数据推送给客户端。
• 在推送 API 中，服务器需要存储客户端详细信息才能直接联系客户端。而使用拉取 API 时，服务器无需存储这些详细信息，因为它们已编码在请求中。
• 推送 API 比拉取 API 速度快得多。在拉取 API 中，服务器必须接收并验证请求，然后处理信息以形成发送给客户端的响应。在推送 API 中，服务器会立即处理信息，并在信息可用时立即将其发送给客户端。

为什么要推送 API？

推送 API 广泛应用于用户群庞大、数据交换频繁或需要实时数据的应用中，以最大程度地降低服务器负载。用户无需频繁请求获取最新信息，服务器会在获取新信息后立即推送数据。推送 API 尤其适用于通过减少资源使用量来提升系统效率，从而打造更稳定、更经济的系统。

用户每天大约会收到四十五条通知。想象一下，这会给拥有数千甚至数百万用户的系统带来多大的负担。推送 API 让这种级别的流量更易于管理。

推送架构还允许您在应用系统中触发并行工作流。您只需创建一条包含适合工作流的数据的消息，然后将其推送到并行工作器进行处理或发送到队列即可。使用拉取架构也可以执行类似的工作流，但反复请求将消息放入队列可能非常耗时且难以实现。

推送 API 的用例

两种架构风格都有各自的亮点。了解这些用例将有助于您了解哪种 API 架构适合您的应用程序，以及它将如何影响您的整个系统。

提供系统更新

在这种情况下，拉取 API 可能是一个昂贵且风险很大的选择。假设您有一千名用户，他们每五分钟请求一次更新。在这种情况下，您每天需要处理大约二十万个更新请求。这会给系统带来巨大的、不必要的负担。如果您的系统不经常更新，这种情况尤其严重，因为大多数情况下，客户端会请求信息，并收到没有任何变化的“更新”信息。

推送 API 是一个很好的选择，因为它可以消除对服务器的持续更新请求。这减少了服务器负载，并为应用服务器中的其他进程腾出了空间。

具有复杂路由的系统

如果您的应用系统需要跨众多服务器进行复杂的路由，那么您选择的通信架构会对系统和实施过程产生重大影响。

采用推送架构，服务器只需将消息和客户端详细信息一起推送到队列即可，这使得推送架构在复杂系统中成为一种可行的选择。采用拉取架构，服务器必须通过复杂的逻辑来检查消息，并将其从另一台服务器拉取到队列中。这不仅难以实现，而且成本高昂且耗时。

还有许多其他常见用例，其中 Push API 被用作标准方法。

• 事件触发器：通过事件触发器启动新的并行工作流。
• 促销营销：向用户发送推送通知，告知他们有关折扣、销售和新优惠的信息。
• 地理位置标记：位置和其他地理数据由远程设备（例如您的手机）收集，并使用推送架构发送到服务器。
• 通知和提醒：发送到您设备的社交媒体通知、天气警报和热门新闻文章都是通过推送架构制作的。

在高级网络架构中推送 API

推送 API 是高级网络架构的常见功能，包括以下内容。

事件驱动

事件驱动架构在基于微服务的系统中很常见。它利用事件来触发不同服务之间的通信和操作。

生产者、代理和消费者是此设计的三个关键组成部分。发布者发布事件，代理过滤该事件并将其推送至消费者微服务。此架构使用推送 API 将事件从发布者推送至代理，再从代理推送至消费者，从而触发相应的服务。

发布/订阅

对于异步消息传递，发布/订阅架构非常流行。发布/订阅架构是一种特定类型的事件驱动架构，比其他消息传递架构更具可扩展性。

发布者将信息发布给代理，客户端根据其订阅从代理接收信息。发布者使用推送 API 将信息发送给代理，代理再将信息发送给其订阅者。

WebSockets

WebSockets在服务器和客户端之间建立类似套接字的长连接，使它们能够随时交换数据。无需请求或响应；消息只是从一端推送到另一端，而推送 API 是 WebSockets 架构的核心。

结论

系统架构很少是单纯的推式或拉式，而是两者的结合。所有应用服务都有不同的用例，您必须根据预期的用例选择合适的架构，以最大限度地发挥系统的潜力。

感谢阅读。开始编码吧。