微服務這個概念一直很火，現在ServiceMesh概念更火，最近我經手的多個項目也都採用微服務的方式開發。但實踐發現，當一個RD同時開發超過2個微服務的時候，出現bug或故障的概率會提升。
我現在看項目的時候會不自覺的關注工程服務拆分個數和研發人數的比值。雖然這麼做，我卻說不出來個所以然，也沒有找到一個理論依據。
一、引子
最近讀到Spring Cloud Alibaba成員姬望（彭文杰）的一篇採訪稿，解開了我的一些疑惑。原文在微信公眾號裡文章裡搜索《Spring Cloud Alibaba，中國 Javaer 的福音，為微服務續上 18 年
我摘錄了比較關鍵的一段
微服務解決的本質問題是團隊分工
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顯示，康威定律最著名的一句話這這樣的
「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?》）中的其他一些核心觀點
1、Communication dictates design（組織溝通方式會通過系統設計表達出來）
2、There is never enough time to do something right, but there is always enough time to do it over（時間再多一件事情也不可能做的完美，但總有時間做完一件事情）
3、There is a homomorphism from the linear graph of a system to the linear graph of its design organization（線性系統和線性組織架構間有潛在的異質同態特性）
4、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?》文中提到任務的拆解可以嵌套進行，意思是先按照大力度拆，拆分出的部分繼續按照更細的粒度拆分，直到不需要拆分為止。
結合阿里姬望和我個人的經驗。如果你還是新手，那麼你預期項目有幾個人開發就拆成幾個部分一般不會有大的問題；如果你比較有經驗，可以結合公司微服務的治理能力靈活發揮。
總之，只要說得清楚，運維能力又能跟上，一般就是合理的！