在不断发展的软件开发环境中，使用 REST 和 GraphQL 构建微服务之间的争论变得越来越重要。这两种技术都有其支持者和批评者，但当涉及到微服务架构的特定需求时，GraphQL 显然是领跑者。原因如下。

了解 RESTful 问题
受欢迎程度与局限性
虽然REST多年来一直是首选的API风格，因其简单性和普遍适用性而广受赞誉，但它的局限性在微服务的上下文中变得非常明显。这些限制包括：

过度获取数据。
对相关数据的多个 HTTP 请求。
复杂的版本控制策略。
此类问题可能会阻碍微服务架构的性能和可伸缩性。

过度获取数据
REST API 旨在返回一组固定的数据，这通常会导致过度提取。这种冗余在移动网络中尤其成问题，因为每增加一个字节的数据都可能导致应用程序速度变慢和用户体验下降。

例如：

假设我们有一个 REST API 端点 /API/user/{userId}，它为用户返回以下数据：

在移动应用只需要特定用户详细信息（如姓名和电子邮件）来提供配置文件概述的情况下，获取全面的用户数据意味着过度获取。

对于数据计划有限的用户来说，这种过量的数据使用可能会造成高昂的代价，并导致应用性能降低和用户体验下降。

延迟和 N+1 问题
微服务通常需要分布在多个服务中的数据。

假设您有一个电子商务应用程序，其中 Order 域处理 Product、Customer、Order 和 Return 实体，而 Stock 域管理 Product、Stock、Warehouse 和 Delivery 实体。常见的操作可能是显示订单详细信息以及订单中每个产品的当前库存状态。

假设我们有一个订单微服务和一个库存微服务来处理订单和库存。

如果客户下了 3 个订单 （N=3），并且每个订单包含 4 个不同的产品。为了显示订单详细信息以及每个产品的库存状态，应用程序最初会发出 1 个请求来获取订单。然后，对于每个订单中的每个产品，它会向 Stock 微服务发出其他请求以检索库存信息。这导致 1 个初始请求 + 12 个后续请求（3 个订单 * 每个订单 4 个产品），总共有 13 个 API 调用。由于多次往返时间 （RTT） 以及网络和服务器上的负载增加，请求的这种成倍增加会导致更高的延迟，这体现了 N+1 问题。

版本控制挑战
随时间推移维护 REST API 涉及复杂的版本控制策略，例如引入新终结点或在 API 路径中嵌入版本号。这可能会导致臃肿和混乱，使 API 的开发和使用复杂化。

GraphQL 的优势
领域驱动设计
微服务在域驱动的设计中蓬勃发展，其中每个服务都是围绕特定的业务功能构建的。GraphQL 以模式为中心的方法与此完美契合，为微服务提供了更有条理和连贯的结构。

统一架构
在微服务架构中，每个服务可能都有自己的架构，表示业务域的一部分。GraphQL 通过允许将这些模式组合或“拼接”在一起而脱颖而出，从而为客户端提供统一的接口。这意味着客户端可以在单个请求中查询来自多个服务的数据，从而大大降低了网络调用的复杂性和数量。

解决 N+1 问题
GraphQL 能够通过单个请求获取数据，而不管需要调用多少个底层服务，直接解决了 REST 架构中固有的 N+1 问题。这不仅提高了性能，还简化了客户端数据获取逻辑。

对于前面描述的 N + 1 问题，如果服务支持 GraphQL，则可以在单个查询中获取嵌套数据，从而有效解决 N+1 问题。

效率和性能
通过允许客户端准确指定他们需要的数据，GraphQL 消除了 REST API 中常见的过度获取和获取不足的问题。这样可以提高数据检索效率，减少带宽使用，提高应用程序速度，这在移动环境中尤为明显。

在前面的场景中，移动应用只需要特定的用户详细信息（如姓名和电子邮件）来提供配置文件概述，客户端可以仅请求姓名和电子邮件。

简化的版本控制
与 REST 不同，GraphQL 允许在不影响现有查询的情况下将新字段和类型添加到架构中，从而减少了对版本控制的需求。这种向前兼容性意味着客户端和服务器可以随着时间的推移而更顺利地发展。

如今，GraphQL 已成为一项成熟的技术，可以满足现代 Web 开发中的特定需求，而传统 REST API 无法完全满足这些需求。它的设计提高了效率、灵活性和开发人员的生产力。展望未来，GraphQL 的未来是光明的，社区驱动的努力专注于解决其当前的局限性，特别是在安全性、性能和标准化方面。随着这些努力取得成果，GraphQL 的采用有望扩大，巩固其作为 API 领域关键技术的地位。