本文详细介绍了微服务设计与治理的16条原则，涵盖微服务规划、设计、实现、调用、发布、治理和下线等阶段。强调按照业务能力与领域驱动设计规划微服务，遵循单一职责、高内聚、低耦合原则。此外，还涉及服务无状态、高可用、可观测、配置管理、避免分布式大单体、异步解耦、引入BFF层、安全发布、持续演进等实践。最后，讨论了微服务下线的重要性。
今天将从存储的上一层「服务维度」学习架构师的第二项常用能力——微服务设计与治理。
- 如何设计合理的微服务架构？
- 如何保持微服务健康运行？
这是我们对微服务进行架构设计过程中非常关注的两个问题。
本文对微服务的生命周期定义了七个阶段，如下图所示。
围绕这七个阶段总结了16条常用原则。
1.微服务规划
原则1：按照业务能力（business capabilities）来规划或拆微服务。
康威定律：Conway’s law: Organizations which design systems[…] are constrained to produce designs which are copies of the communication structures of these organizations.（设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。)
组织的沟通和系统的设计之间紧密相连，特别是复杂系统，解决好人与人的沟通才能有一个更好的系统设计。
《人月神话》中总结出了随着人员的增加沟通成本呈指数增长的规律：沟通成本 = n(n-1)/2。举例说明：
- 5人项目组，需要沟通的渠道是 5*(5–1)/2 = 10
- 15人项目组，需要沟通的渠道是15*(15–1)/2 = 105
- 50人项目组，需要沟通的渠道是50*(50–1)/2 = 1,225
系统越复杂，人手越多，沟通成本也呈指数增长。因此，分而治之便是大多数公司选择的解决方案。分不同的层级，分不同的小团队，让团队内部完成自治理。
原则2: 按照领域驱动设计（Domain-Driven Design，DDD）来规划或拆解微服务。
领域驱动
最低0.47元/天 解锁文章
扫一扫
1251
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
