Microservices (Deep Workflow)
Microservices trade code simplicity for operational and contract complexity. Justify each boundary with ownership and data isolation—not fashion.
When to Offer This Workflow
Trigger conditions:
- - Splitting the monolith; coupling blocks independent deploys
- Latency cascades, partial failures, contract breaks
- Conway’s law alignment between teams and services
Initial offer:
Use six stages: (1) goals & constraints, (2) boundaries & data ownership, (3) integration patterns, (4) contracts & versioning, (5) reliability patterns, (6) ops & governance). Confirm org maturity and platform capabilities.
Stage 1: Goals & Constraints
Goal: Why not a modular monolith first?
Valid drivers
- - Independent deploy cadence per team
- Different scaling profiles or stacks
- Clear domain ownership and blast-radius isolation
Costs
- - Distributed transactions, harder debugging, broader test matrix
Exit condition: Explicit assumption that modular monolith was considered.
Stage 2: Boundaries & Data Ownership
Goal: One service owns each aggregate’s write path; no shared writable tables across services.
Practices
- - Bounded contexts from DDD when helpful
Exit condition: Entity → owning service map.
Stage 3: Integration Patterns
Goal: Sync HTTP/gRPC vs async events—match consistency needs.
Patterns
- - Sagas or outbox for multi-step business processes
Exit condition: Sequence diagrams for top three flows.
Stage 4: Contracts & Versioning
Goal: Backward-compatible evolution; consumer-driven contracts optional.
Practices
- - Deprecation policy published
Stage 5: Reliability Patterns
Goal: Timeouts, retries with backoff, circuit breakers, bulkheads; idempotent handlers for retries.
Stage 6: Ops & Governance
Goal: Service catalog, SLIs on dependency edges, golden paths for new services.
Final Review Checklist
- - [ ] Boundary and data ownership clear
- [ ] Integration style matches consistency needs
- [ ] Contract versioning policy exists
- [ ] Reliability patterns applied at boundaries
- [ ] Ops ownership and catalog in place
Tips for Effective Guidance
- - Microservices without delivery maturity often fail—say so explicitly.
- Shared databases are hidden coupling—flag them.
- The network is not reliable—design for partial failure.
Handling Deviations
- - Small teams: strong bias toward modular monolith or few services.
微服务(深度工作流)
微服务以代码简洁性换取运维与契约复杂性。每个服务边界的划分必须基于所有权和数据隔离——而非追逐潮流。
何时提供此工作流
触发条件:
- - 拆分单体架构时,耦合阻碍独立部署
- 出现延迟级联、部分故障、契约断裂
- 团队与服务的组织架构需遵循康威定律对齐
初始建议:
采用六个阶段:(1)目标与约束、(2)边界与数据所有权、(3)集成模式、(4)契约与版本管理、(5)可靠性模式、(6)运维与治理。确认组织成熟度与平台能力。
阶段1:目标与约束
目标: 为何不优先考虑模块化单体架构?
合理驱动因素
- - 各团队需要独立部署节奏
- 存在不同扩缩容需求或技术栈
- 清晰的领域所有权与故障隔离范围
成本
退出条件: 明确已评估模块化单体架构方案。
阶段2:边界与数据所有权
目标: 每个服务拥有对应聚合的写入路径;服务间不共享可写数据表。
实践
退出条件: 实体→所属服务映射关系图。
阶段3:集成模式
目标: 同步HTTP/gRPC与异步事件——匹配一致性需求。
模式
退出条件: 前三大核心流程的时序图。
阶段4:契约与版本管理
目标: 向后兼容演进;可选消费者驱动契约。
实践
阶段5:可靠性模式
目标: 超时机制、带退避的重试、断路器、隔板模式;幂等处理器支持重试。
阶段6:运维与治理
目标: 服务目录、依赖边界的服务等级指标、新服务的黄金路径。
最终审查清单
- - [ ] 边界与数据所有权清晰
- [ ] 集成方式匹配一致性需求
- [ ] 存在契约版本管理策略
- [ ] 边界处应用可靠性模式
- [ ] 运维所有权与目录已就位
有效指导技巧
- - 缺乏交付成熟度的微服务往往失败——请明确告知。
- 共享数据库是隐藏的耦合——务必指出。
- 网络不可靠——需为部分故障设计。
处理偏差