云原生时代的企业 Java 设计模式 (Chinese Edition)

第 2 章. 云原生 Java的 架构平面

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

传统的企业架构将系统划分为水平层（展示层、业务逻辑层、数据层）。在拥有数十个服务且多个团队并行协作的Cloud原生环境中，这种模型已难以适用。平面模型根据关注点和职责而非技术栈来组织架构，从而将平台工程的关注点与应用程序开发区分开来。

如图 2-1 所示，Cloud 原生架构模型侧重于三个运行时平面，这些平面负责处理应用程序的 运行机制。

图 2-1. 架构 平面

每个平面都被表示为具有特定职责的独立层。这些平面构建在平台层之上，该层为部署、监控和运维提供基础。平台层的详细内容超出了本报告的范围，但我建议您阅读 《平台工程》 （O’Reilly 出版）以获取更多细节。

交互与边缘连接 （前门）

该平面负责管理流量进入系统的方式。在单体应用中，负载均衡器和应用安全约束就已足够。而在微服务架构中，边缘成为了一个复杂的层，负责处理数十个服务之间的身份验证、路由、速率限制和协议转换。外部客户端需要一个稳定的 API，该 API 不会因内部重构而改变。

边缘平面通过提供以下功能来解决这一问题：

• 所有外部流量的单一入口

• 所有服务均采用一致的身份验证和授权机制

• API 版本控制与向后兼容性

• 速率限制与流量控制以防止滥用

• 协议转换（HTTP 转 gRPC，REST 转 GraphQL）

• 请求聚合以降低客户端复杂度

边缘层最重要的组成部分包括：

API 网关（守门人）

作为单一入口点，负责处理速率限制、令牌验证和路由等横切关注点。对于 AI 而言，其关键作用在于成为管理大型语言模型（LLM）令牌成本及强制执行 prompt 安全性的主要控制点。

前端后端（礼宾）

避免使用笨重的企业服务总线（ESB），转而采用轻量级的前端后端（BFF），为特定客户端定制API（例如，针对移动端精简数据，而针对Web端保留丰富数据）。这可防止“过度获取”数据，并允许前端团队独立迭代。

无状态安全（护照）

摒弃粘性会话。采用令牌中继机制，由网关验证 JSON Web Token（JWT）并将其向下传递。服务端仅需验证签名，从而确保零会话状态和无限的水平可扩展性。

执行与通信（运行时）

该平面确保服务能够可靠地进行通信，同时避免将网络代码混入业务逻辑。我们从“智能端点、哑管道”转向“智能管道、智能端点”，并将重试、安全和路由功能委托给基础设施。

执行层提供了实现这一目标的基础设施和模式：

• 服务可在无需了解网络拓扑的情况下进行通信。

• 单个服务发生故障不会波及其他服务。

• 流量可根据负载、版本或其他标准进行智能路由。

• 所有服务间通信均一致地执行安全策略。

• 内置可观测性，支持跨服务追踪请求并衡量性能。

要构建该层，您需要一套技术与实践，以帮助您构建能够可靠、安全且高效地进行通信的服务。

服务网格（Sidecar）模式

服务网格通过在每个服务实例旁部署代理，在基础设施层面上解决了服务间通信的问题（重试、安全、可观测性）。该代理会拦截所有入站和出站流量，并以透明的方式处理这些问题，而非在应用程序代码中处理。对于大规模运行众多服务的组织而言，这是一种强大的工具，但同时也增加了运维复杂性。 ...