架构设计系列（一）：通信协议

一、概述

架构风格（Architecture Styles）定义了应用程序编程接口（API）中不同组件之间的通信与交互方式。因此，它们通过提供一种标准化的方法来设计和构建API，从而确保了效率、可靠性以及与其他系统集成的便捷性。下面 是常见的API架构设计风格：

以下是关于这些技术的简要总结和对比：

---

SOAP

• 特点：成熟、全面、基于XML。
• 优点：标准化强，安全性高，适合复杂的企业级应用。
• 适用场景：企业级应用程序（如金融、医疗等需要严格协议的场景）。

---

RESTful

• 特点：流行、易于实现、基于HTTP方法（GET、POST、PUT、DELETE等）。
• 优点：轻量级、易于理解和使用，适合资源导向的服务。
• 适用场景：Web服务、移动应用后端、公共API。

---

GraphQL

• 特点：查询语言，允许客户端请求特定数据。
• 优点：减少网络开销，提高响应速度，灵活性高。
• 适用场景：需要高效数据获取的场景（如复杂的前端应用、数据密集型服务）。

---

gRPC

• 特点：现代、高性能、使用Protocol Buffers进行数据序列化。
• 优点：传输效率高，支持双向流通信，适合分布式系统。
• 适用场景：微服务架构、需要高性能通信的场景（如实时数据处理）。

---

WebSocket

• 特点：实时、双向、持久连接。
• 优点：低延迟，支持实时数据交换。
• 适用场景：实时应用（如聊天应用、在线游戏、实时通知）。

---

Webhook

• 特点：事件驱动、基于HTTP回调、异步通信。
• 优点：轻量级，适合事件通知。
• 适用场景：系统间的事件通知（如支付回调、CI/CD流水线触发）。

---

对比总结

技术	核心特点	优点	适用场景
SOAP	成熟、XML-based	标准化、安全性高	企业级应用
RESTful	流行、HTTP方法	简单、易用	Web服务、公共API
GraphQL	查询语言、请求特定数据	高效、灵活	复杂前端应用、数据密集型服务
gRPC	高性能、Protocol Buffers	高效、支持双向流	微服务、实时数据处理
WebSocket	实时、双向、持久连接	低延迟、实时通信	聊天、在线游戏、实时通知
Webhook	事件驱动、HTTP回调	轻量级、异步	事件通知、系统集成

二、技术选型

REST API vs. GraphQL

当我们开始做API设计的时候，对于 REST 还是GraphQL风格，各有各的优缺点，下图为你展示两种风格原理：

REST （Representational State Transfer）

• REST 使用标准的 HTTP 方法（如 GET、POST、PUT、DELETE）来实现 CRUD 操作。
• 当您需要在微服务或应用程序之间提供简单、统一的接口时，REST 更佳适合。REST 的设计哲学强调统一的接口和资源导向，使得不同系统之间的交互更加简单和一致。
• REST 基于 HTTP 协议，可以充分利用 HTTP 的缓存机制（如 ETag、Cache-Control）来提高性能。
• 但在复杂场景中，可能需要多次往返请求才能从不同的端点组装相关数据。

GraphQL

• GraphQL 提供了一个单一的端点，客户端可以通过该端点查询其所需的精确数据。

• 客户端可以在嵌套查询中指定所需的字段，服务器会返回仅包含这些字段的优化负载。

• GraphQL 支持 Mutations 用于修改数据，以及 Subscriptions 用于实时通知。

• GraphQL 非常适合从多个来源聚合数据，并且能够很好地适应快速变化的前端需求。

• 缺点：

  • GraphQL 将复杂性转移到了客户端，并且如果没有适当的保护措施，可能会导致滥用查询。
  • 由于 GraphQL 使用单一端点且查询结构灵活，传统的 HTTP 缓存机制可能不适用，需要更复杂的缓存方案（如基于查询的缓存）。

对于选择REST 还是 GraphQL 这取决于具体的业务场景及开发团队使用的技术栈和经验。GraphQL 非常适合复杂或频繁变化的前端需求，而 REST 更适合需要简单且一致接口的应用程序。但这两种 API 方法都不是万能的，仔细评估需求和权衡利弊是选择正确风格的关键。无论是 REST 还是 GraphQL，都是暴露数据和支持现代应用程序的有效选择。

