康威定律——这个50年前就被提出的微服务概念,你知多少?

转载 2017年09月13日 16:32:08

概述

微服务架构是一种非常流行的新概念,即便可供以借鉴的经验比较少,当然不能阻挡它成为热门话题与研究对象。

令人惊讶地是,其实微服务的概念早在五十多年前就已经被提出,多年来,很久研究表明了这些观点的准确性。这就是本文所介绍的——康威定律。现在已经有很多企业正在尝试使用它创建高效的微服务架构。

imageimage

在这篇文章中最有名的一句话莫过于:

设计系统的企业受限于生产设计,这些设计是企业沟通结构的副本——Melvin Conway(1967)。

这意味着设计系统的企业,它们生产的设计等同于企业内的沟通结构。下图说明了此概念:

imageimage

该图展现了企业现有沟通结构,简单地说:企业结构等于系统设计。

作者这里提到的系统并不局限于应用系统,据说这篇文章最初投稿于哈佛商业评论,但被拒绝,因此康威将其提交到了一个编程杂志,所以被误解为只针对应用开发,起初,作者并没有把这种理论作为定律,只是描述了发现和结论,不过著名的《The Mythical Man-Month》一书介绍了Brooks的理论,并引用了康威的一些观点,于是康威的理论被推崇成为我们现在所熟知的康威定律。

康威定律详细介绍

在文章中,Mike Amundesn总结了一些核心观点:

  • 第一定律:企业沟通方式会通过系统设计表达出来
  • 第二定律:再多的时间也没办法让任务完美至极,但总有时间能将它完成
  • 第三定律:线型系统和线型组织架构间有潜在的异质同态特性
  • 第四定律:大系统比小系统更适用于任务分解

〓 康威第一定律

“人类是复杂的社会动物。”

其他领域也提供了一些关于沟通和系统设计之间紧密关系的例证,对于一个复杂的系统,设计主题总会涉及到人们之间的交流,一个好的系统设计能解决这种沟通问题,很多老程序员都读过《The Mythical Man-Month》,里面的一些观点都是这句话的佐证。

imageimage

《The Mythical Man-Month》 这本书里有一句令人难忘的话:在应用项目后期加大人员的投资,会更加拖慢它的速度。——Fred Brooks(1975)

