java - GraphQl usług 网关模式

Question

1) EAA 目录中的网关模式使用网关模式隐藏了“业务微服务”的复杂性。该组件负责根据配置将请求正确重定向到适当的服务。前端应用程序只能与该组件通信。

链接: https://martinfowler.com/eaaCatalog/gateway.html

我想知道 GraphQl 如何处理这种模式？如果每个微服务有一个 GraphQl 端点，我们如何实现这一模式？

回复答案 - 编辑:

在我的项目中，有架构，然后有网关，zuul 将其发送到另一个项目(它通过 URL 来自请求)。 GraphQl 是一个端点，因此 zuul 无法工作。所以我们只有两个步骤(总是 - 例如可以在 zipkin 中检查)，例如:

网关微服务 -> 微服务X

关于:

Maybe you implement another GraphQL API that consolidate these microservices 's GraphQL API

我就是这么想的。在我的项目中，只有 API 网关 可用于互联网。但在这种情况下，我想知道我们是否进入了这样的查询:对微服务 A 进行 5 个查询，对微服务 B 进行 3 个查询 我怎样才能在这个微服务网关中传递它们 - 我不想将其一片一片地切割，所以我会从它向微服务 B 发送一个接一个(总计 3 个)查询 - 但一次发送 3 个。微服务 A 也是如此 -> 我想一次性从 graphQL 发送。

如果我只使用这些:

    <dependency>
        <groupId>com.graphql-java</groupId>
        <artifactId>graphql-spring-boot-starter</artifactId>
        <version>5.0.2</version>
    </dependency>
    <dependency>
        <groupId>com.graphql-java</groupId>
        <artifactId>graphiql-spring-boot-starter</artifactId>
        <version>4.0.0</version> <!--5.0.2 http://localhost:8999/graphiql fails to load-->
    </dependency>

然后在微服务X中我得到了架构和一些查询，例如:

type Query {
    getAllItems: [TestEntity]
    getDataTypes: [DictionaryType]
    (...)
}

在 Controller 中我有:

private DataFetcher<List<TestEntity>> allDictionaryItemsFetcher;
private DataFetcher<Set<DictionaryType>> dictionaryTypeFetcher;

@Value("classpath:test.graphqls")
private Resource schemaResource;
private GraphQL graphQL;
(...)
        allDictionaryItemsFetcher = dataFetchingEnvironment -> dictionaryService.getAllDictionaryItemsAsStrings();
        dictionaryTypeFetcher = dataFetchingEnvironment -> dictionaryService.getDictionaryTypes();


@PostConstruct
private void loadSchema() throws IOException {
    File schemaFile = schemaResource.getFile();
    TypeDefinitionRegistry registry = new SchemaParser().parse(schemaFile);
    RuntimeWiring wiring = buildWiring();
    GraphQLSchema schema = new SchemaGenerator().makeExecutableSchema(registry, wiring);
    graphQL = GraphQL.newGraphQL(schema).build();
}

private RuntimeWiring buildWiring() {
    return RuntimeWiring.newRuntimeWiring()
            .type("Query", typeWriting -> typeWriting
                    .dataFetcher("getAllItems", allDictionaryItemsFetcher)
                    .dataFetcher("getDataTypes", dictionaryTypeFetcher)

            )
            .build();
}

然后，如果我们使用与 GraphQl 相同的依赖关系创建 Gateway 微服务，我们将在 schema 中拥有:

type Query {
    getAllItems: [TestEntity] # from microservice A
    getDataTypes: [DictionaryType] # from microservice A
    (...) # Other from microservice A,B,C,(...)
}

然后，如果用户发送一个请求从 Microserivce A 获取 getAllItems 和 getDataTypes 并从 Z resources 获取>微服务B我如何发送两个查询:首先使用 getAllItems 和 getDataTypes 到 Microservice A第二个是向微服务 B 发出 Z 请求？

如何以这种方式分离 GraphQL 请求？

我不想一一发送请求 - 例如当我得到:从 Microserivce A 获取 getAllItems 和 getDataTypes我不想使用以下命令调用两次微服务A一次: 获取所有项目第二次使用 getDataTypes 。

如何轻松地仅通过微服务分隔查询？

例如，在 GraphQL 网关中创建多个模式(每个微服务一个)，并配置一个端点有多个模式` - 这可能吗？或者有其他方法可以解决吗？

也许这是我的误解GraphQL，但我认为在上面的案例中，我们必须为每个微服务<配置一个GraphQl/code> 在 java 中。

我不想要一个使用经典 REST API(不是 GraphQL)发送到 微服务 X 的 GraphQL 网关 )，导致我们丢失了很多东西，例如获取优化请参见此处: https://youtu.be/1zIHHi2MaQE?t=1369或者向具体的微服务X发出N个请求而不是一个请求

Answer 1

基本上它意味着以下架构。 GraphQL API 是位于不同 API 前面的网关，例如传统 Soap API、REST 微服务 API、第三部分 API、数据库或 blalablab。

图片取自 this

This component was responsible for the proper redirection of requests to the appropriate services based on the configuration.

GraphQL 类型/查询/突变的每个字段都有自己的解析器函数，它们定义自己的逻辑以从不同的后端服务获取值。因此 GraphQL 类型系统及其解析器函数是一种配置，定义了如何请求重定向到适当的服务以获取数据。

Gateway pattern from EAA Catalog The complexity of "business microservices" was hidden by using a Gateway pattern. The fronted application could only communicate with this component.

在添加 GraphQL API 之前，将数据显示在 UI 中。用户可以先调用FooService来获取一部分数据，然后根据一些FooService数据，他必须调用BarService来获取另一部分数据数据。然后，根据一些 BarService 数据，他必须调用 BazService 来获取另一个数据。然后基于一些BazService，他就得blablabla........，这是一个非常繁琐、麻烦的过程。更不用说不同的API使用不同的名称来代表相同的业务概念。

添加 GraphQL API 后，我们将这些麻烦的工作转移到 GraphQL API 上。用户只需要直接与 GraphQL API 进行通信(所以它是一个网关)。他们只需调用一个 API 即可获取他们想要的数据而不是调用许多 API。

此外，GraphQL 将不同服务中具有不同名称和解释的业务概念整合到一个 API 中。所以从用户的角度来看，它隐藏了“业务微服务”的复杂性，更容易使用开发

How we can implement this pattern if we have one GraphQl endpoint per microservice?

也许您可以实现另一个 GraphQL API 来整合这些微服务的 GraphQL API