gRPC 的工作原理

RPC（远程过程调用）被称为“远程”，是因为它支持在微服务架构中部署在不同服务器上的远程服务之间的通信。从用户的角度来看，它的行为类似于本地函数调用。

流程描述
步骤 1：客户端发起 REST 调用，请求体通常为 JSON 格式。
步骤 2-4：订单服务（gRPC 客户端）接收 REST 调用，将其转换并发起 RPC 调用至支付服务。gRPC 将客户端存根编码为二进制格式，并发送至底层传输层。
步骤 5：gRPC 通过 HTTP/2 将数据包发送到网络。由于二进制编码和网络优化，gRPC 的速度比 JSON 快 5 倍。
步骤 6-8：支付服务（gRPC 服务器）从网络接收数据包，解码并调用服务器端应用程序。
步骤 9-11：服务器端应用程序返回结果，结果被编码并发送至传输层。
步骤 12-14：订单服务接收数据包，解码并将结果返回给客户端应用程序。

什么是webhook

polling and Webhook 对比

假设我们运营一个电子商务网站。客户端通过 API 网关将订单发送至订单服务，订单服务再将请求转发至支付服务以处理支付交易。支付服务随后与外部支付服务提供商（PSP）通信，完成交易。
与外部支付服务提供商（PSP）通信有两种方式：

• 短轮询（Short Polling）
  支付服务向 PSP 发送支付请求后，不断向 PSP 询问支付状态。经过多次轮询后，PSP 最终返回状态。
  短轮询有两个缺点：
  • 不断轮询状态会消耗支付服务的资源。
  • 外部服务直接与支付服务通信，可能产生安全漏洞。
• Webhook（Web 钩子）
  我们可以向外部服务注册一个 Webhook，这意味着：当请求有更新时，请通过某个 URL 回调我。当 PSP 完成处理时，它将调用 HTTP 请求来更新支付状态。
  这种方式改变了编程范式，支付服务不再需要浪费资源来轮询支付状态。如果 PSP 从未回调怎么办？我们可以设置一个定时任务，每小时检查一次支付状态。Webhook 通常被称为反向 API 或推送 API，因为服务器会向客户端发送 HTTP 请求。使用 Webhook 时需要注意以下三点：
  • 需要为外部服务设计一个合适的 API。
  • 需要在 API 网关上设置适当的规则以确保安全。
  • 需要在外部服务上注册正确的 URL。

如何提升API性能？

下图展示了提升API性能的五种常见技巧。

• 分页（Pagination）
  当返回结果集较大时，分页是一种常见的优化手段。通过将结果分批次流式传输回客户端，可以显著提升服务的响应速度。这种方式不仅减少了单次请求的数据量，还降低了网络传输和服务器的内存压力，从而提高了系统的整体性能和用户体验。
• 异步日志（Asynchronous Logging）
  同步日志会在每次调用时直接操作磁盘，这可能导致系统性能下降。异步日志机制则将日志先写入一个无锁缓冲区，并立即返回，而日志会定期批量刷新到磁盘。这种设计显著减少了I/O开销，避免了磁盘操作成为性能瓶颈，同时保证了日志的可靠性和系统的响应速度。
• 缓存（Caching）
  将频繁访问的数据存储在缓存中（如Redis），客户端可以优先查询缓存，而不是直接访问数据库。如果缓存未命中（Cache Miss），客户端再从数据库获取数据。由于缓存通常将数据存储在内存中，其访问速度远快于基于磁盘的数据库。缓存机制能够有效降低数据库负载，提升系统的整体吞吐量和响应速度。
• 负载压缩（Payload Compression）
  通过使用gzip等压缩算法对请求和响应数据进行压缩，可以显著减少传输的数据量。这种方式加快了数据的上传和下载速度，尤其适用于带宽有限或网络延迟较高的场景。压缩技术在高并发或大数据传输的场景中尤为重要，能够有效降低网络开销并提升用户体验。
