> For the complete documentation index, see [llms.txt](https://jun-wang.gitbook.io/learnjava/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jun-wang.gitbook.io/learnjava/ji-shu-xue-xi/jia-gou-xue-xi/kang-wei-ding-l.md). # 康威定律 ## 康威定律简介 微服务架构是最近非常流行的概念，很多公司的系统都用上了微服务，其实在50多年前，微服务的概念就已经被提出来了，在康威发表的一篇文章《HOW DO COMMITTEES INVENT》中就提到了企业内部的组织架构，里面提到的很多观点在软件的开发发展中被一再验证，这就是**康威定律**。 据说这篇文章最初投稿于哈佛商业评论，但被拒绝，因此康威将其提交到了一个编程杂志，所以被误解为只针对应用开发，起初，作者并没有把这种理论作为定律，只是描述了发现和结论。 在这篇文章中，最有名的一句话就是：**系统的设计受限于设计系统的组织的人员架构形式**。简单的说就是公司组织的人员形式决定了系统的架构形式。比如说大型单体应用的系统，如CRM，其人员组织形式一般分为前端，后端，DBA，运维等。像微服务的系统一般人员组织是分为很小的一个团队，每个团队独立运行，团队里面包括前端，后端，DBA等。相当于把一个大型的组织结构按照业务维度拆分成几个小的结构。 ## 康威定律的主要内容 ### 第一定律 沟通决定了设计。 组织沟通与设计是紧密关联的。人是复杂的社会动物，对于复杂的系统，解决好沟通问题是拥有良好的设计的前提。微服务架构好比由多个小而独立的团队组成的组织，这样可以保证创建的服务彼此独立以及架构快速优化。设计微服务架构的人，为了想要这样的系统架构，反推出了这样的组织结构与之匹配。 ### 第二定律 再多的时间也不能把事情做完美，但能把事情做完。罗马不是一天建成的，学会先解决首要问题。 运行期间，系统发生了故障，我们会及时地修复，提高系统的健壮性。当系统的体积达到一定规模后，故障是不可避免的，我们无法找到并修复所有故障，将系统打造得非常完美、一点问题都没有。如果我们拥抱故障，采取措施应对故障，系统就可以处于动态的平衡。 ### 第三定律 种瓜得瓜种豆得豆。 这是康威第一定律一个具体应用。直白的说，想要什么样的系统，就搭建什么样的团队。如果团队分成前端、后台、DBA和运维，系统就会是前端、后台、数据库之间组合。如果系统是按照业务边界划分的，会划分出多个独立的小系统，你的整个系统就是小系统的整合，即微服务的架构思想。 ### 第四定律 大型复杂的系统比小的系统更适合分解。 面对复杂系统，我们往往会通过增加人力来解决，而人与人的沟通非常复杂，解决这个问题的办法就是分而治之。对于人员管理和系统都是如此。 > 参考： > > > > > > > >