API网关与微服务之间关注点分离的探讨

API网关与微服务之间关注点分离的探讨

在现代软件架构中，API网关和微服务的结合是一个备受关注的话题。许多人认为，API代理服务，还应该作为进入内部安全和隐私边界的保护屏障，用于防止对微服务的非必要外部访问。这种观点的核心在于：微服务应专注于业务逻辑，而API网关则负责处理与业务核心无关的事务。

从讨论中学到的两点关键认知

在关于API网关角色的讨论中，可以总结出两点重要的认知：

1. 技术性问题可能是业务的核心：一些看似技术性或外围性的担忧，实际上可能直接影响到业务的核心。
2. 安全和隐私架构的分层模型：安全和隐私架构更像是“洋葱”而非“鸡蛋”，需要多层次的保护，而非简单的内外分隔。

安全和隐私问题往往被视为服务的外部保护层，但实际上，它们应该是系统设计中不可或缺的一部分。客户通常不会直接讨论安全和隐私问题，但他们期望系统能够提供足够的保护。

高级架构方法的局限性

在典型的高级架构中，安全和隐私通常被视为内部和外部屏障。然而，这种方法存在明显的局限性。隐私和安全并不是简单地添加到服务中的功能，而是需要从系统设计阶段就进行深度整合。例如，在欧洲，未能妥善处理安全和隐私问题可能会违反GDPR（《通用数据保护条例》）。

虽然分层建模安全和隐私架构是可行的，但过于简化可能会带来问题。例如，在授权框架中，这种局限性尤为明显。

OAuth2架构与API网关的角色

以下是构建微服务时典型的OAuth2架构示例：

在Spring Cloud Gateway）通常被视为应用程序代理，其主要职责是转发请求，而非执行授权。这是因为授权本质上是一个业务问题，涉及到根据业务规则定义用户和应用程序的访问权限。

隐私和模式验证同样如此，虽然它们的实现可能涉及技术细节，但核心问题仍然是业务逻辑。因此，传统上，这些问题并不是由API网关来解决的。

API网关的适用场景与边界

尽管如此，API网关在某些场景中仍然扮演着重要角色。例如：

• API组合：将多个服务的响应组合成一个统一的API响应。
• mTLS终止：在网关层处理双向TLS认证。

这些功能正是API网关设计的初衷，适合在网关层解决。然而，试图让API网关承担更多职责，例如根据mTLS客户端证书中的信息进行授权请求或根据业务规则生成响应，可能会导致架构的复杂化，甚至引发潜在问题。

结论：保持关注点分离

为了避免架构上的混乱和潜在的破坏性问题，建议遵循以下原则：

“让你的网关保持沉默，让你的服务保持智能。”

通过将API网关的职责限制在其设计范围内，并将业务逻辑交由微服务处理，可以确保系统的稳定性和可维护性。

原文链接: https://medium.com/@sydseter/the-separation-of-concerns-between-api-gateway-and-microservice-d9dbce6f1cc8