系统架构之引言（墨菲定律、康威定律） - 小白进阶 - CSDN博客

系统设计的墨菲定律

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

“墨菲定律”的根本内容是“凡是可能出错的事有很大几率会出错”，指的是任何一个事件，只要具有大于零的机率，就不能够假设它不会发生。

系统划分的康威定律

第一定律：组织沟通方式会通过系统设计表达出来

组织的沟通和系统设计之间的紧密联系，解决好人与人的沟通问题，才能有一个好的系统设计。在项目管理《人月神话》一书中有一句“Adding manpower to a late software project makes it later”（ 向进度落后的项目中增加人手，只会使进度更加落后），并给出了说明，沟通渠道（成本） = n(n-1)/2，沟通渠道（成本）随着项目或者组织的人员增加呈指数级增长。

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

沟通的问题，会带来系统设计的问题，进而影响整个系统的开发效率和最终产品结果。

第二定律：时间再多一件事情也不可能做的完美，但总有时间做完一件事情

系统越做越复杂，功能越来越多，但人的智力是有上限的，即使再牛逼的人，融到钱再多也不一定招到足够多合适的人。对于一个巨复杂的系统，我们永远无法考虑周全。Eric Hollnagel 在2009年《Efficiency-Effectiveness Trade Offs》一书中提出“Problem too complicated? Ignore details. Not enough resources?Give up features.”（ 问题太复杂了？忽略详细信息。资源不足？放弃特色。）。

对于一个分布式系统，我们几乎永远不可能找到并修复所有的bug，解决方法不是消灭这些问题，而是容忍这些问题，在问题发生时，能自动恢复，即所谓的高可用设计（High Availability），也叫弹性设计（Resilience）。

第三定律：线型系统和线型组织架构间有潜在的异质同态特性

想要什么样的系统，就搭建什么样的团队，可以按职能或者业务进行划分。微服务的理念团队间应该是内聚的，定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能降低。

第四定律：大的系统组织总是比小系统更倾向于分解

人与人的沟通非常复杂，当我们面对复杂系统时，又只能通过增加人力来解决，可以通过分而治之来解决 ，一个大的组织因为沟通成本或管理问题，总为被拆分成一个个小团队。

总结：

• 人与人的沟通是非常复杂的，一个人的沟通精力是有限的，所以当问题太复杂需要很多人解决的时候，我们需要做拆分组织来达成对沟通效率的管理。
• 组织内人与人的沟通方式决定了他们参与的系统设计，管理者可以通过不同的拆分方式带来不同的团队间沟通方式，从而影响系统设计
• 如果子系统是内聚的，和外部的沟通边界是明确的，能降低沟通成本，对应的设计也会更合理高效
• 复杂的系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的。

拆分原则

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