• 连接池（Connection Pool）
  在访问数据库等资源时，频繁地打开和关闭连接会带来较大的性能开销。连接池通过维护一组预先打开的数据库连接来管理连接的生命周期，避免了重复创建和销毁连接的开销。连接池负责分配、复用和释放连接，从而显著提高了数据库操作的效率，并降低了系统的资源消耗。

HTTP协议的演进

HTTP 1.0 -> HTTP 1.1 -> HTTP 2.0 -> HTTP 3.0 (QUIC)
HTTP协议的每一代都旨在解决特定的问题并引入新的功能，以下是各代HTTP的主要特点及其解决的问题：

• HTTP/1.0（1996年）
  每个请求都需要建立和关闭一个新的TCP连接，导致高延迟和资源浪费。频繁的连接建立和关闭增加了服务器和客户端的负担，限制了系统的吞吐量。
• HTTP/1.1（1997年）
  允许多个请求复用同一个TCP连接，减少连接建立的开销。虽然支持持久连接和管道化，但响应必须按顺序返回，导致队头阻塞Head-of-Line Blocking, HOL）。
  HTTP/1.1通过持久连接显著提升了性能，但队头阻塞和并行请求限制仍然是瓶颈。
• HTTP/2.0（2015年）
  HTTP/2.0通过多路复用和二进制协议显著提升了性能，但依然依赖TCP，存在传输层的队头阻塞问题。
  适用于高并发、低延迟的现代Web应用，但需要客户端和服务器的广泛支持。
• HTTP/3.0（2020年草案）
  • HTTP/3.0通过QUIC协议彻底解决了TCP的瓶颈问题，提供了更快的连接建立、更低的延迟和更好的移动网络支持。
  • 适用于对延迟和可靠性要求极高的场景（如实时通信、在线游戏等），但需要客户端和服务器的广泛支持。

QUIC通过基于UDP的设计、流的多路复用、独立的数据包传输和内置加密等特性，解决了TCP的诸多局限性，为现代网络应用提供了以下优势：

• 更低的延迟：快速连接建立和0-RTT恢复机制显著减少了初始延迟。
• 更高的吞吐量：多路复用和独立的流传输避免了队头阻塞，最大化带宽利用率
• 更强的可靠性：数据包丢失的独立性和基于流的重传机制提高了系统的容错能力。
• 更好的移动网络支持：连接迁移功能使得QUIC在移动设备切换网络时无需重新建立连接。

QUIC的这些特性使其成为HTTP/3的底层协议，并为实时通信、在线游戏、视频流媒体等对延迟和可靠性要求极高的应用场景提供了理想的解决方案。作为架构师，在设计高性能、高可靠的分布式系统时，QUIC是一个值得深入研究和采用的技术选择。

每一代HTTP的演进都是为了解决前一代的局限性，同时适应不断变化的网络环境和应用需求。在选择HTTP版本时，需要根据具体的业务场景、性能需求和客户端兼容性进行权衡。

SOAP vs REST vs GraphQL vs RPC

下图是API架构风格的时间线及其特点的对比及详细解析，
随着时间的推移，不同的 API 架构风格相继问世。它们各自都有标准化数据交换的模式。

先编码还是先定义接口规范

• 在微服务架构下，通常会根据职责或者业务域去拆分系统，种架构有助于解耦和职责分离，同时也增加系统的复杂度，我们需要处理服务之间的各种通信。在编写代码之前，最好先仔细思考系统的复杂性，并明确界定服务的边界。
• 在微服务架构中，不同的功能团队负责各自的组件和服务，这可能导致沟通障碍和技术栈不一致的问题。通过统一的API设计，可以为整个组织建立一种“通用语言”，从而提升协作效率、降低集成成本，并确保系统的一致性和可维护性。
• 在API开发过程中，Mock请求和响应是一种非常有效的方法，可以在编写实际代码之前验证API设计的合理性和可用性。这种方法不仅能够提前发现设计问题，还能促进团队协作和快速迭代。
• 通过Mock请求和响应验证API设计，可以在项目初期减少不确定性，从而显著提高软件质量和开发效率。

