南庄小筑 / 知识 / 康威定律

分享

   

康威定律

2020-07-06  南庄小筑

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:1的映射关系,更加高效。

第四定律

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

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

小结

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

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

康威定律如何解释微服务的合理性:

      了解了康威定律是什么,再来看看他如何在半个世纪前就奠定了微服务架构的理论基础。

  • 人与人的沟通是非常复杂的,一个人的沟通精力是有限的,所以当问题太复杂需要很多人解决的时候,我们需要做拆分组织来达成对沟通效率的管理

  • 组织内人与人的沟通方式决定了他们参与的系统设计,管理者可以通过不同的拆分方式带来不同的团队间沟通方式,从而影响系统设计

  • 如果子系统是内聚的,和外部的沟通边界是明确的,能降低沟通成本,对应的设计也会更合理高效

  • 复杂的系统需要通过容错弹性的方式持续优化,不要指望一个大而全的设计或架构,好的架构和设计都是慢慢迭代出来的

      带来的具体的实践建议是:

  • 我们要用一切手段提升沟通效率,比如slack,github,wiki。能2个人讲清楚的事情,就不要拉更多人,每个人每个系统都有明确的分工,出了问题知道马上找谁,避免踢皮球的问题。

  • 通过MVP的方式来设计系统,通过不断的迭代来验证优化,系统应该是弹性设计的。

  • 你想要什么样的系统设计,就架构什么样的团队,能扁平化就扁平化。最好按业务来划分团队,这样能让团队自然的自治内聚,明确的业务边界会减少和外部的沟通成本,每个小团队都对自己的模块的整个生命周期负责,没有边界不清,没有无效的扯皮,inter-operate, not integrate。

  • 做小而美的团队,人多会带来沟通的成本,让效率下降。亚马逊的Bezos有个逗趣的比喻,如果2个披萨不够一个团队吃的,那么这个团队就太大了。事实上一般一个互联网公司小产品的团队差不多就是7,8人左右(包含前后端测试交互用研等,可能身兼数职)。

      再对应下衡量微服务的标准,我们很容易会发现他们之间的密切关系:

  • 分布式服务组成的系统

  • 按照业务而不是技术来划分组织

  • 做有生命的产品而不是项目

  • Smart endpoints and dumb pipes(我的理解是强服务个体和弱通信)

  • 自动化运维(DevOps)

  • 容错

  • 快速演化

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多
    喜欢该文的人也喜欢 更多

    ×
    ×

    ¥.00

    微信或支付宝扫码支付:

    开通即同意《个图VIP服务协议》

    全部>>