GraphQL和微服务架构

Question

我试图了解GraphQL最适合在微服务架构中使用的位置。

关于只有1个GraphQL架构作为API网关代理对目标微服务的请求并强制其响应，存在争议。微服务仍然会使用REST / Thrift协议进行通信思考。

另一种方法是每个微服务具有多个GraphQL模式。拥有一个较小的API网关服务器，使用请求的所有信息+ GraphQL查询将请求路由到目标微服务。

第一种方法

将1个GraphQL架构作为API网关将有一个缺点，每次更改微服务合同输入/输出时，我们必须在API网关侧相应地更改GraphQL架构。

第二种方法

如果每个微服务使用多个GraphQL模式，那么在某种程度上是有意义的，因为GraphQL强制执行模式定义，并且消费者需要尊重微服务提供的输入/输出。

问题

• 在哪里可以找到适合设计微服务架构的GraphQL？

• 您如何使用可能的GraphQL实现设计API网关？

Answer 1

绝对接近＃1。

让您的客户与多个GraphQL服务进行通信（如方法＃2），首先完全违背了使用GraphQL的目的，即为您的整个应用程序数据提供架构以允许在一次往返中取得它。

从微服务的角度来看，拥有无共享架构似乎是合理的，但对于客户端代码而言，这绝对是一场噩梦，因为每次更改一个微服务时，都必须更新所有您的客户。你肯定会后悔的。

GraphQL和微服务非常适合，因为GraphQL隐藏了一个来自客户端的微服务架构这一事实。从后端的角度来看，您希望将所有内容拆分为微服务，但从前端的角度来看，您希望所有数据都来自单个API。使用GraphQL是我所知道的最好的方法，可以让你做到这两点。它允许您将后端拆分为微服务，同时仍为所有应用程序提供单个API，并允许跨不同服务的数据进行连接。

如果您不想将REST用于您的微服务，您当然可以让每个人都拥有自己的GraphQL API，但您仍然应该拥有API网关。人们使用API​​网关的原因是使从客户端应用程序调用微服务变得更易于管理，而不是因为它非常适合微服务模式。

Answer 2

请参阅文章here，其中说明方法＃1如何以及为何更好地运作。另请参阅我提到的文章中的下图：

将所有内容置于单个端点后面的主要好处之一是，与每个请求都有自己的服务相比，可以更有效地路由数据。虽然这是GraphQL经常被吹捧的价值，复杂性和服务蠕变的减少，但由此产生的数据结构也可以非常明确地定义数据所有权，并明确界定。

采用GraphQL的另一个好处是，您可以从根本上断言对数据加载过程的更大控制。由于数据加载器的过程进入其自己的端点，因此您可以部分地，完全地或通过警告来满足请求，从而以极其精细的方式控制数据的传输方式。

以下文章非常好地解释了这两个好处：https://nordicapis.com/7-unique-benefits-of-using-graphql-in-microservices/

Answer 3

对于方法＃2，实际上这是我选择的方式，因为它比手动维护恼人的API网关容易得多。通过这种方式，您可以独立开发服务。让生活更轻松：P

有一些很好的工具可以将模式组合成一个，例如graphql-weaver和apollo＆＃39; graphql-tools，我使用graphql-weaver，它易于使用且效果很好。

Answer 4

从2019年中期开始，第一种方法的解决方案现在的名称为“ Schema Federation” coined by the Apollo people（以前通常称为GraphQL拼接）。 他们还为此建议了模块@apollo/federation和@apollo/gateway。

Answer 5

我一直在使用GraphQL和微服务

根据我的经验，对我有用的是根据功能/用途将两种方法结合使用，我将永远不会像方法1那样拥有单个网关...而是像方法2那样为每个微服务分配一个graphql。 / p>

例如，基于来自Enayat的答案的图像，在这种情况下，我要做的是拥有3个图形网关（而不是图像中的5个）

• 应用程序（产品，购物篮，运输，库存，需要/链接到其他服务）

• 付款

• 用户

这样，您需要特别注意从相关服务公开的所需/链接的最小数据的设计，例如身份验证令牌，用户ID，付款ID，付款状态

以我的经验为例，我具有“用户”网关，在GraphQL中，我具有用户查询/更改，登录，登录，注销，更改密码，恢复电子邮件，确认电子邮件，删除帐户，编辑个人资料，上传图片等...此图本身就很大！之所以分开，是因为其他服务/网关最后只关心生成的信息，例如用户ID，名称或令牌。

这种方式更容易...

• 根据不同的网关比例缩放/关闭它们。 （例如，人们可能并不总是在编辑个人资料或付款...，但是搜索产品的频率可能会更高）。

• 一旦网关成熟，增长，使用已知或您对域有了更多专业知识，您就可以确定哪些模式可以拥有自己的网关（...发生在我头上，与git仓库交互的架构，我分离了与仓库交互的网关，我看到唯一需要输入/链接的信息是...文件夹路径和预期分支）