通过API优先开发和TDD的结合，可以显著提高软件质量、开发效率和团队满意度。合理的API优先开发和TDD实践，不仅可以加速项目的开发和测试，还能为团队协作和系统集成奠定坚实的基础，从而更好地支持业务的快速迭代和扩展。

HTTP 状态码

HTTP状态码是服务器对客户端请求的响应结果的三位数字代码，用于表示请求的处理状态。状态码分为五类，每类有不同的含义和用途。以下是详细的分类与解析：

1. 信息响应（Informational，100-199）
这类状态码表示请求已被接收，服务器正在处理。

常见状态码：

• 100 Continue：客户端应继续发送请求的剩余部分。通常用于POST请求中，客户端先发送请求头，服务器确认后再发送请求体。
• 101 Switching Protocols：服务器同意客户端请求，切换协议（如从HTTP切换到WebSocket）。
• 102 Processing：服务器已收到请求，但处理尚未完成，通常用于长时间运行的请求。
  使用场景：
• 用于指示客户端继续操作或协议切换。

---

2. 成功响应（Success，200-299）
这类状态码表示请求已成功被服务器接收、理解并处理。
常见状态码：

• 200 OK：请求成功，响应中包含请求的结果（如GET请求返回的资源）。
• 201 Created：请求成功，并且服务器创建了新的资源（通常用于POST请求）。
• 204 No Content：请求成功，但响应中没有返回内容（通常用于DELETE请求）。
• 206 Partial Content：服务器成功处理了部分GET请求（通常用于分块下载或断点续传）。

使用场景：

• 用于表示请求成功并返回相应的结果。

---

3. 重定向响应（Redirection，300-399）
这类状态码表示客户端需要进一步操作以完成请求。
常见状态码：

• 301 Moved Permanently：请求的资源已永久移动到新的URL，客户端应使用新的URL。
• 302 Found：请求的资源临时移动到新的URL，客户端应继续使用原始URL。
• 304 Not Modified：资源未修改，客户端可以使用缓存的版本（通常用于条件GET请求）。
• 307 Temporary Redirect：与302类似，但要求客户端保持请求方法不变。
  使用场景：
• 用于资源重定向或缓存控制。

---

4. 客户端错误响应（Client Error，400-499）
这类状态码表示客户端发送的请求有误，服务器无法处理。
常见状态码：

• 400 Bad Request：请求无效，服务器无法理解（如参数错误或格式错误）。
• 401 Unauthorized：请求需要身份验证，客户端未提供有效的凭据。
• 403 Forbidden：服务器拒绝请求，客户端没有访问权限。
• 404 Not Found：请求的资源不存在。
• 429 Too Many Requests：客户端发送的请求过多，超出了服务器的限制。

使用场景：

• 用于表示客户端请求的错误或权限问题。

---

5. 服务器错误响应（Server Error，500-599）
这类状态码表示服务器在处理请求时发生了错误。
常见状态码：

• 500 Internal Server Error：服务器内部错误，无法完成请求。
• 502 Bad Gateway：服务器作为网关或代理时，从上游服务器收到无效响应。
• 503 Service Unavailable：服务器暂时不可用（通常由于过载或维护）。
• 504 Gateway Timeout：服务器作为网关或代理时，未能及时从上游服务器收到响应。

使用场景：

• 用于表示服务器端的错误或不可用状态。

---

API网关的核心功能与请求处理流程

API网关是微服务架构中的关键组件，负责处理客户端请求的路由、验证、安全性和监控等任务。
以下是API网关的核心功能及其请求处理流程的详细解析：

• 步骤1：客户端发送HTTP请求到API网关
• 步骤2：API网关解析并验证HTTP请求的属性
• 步骤3：API网关执行允许列表/拒绝列表检查（黑白名单）
• 步骤4：API网关与身份提供者（Identity Provider）通信
• 步骤5：API网关应用速率限制规则
• 步骤6-7：API网关通过路径匹配找到相关服务（动态路由）
• 步骤8：API网关将请求转换为适当的协议并发送到后端微服务
• 步骤9-12：API网关处理错误并实现容错机制
  • 错误处理：捕获后端服务的错误并返回适当的HTTP状态码和错误信息。
  • 熔断器模式（Circuit Breaker）：当后端服务不可用时，快速失败并返回缓存数据或默认响应。
  • 日志与监控：使用ELK（Elasticsearch、Logstash、Kibana）堆栈记录日志和监控系统状态。
  • 缓存：在API网关中缓存常用数据，减少后端服务的负载。

