关于微服务的概要，请参考微服务。
微服务是最近非常火热的新概念，大家都在追，都认为是正确的，但似乎没有足够的理论基础来说明它是正确的。 快速高跟鞋不明显。 前不久，看到Mike amundsen 《远距离条件下的tmdbg定律——分布式世界中实现团队构建》 (designrestfulapi作者)在InfoQ上的分享，我觉得很有帮助，结合自己的思考，整理了那个演讲的内容。
一个可能让很多人感到意外的事实是，微服务的许多核心理念其实在半个世纪前的一篇文章中有所阐述，而且这篇文章中的许多论点在软件开发快速发展的半个世纪中得到了多次验证。 这就是tmdbg定律(Conway's Law )。
在tmdbg的这篇文章中，最有名的词是：
organizationswhichdesignsystemsareconstrainedtoproducedesignswhicharecopiesofthecommunicationstructuresoftheseorganizations .
中文直译意味着设计系统的组织，其设计等同于组织内、组织间的交流结构。 看看下面的图片(从网上入侵删除)，再想想苹果的产品、微软的产品设计，就能形象生动地理解这句话。
一般说来，组织形式与系统设计相同。
这里的系统在原作者的意义上不限于软件系统。 这篇文章最初发表的哈佛商业评论，据说是因为程序员的木屐文章没有进入商人的法眼，被无情地拒绝了，tmdbg被发表在了编程相关的杂志上，所以被误解为面向软件开发。 第一篇文章显然不敢自称定律(law )，只是描写了作者自己的发现和总结。 之后，在Brooks Law著名的人月神话中引用了这个论点，并将其“吹捧”成了现在我们熟知的“tmdbg定律”。
tmdbg定律详细介绍了Mike从他的角度总结了本文的其他几个核心观点，如下。
http://www.Sina.com/communicationdictatesdesign (组织的交流方式通过系统设计表现) http://www.Sina.com/thereisneverenoughtimetodosomethingresign butthereisalwaysenoughtimetodoitover ()虽然有多少时间也做不到完美，但是总是有时间去完成一件事(330 ) thereisahomorphismfromthelineargraphofasystemtothelineargraphofitsdesignorganization (线性系统和线性组织结构之间存在潜在的异质同构特性) 3358 www . oflargesystemstendtodisintegrateduringdevelopment、 qualitativelymoresothanwithsmallsystems (大系统组织总是比小系统更容易分解)人是复杂的社会动物http://www.Sina.com/communicationdictation
组织的交流和系统设计之间的密切联系在许多其他领域中得到了同样的描述。 复杂的系统，聊天设计离不开人与人之间的交流，只有解决好的人与人之间的交流问题，才能有好的系统设计。 大多数程序员读过的《人月神话》(1975年，感觉像个古董，但经典的是经得起时间的考验() )的许多观点与这句话有不同的含义。
例如《人月神话》中最有名的词是
addingmanpowertoalatesoftwareprojectmakesitlater---- Fred brooks，1975年
老板们都听到了吗？ 为了加快进度而添加程序员，就像用水熄灭锅里的火一样。
为什么？ 人月神话也给出了简明的答案。 交流成本=n(n-1 )/2，交流成本随着项目和组织人员的增加呈指数函数增长。 是的，项目管理算法的复杂性是o(n^2)。 举一个例子
5人项目团队，需要沟通的渠道为5 * (51 )/2=1015人的项目团队，需要沟通的渠道为15 * (151 )/2=10550人的项目团队
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是敏捷开发社区的fzdxlc之一，在他《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（线型系统和线型组织架构间有潜在的异质同态特性）
这是tmdbg第一定律组织和设计间内在关系的一个具体应用。更直白的说，你想要什么样的系统，就搭建什么样的团队。如果你的团队分成前端团队，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个人以下的？二线经理再管理更少的一线？三线再管理更少的，以此类推。（这里完全没有暗示开发经理比程序猿更难管理）
所以，一个大的组织因为沟通成本/管理问题，总为被拆分成一个个小团队。
创业的想法太好了，反正风投钱多，多招点程序猿人多管不过来啊，找几个经理帮我管，我管经理最后， tmdbg定律 告诉我们组织沟通的方式会在系统设计上有所表达，每个经理都被赋予一定的职责去做大系统的某一小部分，他们和大系统便有了沟通的边界，所以大的系统也会因此被拆分成一个个小团队负责的小系统（微服务是一种好的模式）tmdbg定律如何解释微服务的合理性了解了tmdbg定律是什么，再来看看他如何在半个世纪前就奠定了微服务架构的理论基础。
人与人的沟通是非常复杂的，一个人的沟通精力是有限的，所以当问题太复杂需要很多人解决的时候，我们需要做拆分组织来达成对沟通效率的管理组织内人与人的沟通方式决定了他们参与的系统设计，管理者可以通过不同的拆分方式带来不同的团队间沟通方式，从而影响系统设计如果子系统是内聚的，和外部的沟通边界是明确的，能降低沟通成本，对应的设计也会更合理高效复杂的系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的带来的具体的实践建议是：
我们要用一切手段提升沟通效率，比如slack，github，wiki。能2个人讲清楚的事情，就不要拉更多人，每个人每个系统都有明确的分工，出了问题知道马上找谁，避免踢皮球的问题。通过MVP的方式来设计系统，通过不断的迭代来验证优化，系统应该是弹性设计的。你想要什么样的系统设计，就架构什么样的团队，能扁平化就扁平化。最好按业务来划分团队，这样能让团队自然的自治内聚，明确的业务边界会减少和外部的沟通成本，每个小团队都对自己的模块的整个生命周期负责，没有边界不清，没有无效的扯皮，inter-operate, not integrate。做小而美的团队，人多会带来沟通的成本，让效率下降。亚马逊的lldrg有个逗趣的比喻，如果2个披萨不够一个团队吃的，那么这个团队就太大了。事实上一般一个互联网公司小产品的团队差不多就是7，8人左右（包含前后端测试交互用研等，可能身兼数职）。再对应下衡量微服务的标准，我们很容易会发现他们之间的密切关系：
分布式服务组成的系统按照业务而不是技术来划分组织做有生命的产品而不是项目Smart endpoints and dumb pipes（我的理解是强服务个体和弱通信）自动化运维（DevOps）容错快速演化参考资料 远距离条件下的tmdbg定律——分布式世界中实现团队构建，本文图片来源该ppt截图Conway‘s Law in wikiConway's Law Homepage