微服务

之前有读《架构即未来》这本书，了解到组织架构即系统架构的理念。之前看到有关于康恩定律的深度解读，感觉比较有收获。

微服务是前几年的概念，大家都在追，都觉得很对，也都在执行，但似乎没有很充足的理论基础说明这是正确的，给人的感觉是不明觉厉。

可能出乎很多人意料之外的一个事实是，微服务核心理论其实在半个世纪以前的一篇文章已经被阐述过来额，而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中惊人一再被验证，这就是康威定律（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)

大致意思是：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。看看下面图片，就能形象生动的理解这句话。

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

康威定律详细介绍

第一定律

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)

为什么？人月神话也给出了很简洁的答案：沟通成本 = 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和所有人讲一遍创业的想法后，风投的钱都烧完了。

还有一个非常有意思的理论，叫“Dunbar Number”，这是一个叫邓巴的生物学家在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个人以下的？二线经理再管理更少的一线？三线再管理更少的，以此类推。（这里完全没有暗示开发经理比程序猿更难管理）