微服务这个概念一直很火，现在ServiceMesh概念更火，最近我经手的多个项目也都采用微服务的方式开发。但实践发现，当一个RD同时开发超过2个微服务的时候，出现bug或故障的概率会提升。
我现在看项目的时候会不自觉的关注工程服务拆分个数和研发人数的比值。虽然这么做，我却说不出来个所以然，也没有找到一个理论依据。
一、引子
最近读到Spring Cloud Alibaba成员姬望（彭文杰）的一篇采访稿，解开了我的一些疑惑。原文在这里
https://mp.weixin.qq.com/s/jArp9LUnLv9jveh9qTndfA
我摘录了比较关键的一段
微服务解决的本质问题是团队分工
SOA 也好、微服务也好，解决的根本问题是团队分工问题，详见康威定律，这是大型软件发展的必然，不因为人的喜好而改变。当你读懂康威定律，就会发现“服务拆分粒度难以准确把握”根本不是本质问题。
你有几个 2 pizza 团队，最好就拆成几个微服务。举一个现实的例子：只有一个开发人员时，尽量就做单体应用，不要没事找刺激拆成 10 个微服务，最终这个开发人员还会把他合成一个。微服务要求纵向的 2 pizza 团队（无数个小团队，包含开发、测试、运维），当然我们也实施过一些传统大型企业，但团队还是处在横向结构的场景下（开发、运维、测试各是一个团队），拆分微服务让他们很痛苦，尤其是运维团队。
这段话里有两个概念2 pizza团队和康威定律
2 pizza团队
两个披萨原则是指与会人数不能多到两个披萨饼还不够他们吃的地步。亚马逊CEO杰夫·贝索斯(JeffBezos)认为事实并非公司开会参与人数越多越好，他认为人数越多的会议将不利于决策的形成，而是会导致与会人员的人云亦云，称之为两个披萨原则。2 pizza团队可以简单理解为做某件事情的小团队。
康威定律
出乎很多人意料，微服务很多核心理念在半个世纪前（1968年）的《How Do Committees Invent?》一文中就被阐述过了，这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证，这就是康威定律（Conway's Law）
有意思的是该论点在提出多年后一直默默无名，后来Brooks Law著名的人月神话引用这个论点，“康威定律” 从此进入大众视野。
二、康威定律
wikipedia显示，康威定律（http://www.melconway.com/Home/Committees_Paper.html）最著名的一句话这这样的
“organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”
大致的意思是：系统设计(产品结构)等同组织形式，每个设计系统的组织，其产生的设计等同于组织之间的沟通结构（简单点说就是，系统的设计受限于设计系统的组织的人员架构形式。我们也经常说微服务不光是一个技术问题，更是一个研发组织问题）
想一想你用过的产品，看一看下边这张图，也许能加深对康威定律的理解
Mike Amundsen （Design RESTful API的作者），在《远距离条件下的康威定律——分布式世界中实现团队构建》的一次技术分享中，从他的角度归纳这篇论文（《How Do Committees Invent?》）中的其他一些核心观点
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（大的系统组织总是比小系统更倾向于分解）
Mike Amundsen的更多细节不展开了，感兴趣可以自行搜索。
三、支持康威定律的证据
wikipedia在康威定律条目的Supporting evidence章节有如下描述。
麻省理工学院和哈佛商学院研究小组发表了支持康威定律的证据，他们使用“镜像假设”作为康威定律的等效术语，发现“支持镜像假设”的有力证据，“[产品]模块化的显着差异”与“分布式团队倾向于开发更多模块化产品的观点一致”。
马里兰大学的Nagappan、Murphy和Basili与微软合作，以及芬兰坦佩雷理工大学的Syeed和Hammouda的案例研究，同样支持康威定律。
四、康威定律如何解释微服务的合理性
了解了康威定律是什么，再来看看他如何在半个世纪前就奠定了微服务架构的理论基础。
人与人的沟通是非常复杂的，一个人的沟通精力是有限的，所以当问题太复杂需要很多人解决的时候，我们需要做拆分组织来达成对沟通效率的管理
组织内人与人的沟通方式决定了他们参与的系统设计，管理者可以通过不同的拆分方式带来不同的团队间沟通方式，从而影响系统设计
如果子系统是内聚的，和外部的沟通边界是明确的，能降低沟通成本，对应的设计也会更合理高效
复杂的系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的
带来的具体的实践建议是
我们要用一切手段提升沟通效率，比如slack，github，wiki。能2个人讲清楚的事情，就不要拉更多人，每个人每个系统都有明确的分工，出了问题知道马上找谁，避免踢皮球的问题。
通过MVP的方式来设计系统，通过不断的迭代来验证优化，系统应该是弹性设计的。
你想要什么样的系统设计，就架构什么样的团队，能扁平化就扁平化。最好按业务来划分团队，这样能让团队自然的自治内聚，明确的业务边界会减少和外部的沟通成本，每个小团队都对自己的模块的整个生命周期负责，没有边界不清，没有无效的扯皮，inter-operate, not integrate。
做小而美的团队，人多会带来沟通的成本，让效率下降。亚马逊的Bezos有个逗趣的比喻，如果2个披萨不够一个团队吃的，那么这个团队就太大了。事实上一般一个互联网公司小产品的团队差不多就是7，8人左右。
公司级的组织结构设置看起来层次很高，回到最初的问题，你的小团队微服务到底拆分多少合适呢？
《How Do Committees Invent?》文中提到任务的拆解可以嵌套进行，意思是先按照大力度拆，拆分出的部分继续按照更细的粒度拆分，直到不需要拆分为止。
结合阿里姬望和我个人的经验。如果你还是新手，那么你预期项目有几个人开发就拆成几个部分一般不会有大的问题；如果你比较有经验，可以结合公司微服务的治理能力灵活发挥。
总之，只要说得清楚，运维能力又能跟上，一般就是合理的！
