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

我们的目标是设计一个能够反映域本身而不是数据库模型的GraphQL模式。 UI开发人员不必构建面向前端的后端（BackendsForFrontends ， BFF）来根据他们的需要处理数据，相反，他们应该协助一起来塑造模式，以满足他们的需求。拥抱协作的模式设计方法对于实现这一目标至关重要。

文章图片
Schema设计工作流
协作设计过程涉及跨团队的反馈和审查。为了简化模式设计和审查，我们成立了一个模式工作组并开发了一个用于加入联邦架构的托管技术程序。虽然审查会增加产品开发过程的开销，但我们相信，优先考虑Graph模型的质量能减少未来的变更及其所需的反工量。审查的级别因受影响的实体而异；对于核心联邦类型，则需要更严格的审查（尽管工具有助于简化该流程）。
我们有一个用于改进模式的deprecation工作流。我们利用了GraphQL的deprecation特性，并且还跟踪了模式中每个字段的使用统计信息。一旦统计数据表明已弃用字段不再使用，我们就可以进行向后不兼容的变更，将该字段从模式中删除。

文章图片
显示已弃用字段使用情况的客户端
我们采用了模式优先的方法，而不是从现有的模型中（例如gRPCAPI的Protobuf对象）生成模式。虽然Protobuf和gRPC是构建服务API的优秀解决方案，但我们更喜欢将GraphQL模式与这些层解耦，以实现更清晰的Graph设计和独立的可扩展性。在某些场景中，我们实现了从GraphQL解析器到gRPC调用的通用映射编码，但是额外的样板对GraphQLAPI的长期灵活性来说是值得的。
我们使用的方法是基于“上下文高于控制”（“contextovercontrol”）的，这是Netflix文化的一个重要原则。我们没有试图严格控制整个Graph ，而是为产品团队提供指导和上下文，这样他们就可以应用自己的领域知识为自己的领域创建灵活的API 。随着该架构的成熟，我们将继续监控模式运行情况，并在需要的时候开发新的工具、流程和最佳实践。
可观测性
在我们之前的架构中，可观测性是通过人工分析和API团队的路由来实现的，它的可伸缩性很差。对于我们的联邦架构，我们以一种更具可伸缩性的方式来优先解决可观测性的需求。
我们优先考虑如下三个方面：
报警——当发生错误时（when）报告发现——轻松确定哪些（what）是不工作的诊断——调试某些东西不工作的原因（why）我们在这一领域的指导度量指标是平均修复时间（MTTR）以及服务等级目标和服务等级指标（SLO/SLI）。
我们与Netflix遥测团队的专家合作。我们将网关和DGS架构组件与Zipkin、内部分布式跟踪工具Edgar和应用程序监控工具TellTale集成在一起。在GraphQL中，几乎每个响应都是200 ，错误块中包含了自定义的错误。我们从响应中检查这些自定义的错误代码，并将它们发送到我们的度量服务Atlas中。这些集成为GraphQLAPI的使用者和开发人员奠定了丰富的可见性和洞察力的良好基础。

文章图片
监控联邦请求生命周期的EdgarTrace

文章图片
联邦请求的时间轴视图
分布式日志关联（DistributedLogCorrelation）有助于调试更复杂的服务问题。通过显示处理请求所涉及的所有系统的应用级日志详细信息，我们可以更深入地了解堆栈中发生的事情。开发人员可以很容易地看到与给定请求同时发生的事情，以排查可能影响交互的周边因素。

文章图片
一个跨多个服务记录的联邦请求的日志
为了解决“我应该问谁（who）……”的路由问题，我们集成了从GraphQL类型和字段到它们所属团队的支持（support）渠道的深度链接。现在，寻找support只需单击跟踪中的链接，这有助于缩短MTTR并能减少网关团队所需的参与次数。
保护联邦Graph的安全
我们的目标是在整个联邦架构中实现可靠且一致的安全实践。为了实现这一点，我们与Netflix的安全专家合作，将安全性构建到Graph中。让我们来看下我们安全解决方案的两个基本部分：AuthN和AuthZ 。
身份认证
我们在Studio空间中的所有产品体验都需要一个经过认证的帐户，因此我们将GraphQL网关的访问权限限制为只允许受信任的经过身份验证的调用者。此外， GraphIntrospection仅限于Netflix的内部开发人员。