为什么 GraphQL 是构建微服务的更好选择

关于使用REST还是GraphQL来构建微服务哪个更好，一直存在争论。这两种技术都有其支持者和批评者，但当涉及微服务架构的特定需求时，GraphQL 成为明显的领先者。原因如下。

了解 RESTful 的关注点

虽然 REST 多年来一直是首选 API 风格，因其简单性和普遍适用性而受到赞誉，但它的局限性在微服务环境中变得非常明显。这些限制包括：

• 过度获取数据
• 对相关数据的多个 HTTP 请求
• 复杂的版本控制策略

此类问题可能会阻碍微服务架构的性能和可扩展性。

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

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

在移动应用程序仅需要特定用户详细信息（例如姓名和电子邮件）来进行个人资料概述的情况下，获取全面的用户数据意味着过度获取。

对于数据计划有限的用户来说，过多的数据使用可能会带来高昂的成本，并导致应用程序性能变慢和用户体验下降。

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

假设您有一个电子商务应用程序，其中订单域处理产品、客户、订单和退货实体，库存域管理产品、库存、仓库和交货实体。常见的操作可能是显示订单详细信息以及每种产品的当前库存状态。

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

在我们的场景中，客户下了三个订单 (N=3)，每个订单包含四种不同的产品。为了显示订单详细信息以及每种产品的库存状态，应用程序首先发出一个获取订单的请求。然后，对于每个订单中的每个产品，它向库存微服务发出额外的请求以检索库存信息。这会产生一个初始请求，加上 12 个后续请求（三个订单乘以每个订单四个产品），总共 13 个 API 调用。由于多次往返时间 (RTT) 以及网络和服务器负载的增加，请求的成倍增加会导致更高的延迟，体现了 N+1 问题。

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

GraphQL 的优势

GraphQL解决了许多 REST 弱点。

领域驱动设计：微服务依靠领域驱动设计蓬勃发展，其中每项服务都是围绕特定业务功能构建的。 GraphQL 以模式为中心的方法与此完美契合，为微服务提供了更有组织、更连贯的结构。

统一模式：在微服务架构中，每个服务可能都有自己的模式，代表业务领域的一部分。 GraphQL 的突出之处在于允许将这些模式组合或缝合在一起，为客户端提供统一的界面。这意味着客户端可以在单个请求中从多个服务查询数据，从而大大降低网络调用的复杂性和数量。

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

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

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

在早期的场景中，移动应用程序仅需要特定的用户详细信息（例如姓名和电子邮件）来进行个人资料概述，客户可以仅请求姓名和电子邮件。

简化版本控制：与 REST 不同，GraphQL 允许将新字段和类型添加到架构中而不影响现有查询，从而减少了版本控制的需求。这种向前兼容性意味着客户端和服务器可以随着时间的推移更加平滑地发展。如今，GraphQL 已成为一项成熟的技术，可满足传统 REST API 无法完全满足的现代 Web 开发中的特定需求。其设计提高了效率、灵活性和开发人员的生产力。

展望未来，GraphQL 的未来是光明的，社区驱动的努力专注于解决其当前的局限性，特别是在安全性、性能和标准化方面。随着这些努力取得成果，GraphQL 的采用范围预计将扩大，巩固其作为 API 领域关键技术的地位。