12、微服务架构中的解耦与数据管理策略

微服务架构中的解耦与数据管理策略

1. 微服务架构的解耦目标

微服务架构的一个重要设计目标是实现高度解耦，常体现为“复制优于耦合”的建议。例如，两个服务在传递客户信息时，为遵循领域驱动设计的边界上下文，可让每个服务有自己的实体内部表示，以松散耦合的方式传递信息，如使用 JSON 中的名值对。这样每个服务能随意更改内部表示，包括技术栈，而不影响集成。在微服务架构中，对于“是否复制或耦合某些功能”的问题，答案往往是复制；而在基于服务的架构中，答案可能是耦合，这取决于具体情况。

2. 操作能力的耦合挑战与 Sidecar 模式

在设计微服务时，为保持解耦，架构师会接受实现复制的现实。但对于监控、日志记录、认证授权等需要高耦合的操作能力，若让每个团队管理这些依赖，容易陷入混乱。例如，公司要统一监控解决方案，若各团队自行实现，运维团队难以确保其一致性，统一升级也会面临协调难题。

为解决此问题，微服务生态系统中出现了基于六边形架构（Hexagonal architecture）的 Sidecar 模式。六边形架构将领域逻辑与技术耦合分离，把数据库视为可插拔的适配器，而领域驱动设计认为数据模式和事务性应在内部，这与微服务类似。

Sidecar 模式借鉴了六边形架构的概念，将领域逻辑与技术（基础设施）逻辑解耦。在微服务中，每个服务可将操作关注点和领域关注点分离，若架构师希望操作能力保持一致，可将可分离部分放入 Sidecar 组件。该组件的实现可由团队共同负责或由中央基础设施组管理。若每个服务都包含 Sidecar，就可通过服务平面形成一致的操作接口，进而构成服务网格（Service Mesh）。

服务网格使架构师和 DevOps