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

转自：https://yq.aliyun.com/articles/8611

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

 

 

摘要可能出乎不少人意料以外的一个事实是，微服务不少核心理念其实在半个世纪前的一篇文章中就被阐述过了，并且这篇文章中的不少论点在软件开发飞速发展的这半个世纪中居然一再被验证，这就是康威定律。前段时间看了Mike Amundsen 《远距离条件下的康威定律——分布式世界中实现团队构建》在InfoQ上的一个分

概述

关于微服务的介绍，能够参考微服务那点事。

微服务是最近很是火热的新概念，你们都在追，也都以为很对，可是彷佛没有很充足的理论基础说明这是正确的，给人的感受是 不明觉厉 。前段时间看了Mike Amundsen 《远距离条件下的康威定律——分布式世界中实现团队构建》（是Design RESTful API的做者）在InfoQ上的一个分享，以为颇有帮助，结合本身的一些思考，整理了该演讲的内容。

可能出乎不少人意料以外的一个事实是，微服务不少核心理念其实在半个世纪前的一篇文章中就被阐述过了，并且这篇文章中的不少论点在软件开发飞速发展的这半个世纪中居然一再被验证，这就是康威定律（Conway's Law）。

 

在康威的这篇文章中，最有名的一句话就是：

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

中文直译大概的意思就是：设计系统的组织，其产生的设计等同于组织以内、组织之间的沟通结构。看看下面的图片（来源于互联网，侵删），再想一想Apple的产品、微软的产品设计，就能形象生动的理解这句话。

用通俗的说法就是：组织形式等同系统设计。

这里的系统按原做者的意思并不局限于软件系统。听说这篇文章最初投的哈佛商业评论，结果程序员屌丝的文章不入商业人士的法眼，无情被拒，康威就投到了一个编程相关的杂志，因此被误解为是针对软件开发的。最初这篇文章显然不敢自称定律（law），只是描述了做者本身的发现和总结。后来，在Brooks Law著名的人月神话中，引用这个论点，并将其“吹捧”成了如今咱们熟知“康威定律”。

康威定律详细介绍

Mike从他的角度概括这篇论文中的其余一些核心观点，以下：

• 第必定律
  • Communication dictates design
  • 组织沟通方式会经过系统设计表达出来
• 第二定律
  • There is never enough time to do something right, but there is always enough time to do it over
  • 时间再多一件事情也不可能作的完美，但总有时间作完一件事情
• 第三定律
  • There is a homomorphism from the linear graph of a system to the linear graph of its design organization
  • 线型系统和线型组织架构间有潜在的异质同态特性
• 第四定律
  • The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems
  • 大的系统组织老是比小系统更倾向于分解

人是复杂社会动物

• 第必定律
  • Communication dictates design
  • 组织沟通方式决定系统设计

组织的沟通和系统设计之间的紧密联系，在不少别的领域有相似的阐述。对于复杂的系统，聊设计就离不开聊人与人的沟通，解决好人与人的沟通问题，才能有一个好的系统设计。相信几乎每一个程序员都读过的《人月神话》（1975年，感受都是老古董了，经典的就是经得起时间考验）里面许多观点都和这句话有殊途同归之妙。

 

好比《人月神话》中最著名的一句话就是

Adding manpower to a late software project makes it later --Fred Brooks, (1975)

Boss们都听到了吗？为了赶进度加程序员就像用水去灭油锅里的火同样（无奈你们仍是前赴后继）。

为何？人月神话也给出了很简洁的答案：沟通成本 = 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

因此知道为何互联网创业公司都这么小了吧，必须小啊，否则等CEO和全部人讲一遍创业的想法后，风投的钱都烧完了。

Mike还举了一个很是有意思的理论，叫“Dunbar Number”，这是一个叫Dunbar（废话）生物学家在1992年最先提出来的。最初，他发现灵长类的大脑容量和其对应的族群大小有必定关联，进而推断出人类的大脑能维系的关系的一些有趣估计。举例来讲

• 亲密（intimate）朋友: 5
• 信任（trusted）朋友: 15
• 酒肉（close）朋友: 35
• 照面（casual）朋友: 150

是否是和上面的沟通成本的数字很貌似有关联？是的，咱们的大脑智力只能支持咱们维系这么多的关系。（你们都知道这不是程序猿擅长的领域，在开发团队里，这个值应该更小，估计和猿差很少 -_-凸 ）

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

一口气吃不成胖子，先搞定能搞定的

• 第二定律:
  • There is never enough time to do something right, but there is always enough time to do it over
  • 时间再多一件事情也不可能作的完美，但总有时间作完一件事情

Eric Hollnagel是敏捷开发社区的泰斗之一，在他《Efficiency-Effectiveness Trade Offs》 一书中解释了相似的论点。

Problem too complicated? Ignore details. 
Not enough resources?Give up features.
--Eric Hollnagel (2009)

 

系统越作越复杂，功能愈来愈多，外部市场的竞争愈来愈剧烈，投资人的期待愈来愈高。但人的智力是有上限的，即便再牛逼的人，融到钱再多也不必定招到足够多合适的人。对于一个巨复杂的系统，咱们永远没法考虑周全。Eric认为，这个时候最好的解决办法居然是——“破罐子破摔”。

其实咱们在平常开发中也常常碰到。产品经理的需求太复杂了？适当忽略一些细节，先抓主线。产品经理的需求太多了？放弃一些功能。

