基于 GraphQL 平台化 BFF 构建及微服务治理( 四 ) 01什么是BFFBackendForFrontend

3.4引入路由能力
路由这部分比较简单，主要就是根据不同的端、版本、iOS/Anroid等参数，映射到对应的GraphQL请求和JSON模板上即可。
3.5构建BFF平台
BFF由前端还是后端开发，其实在各家公司都有不同的实践。但不管是谁来做，都会存在一定的问题
BFF由前端负责，需要额外关注服务器的稳定性、性能，以及RPC/HTTP请求的容错等等，对前端同学的能力要求较高
BFF由后端负责，由于并不一定能很好的理解前端页面的各种数据需求，对后端同学来说基本上是纯工作量。如果是一个独立的后端BFF团队，工程师容易觉得没有成长，人员也很难稳定
这个问题我们先放放，回到BFF本身的开发工作，通过前面的拆解之后，我们发现BFF的开发工作其实比较模板化
数据获取：编写GraphQLquery ，调用GraphQL服务获取数据
数据转换：编写JSON模板，转换成前端需要的JSON结构
请求映射：编写路由逻辑，映射到对应的GraphQL请求和JSON模板上
基于这样的项目开发流程，我们把整个BFF层构建成了一个平台。开发同学只需要在平台里的三个表单里输入上面的内容，就可以得到想要的API接口。

文章图片

文章图片
整合完成后，我们的整体架构如下

文章图片
统一请求入口：BFF平台负责对外部统一的API接口
请求映射：根据请求参数和内部配置的路由规则，把请求映射到不同的配置模板上
获取模板信息：单个配置模板里，保存着GraphQL的query语句和JSON映射模板
数据获取：使用GraphQLquery语句调用GraphQL网关，获取数据结果
数据转换：调用模板引擎，进行JSON结构的转换，并将数据返回给调用方
通过上述几个步骤，我们的BFF平台可以支持非常快速的实现一个API来对外提供服务
BFF平台由后端负责开发和维护，保证服务的性能和稳定性。前端主要的工作使用BFF平台写query和模板，完成页面的数据拼装。通过这样的方式，前端和后端都能够最大化的发挥自己的擅长的能力，优化团队研发效率。
04GraphQL网关架构及微服务治理
前面的架构里可以看到，我们是把GraphQL当做一个网关来处理，负责对接底层的微服务。在一些GraphQL应用的场景里，随着接入的业务越来越多， GraphQL的服务会逐步的变成一个非常庞大的单体应用，维护起来会越来越困难。另外所有的业务都聚合到这一个GraphQL的出口，可能光Schema定义就需要上万行。这样不论是维护还是使用上都很难进行下去，而且与现在主流的微服务架构体系相矛盾
业界目前最主流的解决方案是ApolloGraphQL提供的GraphQLFederation功能，并且Netflix在此基础上构建了一套DGS(DomainGraphQLService)的架构来进行治理的。这里做一个简单的介绍：

文章图片
每个领域服务单独构建一个对应的GraphQL领域服务(DGS)
由集中式的GraphQLGateway借助Federation的能力来负责聚合多个DGS ，自动生成统一Schema对外提供服务
但是这样的做法只是解决了GraphQL服务的单体应用的问题，最终聚合出来的GraphQLSchema还是可能会非常的庞大，使用起来还是会很困难。而且整个架构其实是做了2层的GraphQL处理，一层在DSG上，一层在Gateway上，会有一定性能的重复开销，服务稳定性上也有更多的挑战。