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

文档介绍：GraphQL在微服务架构中的实践架构目录 GraphQL是什么? 1GraphQL在微服务架构中的使用 2GraphQL在实践过程中遇到的棘手问题 3合理的GraphQL微服务架构的设计 4GraphQL是什么?简单对象访问协议(SOAP)从今天来看已经是一门非常古老的Web服务技术了,虽然很多服务仍然在使用遵循SOAP的接口,但是到今天REST风格的面向资源的API接口已经非常深入人心,也非常的成熟;但是这篇文章要介绍的主角其实是另一门更加复杂、完备的查询语言GraphQL。作为Facebook在2015年推出的查询语言,GraphQL能够对API中的数据提供一套易于理解的完整描述,使得客户端能够更加准确的获得它需要的数据,目前包括Facebook、Twitter、GitHub在内的很多公司都已经在生产环境使用GraphQL提供API;其实无论我们是否决定生产环境中使用GraphQL,它确实是一门值得学习的技术。二、GraphQL在微服务架构中的使用类型系统GraphQL的强大表达能力主要还是来自于它完备的类型系统,与REST不同,它将整个Web服务中的全部资源看成一个有连接的图,而不是一个个资源孤岛,在访问任何资源时都可以通过资源之间的连接访问其它的资源。如上图所示,当我们访问User资源时,就可以通过GraphQL中的连接访问当前User的Repo和Issue等资源,我们不再需要通过多个REST的接口分别获取这些资源,只需要通过如下所示的查询就能一次性拿到全部的结果:{user{idemailusernamerepos(first:10){idurlnameissues(first:20){idauthortitle}}}}GraphQL这种方式能够将原有RESTful风格时的多次请求聚合成一次请求,不仅能够减少多次请求带来的延迟,还能够降低服务器压力,加快前端的渲染速度。它的类型系统也非常丰富,除了标量、枚举、列表和对象等类型之外,还支持接口和联合类型等高级特性。为了能够更好的表示非空和空字段,GraphQL也引入了Non-Null等标识代表非空的类型,例如String!表示非空的字符串。schema{query:Querymutation:Mutation}Schema中绝大多数的类型都是普通的对象类型,但是每一个Schema中都有两个特殊类型:query和mutation,它们是GraphQL中所有查询的入口,在使用时所有查询接口都是query的子字段,所有改变服务器资源的请求都应该属于mutation类型。集中式vs分散式GraphQL以图的形式将整个Web服务中的资源展示出来,其实我们可以理解为它将整个Web服务以“SQL”的方式展示给前端和客户端,服务端的资源最终都被聚合到一张完整的图上,这样客户端可以按照其需求自行调用,类似添加字段的需求其实就不再需要后端多次修改了。与RESTful不同,每一个的GraphQL服务其实对外只提供了一个用于调用内部接口的端点,所有的请求都访问这个暴露出来的端点。GraphQL实际上将多个HTTP请求聚合成了一个请求,ment和Author的图,多个请求变成了一个请求的不同字段,从原有的分散式请求变成了集中式的请求,这种方式非常适合单体服务直接对外提供GraphQL服务,能够在数据源和展示层建立一个非常清晰的分离,同时也能够通过一些强大的工具,例如GraphiQL直接提供可视化的文档;但是在业务复杂性指数提升的今天,微服务架构成为了解决某些问题时必不可少的解决方案,所以如何在微服务架构中使用GraphQL提高前后端之间的沟通效率并降低开发成本成为了一个值得考虑的问题。Relay标准如果说RESTful其实是客户端与服务端在HTTP协议通信时定义的固定标准,那么Relay其实也是我们在使用GraphQL可以遵循的一套规范。这种标准的出现能够让不同的工程师开发出较为相似的通信接口,在一些场景下,例如标识对象和分页这种常见的需求,引入设计良好的标准能够降低开发人员之间的沟通成本。Relay标准其实为三个与API有关的最常见的问题制定了一些规范:提供能够重新获取对象的机制;提供对如何对连接进行分页的描述;标准化mutation请求,使它们变得更加可预测;通过将上述的三个问题规范化,能够极大地增加前后端对于接口制定和对接时的工作效率。对象标识符Node是Relay标准中定义的一个接口,所有遵循Node接口的类型都应该包含一个id字段:interfaceNode{id:ID!}typeFaction:Node{id:ID!name:Stringships:ShipConnection}typeShip:Node{id:ID!name:String}Faction和Ship两个类型都拥有标