内容总结自《微服务架构设计模式》

---

一、API设计难题

1、移动客户端的API设计难题

在此设计中，移动应用程序扮演着API组合器的角色。它调用多个服务并组合结果。尽管这种方法看似合理,但它有几个严重的问题。（虽然书中说这合理，不会真的有微服务架构是这样设计的吧？好呆呀）

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

2、Web 应用程序的API设计难题

传统的服务器端Web应用程序处理来自浏览器的HTTP请求并返回HTML页面，在防火墙内运行并通过局域网访问服务。网络带宽和延迟不是在Web应用程序中实现API组合的障碍。此外，Web应用程序可以使用非 Web友好的协议来访问服务。开发Web应用程序的团队是同一组织的一部分，并且经常与编写后端服务的团队密切合作，因此无论何时更改后端服务，都可以轻松更新Web应用程序。因此，Web应用程序直接访问后端服务是可行的。

3、基于浏览器的JavaScript应用程序的API设计难题

现代浏览器应用程序使用一些JavaScript。即使HTML 主要由服务器端Web应用程序生成，但在浏览器中运行的JavaScript通常会调用服务。

一方面，当服务API发生变化时，基于浏览器的JavaScript应用程序很容易更新。另一方面，通过互联网访问服务的JavaScript应用程序与移动应用程序具有相同的网络延迟问题。更糟糕的是，基于浏览器的用户界面，尤其是桌面用户界面，通常比移动应用程序更复杂，需要组合更多服务。

4、为第三方应用程序设计API

第三方应用程序通过互联网访问API，因此API组合可能效率低下。但是，与设计第三方应用程序使用的API面临的更大问题相比，API组合的低效率是一个相对较小的问题。因为第三方开发人员需要一个稳定的API。

很少有组织可以强制第三方开发人员升级到新的API。具有不稳定API的组织可能会使开发人员加入竞争对手阵营。因此，你必须仔细管理第三方开发人员使用的API的演变。通常你必须长时间维护旧版本（可能永远)。

这个要求对组织来说是一个巨大的负担。让后端服务的开发人员负责维护长期的后向兼容性是不切实际的。组织应该拥有一个由独立团队开发的独立公共API，而不是直接向第三方开发人员公开服务的API。

---

二、API Gateway 模式

1、简介

其实就是抽一层，将前端的组合逻辑抽到统一的一层，这一层就是API Gateway层

API Gateway负责请求路由、API组合和协议转换。来自外部客户端的所有API请求首先转到APl Gateway，后者将一些请求路由到相应的服务。API Gateway使用API组合模式处理其他请求，调用多个服务并聚合结果。它还可以在客户端友好的协议(如HTTP和WebSockets)与客户端不友好的协议之间进行转换。

特点：

1. API组合：API Gateway通常不仅仅是简单地扮演反向代理的角色。它也可能使用API组合实现一些API操作。移动应用程序向API Gateway发出一个请求，该API Gateway从多个服务获取订单详细信息。API Gateway提供粗粒度API，使移动客户端能够通过单个请求检索所需的数据。
2. 协议转换：API Gateway也可以完成协议转换。它可能为外部客户端提供RESTful API，即使应用程序服务在内部使用混合协议，包括REST 和gRPC。在需要时，某些API的操作实现在RESTful外部 API和基于内部的gRPC API之间进行转换。
3. API Gateway能够为每一个客户端提供它们专用的API：API Gateway可以提供单一的万能( one-size-fits-all, OSFA)API。单一API的问题在于不同的客户端通常具有不同的需求。例如，第三方应用程序可能需要Get order DetailsAPI操作以返回完整的order信息；而移动客户端只需要订单的部分数据即可。解决此问题的一种方法是为客户端提供在请求中指定服务器应返回哪些字段和相关对象的选项。这种方法适用于公共API，因为这些API必须为大量的第三方应用程序提供服务，但它通常不会为客户端提供所需的细颗粒度控制。
4. 实现边缘功能：身份验证、访问授权、速率限制、缓存、指标收集（手机有关API的使用情况的指标，可进行分析）、请求日志等

2、所有者模式

谁负责API Gateway的开发及运维？

这个问题有几种不同的答案。

1、由一个单独的团队负责API Gateway。弊端是它与SOA类似，SOA中企业服务总线（ESB）团队负责所有ESB开发。如果从事移动应用程序的开发人员需要访问特定服务，他们必须向API Gateway团队提交请求并等待他们公开API。组织中的这种集中式的瓶颈与微服务架构的理念背道而驰，微服务架构下我们更提倡松散耦合的自治团队。

