微服务、API网关与API服务器：一次好奇的相遇

这一切始于我工作中的一次常规代码审查。我正在审查一个最近刚上线的功能。任务很简单：用户仪表板需要整合来自多个服务的数据，比如用户信息、订单历史和通知。我们的系统采用了微服务架构，并且已经部署了 API 网关。但是，还有一个 API 服务器在协调整个流程。

我不禁想：为什么我们要在这边写这段业务逻辑？微服务直接处理不是更好吗？既然API网关已经处理了请求路由，我们还需要API服务器干嘛呢？

那个挥之不去的想法整天都让我心里不自在。后来在团队讨论中，我提了出来。

“如果我们的微服务已经自包含并且负责业务逻辑处理，为什么我们在API服务器端还要重复或集中处理一些业务逻辑？这不与微服务的理念相违背吗？在这种情况下，API网关的具体作用是什么？”

一些关键概念：

微服务：

每个微服务都专注于特定的业务功能（例如，如用户、订单和支付服务）。
它们各自独立，封装了自身的业务规则和数据库。

API网关:

客户端请求的集中处理点。
负责路由、认证、限流、负载均衡，有时也做响应聚合。
它不处理业务逻辑，但确保客户端和微服务之间的顺畅通信。

API服务:

可能存在于 API 网关和微服务之间的中间层。
通常用于正在向微服务转型的系统，或者业务逻辑过于复杂，不适合由微服务直接处理的情况。

为什么要用API服务器配合微服务架构？

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

有时候，你需要一个用来结合的层来结合来自多个微服务的数据或功能。
而不是将复杂的编排逻辑嵌入到客户端或微服务中，API 服务器起到中介的作用。
示例：
你有一个用户服务和一个订单服务。为了展示用户的仪表板，你需要结合这两个服务的数据。API 服务器协调这些调用并合并响应。

2). 遗留支持或逐步迁移
在从单体架构过渡到微服务架构的系统中，API 服务器可能仍然处理一些业务逻辑，直到迁移完成为止。
示例 :
一个单体应用正在被拆分成微服务组件，但 API 服务器仍然处理用户认证逻辑，直到创建专门的用户认证服务为止。

3). 客户端抽象
API 服务器可以向客户端提供统一的 API，简化多个微服务的复杂性。
例如：
客户端不再分别调用这些接口（/users、/orders 和 /notifications），而是调用 /dashboard，API 服务器协调各个微服务。

来看这张图片：

API网关到底做了什么呢？

API网关专注于跨领域的问题，并提供系统级功能。它的角色是补充API服务器，而不是与其重叠。

API网关的责任:

1). 路由:
把请求送到正确的微服务或 API 服务器端。

2).身份验证和授权:
验证令牌或API密钥后转发请求。

3). 速率限制和流量控制:
确保没有任何客户端会压垮系统。

4).缓存:
通过缓存响应来减轻微服务系统的负担。

5).负载均衡：
将流量分配给服务的多个副本。

6).请求转换:
转换传入的请求或修改响应（例如，把XML转换成JSON）。

（这是一张图片，点击可以查看。）

当你不用操心 API 服务器的时候

如果你的微服务完全独立且轻量，API网关可以直接将客户端请求路由到这些微服务，从而不需要单独的API服务器。

例子：

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

这种方法适用于以下情况：

• 需求简单编排的系统。
• 设计时依赖最少且API明确的微服务。

当你既需要 API 接口服务器又需要 API 网关

1). 复杂的调度:

如果多个微服务需要一起工作来完成一个请求。
例如：生成报告需要从用户、订单和分析服务中收集数据。

2). 集中式业务逻辑

如果业务逻辑涉及多个微服务。
例如：根据用户的购买历史、当前的促销活动和付款方式来计算折扣。

3). 简化客户:

客户通过API服务器暴露的单一端点与之交互，而服务器负责协调各微服务。

结论：

如果你的微服务可以直接处理请求，你可能就无需使用API服务器了。然而，如果有复杂的业务逻辑横跨多个服务，一个API服务器就很有用了。API网关在路由、安全和系统级任务方面总是不可或缺的。