导读

• 设计能够支持多种客户端的API的挑战
• 使用API Gateway模式和后端前置模式
• 设计和实现API Gateway
• 使用响应式编程来简化API组合
• 使用GraphQL实现API Gateway

设计应用程序外部API的任务因其客户端的多样性而变得更具有挑战性，不同客户端通常需要不同的数据，拥有单一、适合所有客户端的API通常没有意义。

外部API的设计难题

使用服务API的客户端一共有四种

• Web应用程序
• 在浏览器中运行的JavaScript应用程序
• 移动应用程序
• 由第三方开发人员编写的应用程序

Web应用程序在防火墙内部，可以通过高带宽、低延迟的局域网访问服务，其他客户端在防火墙之外，通过较低的带宽、较高的网络延迟或者移动网络访问服务。

API的一种设计思路是让客户端直接调用服务，但存在以下弊端，很少用于微服务：

• 细颗粒度服务API要求客户端发出多个请求以检索所需的数据，这样做效率低，并且可能导致糟糕的用户体验
• 由于客户端了解每项服务以及服务的API从而导致封装不足（紧耦合），因此今后很难更改服务的架构和API
• 服务可能使用对客户端而言不便或不能使用的进程间通信机制，尤其是防火墙外的客户端

API Gateway模式

API Gateway模式

API Gateway模式：实现一个服务，该服务是外部API客户端进入基于微服务应用程序的入口点

API网关同时负责请求路由、API组合以及协议转换。所有外部客户端的请求都先到达API网关，网关再把部分请求路由给不同的服务。另一部分请求，由API网关使用API组合模式处理，网关分别请求多个服务，并把结果组合起来。同时可能把对客户端友好得协议，比如HTTP和WebSocket转换成客户端不友好的协议。

请求路由

当接收到请求时，API网关将查询路由映射，该路由映射指定将请求路由到哪个服务。例如，路由映射可以将HTTP方法和路径映射到服务的HTTP URL。此功能与NGINX等web服务器提供的反向代理功能相同。

API 组合

比如外卖应用的API网关，可能会实现Get Order Details API 操作。如下图所示，移动应用向API 网关发送一个请求，然后网关向各个服务获取订单的详情。

协议转换

网关向外部客户端提供RESTFul接口，而内服务可能是多种协议混用，比如REST或gRPC。

为每一个客户端提供专用的API

因为不同的客户端对同一对象需要查询的数据不同，所以最好网关对不同类型的客户端提供不同的接口。

实现边缘功能

• 认证：验证请求发起者的身份
• 授权：验证请求发起者有没有权限执行相应的操作
• 限速：限制每秒允许的请求数
• 缓存：用于减少对服务的请求
• 指标收集：收集API使用指标，用于计费分析
• 请求日志：记录请求的日志

API Gateway架构
API网关是一种分层、模块化的架构。

这里展示了两层，API层和通用层。API层由一个或多个独立的API模块构成。每个API模块为一种客户端实现一个API。通用层实现通用功能，包括边缘功能，比如认证。

集中式：API Gateway由独立团队开发和维护

• 客户端调整需要协同API Gateway团队
• 与微服务提倡的松散耦合，团队自治理念背道而驰

所有者模式：API Gateway为每个客户端提供专用API（适合规模较大网关服务）

• 客户端开发团队负责API Gateway的专用API开发和维护，API Gateway团队负责开发公共模块和API Gateway的运维，各个团队可以控制各自的API
• API Gateway的部署流水线必须完全自动化，否则客户端团队必须等API Gateway团队手工更新版本

后端前置模式：为每种类型的客户端实现单独的API Gateway

• API模块彼此隔离，提高了可靠性（如：部署、出现故障）
• 提高可观测性（不同进程的监控）
• 更高的可扩展性
• 提高可部署性

AG三种模式对比

使用AG前后对比

API Gateway的设计难题

性能和可扩展性

• 承载的并发能力（并发连接数、线程数存在上限）
• 必须高可用
• 良好可扩展性

需要使用异步IO模型提高并发，Java提供了很多NIO框架（netty、Spring Reactor、Vertx、JBoss Undertow、NodeJS）