增加开发者的数量以跟上紧凑的进度是许多企业常见的问题,虽然增加劳动以达到增加产出的目的是有意义的,但在沟通成本上也会大大增加——随着项目或企业中的人员数量增加,沟通成本成指数级增长,它可以通过公式n(n-1)/2来计算,而项目管理算法的复杂度是O(N 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

这也就是互联网创业公司一般都比较小的原因,如果创业公司有太多的员工,Boos向每个人介绍自己的想法,那么风投估计也快花完了。

生物学家Dunbar在1992年提出了一个名为Dunbar Number的理论:灵长类动物的大脑容量与它的族群大小有关,然后推论出一些人类大脑能够维持的关系数量,例如,一个典型的人会有:

  • 5个死党
  • 15个信任的朋友
  • 35个一般的朋友
  • 150个只打过照面的朋友

imageimage

所以它们与上面提到的沟通成本有关,大脑只能维持这么多的关系(在开发团队中,这个数字可能更小)。

沟通的问题会影响系统设计,进而影响整个系统的开发效率以及最终结果。

〓 康威第二定律

罗马不是一天建成的,学会先解决首要问题。

敏捷开发巨头之一Erik Hollnagel 在他的书中阐述了类似的观点:

问题太复杂?那么不妨忽略不必要的细节。

没有足够的资源?放弃无用的功能。

——Erik Hollnagel(2009)

imageimage

系统的复杂性、功能数量、市场竞争以及投资人的期望值都在增加,而人的智力是有上限的,没有企业能说一定能找到合适的人,对于一个极其复杂的系统,总会有考虑不周全的地方,Erik认为这个问题最好的解决办法就是:不去管它。

在日常开发任务汇总会遇到一些问题如,产品经理提出的要求是否过于复杂?如果是,首先关注那些主要的需求,忽略次要的需求,产品经理的需求太多了?那就放弃一些功能。

据称,Erik曾收到一家航空公司的顾问邀请,保证飞行系统的稳定性和安全性,他相信通过两种方式可以确保安全性:

  • 常规安全:必须检测和消除尽可能多的错误
  • 非常规安全:若出现错误,要及时处理,最快恢复服务

对于像飞行系统这样复杂的系统,不管测试人员的业务多么纯熟,也会忽略一些漏洞,因此Erik建议公司放弃建立一个完美系统的想法,尽量去保证安全和正确性,通过不断地飞行测试,去识别安全问题,确保系统能够在出现故障时自动回复,下图显示了安全的不同解释。

imageimage

听起来是不是很熟悉?没错,这就是我们常说的持续集成和敏捷开发的概念。

而这个原则与互联网公司维护的分布式系统弹性设计也相同,即使单元测试覆盖整个系统,也不不可能识别和修复分布式系统中所有的缺陷,分布式系统很容易出现错误,最佳解决方案不是消除所有问题,而是允许它们存在,在发生故障时实现自动恢复。

在由微服务组成的系统中,每个微服务都可能停止响应,这是完全正常的,只需要确保足够的冗余和备份,这就是弹性或高可用性设计。

〓 康威第三定律

创建独立的子系统,减少沟通成本。

imageimage

上图代表了第一定律的团队和系统设计之间的内部关系具体应用,简单地说,需要建立一个适合自身系统的团队,如果有一个前端团队、Java后端开发团队、DBA团队和O&M团队,那么系统将会如下图:

imageimage

相反,如果系统是以业务边界划分的,按照业务目标去构建小的系统或产品,整体系统将会如下图所示,即微服务架构:

imageimage

团队中微服务的理念应是Inter-Operate,而不是Integrate ,Inter-Operate是指定义系统边界和接口,并为整个团队提供完整的堆栈,实现完全的自制。如此就能降低系统间的依赖性,减少通信成本。

〓 康威第四定律

前面提到,人类是复杂的社会动物,人与人之间的交流是非常复杂的,当涉及到一个系统时,人们经常选择增加人力去减少复杂性,对于企业来说,该如何处理这样的沟通问题?答案是:分而治之。

看看公司内,一名经理管理的员工一般少于15个,二三线经理管理的员工要更少,因此,大企业通常会将团队拆成一个个小团队或部门减少沟通成本及管理的问题,有一些需要考虑的场景:

  • 创业的项目很好,拿到一大笔风投,再招募更多的程序员
  • 人员太多,需要找几个经理进行管理
  • 康威定律好告诉我们,可以从系统设计中看出组织通信的模式,每个经理要对大系统的某一小部分负责,通过这种方式,它们和更大的系统间沟通有了便捷,因此大的系统也会被拆分成一个个小系统。(微服务可以更好地服务于此)。

〓 康威定律与微服务

再来看一下康威定律是如何在半个世纪前就奠定了微服务理论基础的。

  • 人与人之间的交流很复杂,每个人的精力是有限的,因此当问题很复杂,需要协调地去解决时,需要将组织划分进而提高沟通效率。
  • 团队成员工作的系统设计依赖于成员之间的沟通,管理人员可以调整划分模式,实现团队之间的不同沟通方式,这也会影响系统的设计。
  • 如果子系统有清晰的外部通信便捷,那么就可以有效地降低通信成本,响应地设计将更加适合和有效。
  • 需要不断优化一个复杂的系统,并容错性和故障恢复率的帮助下进行优化,不要期望大而全面的设计或架构,因为它们的开发以迭代的方式发生。

以下是一些具体的实践建议:

  • 利用一切手段提高通信效率,如Slack、Github和Wiki,且只与相关人员进行沟通,每个人和每个系统必须有明确的职责,在遇到问题时,知道该找谁去解决。
  • 在MVP模式下设计一套系统,以迭代的方式优化及验证,并确保系统的弹性。
  • 采用与系统设计相一致的团队,以扁平化和以业务为基准的方式去简化团队,每个小团队之间必须有对应负责的模块,避免模糊的界限,以免在发生问题时互相推卸责任。
  • 要做小而美的团队,人员数量的增加会降低效率以及加大成本,亚马逊CEO Jeff Bezos有个一个经验法则:如果两个披萨对于一个团队来说不够,那么这个团队就太大了。一般来说,一家互联网公司的产品团队由7到8个人组成(包括前端和后端测试、交互和用户体验师,一些人可能身兼数职)。

在查看以下微服务标准时,我们可以很容易地看到微服务与康威定律之间的密切关系:

  • 由分布式服务组成的系统
  • 企业部门的业务线
  • 开发优秀的产品
  • Smart endpoints and dumb pipes
  • DevOps
  • 容错
  • 快速发展
本文作者:云栖团队博客
原文链接:http://www.tuicool.com/articles/3MF7BnV
版权归作者所有,转载请注明出处

相关文章推荐

微服务架构的理论基础 - 康威定律

概述 关于微服务的介绍,可以参考微服务那点事。 微服务是最近非常火热的新概念,大家都在追,也都觉得很对,但是似乎没有很充足的理论基础说明这是正确的,给人的感觉是 不明觉厉 。前段时间看了M...

每个架构师都应该研究下康威定律

今天的分享主要来自我之前的工作经验以及平时的学习总结和思考。我之前的背景主要是做框架、系统和平台架构,之前工作过的公司 eBay、携程、唯品会都是平台型互联网公司,所以今天主要带着平台架构视角和大家分...

【转】每个架构师都应该研究下康威定律

技术干货

使用Jenkins的任务自动跑脚本后发现,tomcat服务刚启动就被杀死

在Jenkins的使用中,遇到过的一个场景是:使用python自动执行tomcat bin目录下的startup.bat开启批处理,服务开启成功后就随着python脚本执行结束该服务就被杀死,开始以为...

这些管理学定律你知多少?

 1、木桶定律的意思:一只沿口不齐的木桶,盛水的多少,不取决于木桶上那块最长的木板,而取决于木桶上最短的那块木板。    木桶定律对于企业培训的启示:企业要想提高员工的竞争力,并将他们的力量有效地凝聚...
  • e3002
  • e3002
  • 2011年05月23日 21:52
  • 425

好不容易申请的微信号玩两天就被封了?微信经常出现意想不到的闪退?多半是没有这个软件的支持

好不容易申请的微信号才玩了两天就被封了?切换太过频繁,微信经常出现意想不到的闪退?使用模拟器微信多开立马被封号?手动加人转、发朋友圈效率太低?通过通路云手机群控系统拦截屏幕和按键驱动,我们可以任意管理...

微电脑世界:25年前和后 信息技术50年

微电脑世界:25年前和后 信息技术50年   http://www.sina.com.cn 2004年02月11日 10:10 微电脑世界   微电脑世...
  • junecau
  • junecau
  • 2011年08月08日 23:38
  • 1406

海康威视多摄像头视频实时采集——OpenCV显示

海康威视多摄像头视频实时采集——OpenCV显示最近由于工程上要做多摄像头多目标跟踪,用到的摄像头是海康威视的DS-2CD3320D摄像头。一、摄像头的配置 本人购买的摄像头的型号是DS-2CD3...

编码操练招式——康威生命游戏

康威生命游戏(Conway’s Game Of Life) 在一个有边界的二维网格(Grid)中,每个格子中生活着一个细胞(Cell);每个细胞只有两种生命状态:生(Alive)或死(Dea...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:康威定律——这个50年前就被提出的微服务概念,你知多少?
举报原因:
原因补充:

(最多只允许输入30个字)