读书笔记：微服务设计
Building Microservices
- 是什么（What）：
- 从业务边界、组织结构、通信、数据、部署、测试、安全、韧性和演进等方面，说明如何构建可
独立发布的微服务系统
- 从业务边界、组织结构、通信、数据、部署、测试、安全、韧性和演进等方面，说明如何构建可
- 为什么（Why）：
- 微服务的目标不是追求小，而是降低变更的
协调成本；只有服务与团队都具备自治能力，分布式成本才可能换来更快、更安全的交付
- 微服务的目标不是追求小，而是降低变更的
- 怎么做（How）：
- 围绕业务领域建立边界，以
独立部署为核心约束，用信息隐藏降低耦合，以自动化交付和可观测性支撑运行，并通过渐进迁移持续校正设计
- 围绕业务领域建立边界，以
核心观点：
微服务是围绕业务领域建模、能够独立发布的一组服务。
- 独立发布能力是微服务的核心，而不是服务足够小
- 每个服务应能独立构建、测试、部署和回滚，避免锁步发布；接口变更必须向后兼容
- 微服务用分布式系统的复杂性换取并行交付，若没有明确的交付、扩展或故障隔离收益，就不应采用
- 如果服务不能在不协调其他服务发布的情况下安全上线，就还没有获得微服务的核心收益
- 好的服务边界围绕业务领域，并通过信息隐藏降低耦合
- 以业务能力和限界上下文划分服务，让一起变化的行为与数据保持高内聚
- 服务大小没有统一标准；一个边界清晰的较大服务，优于多个需要频繁协同的小服务
- 系统架构与组织结构必须对齐
- 康威定律使系统通信结构映射组织沟通结构，因此应由跨职能团队端到端拥有服务
- 自治不等于自由放任：平台团队提供通用能力，组织统一交付、安全和可观测性底线，而非统一所有技术细节
- 分布式系统要求把交付、故障和观测能力内建到架构中
- 同步与异步通信会产生不同耦合；数据所有权、最终一致性、超时、幂等、隔离和降级都必须显式设计
- 自动化测试、持续交付、结构化日志、指标、追踪、SLO 和纵深安全是微服务的采用前提
- 微服务应从单体渐进演化，而不是大爆炸重写
- 先改善模块化和交付能力，再用 Strangler Fig 按实际瓶颈逐步抽取服务，并允许边界继续拆分、合并和调整
- 当团队小、领域边界不清或运维能力不足时，模块化单体通常是成本更低、可逆性更好的选择
启发点（关键洞察）：
- 微服务优化的是组织的变更吞吐量：它牺牲单机调用、事务和调试的简单性，换取多个团队并行交付；没有并行交付需求时，收益很弱
- 服务越小不代表架构越好：过细边界会把一次本地函数调用变成需要版本治理、监控和容错的远程协作
- 自治不等于自由放任：真正有效的自治建立在明确所有权、自助平台和少量强约束之上
- 独立部署是耦合的可执行测试：代码依赖图可能看起来合理，但发布时是否需要协调才揭示真实耦合
- 先修复交付能力，再拆系统：自动化测试、CI/CD 和可观测性既是微服务前提，也常常能直接缓解原本归咎于单体的问题
- 数据边界比 API 边界更重要：只拆应用、不拆所有权，会留下一个所有服务共同依赖的数据库单体
- 组织和架构必须共同演进：让按技术职能划分的团队共同维护业务服务，跨团队交接会抵消微服务的自治收益
- 模块化单体是有效选项，不是失败状态：当边界尚在探索或分布式收益不明确时，它保留了低成本重构能力
行动：
- 在决定拆分前记录期望改善的指标，如部署频率、变更前置时间、故障恢复时间、独立扩展成本，并设置复盘点
- 以业务能力和变更模式绘制服务候选边界，同时标注团队、数据和外部依赖，检查是否出现跨边界高频协作
- 把
可独立部署写入服务验收标准：兼容契约、独立流水线、独立回滚、无共享数据库写入 - 建立统一的 service template / paved road，内置日志、指标、追踪、健康检查、安全基线和部署配置
- 对每条同步调用评估超时、失败语义与降级路径；对每条异步链路评估幂等、顺序、积压和重放
- 先用模块化单体验证领域边界，再按实际交付或扩展瓶颈渐进抽取，不按预设目标追求服务数量
- 让团队拥有从代码到生产的完整责任，并用 SLO 和用户旅程衡量服务，而不是只看组件是否存活
- 定期检查服务是否应该拆分、合并或重划边界，把拓扑视为可演进设计而非一次性组织图
金句：
- Microservices are independently releasable services modeled around a business domain.
- 微服务的小是手段，独立发布和业务自治才是目的。
- 如果两个服务必须一起发布，它们实际上仍是一个部署单元。
- 不要采用微服务，除非你有充分理由；单体并没有原罪，分布式系统也不是免费的。
- 好的服务边界隐藏内部复杂性，让大多数变更只发生在边界之内。
评论