3. 服务边界定义：什么是服务边界，数据库与缓存之间的所有权划分原则
在分布式系统中，服务边界（Service Boundary）是指一个微服务或功能模块所负责的数据、逻辑与运行时环境的明确范围。边界划分的核心目标是实现高内聚、低耦合，让每个服务拥有独立的生命周期、数据主权和故障域。
当引入缓存层（如 Redis、Memcached）后，服务边界问题变得更加复杂：缓存究竟属于哪个服务？谁有权写入、更新或失效缓存？如果边界模糊，就会引发缓存与数据库之间的数据不一致，这是故障排查中最常见也最难定位的根因之一。
3.1 服务边界的核心要素
一个清晰的服务边界应包含以下三个维度：
| 维度 | 定义 | 边界模糊的后果 |
|---|---|---|
| 数据主权 | 服务对其所管理的数据库表或数据集合拥有唯一的写入权限 | 多个服务同时写同一张表，导致数据冲突与缓存污染 |
| 逻辑归属 | 业务规则、校验、状态转换由该服务独立完成 | 缓存失效逻辑分散在多个服务中，难以追踪 |
| 运行时隔离 | 服务拥有独立的进程、部署单元和资源配额 | 缓存击穿时，依赖方无法独立降级，故障扩散 |
实践要点：服务边界应以“业务实体”而非“技术组件”来划分。例如，“用户服务”拥有用户表的所有权，而“订单服务”只能通过 API 读取用户信息，不能直接操作用户数据库或用户缓存。
3.2 数据库与缓存的所有权划分原则
缓存是数据库的加速副本，不是独立的数据源。因此，缓存的所有权必须与数据库的所有权保持一致。以下是四条核心原则：
- 写者即所有者：只有拥有数据库写入权限的服务，才能写入或失效对应的缓存条目。
- 缓存随库走：缓存 key 的命名空间、生命周期、失效策略由数据库所有者定义，其他服务只能读取。
- 读多写少可共享：对于只读缓存（如配置、字典），可以跨服务共享，但必须由数据所有者发布变更通知。
- 跨边界必须走 API：服务 A 需要更新服务 B 的数据时，必须调用 B 的 API，由 B 负责更新数据库和缓存。
反模式示例：订单服务直接删除用户服务的缓存 key “user:123:profile”，导致用户服务下次读取时从数据库加载旧数据，而订单服务已基于新数据完成操作，造成数据不一致。
3.3 所有权划分的两种典型模式
根据业务场景不同，数据库与缓存的所有权关系可分为以下两种模式：
| 模式 | 描述 | 适用场景 | 一致性风险 |
|---|---|---|---|
| 紧耦合模式 | 缓存与数据库在同一服务内部，由同一代码模块管理 | 高一致性要求、低延迟场景（如库存、余额） | 低：缓存与数据库的更新在同一个事务边界内 |
| 松耦合模式 | 缓存由独立缓存服务管理，数据库服务通过消息或 API 通知缓存变更 | 高并发读取、多服务共享缓存（如商品详情、用户画像） | 中：存在通知延迟或丢失导致的不一致窗口 |
3.4 服务边界与缓存一致性关系图
下图展示了在正确的服务边界划分下，数据库与缓存的所有权关系：
3.5 边界模糊的典型故障场景
当服务边界划分不清晰时，缓存一致性故障会以多种形式出现。以下是最常见的三种：
| 故障模式 | 根因 | 典型表现 | 恢复难度 |
|---|---|---|---|
| 缓存污染 | 非所有者写入缓存，导致数据与数据库不一致 | 用户看到过时或错误的数据，刷新后恢复 | 低：清除缓存即可 |
| 缓存雪崩 | 多个服务共享同一缓存实例，一个服务失效导致全局缓存失效 | 大量请求穿透到数据库，数据库负载飙升 | 高：需要重新设计缓存隔离 |
| 数据回滚不一致 | 服务 A 更新数据库成功，但通知服务 B 失效缓存失败 | 服务 B 的缓存长期保留旧数据，业务决策错误 | 高：需要引入补偿机制或最终一致性方案 |
关键警示：在微服务架构中，缓存边界模糊是导致“幽灵数据”和“数据血案”的首要原因。每次故障排查的第一步，都应该是确认：谁拥有这个缓存？谁有权写入？谁负责失效？ 如果答案不唯一，边界已经失守。
3.6 边界划分的实践检查清单
在设计和评审阶段，可以使用以下清单来验证服务边界是否清晰：
- 数据主权检查：每个数据库表是否只有一个服务拥有写入权限？
- 缓存归属检查：每个缓存 key 是否与一个数据库表或一个服务强绑定？
- 失效路径检查：缓存失效操作是否只由数据所有者触发？
- 跨服务访问检查：服务 A 需要服务 B 的数据时，是否通过 API 而非直接操作数据库或缓存？
- 故障隔离检查：一个服务的缓存故障是否会影响其他服务的正常运行？