系统架构之引言(墨菲定律、康威定律) - 小白进阶 - 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)。
第三定律:线型系统和线型组织架构间有潜在的异质同态特性
想要什么样的系统,就搭建什么样的团队,可以按职能或者业务进行划分。微服务的理念团队间应该是内聚的,定义好系统的边界和接口,在一个团队内全栈,让团队自治,原因就是因为如果团队按照这样的方式组建,将沟通的成本维持在系统内部,每个子系统就会更加内聚,彼此的依赖耦合能变弱,跨系统的沟通成本也就能降低。
第四定律:大的系统组织总是比小系统更倾向于分解
人与人的沟通非常复杂,当我们面对复杂系统时,又只能通过增加人力来解决,可以通过分而治之来解决 ,一个大的组织因为沟通成本或管理问题,总为被拆分成一个个小团队。
总结:
- 人与人的沟通是非常复杂的,一个人的沟通精力是有限的,所以当问题太复杂需要很多人解决的时候,我们需要做拆分组织来达成对沟通效率的管理。
- 组织内人与人的沟通方式决定了他们参与的系统设计,管理者可以通过不同的拆分方式带来不同的团队间沟通方式,从而影响系统设计
- 如果子系统是内聚的,和外部的沟通边界是明确的,能降低沟通成本,对应的设计也会更合理高效
- 复杂的系统需要通过容错弹性的方式持续优化,不要指望一个大而全的设计或架构,好的架构和设计都是慢慢迭代出来的。
拆分原则
- 应该按照业务闭环进行系统拆分或组织架构划分,实现闭环、高内聚、低耦合,减少沟通成本。
- 如果沟通出现问题,那么应该考虑进行系统和组织架构的调整。
- 在合适时机进行系统拆分,不要一开始就把系统或服务拆的非常细,虽然闭环,但是每个人维护的系统多,维护成本高。