微服务系统设计：API 网关

API Gateway 是一个 API 管理工具，位于客户端和后端服务集合之间。它是系统的单一入口点，封装了内部系统架构并提供为每个客户端量身定制的 API。它还具有其他职责，例如身份验证、监控、负载平衡、缓存、节流、日志记录等。

微服务提供的 API 粒度通常与客户端所需的不同。微服务通常提供细粒度的 API，这意味着客户端需要与多个服务交互。因此，API 网关可以为所有客户端提供单个入口点，并提供一些附加功能和更好的管理。

特征
以下是 API 网关的一些所需功能：

• 认证和授权

• 服务发现

• 反向代理

• 缓存

• 安全

• 重试和断路

• 负载均衡

• 记录、追踪

• API组成

• 速率限制和节流

• 版本控制

• 路由

• IP白名单或黑名单

优点
让我们看看使用 API Gateway 的一些优势：

• 封装 API 的内部结构。

• 提供 API 的集中视图。

• 简化客户端代码。

• 监控、分析、跟踪和其他此类功能。

缺点
以下是 API 网关的一些可能缺点：

• 可能的单点故障。

• 可能会影响性能。

• 如果缩放不当，可能会成为瓶颈。

• 配置可能具有挑战性。

后端换前端 (BFF) 模式
在后端换前端 (BFF) 模式中，我们创建单独的后端服务以供特定前端应用程序或接口使用。当我们想要避免为多个接口定制单个后端时，这种模式很有用。这种模式首先由Sam Newman描述。
此外，有时微服务返回到前端的数据输出的格式不准确，或者没有按照前端的需要进行过滤。为了解决这个问题，前端应该有一些逻辑来重新格式化数据，因此，我们可以使用 BFF 将一些逻辑转移到中间层。

前端模式的后端的主要功能是从适当的服务中获取所需的数据，格式化数据，并将其发送到前端。

GraphQL作为前端（BFF）的后端性能非常好。

什么时候使用这种模式？
在以下情况下，我们应该考虑使用后端换前端 (BFF) 模式：

• 必须使用大量开发开销来维护共享或通用后端服务。

• 我们希望针对特定客户的要求优化后端。

• 对通用后端进行了定制以适应多个接口。

例子
以下是一些广泛使用的网关技术：

• 亚马逊 API 网关

• Apigee API 网关

• Azure API 网关

• 自己的API 网关

附送幽默图：

JavaScript和python不同写法。
“主语是什么”是一个重要的哲学课题。
“有无主语”、“什么是主语”或“主语是什么”是一个关键哲学课题，会引向不同的节奏。