康威定律

康威定律简介

微服务架构是最近非常流行的概念,很多公司的系统都用上了微服务,其实在50多年前,微服务的概念就已经被提出来了,在康威发表的一篇文章《HOW DO COMMITTEES INVENT》中就提到了企业内部的组织架构,里面提到的很多观点在软件的开发发展中被一再验证,这就是康威定律

据说这篇文章最初投稿于哈佛商业评论,但被拒绝,因此康威将其提交到了一个编程杂志,所以被误解为只针对应用开发,起初,作者并没有把这种理论作为定律,只是描述了发现和结论。

在这篇文章中,最有名的一句话就是:系统的设计受限于设计系统的组织的人员架构形式。简单的说就是公司组织的人员形式决定了系统的架构形式。比如说大型单体应用的系统,如CRM,其人员组织形式一般分为前端,后端,DBA,运维等。像微服务的系统一般人员组织是分为很小的一个团队,每个团队独立运行,团队里面包括前端,后端,DBA等。相当于把一个大型的组织结构按照业务维度拆分成几个小的结构。

康威定律的主要内容

第一定律

沟通决定了设计。

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

第二定律

再多的时间也不能把事情做完美,但能把事情做完。罗马不是一天建成的,学会先解决首要问题。

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

第三定律

种瓜得瓜种豆得豆。

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

第四定律

大型复杂的系统比小的系统更适合分解。

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

参考:

http://www.sohu.com/a/215574765_717586

https://segmentfault.com/a/1190000011118897

https://blog.csdn.net/mytobaby00/article/details/79840927

https://36kr.com/p/5042735.html

Last updated