2、Netflix推出的方法为，让客户端团队(包括移动、Web和公共API团队）拥有与他们有关的API模块并公开API。API Gateway团队负责开发公共模块和API Gateway的运维

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

即前端有移动端、PC端、第三方，这三端在前端团队的工作划分

3、好处和弊端

好处

使用API Gateway的一个主要好处是它封装了应用程序的内部结构。客户端不必调用特定服务，而是与API Gateway通信。APl Gateway为每个客户端提供特定于客户端的API，从而减少客户端和应用程序之间的往返次数。它还简化了客户端代码。

弊端

API Gateway模式也有一些弊端。它是另一个必须开发、部署和管理的高可用组件，但存在成为开发瓶颈的风险。开发人员必须更新API Gateway才能对外公开服务的API。更新API Gateway 的过程尽可能轻量化是非常重要的。否则，开发人员将被迫排队等待更新API Gateway。尽管存在这些弊端，但对于大多数实际应用来说，使用APIGateway是有意义的。如有必要，你可以使用后端前置模式使团队能够独立开发和部署其API。

4、设计问题

1、性能和可扩展性

API Gateway是应用程序的入口。所有外部请求必须首先通过API Gateway。虽然大多数公司的运营规模没有每天处理数十亿个请求的Netflix那么大，但API Gateway的性能和可扩展性通常非常重要。影响性能和可扩展性的关键设计决策是API Gateway应该使用同步还是异步IO。

2、使用响应式编程抽象可维护的代码

如前所述，API组合包括调用多个后端服务。一些后端服务请求完全取决于客户端请求的参数。其他人可能依赖于其他服务请求的结果。一种方法是API端点处理程序方法按照依赖性确定的顺序调用服务。更好的方法是使用响应式方法，以声明式风格编写API组合代码，JVM的响应式抽象包括：

• Java 8 completableFutures
• Project Reactor Monos
• 由Netflix创建的RxJava(用于Java的Reactive Extensions)Observable，专门用于在其API Gateway 中解决此问题
• Scala Futures

3、处理局部异常

除了可扩展之外，API Gateway也必须可靠。实现可靠性的一种方法是在负载均衡器后面运行多个API Gateway实例。如果一个实例失败，负载均衡器会将请求路由到其他实例。

还有一种方法可以提高API Gateway的可靠性，API Gateway需要正确处理可能导致高延迟的请求。当APl Gateway调用服务时，服务总是很慢或不可用。APl Gateway可能会在很长一段时间内(可能无限期地）等待响应，这会消耗资源并堵塞向客户端发送的响应。对失败服务未完成的请求甚至可能消耗宝贵的资源（例如线程)，并最终导致API Gateway无法处理任何其他请求。

4、成为应用程续架构中的好公民

使服务的客户端(如API Gateway)能够确定服务实例的网络位置，以便客户端可以调用服务。可观测性模式使开发人员能够监控应用程序的行为并解决问题。与架构中的其他服务一样，API Gateway 必须实现整个架构中选择的各种模式。

5、实现一个API Gateway

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

• 此选项几乎不需要代码开发，但灵活性最低。例如AWS API Gateway、AWS Application Load Balancer、使用产品化的API Gateway，现成的API Gateway通常不支持API组合。
• 使用API Gateway框架或Web框架作为起点，开发属于自己的API Gateway，这是最灵活的方法，但需要进行一些开发工作。例如Netfix Zuul、Spring Cloud Gateway

---

三、使用GraphQL 实现API Gateway

前面提到的另一个挑战是不同的客户需要稍微不同的数据。例如，与移动应用程序不同，桌面Web应用程序需要显示用户对订单的评级。解决方案可以是，定制接口返回数据的一种方法是让客户端能够指定所需的数据。例如，接口可以支持查询参数，如expand参数，它指定要返回的相关资源，以及field参数，它指定要返回的每个资源的字段。另一种选择是定义此接口的多个版本，作为应用后端前置模式的一部分。对于API Gateway，需要实现众多API接口，这需要做很多工作。

实现支持多种客户端的REST API的API Gateway非常耗时。因此，你可能需要考虑使用基于图形的API框架，例如GraphQL，它旨在支持高效的数据提取

模式（Schema）驱动的 API技术：

两种最流行的基于图形的API技术是 GraphQL 和Netflix Falcor。

Netflix Falcor将服务器端数据建模为虚拟JSON对象图。Falcor客户端通过执行检索该JSON对象属性的查询，从Falcor服务器检索数据。客户端还可以更新属性。在Falcor 服务器中，对象图的属性映射到后端数据源，例如使用REST API 的服务。服务器通过调用一个或多个后端数据源来处理设置或获取属性的请求。

GraphQL 由Facebook开发并于2015年发布，是另一种流行的基于图形的API技术。它将服务器端数据建模为具有字段和对其他对象引用的图形，将对象图映射到后端数据源。GraphQL客户端可以执行检索创建和更新数据的查询。与 Netflix Falcor不同，后者是一种实现，而 GraphQL是一种标准。客户端和服务器可用于各种语言，包括Node.js，Java和 Scala。

Apollo GraphQL是一种流行的JavaScript/Node.js实现。它是一个包含GraphQL服务器和客户端的平台。Apollo GraphQL实现了GraphQL规范的一些强大扩展，例如将更改的数据推送到客户端的子脚本。

就是将原本流程式的后端服务端语言代码，调整为GraphQL的语法，类比为定制化的脚本语言。由配置替代代码，如下图

---

四、总结

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