如何设计高效、安全的API

下图为购物车的API设计
API设计不仅仅是URL路径的设计，它涵盖了资源命名、标识符、路径模式、HTTP头字段设计以及速率限制规则等多个方面。

• 资源命名与标识符
  • 核心原则：
    • 资源命名：使用名词而非动词命名资源，确保资源名称具有描述性和一致性。
      示例：/users（用户资源），/orders（订单资源）。
    • 标识符设计：使用唯一标识符（如UUID或自增ID）标识资源。
      示例：/users/{userId}，/orders/{orderId}。
• 路径模式设计
  • 核心原则：
    • 层级结构：使用层级路径表示资源之间的关系。 示例：/users/{userId}/orders（用户的订单）。
    • 避免过度嵌套：路径层级不宜过深，通常不超过3-4层。
      反例：/users/{userId}/orders/{orderId}/items/{itemId}/details（过度嵌套）。
• HTTP方法设计
  • 核心原则：
    • GET：用于获取资源。
      示例：GET /users/{userId}（获取用户信息）。
    • POST：用于创建资源。
      示例：POST /users（创建用户）。
    • PUT/PATCH：用于更新资源（PUT用于全量更新，PATCH用于部分更新）。
      示例：PUT /users/{userId}（更新用户信息）。
    • DELETE：用于删除资源。
      示例：DELETE /users/{userId}（删除用户）。

TCP/IP协议

数据在网络中的传输涉及多个步骤和协议，OSI（Open Systems Interconnection）模型通过分层设计将这些步骤标准化，以确保不同设备和系统之间的互操作性。

步骤 1：当设备 A 通过 HTTP 协议向设备 B 发送数据时，首先在应用层添加 HTTP 头。
步骤 2：然后在传输层添加 TCP 或 UDP 头，将数据封装为 TCP 段。头中包含源端口、目标端口和序列号。
步骤 3：接着在网络层添加 IP 头，封装为 IP 数据报。IP 头中包含源/目标 IP 地址。
步骤 4：在数据链路层添加 MAC 头，封装为帧。MAC 头中包含源/目标 MAC 地址。
步骤 5：封装后的帧被发送到物理层，以二进制比特的形式通过网络传输。
步骤 6-10：当设备 B 从网络接收到比特流时，它会执行解封装过程，这是封装过程的逆过程。头信息被逐层移除，最终设备 B 可以读取数据。
我们需要网络模型中的分层，因为每一层都专注于自己的职责。每一层可以依赖头信息进行处理，而无需知道上一层数据的含义。

“反向”代理-Nginx

正向代理是位于用户设备和互联网之间的服务器。
正向代理通常用于：

• 保护客户端。
• 绕过浏览限制。
• 阻止访问某些内容。

反向代理是接受客户端请求的服务器，它将请求转发给 Web 服务器，并将结果返回给客户端，就像代理服务器处理了请求一样。
反向代理适用于：

• 保护服务器。
• 负载均衡。
• 缓存静态内容。
• 加密和解密 SSL 通信。

常见负载均衡算法

静态算法

• 轮询（Round Robin）
  • 工作原理：
    客户端请求按顺序依次分配给每个服务实例。例如，如果有三个实例（A、B、C），第一个请求发给A，第二个发给B，第三个发给C，第四个又回到A，以此类推。
  • 适用场景：
    适合所有服务实例性能相近且负载相对均匀的场景。
  • 局限性：
    不考虑实例的当前负载或处理能力，如果实例性能差异较大，可能导致负载不均衡。
• 粘性轮询（Sticky Round Robin）
  • 工作原理：
    与轮询类似，但一旦某个客户端的第一个请求被分配到某个实例，该客户端后续的所有请求都会发送到同一个实例。
  • 适用场景：
    适用于需要会话保持的应用场景，比如电商网站需要保持用户会话。
  • 局限性：
    如果某些客户端请求量远大于其他客户端，可能导致负载不均衡。
