架构师进阶，微服务设计与治理的16条常用原则

今天将从存储的上一层「服务维度」学习架构师的第二项常用能力——微服务设计与治理。

• 如何设计合理的微服务架构？
• 如何保持微服务健康运行？

这是我们对微服务进行架构设计过程中非常关注的两个问题。

本文对微服务的生命周期定义了七个阶段，如下图所示。

围绕这七个阶段总结了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）来规划或拆解微服务。

领域驱动