稳如车！半个世纪过去了，康威定律依然适用

Posted 2021-04-24 擎天软件

关于架构，每个人的视角都不一样，有业务架构、安全架构、平台架构、数据架构等等，各不相同。今天擎天科技要讲的就是每个架构师都应该吃透的康威定律，半个世纪过去了，这个定律依然适用！

微服务是最近非常火热的新概念，可能很多人不清楚的是，微服务很多理念在半个世纪前的一篇《How Do Committees Invent》文章中就被阐述过了，而且这篇文章中的很多论点在软件开发发展的中一再被验证，这就是康威定律（Conway's Law）。

在这篇文章中，最有名的一句话就是：

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. 大致的意思是：系统的设计受限于设计系统的组织的人员架构形式。

康威定律的主要内容

1

第一定律

Communication dictates design：沟通决定了设计。

组织沟通与设计是紧密关联的。人是复杂的社会动物，对于复杂的系统，解决好沟通问题是拥有良好的设计的前提。微服务架构好比由多个小而独立的团队组成的组织，这样可以保证创建的服务彼此独立以及架构快速优化。设计微服务架构的人，为了想要这样的系统架构，反推出了这样的组织结构与之匹配。

2

第二定律

There is never enough time to do something right, but there is always enough time to do it over：再多的时间也不能把事情做完美，但能把事情做完。

运行期间，系统发生了故障，我们会及时地修复，提高系统的健壮性。当系统的体积达到一定规模后，故障是不可避免的，我们无法找到并修复所有故障，将系统打造得非常完美、一点问题都没有。如果我们拥抱故障，采取措施应对故障，系统就可以处于动态的平衡。

3

第三定律

There is a homomorphism from the linear graph of a system to the linear graph of its design organization：种瓜得瓜种豆得豆。

这是康威第一定律一个具体应用。直白的说，想要什么样的系统，就搭建什么样的团队。如果团队分成前端、后台、DBA和运维，系统就会是前端、后台、数据库之间组合。如果系统是按照业务边界划分的，会划分出多个独立的小系统，你的整个系统就是小系统的整合，即微服务的架构思想。

4

第四定律

The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems：大型复杂的系统比小的系统更适合分解。

面对复杂系统，我们往往会通过增加人力来解决，而人与人的沟通非常复杂，解决这个问题的办法就是分而治之。对于人员管理和系统都是如此。

康威定律带来的实践建议

1

创建小的团队

亚马逊的Jeff  Bezos提出了一个概念：如果一个团队，2个批萨都不够吃，那么这个团队过大了。团队中的人应该较少且身兼数职。这个概念在微服务的延伸就是大而复杂的系统应该是多个小而独立的服务构成的，服务间的通信应该简单高效（Smart endpoints and dumb pipes）。

2

慢慢来

不要过度工程，我们可以先做出最小可用产品，尽快交付给用户、获取用户反馈，在此基础上不断迭代和演化产品和架构。在微服务中会涉及到快速演化和自动化运维（DevOps）。

3

有效沟通

组织按业务来划分团队，每个小团队有明确的业务边界，团队自治内聚。这样可以提高团队间的沟通，减少之间的推诿扯皮。