微服务架构设计模式笔记--第八章 外部API模式

1. 外部API设计难题

设计应用程序外部API的任务因其客户端的多样性而变得更具挑战性。不同客户端通常需要不同的数据。通常，基于桌面浏览器的用户界面显示的信息远远多于移动应用程序。此外，不同的客户端通过不同类型的网络访问服务。防火墙内的客户端使用高性能局域网，防火墙外的客户端使用性能较低的互联网或移动网络。因此，你会发现，拥有单一、适合所有客户端的API通常没有意义。

存在的问题：

• 多次客户端请求导致用户体验不佳
• 缺乏封装导致前端开发做出的代码修改影响后端
• 服务可能选用对客户端不友好的进程间通信机制

2. API Gateway模式功能

• 请求路由
  API Gateway通过将请求路由到相应的服务来实现一些API操作。当它收到请求时，API Gateway会查询路由映射，该映射指定将请求路由到哪个服务。例如，路由映射可以将HTTP方法和路径映射到服务的HTTP URL。此功能与NGINX等Web服务器提供的反向代理功能相同。
• API组合
  使用API组合实现一些API操作。应用程序向API Gateway发出一个请求，该API Gateway从多个服务获取信息，组合后返回。
• 协议转换
  为外部客户端提供RESTful API，即使应用程序服务在内部使用混合协议，包括REST和gRPC。在需要时，某些API的操作实现在REST ful外部API和基于内部的gRPC API之间进行转换。
• 为不同的客户端提供专用的API
  API Gateway可以提供单一的万能API。单一API的问题在于不同的客户端通常具有不同的需求。
• 实现边缘功能
  应用程序可能实现的边缘功能包括：
  身份验证：验证发出请求的客户端身份。
  访问授权：验证客户端是否有权执行该特定操作。
  速率限制：限制特定客户或所有客户端每秒的请求数。
  缓存：缓存响应以减少对服务的请求数。
  指标收集：收集有关API使用情况的指标，以进行计费分析。
  请求日志：记录请求历史。
• 后端前置模式
  后端只提供公共API接口，前端团队可以根据自己需求，通过node开发自己的api接口组合。
  

3. 实现一个API Gateway

开发API Gateway并不是特别困难。它本质上是一个代理其他服务请求的Web应用程序。你可以使用自己喜欢的Web框架构建一个。但是，你需要解决两个关键设计问题：

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

因此，开发API Gateway更好的起点是使用满足上述目的的框架。框架中内置的功能可显著减少你需要编写的代码量。

3.1 自己开发一个

洗洗睡吧。

3.2 使用Zuul

Netflix开发了Zuul框架来实现边缘功能，例如路由、速率限制和身份验证。Zuul框架使用过滤器的概念，可重用的请求拦截器类似于Servlet过滤器或Node.js Express中间件。Zuul通过组合一系列适用的过滤器来处理HTTP请求，然后转换请求，调用后端服务，并在响应发送回客户端之前转换响应。
Zuul处理路由和边缘功能。你可以通过定义实现API组合的Spring MVC控制器来扩展Zuul。但Zuul的一个主要限制是它只能实现基于路径的路由。例如，它无法将GET/orders路由到一个服务，将POST/orders路由到另一个服务。因此，Zuul不支持第7章中描述的查询架构。
目前Zuul停止维护了，不建议继续使用。

3.3 使用spring Cloud Gateway

Spring Cloud Gateway项目是一个基于多个框架（包括 Spring Framework 5、Spring Boot 2 和 Spring Webflux)构建的 API Gateway框架，属于响应式Web框架，是Spring Framework5的一部分，构建在Project Reactor之上。
Project Reactor是一个基于NIO的JVM响应式框架，它提供了本章稍后使用的Mono抽象。
Spring Cloud Gateway提供了一种简单而全面的方法来执行以下操作：

• 将请求路由到后端服务。
• 实现执行API组合的请求处理程序。
• 处理边缘功能，例如身份验证。

Mono是一个异步请求，多个微服务请求返回Mono，组合后操作后返回结果，避免同步等待。

3.4 使用GraphQL实现APIGateway

用基于图形的API框架GraphQL，它旨在支持高效的数据提取。基于图形的API框架的关键思想是，如图所示，服务器的API由基于图形的模式组成。基于图形的模式定义了一组节点（类型）,它们具有属性（字段）和与其他节点的关系。客户端通过执行查询）检索数据，该查询根据图的节点及其属性和关系指定所需的数据。因此，客户端可以在API Gateway的单次往返中检索所需的数据。
基于图形的API技术有几个重要的好处。它使客户能够控制返回的数据。这就使开发一个用来支持不同客户需求的灵活单一的API变得可行。另一个好处是，即使API更灵活，这种方法也可以显著减少开发的工作量。因为在编写服务器端代码时，我们使用的框架内建了对API组合和映射查询的支持。这就好像，不是客户端强迫你编写和维护各种存储过程来检索数据，而是让客户端直接对底层数据库执行查询。
GraphQL是一个提供基于图形的查询语言框架，是开发API Gateway的另一个很好的基础。你可以编写一个面向图形的模式来描述服务器端数据模型及其支持的查询。然后，通过编写检索数据的解析器，将该模式映射到你的服务。基于GraphQL的客户端对模式执行查询，该模式准确指定服务器应返回的数据。因此，基于GraphQL的 API Gateway 可以支持不同的客户端。