使用响应式编程编写可维护代码

AG服务中使用响应式方法，并发调用其他服务，以提高AG的响应速度。如一个请求在AG里组合调用了其他四个服务，且为顺序调用，那么应该实现四个调用并发执行，在得到所有执行结果再进行组合最终结果返回。

使用传统的异步回调方法编写API组合代码很快会导致“回调地狱”，更好的方法是使用响应式方法：

• Java8 CompletableFutures（CompletableFutures.all(…)）
• Reactors Monos
• Netflix创建的RxJava Observable
• Scala Futures
• 基于NodeJs使用JavaScript promises或RxJS

处理局部故障

• 重试机制：服务失败后的重试
• 熔断器模式：下游服务一直未响应，AG可在一定时间后断开连接并开启熔断
• 失败负载均衡：失败后自动负载到其他服务

可观测性

AG服务的运行状态等数据监控

实现API Gateway

使用现成的API Gateway产品或者服务

• Nginx
• Kong
• Traefik
• APISIX
• AWS Application LoadBalancer
• AWS API Gateway

其中，定制化产品Kong（基于Nginx），实现了身份验证、鉴权、可埋点、路由规则动态配置、负载均衡，需要独立运维和配置。Traefik（Golang编写），类似Kong并支持服务注册发现（基于K8S）。APISIX，支持动态负载平衡、身份验证、限流限速，国产云原生、高性能、可扩展的微服务 API 网关，定制插件开发。

其实如果只需要路由和负载均衡，nginx就够了，如果还需要认证鉴权可以使用Kong。

开发自己的API Gateway

并不难，但需要解决两个关键问题

• 实现定义路由规则的机制以简化代码
• 正确实现HTTP代理行为，包括如何处理HTTP header

因此，开发API Gateway更好的起点是使用满足上述目的的框架，可以显著减少代码量。

• Netfix Zuul：实现了响应式，NIO线程模型，支持路由、速率限制和身份验证等功能，但只支持基于path路由
• SpringCloud Gateway：底层基于Project Reactor，实现了响应式，NIO线程模型，支持API组合

使用GraphQL实现API Gateway

GraphQL是一种基于图像的API框架，其旨在支持高效的数据提取。

好处

• 客户端能够控制返回的数据，使得开发一个用来支持不同客户需求的灵活单一API可行
• API更灵活，显著减少开发的工作量

GraphQL API以模式（Schema）为中心，模式由一组类型组成，这些类型定义了服务器端数据模型的结构，以及客户端可以执行的操作（如查询）。

关键部分

• GraphQL模式：定义服务器端数据模型及其支持的查询
• 解析器函数：解析函数将模式的元素映射到各种后端服务
• 代理类：代理类调用FTGO应用程序的服务

小结

• 应用程序的外部客户端通常利用API Gateway访问应用程序的服务。API Gateway为每个客户端提供自定义API。它负责请求路由、API组合、协议转换以及边缘功能（如身份验证）的实现。
• 应用程序可以具有单个API Gateway，也可以使用后端前置模式，该模式为每种类型的客户端定义API Gateway。后端前置模式的主要优点是它为客户端团队提供了更大的自主权，因为他们可以开发、部署和运维自己的API Gateway。
• 可以使用许多种技术来实现API Gateway，包括现成的API Gateway产品。或者，也可以使用框架开发自己的API Gateway。
• Spring Cloud Gateway是一个易于使用的良好框架，用于开发API Gateway。它使用任何属性（包括方法和路径）路由请求。Spring Cloud Gateway可以将请求直接路由到后端服务或自定义处理程序方法。它采用可扩展、响应式的Spring Framework 5 和Project Reactor框架构建。可以使用，例如，Project Reactor的Mono抽象，以响应式风格编写自定义请求处理程序。
• GraphQL是一个提供基于图形的查询语言框架，是开发API Gateway的另一个很好的基础。你可以编写一个面向图形的模式来描述服务端数据模型及其支持的查询。然后，通过编写检索数据的解析器，将该模式映射到你的服务。基于GraphQL的客户端对模式执行查询，该模式准确指定服务器应返回的数据。因此基于GraphQL的API Gateway可以支持不同的客户端。