墨菲定律（设计系统）和康威定律（系统划分）

骑猪看日落 2023-02-15 10:26 15阅读 0赞

## 在设计系统时，应该多考虑 墨菲定律： ##

*  任何事物都没有表面看起来那么简单。
 *  所有的事都会比你预计的时间长。
 *  可能出错的事总会出错。
 *  如果你担心某种情况发生，那么他就更有可能发生。

## 在划分系统时，应该多考虑 康威定律： ##

*  系统架构是公司组织架构的反映。
 *  应该按照业务闭环进行系统拆分／组织架构划分，实现闭环／高内聚／低耦合，减少沟通成本。
 *  如果沟通出现问题，那么应该考虑进行系统和组织架构的调整。
 *  在合适时机进行系统拆分，不要一开始就把系统／服务拆的非常细，虽然闭环，但是每个人维护的系统多，维护成本高。

## 墨菲定律 ##

**![format_png][]**

**墨菲定律本质是：“小概率事件在大量独立重复试验的情况下是必然发生”。**理解为，让你对自己在生活工作中，对想到可能出错的地方一定要多加重视不要心存侥幸。

查理芒格曾说过：如果我知道我会死在哪里，我就永远不去那个地方。这就是一种降低概率的做法。

相反，一个更广泛的法则——**吸引力法则**。这个法则不像墨菲定律只说，坏的事情一定会发生，它也会告诉你，如果你一直思考正向积极且是你想实现的梦想，那么好事也一定发生。

2014年在世界各国热映的电影《星际穿越》里，男主角库珀的女儿叫墨菲 。

影片开始部分，库珀和他的儿子女儿开车去学校，路上车子出现了爆胎，库珀的儿子说:墨菲定律。女儿很生气，问父亲为什么他和妈妈以坏事给她起名字。

这里有个概念叫“墨菲定律”，也有个同名书叫《墨菲定律》，意思就是：**凡事只要有可能出错，那就一定会出错。**

这是美国爱德华兹空军基地的上尉工程师爱德华·墨菲 总结的，但总结的依据不过时他经历的一次事故罢了：

1949年，他和他的上司斯塔普少校，在一次火箭减速超重试验中，因仪器失灵发生了事故。爱德华·墨菲 发现，测量仪表被一个技术人员装反了。

由此，他得出的教训是：

**如果做某项工作有多种方法，而其中有一种方法将导致事故，那么一定有人会按这种方法去做。**

## 康威定律 ##

> Soft skills are always hard than hard skills. 软技能比硬技能难。

老板听说最近流行“微服务”，问架构师咱们的系统要不要来一套？老板又听说最近流行“中台系统”，问架构师咱们要不要搞起来？其实，这些问题不用老板问，关注技术发展趋势的架构师每当听到新的技术或解决方案，都会暗中思忖是否应用到系统中。然而，用或不用，总不能凭感觉吧。此时，如果你能灵活运用康威定律，那么做出的判断将更加完美。

# #

康威定律是马尔文·康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。

跨部门沟通是非常难的，系统各个模块的接口也反映了它们之间的信息流动和合作方式。

![image][]

康威定律可谓软件架构设计中的第一定律，起初只是在杂志上的发表，后经过《人月神话》这本软件界圣经的引用，并命名为康威定律（Conway’s law），因此得以推广。

只通过简单的描述可能无法理解康威定律的精髓所在，原文中康威定律可总结为四个定律：

*  第一定律 组织沟通方式会通过系统设计表达出来。
 *  第二定律 时间再多一件事情也不可能做的完美，但总有时间做完一件事情。
 *  第三定律 线型系统和线型组织架构间有潜在的异质同态特性。
 *  第四定律 大的系统组织总是比小系统更倾向于分解。

## 第一定律 ##

> Communication dictates design。  
> 组织沟通方式决定系统设计。

这条定律重点是讲组织架构和沟通对系统设计的影响。组织的沟通和系统的设计之间紧密相连，特别是复杂系统，解决好人与人的沟通才能有一个更好的系统设计。

《人月神话》中总结出了随着人员的增加沟通成本呈指数增长的规律：沟通成本 = n(n-1)/2。举例说明一下：

*  5人项目组，需要沟通的渠道是 5\*(5–1)/2 = 10
 *  15人项目组，需要沟通的渠道是15\*(15–1)/2 = 105
 *  50人项目组，需要沟通的渠道是50\*(50–1)/2 = 1,225
 *  150人项目组，需要沟通的渠道是150\*(150–1)/2 = 11,175

这也是为什么互联网公司都追求小团队的原因之一。沟通的问题会带来系统设计的问题，进而影响整个系统的开发效率和最终产品结果。

## 第二定律 ##

> There is never enough time to do something right, but there is always enough time to do it over。  
> 时间再多一件事情也不可能做的完美，但总有时间做完一件事情。

人手永远是不够的，事情永远是做不完的，但可以一件一件来。这不就是软件行业中“敏捷开发”模式所解决的问题吗。面对这样的状况，敏捷开发可以做到不断迭代、持续交付、快速验证和反馈，并持续改进。

再牛的开发也会写出bug，再全面的测试覆盖率也无法测出所有的问题。解决方案不是消灭这些问题，是容忍一些问题的存在，然后通过适当的设计（冗余、监控、高可用设计）当问题发生时能够快速解决。

几个开发人员的小公司，去追求微服务、去追求中台架构，这是追求完美吗？不是，是找死。

好的架构不是买来的，也不是设计出来的，而是根据业务落地生根长期演化来的。

## 第三定律 ##

> There is a homomorphism from the linear graph of a system to the linear graph of its design organization。  
> 线型系统和线型组织架构间有潜在的异质同态特性。

