一次奇妙的邂逅：揭开微服务、API网关和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 服务器。
例子：
客户端 -> API 网关 -> 微服务（用户服务、订单服务等）。
这种方法适用于：
- 编排需求简单的系统。
- 采用依赖项最少、API清晰的微服务设计。
当您需要同时使用 API 服务器和 API 网关时
1）复杂的编曲：
如果多个微服务需要协同工作才能完成请求。
例如：生成一份需要来自用户服务、订单服务和分析服务的数据的报告。
2）集中式业务逻辑：
如果业务逻辑跨越多个微服务。
例如：根据用户历史记录、当前促销活动和支付方式计算折扣。
3）客户简化：
客户端与 API 服务器公开的单个 API 端点进行交互，而服务器则与微服务进行协调。
结论
如果你的微服务可以直接处理请求，你可能不需要 API 服务器。但是，如果业务逻辑复杂且跨越多个服务，API 服务器就派上用场了。API 网关对于路由、安全和系统级任务始终至关重要。