听说Eric被一家航空公司请去作安全咨询顾问，复杂保证飞机飞行系统的稳定性和安全性。Eric认为作到安全有两种方式：

• 常规的安全指的是尽量多的发现并消除错误的部分，达到绝对安全，这是理想。
• 另外一种则是弹性安全，即便发生错误，只要及时恢复，也能正常工做，这是现实。

对于飞机这样的复杂系统，再牛逼的人也没法考虑到漏洞的方方面面，因此Eric建议放弃打造完美系统的想法，而是经过不断的试飞，发现问题，确保问题发生时，系统能自动复原便可，而不追求飞行系统的绝对正确和安全。

下面的图很好的解释了这个过程：

听着很耳熟不是吗？这不就是 持续集成 和敏捷开发吗？的确就是。

另外一方面，这和互联网公司维护的分布式系统的弹性设计也是一个道理。对于一个分布式系统，咱们几乎永远不可能找到并修复全部的bug，单元测试覆盖1000%也没有用，错误流淌在分布式系统的血液里。解决方法不是消灭这些问题，而是容忍这些问题，在问题发生时，能自动回复，微服务组成的系统，每个微服务均可能挂掉，这是常态，咱们只有有足够的冗余和备份便可。即所谓的 弹性设计（Resilience） 或者叫高可用设计（High Availability）。

种瓜得瓜，作独立自治的字系统减小沟通成本

• 第三定律
  • There is a homomorphism from the linear graph of a system to the linear graph of its design organization
  • 线型系统和线型组织架构间有潜在的异质同态特性

这是康威第必定律组织和设计间内在关系的一个具体应用。更直白的说，你想要什么样的系统，就搭建什么样的团队。若是你的团队分红前端团队，Java后台开发团队，DBA团队，运维团队，你的系统就会长成下面的样子：

相反，若是你的系统是按照业务边界划分的，你们按照一个业务目标去把本身的模块作出小系统，小产品的话，你的大系统就会长成下面的样子，即微服务的架构

微服务的理念团队间应该是 inter-operate, not integrate 。inter-operate是定义好系统的边界和接口，在一个团队内全栈，让团队自治，缘由就是由于若是团队按照这样的方式组建，将沟通的成本维持在系统内部，每一个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能下降。

合久必分，分而治之

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

前面说了，人是复杂的社会动物，人与人的经过很是复杂。可是当咱们面对复杂系统时，又每每只能经过增长人力来解决。这时，咱们的组织通常是如何解决这个沟通问题的呢？Divide and conquer,分而治之。你们看看本身的公司的组织，是否是一个一线经理通常都是管理15我的如下的？二线经理再管理更少的一线？三线再管理更少的，以此类推。（这里彻底没有暗示开发经理比程序猿更难管理）

因此，一个大的组织由于沟通成本/管理问题，总为被拆分红一个个小团队。

• 创业的想法太好了，反正风投钱多，多招点程序猿
• 人多管不过来啊，找几个经理帮我管，我管经理
• 最后， 康威定律 告诉咱们组织沟通的方式会在系统设计上有所表达，每一个经理都被赋予必定的职责去作大系统的某一小部分，他们和大系统便有了沟通的边界，因此大的系统也会所以被拆分红一个个小团队负责的小系统（微服务是一种好的模式）

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

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

• 人与人的沟通是很是复杂的，一我的的沟通精力是有限的，因此当问题太复杂须要不少人解决的时候，咱们须要作拆分组织来达成对沟通效率的管理
• 组织内人与人的沟通方式决定了他们参与的系统设计，管理者能够经过不一样的拆分方式带来不一样的团队间沟通方式，从而影响系统设计
• 若是子系统是内聚的，和外部的沟通边界是明确的，能下降沟通成本，对应的设计也会更合理高效
• 复杂的系统须要经过容错弹性的方式持续优化，不要期望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的

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

• 咱们要用一切手段提高沟通效率，好比slack，github，wiki。能2我的讲清楚的事情，就不要拉更多人，每一个人每一个系统都有明确的分工，出了问题知道立刻找谁，避免踢皮球的问题。
• 经过MVP的方式来设计系统，经过不断的迭代来验证优化，系统应该是弹性设计的。
• 你想要什么样的系统设计，就架构什么样的团队，能扁平化就扁平化。最好按业务来划分团队，这样能让团队天然的自治内聚，明确的业务边界会减小和外部的沟通成本，每一个小团队都对本身的模块的整个生命周期负责，没有边界不清，没有无效的扯皮，inter-operate, not integrate。
• 作小而美的团队，人多会带来沟通的成本，让效率降低。亚马逊的Bezos有个逗趣的比喻，若是2个披萨不够一个团队吃的，那么这个团队就太大了。事实上通常一个互联网公司小产品的团队差很少就是7，8人左右（包含先后端测试交互用研等，可能身兼数职）。

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

• 分布式服务组成的系统
• 按照业务而不是技术来划分组织
• 作有生命的产品而不是项目
• Smart endpoints and dumb pipes（个人理解是强服务个体和弱通讯）
• 自动化运维（DevOps）
• 容错
• 快速演化

参考资料

• 远距离条件下的康威定律——分布式世界中实现团队构建，本文图片来源该ppt截图
• Conway‘s Law in wiki
• Conway's Law Homepage