奇妙的邂逅：揭秘微服务、API 网关和 API 服务器的角色

这一切都始于我工作中的一次例行代码审查。当时我正在审查最近实现的一项功能。任务很简单：用户仪表板需要从多个服务中提取数据 - 用户信息、订单历史记录和通知。我们的系统已经建立在微服务架构上，并且我们已经有一个 API 网关。然而，它就在那里：API 服务器在协调整个过程。

我不禁想问：我们为什么要在 API 服务器中编写这个业务逻辑？微服务不应该直接处理这个问题吗？如果 API 网关已经在路由请求，为什么我们还需要 API 服务器？

这个想法萦绕了我一整天。后来，在一次团队讨论中，我提出了这个问题。我问道：

“如果我们的微服务已经是自包含的并能处理业务逻辑，为什么我们要在 API 服务器中复制或集中部分内容？这难道不与微服务的理念相矛盾吗？在这种设置中，API 网关的作用到底是什么？”

关键概念：

微服务：

每个微服务负责特定的业务能力（例如用户服务、订单服务、支付服务）。

微服务是独立的，封装了自己的业务逻辑和数据库。

API 网关：

客户端请求的集中入口点。

处理路由、身份验证、速率限制、负载平衡以及有时的响应聚合。

它不实现业务逻辑，但确保客户端和微服务之间的顺畅交互。

API 服务器：

API 网关和微服务之间可能存在的层。

通常用于过渡到微服务的系统或业务逻辑过于复杂而无法由微服务直接处理的系统。

为什么要与微服务一起使用 API 服务器？

**1). 复杂用例的集中逻辑**

有时，您需要一个层来组合来自多个微服务的数据或功能。

API 服务器充当中介，而不是在客户端或微服务中嵌入复杂的编排逻辑。

**例子**：

您有一个用户服务和一个订单服务。要显示用户的仪表板，您需要合并两者的数据。API 服务器会协调这些调用并合并响应。

**2). 旧版支持或逐步迁移**

在从单片架构过渡到微服务架构的系统中，API 服务器可能仍会包含一些业务逻辑，直到迁移完成。

**例子**：

单体应用程序正在被分解为微服务，但 API 服务器仍处理用户身份验证逻辑，直到创建专用服务。

**3). 客户端抽象**

API Server可以向客户端暴露统一的API，抽象多个微服务的复杂性。

**例子**：

客户端不再单独调用/users、/orders、/notifications，而是调用/dashboard，API Server 与微服务进行协调。

那么 API 网关做什么？

API 网关专注于横切关注点并提供系统范围的功能。它的作用是对 API 服务器的补充，而不是与 API 服务器重叠。

**API网关职责：**

**1).路由：**

将请求定向到正确的微服务或 API 服务器。

**2).身份验证和授权：**

转发请求之前验证令牌或 API 密钥。

**3).速率限制和节流：**

确保没有客户端导致系统超载。

**4).缓存：**

通过缓存响应来减少微服务的负载。

**5).负载平衡：**

在服务的多个实例之间分配流量。

**6).请求转换：**

转换传入的请求或修改响应（例如，转换

XML 到 JSON 的转换)。

当你不需要 API 服务器时

如果您的微服务完全独立且轻量级，则 API 网关可以直接将客户端请求路由给它们，从而无需 API 服务器。

**例子**：

客户端->API网关->微服务（用户服务、订单服务等）。

此方法适用于：

当您同时需要 API 服务器和 API 网关时

**1). 复杂编排：**

如果多个微服务必须协同工作才能满足请求。

示例：生成需要来自用户、订单和分析服务的数据的报告。

**2). 集中式业务逻辑：**

如果业务逻辑跨越多个微服务。

示例：根据用户历史记录、当前促销和付款方式计算折扣。

**3). 客户端简化：**

客户端与 API 服务器公开的单个 API 端点交互，而服务器则与微服务协调。

结论

如果您的微服务可以直接处理请求，则可能不需要 API 服务器。但是，如果有跨多个服务的复杂业务逻辑，则 API 服务器会很有用。API 网关对于路由、安全性和系统范围的任务始终必不可少。