GraphQL在微服务架构中的实践架构

9

}

]

}

}

}

在一个

PostConnection

中会存在多个

PostEdge

对象，其中的

cursor

就是我们用来做分页的字段，

所有的

cursor

其实都是

Base64

编码的字符串，

这能够提醒调用方

cursor

是一个不透明的指针，

拿到当前

cursor

后就可以将

它作为

after

参数传到下一个查询中：

query {

viewer {

name

email

posts(first: 1, after:

edge {

cursor

来源：

CDA

数据分析

10

node {

title }

}

}

}

}

当我们想要知道当前页是否是 最后一页时，其实只需要使用每一个连接中的

PageInfo

对象，其中包含了很多与分页相关的信息， 一个连接对象中一般都有

以下的结构和字段，例如：

Edge< /p>

、

PageInfo

以及游标和节点等。

PostConnection

├──

PostEdge

│

├──

cursor

│

└──

Post

└──

PageInfo

├──

hasNextPage

├──

hasPreviousPage

来源：

CDA

数据分析

11

├──

startCursor

└──

endCursor

Relay

使用了非常多的功能在连接周围构建抽象，

让我们能够更加方便地管

理客户端中的游标，

整个连接相关的规范其实特别复杂，

可以阅读

Relay Cursor

Connections Specification

了解更多与连接和游标有关的设计。

可变请求

每一个

Web

服务都可以看做一个大型的复杂状态机，这个状态机对外提

供两种不同的接口，

一种接口是查询接口，

它能够查询状态机的当前状态，

而另

一种接口是可以改变服务器状态的可变操作，例如

POST

、

DELETE

等请求。

按照约定，所有的可变请求都应该以动词开头并且它们的输入都以

Input

结尾，与之相对应的，所有的输出都以

Payload

结尾：

input IntroduceShipInput {

factionId: ID!

shipName: String!

来源：

CDA

数据分 析

12

clientMutationId: String!

}

type IntroduceShipPayload {

faction: Faction

ship: Ship

clientMutationId: String!

}

除此之外，可变请求还可以通过传入

clientMutationId

保证请求的幂等

性。

小结

Facebook

的

Relay

标准其实是一个在

GraphQL

上对于常见领域问题

的约定，

通过这种 约定我们能够减少工程师的沟通成本和项目的维护成本并在多

人协作时保证服务对外提供 接口的统一。

三、

GraphQL< /p>

在实践过程中遇到的棘手问题

N + 1

问题

在传统的后端服务中，

N + 1

查 询的问题就非常明显，由于数据库中一对

多的关系非常常见，再加上目前大多服务都使用

ORM

取代了数据层，所以在

来源：

CDA

数据分析

13

很多时候相关问题都不会暴露出来，

只有真正出现性能问题或者慢查询时才会发

现。

SELECT * FROM users LIMIT 3;

SELECT * FROM posts WHERE user_id = 1;

SELECT * FROM posts WHERE user_id = 2;

SELECT * FROM posts WHERE user_id = 3;

SELECT * FROM users LIMIT 3;

SELECT * FROM posts WHERE user_id IN (1, 2, 3);

GraphQL

作为一种更灵活的

API

服务提供方式，相比于传统的

Web

服

务更容易出现上述问题，

类似的问题 在出现时也可能更加严重，

所以我们更需要

避免

N + 1

问题的发生。

数据库层面的

N + 1

查询我们可以通过减少

SQL

查询的次数来解决，一

般我们会将多个

=

查询转换成

IN

查询；

但是

GraphQL

中的

N + 1

问题就

有些复杂了，

尤其是当资源需要通过

RPC