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

(44页)

'GraphQL在微服务架构中实践架构'
GraphQL在微服务架构中的实践架构目录GraphQL 是什么? iGraphQL在微服务架构中的使用 2GraphQL在实践过程中遇到的棘手问题 3合理的GraphQL彳敦服务架构的设计 4一、GraphQL 是什么?简单对象访问协议(SOAP)从今天来看已经是一门非常古老的Web服务 技术了,虽然很多服务仍然在使用遵循SOAP的接口,但是到今天REST风格 的面向资源的API接口已经非常深入人心,也非常的成熟;但是这篇文章要介 绍的主角其实是另一门更加复杂、完备的查询语言GraphQLo作为Facebook在2015年推出的查询语言,GraphQL能够对API中 的数据提供一套易于理解的完整描述,使得客户端能够更加准确的获得它需要的 数据,目前包括Facebook. Twitter. GitHub在内的很多公司都已经在生产 环境使用GraphQL提供API ;其实无论我们是否决定生产环境中使用 GraphQL ,它确实是一门值得学习的技术。二、GraphQL在微服务架构中的使用类型系统GraphQL的强大表达能力主要还是来自于它完备的类型系统,与REST 不同,它将整个Web服务中的全部资源看成一个有连接的图,而不是一个个 资源孤岛,在访问任何资源时都可以通过资源之间的连接访问其它的资源。GRAPH QUERY LANGUAGEIssue如上图所示,当我们访问User资源时,就可以通过GraphQL中的连接 访问当前User的Repo和Issue等资源,我们不再需要通过多个REST的 接口分别获取这些资源,只需要通过如下所示的查询就能一次性拿到全部的结 果:{user {idemailuser namerepos(first: 10) {idurln ameissues(first: 20) {id authortitle}GraphQL这种方式能够将原有RESTful风格时的多次请求聚合成一次请 求,不仅能够减少多次请求带来的延迟,还能够降低服务器压力,加快前端的渲 染速度。它的类型系统也非常丰富,除了标量、枚举、列表和对象等类型之外, 还支持接口和联合类型等高级特性。GRAPHQL SCHEMAInput Union Interface为了能够更好的表示非空和空字段,GraphQL也引入了 NomNull等标 识代表非空的类型,例如String!表示非空的字符串。schema { query: Querymutation: Mutation Schema中绝大多数的类型都是普通的对象类型,但是每一个Schema中都有两个特殊类型:query和mutation ,匕们是GraphQL中所有查询的入 口,在使用时所有查询接口都是query的子字段,所有改变服务器资源的请求 都应该属于mutation类型。集中式vs分散式GraphQL以图的形式将整个Web服务中的资源展示出来,其实我们可以 理解为它将整个Web服务以〃SQL〃的方式展示给前端和客户端,服务端 的资源最终都被聚合到一张完整的图上,这样客户端可以按照其需求自行调用, 类似添加字段的需求其实就不再需要后端多次修改了。与RESTful不同,每一个的GraphQL服务其实对外只提供了一个用于调 用内部接口的端点,所有的请求都访问这个暴露出来的端点。GraphQL vs RESTful(endpoint)dravorwtt .”/叩1!/potttdr^venessGraphQL实际上将多个HTTP请求聚合成了一个请求,它只是将多个RESTful请求的资源变成了一个从根资源Post访问其他资源的Comment和Author的图,多个请求变成了一个请求的不同字段,从原有的分散式请求 变成了集中式的请求,这种方式非常适合单体服务直接对外提供GraphQL服 务,能够在数据源和展示层建立一个非常清晰的分离,同时也能够通过一些强大 的工具,例如GraphiQL直接提供可视化的文档;但是在业务复杂性指数提升 的今天,微服务架构成为了解决某些问题时必不可少的解决方案,所以如何在微 服务架构中使用GraphQL提高前后端之间的沟通效率并降低开发成本成为了 一个值得考虑的问题。Relay标准如果说RESTful其实是客户端与服务端在HTTP协议通信时定义的固定 标准,那么Relay其实也是我们在使用GraphQL可以遵循的一套规范。GRAPHQL AND RELAY这种标准的出现能够让不同的工程师开发出较为相似的通信接口,在一些场 景下,例如标识对象和分页这种常见的需求,引入设计良好的标准能够降低开发 人员之间的沟通成本。Relay标准其实为三个与API有关的最常见的问题制定了一些规范:提供能够重新获取对象的机制;提供对^何对连接进行分页的描述;标准化mutation请求,使它们变得更加可预测;通过将上述的三个问题规范化,能够极大地增加前后端对于接口制定和对接 时的工作效率。对象标识符Node是Relay标准中定义的一个接口,所有遵循Node接口的类型都 应该包含一个id字段:in terface Node {id: ID!}type Faction : Node {id: ID!name: Stringships: ShipConnectiontype Ship : Node { id: ID!name: String}Faction和Ship两个类型都拥有标识符id字段,我们可以通过该标识符重新从服务端取回对应的对象,Node接口和字段在默认情况下会假定整个服 务中的所有资源的id都是不同的,但是很多时候我们都会将类型和id绑定到 一起,组合后才能一个类型特定的ID ;为了保证id的不透明性,返回的id往 往都是Base64编码的字符串QraphQL服务器接收到对应id时进行解码就 可以得到相关的信息。连接与分页在一个常见的数据库中,一对多关系是非常常见的,一个User可以同时 拥有多个Post以及多个Comment,这些资源的数量在理论上不是有穷的, 没有办法在同一个请求全部返回,所以要对这部分资源进行分页。query {viewer {name email posts(first: 1) {edge{cursornode {title}}}}}Relay通过抽象出的『连接模型』为一对多的关系提供了分片和分页的支持, 在Relay看来,当我们获取某一个User对应的多个Post时z其实是得到了 —个PostConnection ,也就是一个连接:{"viewer": {“name": nDraveness;"email": ni@draveness.me;"posts": {"edges":[ncursor11: ,,YXJyYXIjb25uZWNOaW9uOjI=,,/ n
关 键 词:
GraphQL 微服 架构 实践
 天天文库所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
关于本文
本文标题:GraphQL在微服务架构中实践架构
链接地址: https://www.wenku365.com/p-43445634.html
关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服点击这里,给天天文库发消息,QQ:1290478887 - 联系我们

本站为“文档C2C交易模式”,即用户上传的文档直接卖给(下载)用户,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有【成交的100%(原创)】。本站是网络服务平台方,若您的权利被侵害,侵权客服QQ:1290478887 欢迎举报。

1290478887@qq.com 2017-2027 https://www.wenku365.com 网站版权所有

粤ICP备19057495号 

收起
展开