干货｜Netflix 联邦 GraphQL 平台的过程及教训( 三 ) 在之前的文章和QConPlus讨论中

授权
在StudioEdge之前，授权逻辑在各个团队之间是分散的。一些团队在他们的BFF中实现了授权，一些在微服务中实现了授权，而另一些团队则在这两处兼而有之。结果往往是，由于用户访问的UI不同，对于给定的数据，授权也不同。 UI团队还发现他们需要对每个新的前端实现（以及重新实现）进行授权检查。
在StudioEdge中，我们将授权责任委托给DGS的所有者。这就实现了在不同应用程序中对同一用户进行一致的授权。此外，产品经理、工程师和安全团队可以很容易地了解谁可以访问哪种数据类型以及如何访问。
我们在Netflix内部提供了多种授权服务：从基于用户身份授予访问权限的简单系统，到引入角色和功能概念的更细粒度的系统。 DGS开发人员可以根据自己的需要选择解决方案。然后，他们只需使用@Secured注解对解析器进行注解，并将其配置为使用一个可用的系统即可。如果需要，可以在解析器或下游系统中实现更复杂的授权。
授权的未来
我们目前正在构建一个支持GraphQL授权解决方案的原型。注册模式时， SchemaRegistry会自动为每个字段及其相应类型生成访问控制组（AccessControlGroups ， ACGs）。产品经理和DGS工程师可以决策这些生成的ACG的成员资格和规则。由于ACG映射到GraphQL中的某个字段，因此DGS框架会在执行期间自动应用与ACG关联的规则。
面向失败的架构设计
GraphQL网关是所有请求的单一入口点；网关上的故障可能会导致严重的中断。根据Netflix工程的最佳实践，我们假设会发生故障，并设计方法来减轻这些故障的影响。以下是我们用来确保网关层具有弹性的设计原则：
单一用途无状态服务需求控制多区域按功能分片首先，我们将网关层的职责集中在一个用途上：解析客户端查询，然后构建和执行查询计划。通过缩小范围，我们限制了可能发生的问题的范围。我们的目标是即时执行日志记录和度量指标之外的任何其他资源密集型操作。在网关层中添加其他不相关的逻辑可能会增加在这一关键层中出现故障的表面积。
其次，我们运行网关服务的多个无状态实例。任何网关实例都能够为任何请求生成和执行查询计划。当我们对网关层进行代码变更时，我们会在正式投入生产之前对它们进行严格的测试。
第三，我们通过应用需求控制来平衡每个请求消耗的资源。我们限制调用方的速率，以避免底层数据库过载，这些数据库是大多数领域元素的来源。我们还对所有传入的查询运行静态查询开销计算，并拒绝昂贵的查询，以避免网关和DGS资源的阻塞。我们的合作伙伴了解这些折衷方案，并与我们一起来满足这些要求，重新处理昂贵的查询并减少大的调用。
第四，我们在世界各地的多个AWS区域中部署了网关层。这使我们能够限制爆炸半径以应对发生不可避免的问题。当问题发生时，我们可以将故障转移到另一个区域，以确保我们的客户受到的影响最小。
最后，我们部署多个网关层的功能分片（Shard），每个分片中的代码均相同，传入的请求根据类别进行路由。例如， GraphQL订阅（Subscription）通常会导致长时间的连接，而查询（Query）和突变（Mutation）则是短暂的。我们使用一个单独的实例组来处理订阅，因此“连接耗尽”也不会影响查询和突变的可用性。
我们还可以做更多的事情来提高弹性。我们计划对网关部署以及最终的模式变更进行金丝雀（Canary）部署和分析。今天，我们的网关通过轮询模式注册来动态更新其模式。我们正在通过将联邦配置存储在一个版本化的S3存储桶中来实现这些功能的解耦，从而使网关能够抵御模式注册的故障。
结束语
GraphQL和Federation已成为Studio应用程序的效率倍增器。基于此，我们最近使用GraphQLFederation为iOS和Android上的Netflix消费者应用程序搜索页面创建了原型。为了做到这一点，我们创建了三个DGS来为消费者Graph的最小部分提供数据。我们正在将一小部分用户切流到这个替代技术栈中，并测量其高层度量指标。我们很高兴看到结果，并进一步探讨其在Netflix消费者领域的适用空间。
尽管我们拥有积极的经验，但GraphQLFederation尚处于成熟期的早期，可能对每个团队和组织来说并不都是最合适的。学习GraphQL和DGS开发、运行联邦层并进行迁移需要合作团队的高度投入以及无缝的跨功能协作。如果你正在考虑朝这个方向发展，我们建议你查看Apollo为Federation提供的SaaS产品，以及许多学习GraphQL相关的在线资源。对于像我们这样拥有大量的微服务并需要其聚合在一起的生态系统来说，开发速度和可操作性的提高使得这种转变是值得的。