• 您的存储库的历史更加清晰，您可以拥有一个专门用于网关及其所涉及的微服务的存储库/开发人员/团队。

Answer 6

从2019年开始，最好的方法是编写实现apollo gateway规范的微服务，然后按照方法＃1使用网关将这些服务粘合在一起。 建立网关最快的方法是像this one这样的docker镜像 然后使用docker-compose同时启动所有服务：

version: '3'

services:
    service1:
        build: service1
    service2:
        build: service2
    gateway:
        ports:
            - 80:80
        image: xmorse/apollo-federation-gateway
        environment: 
            - CACHE_MAX_AGE=5
            - "FORWARD_HEADERS=Authorization, X-Custom-Header" # default is Authorization, pass '' to reset
            - URL_0=http://service1
            - URL_1=http://service2

Answer 7

我在此问题中描述的方式，我相信使用自定义API网关作为业务流程服务对于以企业为中心的复杂应用程序很有意义。至少就查询而言，GraphQL可以成为该编排服务的良好技术选择。第一种方法（所有微服务的一个模式）的优点是能够在单个请求中将多个微服务的数据缝合在一起。根据您的情况，这可能非常重要，也可能不会非常重要。如果GUI一次要求从多个微服务渲染数据，则此方法可以简化客户端代码，以便单个调用可以返回适合与Angular或React这样的框架的GUI元素进行数据绑定的数据。这种优势不适用于突变。

缺点是数据API和业务流程服务之间紧密耦合。发布不再是原子的。如果您避免在数据API中引入向后突破性更改，那么仅当回滚发行版时，这可能会带来复杂性。例如，如果您将要发布两个数据API的新版本，并在业务流程服务中进行了相应的更改，并且您需要回滚其中一个版本，而又不回滚另一个版本，那么无论如何您都将不得不回滚这三个版本。

在GraphQL vs REST的比较中，您会发现GraphQL不如RESTful API高效，因此我不建议您为数据API用GraphQL代替REST。

Answer 8

对于问题1，Intuit在数年前宣布迁移到One Intuit API生态系统（https://www.slideshare.net/IntuitDeveloper/building-the-next-generation-of-quickbooks-app-integrations-quickbooks-connect-2017）时就承认GraphQL的强大功能。 Intuit选择采用方法1。您提到的缺点实际上阻止了开发人员引入可能会破坏客户端应用程序的重大架构更改。

GraphQL通过多种方式帮助提高了开发人员的生产力。

1. 在为域设计新的微服务时，工程师（后端/前端/利益相关者）同意域实体的架构。架构被批准后，将与主域架构（通用）合并并部署在网关上。前端工程师可以开始使用此架构对客户端应用程序进行编码，而后端工程师则可以实现该功能。具有一个通用模式意味着没有两个具有冗余功能的微服务。

2. GraphQL帮助客户应用程序变得更简单，更快。是否想从/ update数据中检索数据到多个微服务？所有客户端应用程序必须执行的是发出一个GraphQL请求，并且API网关抽象层将注意从多个源（微服务）获取和整理数据。像Apollo（https://www.apollographql.com/）这样的开源框架加快了GraphQL的采用速度。

3. 由于移动设备是现代应用程序的首选，因此从零接地开始设计以降低数据带宽需求非常重要。 GraphQL通过允许客户端应用程序仅请求特定字段来提供帮助。

对于问题2：我们在API网关处构建了一个自定义抽象层，该抽象层知道模式的哪一部分归哪个服务（提供者）所有。当查询请求到达时，抽象层将请求转发到适当的服务。基础服务返回响应后，抽象层将负责返回请求的字段。

但是，今天有数个平台（Apollo服务器，graphql-yoga等）允许一个人立即构建GraphQL抽象层。

Answer 9

对于使用graphql引导微服务生态系统，我们也有类似的担忧。我们可以使用Apollo GraphQL来解决它。

我们为One Platform从零开始构建了这些解决方案。以service结尾的文件夹是微服务，其他是SPA（又称为单页应用程序）

这由各种微服务和水疗中心组成，它们带有API Gateway，这是多个微服务的主要界面。

与此相关的是，您可以找到一个OP CLI generator，它可以帮助从头开始引导微服务。

项目-https://github.com/1-Platform/one-platform

我要求请看一下这个项目，如果对您来说不错，请随时采用。

致谢

Rigin Oommen

Answer 10

由于微服务架构没有正确的定义，因此没有针对此类型的特定模型，但是，其中大多数都具有很少的显着特征。在微服务架构的情况下，每个服务可以分解为单独的小组件，可以单独调整和部署，而不会影响应用程序的完整性。这意味着您只需更改一些服务，而无需通过自定义 microservices app development 进行应用程序重新部署。

Answer 11

有关微服务的更多信息，我认为GraphQL在无服务器架构中也可以完美运行。我没有使用GraphQL，但我有my own similar project。我将它用作aggregator，它可以调用许多函数并将其集中到单个结果中。我认为你可以为GraphQL应用相同的模式。