揭秘 Uber API 网关的架构.docxVIP

揭秘 Uber API 网关的架构 一个功能丰富的 App 是通过与众多供应不同功能的后端服务交互来实现的。全部这些交互都要经过一个通用的应用网关层。API 管理指的是这些网关 API 的创建、编辑、删除和版本把握。 工程师在 UI 中配置 API 的参数，并将功能性的 API 发布到互联网上供全部 Uber App 消费。配置管理着 API 的行为：路径、恳求数据类型、响应类型、允许的最大调用数、允许的 App、通信协议、要调用的特定微服务、允许的头、可观看性、字段映射验证等等。 一旦配置发布，网关基础设备就会将这些配置转换为有效的功能性 API，服务于我们的应用流量。网关基础设备还为使用这些 API 的 App 生成客户端 SDK。 与网关系统的全部交互都通过 UI 发生，UI 会引导用户一步一步地完成创建端点的过程。UI 简化了流程，并对 API 的各个方面做了各种验证。此外，这也是配置恳求超时、监控和告警的地方。 管理系统供应了一些协助功能，比如新的配置更改发布前的审查门，以及存储会话用于共享或恢复 API 管理。以下截图是可用于添加两头件的 UI 步骤的概览： 恳求生命周期中的组件 为了说明网关的各种组件，了解单个恳求如何通过网关运转时是很重要的。传入恳求包含一个路径，该路径映射到为其供应服务的处理程序。在恳求的生命周期中，它流经以下组件：协议管理器、两头件、数据验证、处理程序和后端客户端。恳求生命周期中的全部组件被实现为一个栈。 下面具体引见了每个组件，它们在恳求对象进入时对其进行操作，而相同的组件在响应对象传出时以相反的挨次运转。 协议管理器是栈的第一层。它包含网关支持的每种协议的反序列化器和序列化器。这一层供应了实现 API 的力量，它可以接收相关协议的任何类型的有效负载，包括 JSON、Thrift 或 Protobuf。它还可以便利地接收传入的 JSON 恳求，并使用原编码的响应进行应答。 两头件层是在调用端点处理程序之前实现可组合规律的笼统。两头件实现了横切关注点，如身份验证、授权、速率限制等。每个端点可以选择配置一个或多个两头件。除了可选两头件之外，该平台还包括一组必备的会针对每个恳求执行的两头件。一个两头件不需要同时实现 requestMiddleware 和 responseMiddleware 方法。假如两头件执行失败，调用将使栈的其余部分短路，来自两头件的响应将前往给调用者。在某些情况下，两头件可能没有操作，这取决于恳求上下文。 端点处理程序层担任恳求验证、有效负载转换以及将端点恳求对象转换为客户端恳求对象。当操作响应对象时，endpointHandler 将后端服务响应转换为端点响应，对响应对象执行某些转换，基于模式进行响应验证并序列化。 客户端向后端服务发送恳求。客户端是协议感知的，依据配置过程中选择的协议生成。用户可以配置客户端的内部功能，如恳求和响应转换、模式验证、断路和重试、超时和截止日期管理以及错误处理。 配置组件 协议管理器、两头件、处理程序和客户端有很多行为可以通过配置把握。管理 API 的用户不需要修改任何代码，而只需修改配置，就可以打算网关上端点的预期行为。为了便于配置，这些是通过 UI 进行管理的，其后台有一个 Git 存储库。 每个组件的配置都是从 Thrift 和/或 YAML 文件中猎取。YAML 文件供应了组件信息，并充当它们之间的粘合剂。Thrift 文件定义有效负载和协议语义。 网关 thrift 文件大量使用了thrift IDL中的注解特性，以便为各种特性和协议供应独一现实来源。在下面的小节中，我们将深化争辩每个组件的配置。 协议管理器 协议管理器需要理解恳求协议上下文中数据的格式和类型。响应也应当晓得类似的参数。 下面三行 YAML 配置供应了协议类型、Thrift 文件路径和协议管理器用于处理传入恳求的方法： 上面的配置表明，新 API 的类型是“HTTP”协议，关于模式和协议的全部其他细节都在 apiSample.thrift 文件中供应。 Thrift 文件 apiSample.thrift 功能丰富，描述了 JSON 恳求和响应有效负载的数据类型、HTTP 路径和 HTTP 谓词。HTTP 协议是在 Thrift 模式中使用 Thrift 注解特性定义的。 并非全部 API 调用都会成功。下面的示例模式供应了从处理程序到适当的 HTTP 协议的错误响应。这是通过如下所示的注解来完成的： 还有很多其他注解可以挂念协议管理器使用 thrift 注解管理 HTTP 恳求的行为。 两头件 两头件是栈中最机警、功能最丰富的组件。它允许网关平台向 API 网关用户公开更高阶的特性。我们将在解锁特性一节中具体引见两头件支持的特性。在这里，我们将重点关注 YAML