这一定律是第一定律的具体应用。想象一下如果公司的组织架构是这样的：团队是分布式，每个团队都包含产品、研发、测试、运维等角色。而此时系统是单块的，项目沟通和协调的成本是巨大的，弄不好还会打起来。

![image][image 1]

如果将单块的系统拆分成微服务，每个团队负责自己的部分，对外提供对应的接口即可，互不干扰。系统效率将得到提升。这与软件设计中的高内聚、低耦合是相通的。

![image][image 2]

直白的说就是想要什么的系统就搭建什么样的团队，有什么样的团队就搭建什么样的系统。需要前后端分离的系统就搭建前后端分离的团队，反之，拥有前后端分离的团队，可以设计前后端分离的系统。当然，如果能统筹管理，拥有重组团队或设计系统架构的权利，那就再好不过了。通常情况下让两者形成1：1的映射关系，更加高效。

## 第四定律 ##

> The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems。  
> 大的系统组织总是比小系统更倾向于分解。

“话说天下大势，分久必合，合久必分。”系统越复杂，越需要增加人手，人手越多，沟通成本也呈指数增长。分而治之便是大多数公司选择的解决方案。分不同的层级，分不同的小团队，让团队内部完成自治理，然后统一对外沟通。

## 小结 ##

架构不仅仅需要技术，在大公司尤其需要政治，所谓的架构的政治。

杨波老师曾在他的文章《[每个架构师都应该研究下康威定律][Link 1]》中提到：“政治指的是和他人协作将事情搞定的艺术，架构是一种社交活动，在技术的世界里，个人主义很容易被打败，即使你的目的是好的技术是最优的，技术决策是政治决策（technical decisions are political decisions），一个技术产品，一波人可以做，另一波人也可以做，到底谁做的好，真不好说，不管谁做，都给业务套上了一副手铐。”

最近阅读了架构之美，其中康威定律印象深刻，于是查阅了相关资料，再根据自己这么多年的开发架构经验，总结一下心得。

首先来看一下这个定律的原文：

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

大概翻译下就是设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。

康威定律被视为微服务架构的理论基础，是有一定的根据的，主要有以下几点：

1.把一个大的系统分成一个个小的业务模块，每个业务模块由对应的小团队来负责而且各个小团队都是独立的，所以在分模块时要按业务而不是技术来划分。

2.避免过度设计。一个系统初级是不可能大而全，十分完美，它必须是有一个演进进程，所以刚开始能保持可移植性、高扩展性即可。保持弹性设计。

3.各微服务应该都有自己独立的数据库和资源，避免耦合在一起。

4.各微服务对外提供的接口尽量的兼容各种不同的技术和开发语言。

5.专注产品的生命力，而不是为了项目而技术。所以技术人员也有必要对业务有一定的理解。

--------------------

引用：

[https://www.choupangxia.com/2019/10/10/%e5%ba%b7%e5%a8%81%e5%ae%9a%e5%be%8b%ef%bc%8c%e4%bd%9c%e4%b8%ba%e6%9e%b6%e6%9e%84%e5%b8%88%e8%bf%98%e4%b8%8d%e4%bc%9a%e7%81%b5%e6%b4%bb%e8%bf%90%e7%94%a8%ef%bc%9f/][https_www.choupangxia.com_2019_10_10_e5_ba_b7_e5_a8_81_e5_ae_9a_e5_be_8b_ef_bc_8c_e4_bd_9c_e4_b8_ba_e6_9e_b6_e6_9e_84_e5_b8_88_e8_bf_98_e4_b8_8d_e4_bc_9a_e7_81_b5_e6_b4_bb_e8_bf_90_e7_94_a8_ef_bc_9f]

https://blog.csdn.net/guotufu/article/details/80287768

[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWM0LnpoaW1nLmNvbS84MC92Mi1jMDRmNDFiNmEyZjBiN2ExNWE1OGQ5MjUzMWMyMGJhYl83MjB3LmpwZw?x-oss-process=image/format,png
[image]: https://imgconvert.csdnimg.cn/aHR0cDovL3d3dy5jaG91cGFuZ3hpYS5jb20vd3AtY29udGVudC91cGxvYWRzLzIwMTkvMTAvY29ud2F5My5qcGc?x-oss-process=image/format,png
[image 1]: https://imgconvert.csdnimg.cn/aHR0cDovL3d3dy5jaG91cGFuZ3hpYS5jb20vd3AtY29udGVudC91cGxvYWRzLzIwMTkvMTAvY29ud2F5MS5wbmc?x-oss-process=image/format,png
[image 2]: https://imgconvert.csdnimg.cn/aHR0cDovL3d3dy5jaG91cGFuZ3hpYS5jb20vd3AtY29udGVudC91cGxvYWRzLzIwMTkvMTAvY29ud2F5Mi5wbmc?x-oss-process=image/format,png
[Link 1]: https://www.infoq.cn/article/every-architect-should-study-conway-law
[https_www.choupangxia.com_2019_10_10_e5_ba_b7_e5_a8_81_e5_ae_9a_e5_be_8b_ef_bc_8c_e4_bd_9c_e4_b8_ba_e6_9e_b6_e6_9e_84_e5_b8_88_e8_bf_98_e4_b8_8d_e4_bc_9a_e7_81_b5_e6_b4_bb_e8_bf_90_e7_94_a8_ef_bc_9f]: https://www.choupangxia.com/2019/10/10/%E5%BA%B7%E5%A8%81%E5%AE%9A%E5%BE%8B%EF%BC%8C%E4%BD%9C%E4%B8%BA%E6%9E%B6%E6%9E%84%E5%B8%88%E8%BF%98%E4%B8%8D%E4%BC%9A%E7%81%B5%E6%B4%BB%E8%BF%90%E7%94%A8%EF%BC%9F/