架构模式: API网关

时间 2019-11-14

标签架构模式 api 网关栏目系统架构繁體版

原文原文链接

模式: API网关

让咱们假设您正在构建一个使用Microservice体系结构模式的在线商店，而且您正在实现产品详细信息页面。您须要开发产品详细信息用户界面的多个版本：html

此外，在线商店必须经过REST API公开产品详细信息，以供第三方应用程序使用。
产品详细信息UI能够显示有关产品的大量信息。例如，POJO in Action的Amazon.com详细信息页面显示：前端

因为在线商店使用微服务架构模式，所以产品详细信息数据分布在多个服务上。例如，java

所以，显示产品详细信息的代码须要从全部这些服务中获取信息。git

基于微服务的应用程序的客户端如何访问各个服务？github

微服务提供的API的粒度一般与客户端所需的不一样。微服务一般提供细粒度的API，这意味着客户端须要与多个服务进行交互。例如，如上所述，须要产品细节的客户端须要从众多服务中获取数据。spring
不一样客户须要不一样的数据。例如，产品详细信息页面桌面的桌面浏览器版本一般比移动版本更精细。后端
不一样类型的客户端的网络性能不一样。例如，移动网络一般比非移动网络慢得多且具备更高的延迟。固然，任何WAN都比LAN快得多。这意味着本机移动客户端使用的网络与服务器端Web应用程序使用的LAN具备很是不一样的性能特征。服务器端Web应用程序能够对后端服务发出多个请求，而不会影响用户体验，由于移动客户端只能作一些。api
服务实例的数量及其位置（主机+端口）动态变化浏览器
对服务的分区可能会随着时间的推移而发生变化，应该从客户端隐藏安全
服务可能使用各类协议，其中一些协议可能不适合Web

实现API网关，它是全部客户端的单一入口点。API网关以两种方式之一处理请求。有些请求只是代理/路由到适当的服务。它经过扇出多个服务来处理其余请求。

API网关能够为每一个客户端公开不一样的API，而不是提供一个通用的样式API。例如，Netflix API网关运行特定于客户端的适配器代码，该代码为每一个客户端提供最适合其要求的API。

API网关也能够实现安全性，例如验证客户端是否有权执行请求

此模式的变体是前端模式的后端。它为每种客户端定义了一个单独的API网关。

在此示例中，有三种客户端：Web应用程序，移动应用程序和外部第三方应用程序。有三种不一样的API网关。每一个都为其客户提供API。

使用API网关具备如下好处：

将客户端与应用程序分区为微服务的方式隔离，使客户端免于肯定服务实例位置的问题为每一个客户端提供最佳API减小请求/往返次数。例如，API网关使客户端可以经过单次往返从多个服务中检索数据。
更少的请求也意味着更少的开销并改善用户体验。
API网关对于移动应用程序相当重要。经过将用于调用多个服务的逻辑从客户端移动到API网关来简化客户端从“标准”公共Web友好API协议转换为内部使用的任何协议

API网关模式有一些缺点：

复杂性增长 - API网关是必须开发，部署和管理的另外一个移动部分因为经过API网关额外的网络跳跃而增长了响应时间 - 可是，对于大多数应用程序而言，额外往返的成本是微不足道的。

问题:

如何实现API网关？事件驱动/被动方法最好是必须按比例扩展以处理高负载。在JVM上，基于NIO的库（如Netty，Spring Reactor等）是有意义的。NodeJS是另外一种选择。