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

概述

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

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

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

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

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

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

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

康威定律详细介绍

在文章中，Mike Amundesn总结了一些核心观点：

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

〓 康威第必定律

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

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

《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个只打过照面的朋友

因此它们与上面提到的沟通成本有关，大脑只能维持这么多的关系（在开发团队中，这个数字可能更小）。

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

〓 康威第二定律

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

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

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

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

——Erik Hollnagel（2009）

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

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

据称，Erik曾收到一家航空公司的顾问邀请，保证飞行系统的稳定性和安全性，他相信经过两种方式能够确保安全性：

• 常规安全：必须检测和消除尽量多的错误
• 很是规安全：若出现错误，要及时处理，最快恢复服务

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

听起来是否是很熟悉？没错，这就是咱们常说的持续集成和敏捷开发的概念。

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

在由微服务组成的系统中，每一个微服务均可能中止响应，这是彻底正常的，只须要确保足够的冗余和备份，这就是弹性或高可用性设计。

〓 康威第三定律

建立独立的子系统，减小沟通成本。

上图表明了第必定律的团队和系统设计之间的内部关系具体应用，简单地说，须要创建一个适合自身系统的团队，若是有一个前端团队、Java后端开发团队、DBA团队和O&M团队，那么系统将会以下图：

相反，若是系统是以业务边界划分的，按照业务目标去构建小的系统或产品，总体系统将会以下图所示，即微服务架构：

团队中微服务的理念应是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/articl...