系统设计 - 我们如何通俗的理解那些技术的运行原理 - 第一部分：通信协议（1）

本心、输入输出、结果

系统设计 - 我们如何通俗的理解那些技术的运行原理 - 第一部分：通信协议（1）

---

编辑：简简单单 Online zuozuo
地址：https://blog.csdn.net/qq_15071263

前言

我们使用视觉效果和简单术语来解释复杂的系统是如何运转的，帮助我们理解技术细节

我们使用视觉效果和简单术语来解释复杂的系统是如何运转的，帮助我们理解技术细节

通信协议

软件体系结构风格定义应用程序编程接口 （API） 的不同组件如何相互交互。因此，它们通过提供设计和构建 API 的标准方法来确保效率、可靠性和与其他系统的轻松集成。

以下是常见的形式

REST API vs. GraphQL 对比

下图显示了 REST 和 GraphQL 之间的比较

GraphQL

GraphQL 是由 Meta 开发的 API 查询语言。它提供了 API 中数据的完整描述，并让客户能够准确询问他们需要什么。

GraphQL 服务器位于客户端和后端服务之间。 GraphQL 可以将多个 REST 请求聚合到一个查询中。GraphQL 服务器在图形中组织资源。

GraphQL 支持查询、突变（将数据修改应用于资源）和订阅（接收有关模式修改的通知）

gRPC 运行原理

gRPC 运行原理

步骤说明

RPC（远程过程调用）之所以称为“远程”，是因为当服务部署到微服务体系结构下的不同服务器时，它支持远程服务之间的通信。从用户的角度来看，它的作用类似于本地函数调用。

下图说明了 gRPC 的整体数据流。

第 1 步：从客户端进行 REST 调用。请求正文通常采用 JSON 格式。

步骤 2 - 4：订单服务（gRPC 客户端）接收 REST 调用，对其进行转换，并对付款服务进行 RPC 调用。gPRC 将客户端存根编码为二进制格式，并将其发送到低级传输层。

第 5 步：gRPC 通过 HTTP2 通过网络发送数据包。由于二进制编码和网络优化，据说 gRPC 比 JSON 快 5 倍。

步骤 6 - 8：支付服务（gRPC 服务器）从网络接收数据包，对其进行解码，然后调用服务器应用程序。

步骤 9 - 11：结果从服务器应用程序返回，并被编码并发送到传输层。

步骤 12 - 14：订单服务接收数据包，对其进行解码，并将结果发送到客户端应用程序

什么是 WebHook （网络钩子）

我们先看看轮询和 WebHook 的对比

假设我们运行一个电子商务网站。客户端通过 API 网关将订单发送到订单服务，该网关转到支付服务进行支付交易。然后，支付服务与外部支付服务提供商 （PSP） 交谈以完成交易。

有两种方法可以处理与外部PSP的通信。

1、短轮询

向PSP发送付款请求后，付款服务会不断向PSP询问付款状态。经过几轮比赛，PSP终于以状态回归。

短轮询有两个缺点：

• 状态的持续轮询需要支付服务的资源。
• 外部服务直接与支付服务通信，从而产生安全漏洞。

2、网络钩子

我们可以向外部服务注册一个网络钩子。这意味着：当您对请求有更新时，请通过某个 URL 给我回电。当PSP完成处理后，它将调用HTTP请求来更新付款状态。

通过这种方式，编程范式发生了变化，支付服务不再需要浪费资源来轮询支付状态。

如果PSP从不回电怎么办？我们可以设置一个家政工作，每小时检查一次付款状态。

Webhook 通常被称为反向 API 或推送 API，因为服务器向客户端发送 HTTP 请求。使用网络钩子时，我们需要注意 3 件事：

• 我们需要为外部服务设计一个合适的 API。
• 出于安全原因，我们需要在 API 网关中设置适当的规则。
• 我们需要在外部服务中注册正确的 URL。

如何提升 API 性能

我们可以参考如图所示的 5 个技巧

分页

当结果的大小很大时，这是常见的优化。结果将流式传输回客户端，以提高服务响应能力。

异步日志记录

同步日志记录处理每个调用的磁盘，并可能降低系统速度。异步日志记录首先将日志发送到无锁缓冲区，然后立即返回。日志将定期刷新到磁盘。这大大降低了 I/O 开销。

缓存

我们可以将经常访问的数据缓存到缓存中。客户端可以先查询缓存，而不是直接访问数据库。如果缓存未命中，客户端可以从数据库进行查询。像 Redis 这样的缓存将数据存储在内存中，因此数据访问比数据库快得多。

有效负载压缩

请求和响应可以使用gzip等进行压缩，以便传输的数据大小要小得多。这样可以加快上传和下载速度。

连接池

在访问资源时，我们经常需要从数据库中加载数据。打开关闭的数据库连接会增加大量开销。因此，我们应该通过开放连接池连接到数据库。连接池负责管理连接生命周期。

HTTP 1.0 -> HTTP 1.1 -> HTTP 2.0 -> HTTP 3.0 （QUIC）

让我们了解一下每一代的 HTTP 都做了什么事情

• HTTP 1.0于1996年完成并完整记录。对同一服务器的每个请求都需要单独的 TCP 连接。
• HTTP 1.1 发布于 1997 年。TCP 连接可以保持打开状态以供重用（持久连接），但它不能解决 HOL（行头）阻塞问题。
• HOL 阻塞 - 当浏览器中允许的并行请求数用完时，后续请求需要等待前一个请求完成。
• HTTP 2.0 于 2015 年发布。它通过请求多路复用解决了 HOL 问题，从而消除了应用层的 HOL 阻塞，但 HOL 仍然存在于传输 （TCP） 层。
• 正如你在图中所看到的，HTTP 2.0引入了HTTP“流”的概念：一种抽象，允许将不同的HTTP交换多路复用到同一个TCP连接上。每个流不需要按顺序发送。
• HTTP 3.0 初稿于 2020 年发布。它是HTTP 2.0的后继者。它使用 QUIC 而不是 TCP 作为底层传输协议，从而消除了传输层中的 HOL 阻塞

QUIC基于UDP。它将流作为一等公民引入传输层。QUIC 流共享相同的 QUIC 连接，因此不需要额外的握手和缓慢启动来创建新流，但 QUIC 流是独立交付的，因此在大多数情况下，影响一个流的数据包丢失不会影响其他流

弘扬爱国精神