• 加权轮询（Weighted Round Robin）
  • 工作原理：
    为每个服务实例分配一个权重，权重越高的实例处理的请求越多。例如，实例A权重为3，实例B权重为1，则A会处理3个请求，B处理1个请求，循环往复。
  • 适用场景：
    适合服务实例性能不均等的环境（例如某些服务器性能更强）。
  • 局限性：
    需要手动配置权重，在动态环境中调整权重可能比较复杂。
• 哈希算法（Hash-Based Load Balancing）
  • 工作原理：
    对请求的某个特征（如IP地址或URL）进行哈希计算，根据哈希结果将请求分配到对应的服务实例。
  • 适用场景：
    适用于需要确保同一客户端或同一资源的请求总是分配到同一实例的场景。
  • 局限性：
    如果哈希函数设计不好，可能导致负载不均衡；增加或减少实例时需要重新哈希，可能影响系统稳定性。

动态负载均衡算法

• 最少连接数（Least Connections）
  • 工作原理：
    将新请求分配给当前连接数最少的服务实例。
  • 适用场景：
    适合请求处理时间差异较大的场景，能够根据实例的当前负载动态分配请求。
  • 局限性：
    需要实时监控连接数，可能增加系统开销。
• 最短响应时间（Least Response Time）
  • 工作原理：
    将新请求分配给响应时间最短的服务实例（通常是最空闲或最高效的实例）。
  • 适用场景：
    适合对响应时间要求较高的场景，如实时系统或高性能Web服务。
  • 局限性：
    需要持续监控响应时间，可能增加系统开销。

URL, URI, URN 的区别

• URI（统一资源标识符，Uniform Resource Identifier）
  URI 是用于标识网络资源的字符串，可以是逻辑资源或物理资源。它是 URL 和 URN 的超集。URI 的通用格式如下：

  scheme:[//authority]path[?query][#fragment]
  

  • scheme：协议或方案（如 http、ftp、urn）。
  • authority：通常包括主机名和端口号（如 www.example.com:80）。
  • path：资源的路径（如 /index.html）。
  • query：查询参数（如 ?id=123&name=foo）。
  • fragment：片段标识符，通常指向资源的某一部分（如 #section1）。

  作用：URI 用于唯一标识一个资源，但不一定提供资源的位置或访问方式。

• URL（统一资源定位符，Uniform Resource Locator）
  URL 是 URI 的子集，用于定位网络上的资源。它不仅标识资源，还提供了访问资源的方式。
  特点：

  • 包含协议（如 http、https、ftp）。
  • 提供资源的具体位置（如 https://www.example.com/index.html）。
  • 可以用于访问资源（如通过浏览器打开 URL）。
    URL 的格式与 URI 相同，但通常用于定位资源。

• 示例：

  https://www.example.com:8080/path/to/resource?query=123#section
  

  • https：协议。
  • www.example.com:8080：主机名和端口号。
  • /path/to/resource：资源路径。
  • query=123：查询参数。
  • #section：片段标识符。

• URN（统一资源名称，Uniform Resource Name）
  URN 是 URI 的另一种子集，用于唯一命名资源，但不提供资源的位置或访问方式。
  特点：

  • 使用 urn 作为协议（如 urn:isbn:0451450523）。
  • 通常由命名空间（namespace）和命名空间特定的字符串组成。
  • 不能直接用于访问资源。
    示例：

  urn:isbn:0451450523
  

  • urn：协议。
  • isbn：命名空间（表示国际标准书号）。
  • 0451450523：命名空间特定的字符串（表示具体的书号）。

URI、URL 和 URN 的关系

• URI 是广义概念，包含 URL 和 URN。
• URL 是 URI 的一种，用于定位资源。
• URN 是 URI 的另一种，用于命名资源，但不提供位置信息。

示例对比

类型	示例
URI	https://www.example.com/index.html
URL	https://www.example.com/index.html
URN	urn:isbn:0451450523

如果想深入了解这些概念，可以参考 W3C 的官方文档，其中对 URI、URL 和 URN 的定义和区别有详细说明。