设计微服务架构时如何划分服务边界…

在拆分单体或设计分布式系统时，按 DDD 划分服务边界并落地通信、数据、容错、可观测与部署方案。

适用场景

解决思路

1. 领域分析：应用 DDD 识别限界上下文与服务边界；校验每个候选服务独占其数据、有清晰公开 API 契约、可独立部署。
2. 通信设计：选择同步/异步模式与协议（REST、gRPC、事件）；校验长耗时或跨聚合操作使用异步消息，仅亚 100ms SLA 的查询/命令对使用同步调用。
3. 数据策略：采用每服务独立数据库、事件溯源、最终一致性；校验服务间不存在共享数据库 schema，一致性边界与限界上下文对齐。
4. 容错设计：为每个外部调用配置熔断器、重试、超时、舱壁隔离、降级回退；校验每次外部调用都有显式超时、重试预算和优雅降级路径。
5. 可观测性：实现分布式追踪、关联 ID、集中式日志；校验单个请求可通过其关联 ID 在所有服务间端到端追踪。
6. 部署：使用容器编排、服务网格、渐进式交付；校验已定义健康与就绪探针，并记录金丝雀或蓝绿发布策略。
7. 按上下文加载参考文档：服务边界看 references/decomposition.md，通信看 references/communication.md，容错模式看 references/patterns.md，数据管理看 references/data.md，可观测性看 references/observability.md。
8. 关联 ID 中间件（Node.js/Express）：从 x-correlation-id 请求头读取或生成 uuid，写回响应头，并绑定到 logger 上下文；在所有出站 HTTP 调用和 Kafka 消息头中传播 x-correlation-id。
9. 熔断器（Python/pybreaker）：用 pybreaker.CircuitBreaker(fail_max=5, reset_timeout=30) 配置 5 次失败后打开、30 秒后半开重置；被装饰的调用设置 timeout=2 并 raise_for_status；捕获 CircuitBreakerError 时返回降级结果。
10. Saga 编排骨架（TypeScript）：定义含 execute() 与 compensate() 的 SagaStep 接口；runSaga 顺序执行步骤并记录已完成步骤，任一步失败则逆序调用已完成步骤的 compensate() 后抛出异常；例如订单创建 saga 使用 reserveInventoryStep、chargePaymentStep、scheduleShipmentStep。
11. Kubernetes 健康与就绪探针：livenessProbe 指向 /health/live（进程存活返回 200），readinessProbe 指向 /health/ready（仅在可服务流量、DB 已连接、缓存已预热时返回 200），并配置 initialDelaySeconds 与 periodSeconds。
12. 必须做：用 DDD 划分服务边界、每服务独立数据库、外部调用加熔断器、所有请求加关联 ID、跨聚合操作用异步通信、为失败与优雅降级设计、实现健康检查与就绪探针、使用 API 版本化策略。
13. 禁止做：制造分布式单体、服务间共享数据库、长耗时操作使用同步调用、跳过分布式追踪、忽视网络延迟与部分失败、设计话痨式服务接口、无正确模式地存储共享状态、无可观测性就部署。
14. 输出架构设计时提供：带限界上下文的服边界图、通信模式（同步/异步与协议）、数据归属与一致性模型、每个集成点的容错模式、部署与基础设施需求。

适用边界 · 注意事项

• 不适用于单体应用内部模块划分或无需独立部署的小型系统
• 不适用于无法承担分布式系统运维复杂度（服务网格、分布式追踪、多数据库）的团队
• 不适用于对强一致性有硬性要求、无法接受最终一致性的场景