微服务规则：优秀实践指南 - 2024年7月版
内容提要
这篇文章介绍了微服务架构的11个开发和架构规则，帮助组织避免问题。规则包括持续交付/部署、自动化部署流水线、团队拓扑、开发者体验、独立可部署的服务、松耦合的服务、可测试的服务、可观察的服务、小而安全的变更、软件指标和KPI。作者提供了演讲和帮助组织提高软件交付速度的服务。
延伸解读
规则更新背后的考量
2024年7月版对两条规则进行了调整。规则3从“组织成小型、跨职能、松耦合的团队”改为直接采用团队拓扑作为指导，因为团队拓扑提供了更系统的组织模式。规则10从“从单体逐步迁移到微服务”泛化为“大/高风险变更应拆分为更小、更安全且可逆的变更”，因为大规模风险变更不仅出现在迁移场景，也可能出现在子系统重写等情境中。
规则作为评估清单
作者将这11条规则定位为工程领导者评估组织交付实践和架构状态的清单。规则覆盖持续交付、自动化流水线、团队拓扑、开发者体验、独立部署、松耦合、可测试性、可观察性、小步变更以及软件指标。文章强调，由于语义扩散和组织误用，遵循规则并不能保证成功，但能提高微服务采用的成功概率。
渐进式变更的实践意义
规则10建议避免大规模风险变更，例如花费数月重写子系统后在一个周末迁移所有用户。更好的做法是逐步开发新子系统，并逐步迁移用户。这一原则不仅适用于单体到微服务的迁移，也适用于任何可能带来高风险的大规模变更，有助于降低失败影响并保持系统可逆性。
Q&A
微服务架构的主要优势是什么？
微服务架构能够显著改善开发者体验和加速软件交付。
文章中提到的11条微服务开发规则有哪些？
规则包括持续交付/部署、自动化部署流水线、团队拓扑、开发者体验、独立可部署的服务、松耦合的服务、可测试的服务、可观察的服务、小而安全的变更、软件指标和KPI。
如何组织团队以实现快速流动？
建议使用团队拓扑作为组织团队的指南，以实现快速流动。
为什么许多组织在采用微服务时会遇到问题？
许多组织误解和不当使用微服务，导致难以获得预期的好处。
如何进行安全的小规模变更？
应逐步开发新子系统，并逐步迁移用户，而不是进行大规模的风险变更。
作者提供了哪些帮助组织提高软件交付速度的服务？
作者提供培训工作坊、架构评审等服务，帮助组织提高敏捷性和竞争力。
