康威定律。
几天讨论了一下如何拆分微服务，拆分粒度？
按照单一职责原则和康威定律，在业务域、团队还有技术上平衡粒度。
延伸讨论了 什么是康威定律
康威定律
第一定律
Communication dictates design
组织沟通方式会通过系统设计表达出来
沟通成本 = n(n-1)/2
0人====>0
1人====>0
2人====>1
3人====>3
4人====>6
5人====>10
6人====>15
7人====>21
8人====>28
9人====>36
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认为做到安全有两种方式：
常规的安全指的是尽可能多的发现并消除错误的部分，达到绝对安全，这是理想。
另一种则是弹性安全，即使发生错误，只要及时恢复，也能正常工作，这是现实。
对于一个分布式系统，我们几乎永远不可能找到并修复所有的bug，单元测试覆盖1000%也没有用，错误流淌在分布式系统的血液里。解决方法不是消灭这些问题，而是容忍这些问题，在问题发生时，能自动回复，微服务组成的系统，每一个微服务都可能挂掉，这是常态，我们只有有足够的冗余和备份即可。即所谓的 弹性设计（Resilience） 或者叫高可用设计（High Availability）。
种瓜得瓜，做独立自治的字系统减少沟通成本
第三定律
There is a homomorphism from the linear graph of a system to the linear graph of its design organization
线型系统和线型组织架构间有潜在的异质同态特性
微服务的理念团队间应该是 inter-operate, not integrate 。inter-operate是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能降低。
第四定律
The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems
大的系统组织总是比小系统更倾向于分解
所以，一个大的组织因为沟通成本/管理问题，总为被拆分成一个个小团队。
创业的想法太好了，反正风投钱多，多招点程序猿
人多管不过来啊，找几个经理帮我管，我管经理
最后， 康威定律 告诉我们组织沟通的方式会在系统设计上有所表达，每个经理都被赋予一定的职责去做大系统的某一小部分，他们和大系统便有了沟通的边界，所以大的系统也会因此被拆分成一个个小团队负责的小系统（微服务是一种好的模式）
带来的具体的实践建议是：
我们要用一切手段提升沟通效率，比如slack，github，wiki。能2个人讲清楚的事情，就不要拉更多人，每个人每个系统都有明确的分工，出了问题知道马上找谁，避免踢皮球的问题。
通过MVP的方式来设计系统，通过不断的迭代来验证优化，系统应该是弹性设计的。
你想要什么样的系统设计，就架构什么样的团队，能扁平化就扁平化。最好按业务来划分团队，这样能让团队自然的自治内聚，明确的业务边界会减少和外部的沟通成本，每个小团队都对自己的模块的整个生命周期负责，没有边界不清，没有无效的扯皮，inter-operate, not integrate。
做小而美的团队，人多会带来沟通的成本，让效率下降。亚马逊的Bezos有个逗趣的比喻，如果2个披萨不够一个团队吃的，那么这个团队就太大了。事实上一般一个互联网公司小产品的团队差不多就是7，8人左右（包含前后端测试交互用研等，可能身兼数职）。
再对应下衡量微服务的标准，我们很容易会发现他们之间的密切关系：
分布式服务组成的系统
按照业务而不是技术来划分组织
做有生命的产品而不是项目
Smart endpoints and dumb pipes（我的理解是强服务个体和弱通信）
自动化运维（DevOps）
容错
快速演化
