微服務(wù)這個(gè)概念一直很火，現(xiàn)在ServiceMesh概念更火，最近我經(jīng)手的多個(gè)項(xiàng)目也都采用微服務(wù)的方式開發(fā)。但實(shí)踐發(fā)現(xiàn)，當(dāng)一個(gè)RD同時(shí)開發(fā)超過2個(gè)微服務(wù)的時(shí)候，出現(xiàn)bug或故障的概率會(huì)提升。

創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供宜黃網(wǎng)站建設(shè)、宜黃做網(wǎng)站、宜黃網(wǎng)站設(shè)計(jì)、宜黃網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、宜黃企業(yè)網(wǎng)站模板建站服務(wù)，十多年宜黃做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。

我現(xiàn)在看項(xiàng)目的時(shí)候會(huì)不自覺的關(guān)注工程服務(wù)拆分個(gè)數(shù)和研發(fā)人數(shù)的比值。雖然這么做，我卻說不出來個(gè)所以然，也沒有找到一個(gè)理論依據(jù)。

一、引子

最近讀到Spring Cloud Alibaba成員姬望（彭文杰）的一篇采訪稿，解開了我的一些疑惑。原文在這里

https://mp.weixin.qq.com/s/jArp9LUnLv9jveh9qTndfA

我摘錄了比較關(guān)鍵的一段

微服務(wù)解決的本質(zhì)問題是團(tuán)隊(duì)分工

SOA 也好、微服務(wù)也好，解決的根本問題是團(tuán)隊(duì)分工問題，詳見康威定律，這是大型軟件發(fā)展的必然，不因?yàn)槿说南埠枚淖?。?dāng)你讀懂康威定律，就會(huì)發(fā)現(xiàn)“服務(wù)拆分粒度難以準(zhǔn)確把握”根本不是本質(zhì)問題。

你有幾個(gè) 2 pizza 團(tuán)隊(duì)，最好就拆成幾個(gè)微服務(wù)。舉一個(gè)現(xiàn)實(shí)的例子：只有一個(gè)開發(fā)人員時(shí)，盡量就做單體應(yīng)用，不要沒事找刺激拆成 10 個(gè)微服務(wù)，最終這個(gè)開發(fā)人員還會(huì)把他合成一個(gè)。微服務(wù)要求縱向的 2 pizza 團(tuán)隊(duì)（無數(shù)個(gè)小團(tuán)隊(duì)，包含開發(fā)、測(cè)試、運(yùn)維），當(dāng)然我們也實(shí)施過一些傳統(tǒng)大型企業(yè)，但團(tuán)隊(duì)還是處在橫向結(jié)構(gòu)的場(chǎng)景下（開發(fā)、運(yùn)維、測(cè)試各是一個(gè)團(tuán)隊(duì)），拆分微服務(wù)讓他們很痛苦，尤其是運(yùn)維團(tuán)隊(duì)。

這段話里有兩個(gè)概念2 pizza團(tuán)隊(duì)和康威定律

2 pizza團(tuán)隊(duì)

兩個(gè)披薩原則是指與會(huì)人數(shù)不能多到兩個(gè)披薩餅還不夠他們吃的地步。亞馬遜CEO杰夫·貝索斯(JeffBezos)認(rèn)為事實(shí)并非公司開會(huì)參與人數(shù)越多越好，他認(rèn)為人數(shù)越多的會(huì)議將不利于決策的形成，而是會(huì)導(dǎo)致與會(huì)人員的人云亦云，稱之為兩個(gè)披薩原則。2 pizza團(tuán)隊(duì)可以簡單理解為做某件事情的小團(tuán)隊(duì)。

康威定律

出乎很多人意料，微服務(wù)很多核心理念在半個(gè)世紀(jì)前（1968年）的《How Do Committees Invent?》一文中就被闡述過了，這篇文章中的很多論點(diǎn)在軟件開發(fā)飛速發(fā)展的這半個(gè)世紀(jì)中竟然一再被驗(yàn)證，這就是康威定律（Conway's Law）

有意思的是該論點(diǎn)在提出多年后一直默默無名，后來Brooks Law著名的人月神話引用這個(gè)論點(diǎn)，“康威定律” 從此進(jìn)入大眾視野。

二、康威定律

wikipedia顯示，康威定律（http://www.melconway.com/Home/Committees_Paper.html）最著名的一句話這這樣的

“organizations which design systems areconstrained to produce designs which arecopies of the communication structures of these organizations.”

大致的意思是：系統(tǒng)設(shè)計(jì)(產(chǎn)品結(jié)構(gòu))等同組織形式，每個(gè)設(shè)計(jì)系統(tǒng)的組織，其產(chǎn)生的設(shè)計(jì)等同于組織之間的溝通結(jié)構(gòu)（簡單點(diǎn)說就是，系統(tǒng)的設(shè)計(jì)受限于設(shè)計(jì)系統(tǒng)的組織的人員架構(gòu)形式。我們也經(jīng)常說微服務(wù)不光是一個(gè)技術(shù)問題，更是一個(gè)研發(fā)組織問題）

想一想你用過的產(chǎn)品，看一看下邊這張圖，也許能加深對(duì)康威定律的理解 

Mike Amundsen （Design RESTful API的作者），在《遠(yuǎn)距離條件下的康威定律——分布式世界中實(shí)現(xiàn)團(tuán)隊(duì)構(gòu)建》的一次技術(shù)分享中，從他的角度歸納這篇論文（《How Do Committees Invent?》）中的其他一些核心觀點(diǎn)

1、Communication dictates design（組織溝通方式會(huì)通過系統(tǒng)設(shè)計(jì)表達(dá)出來）

2、There is never enough time to do something right, but there is always enough time to do it over（時(shí)間再多一件事情也不可能做的完美，但總有時(shí)間做完一件事情）

3、There is a homomorphism from the linear graph of a system to the linear graph of its design organization（線型系統(tǒng)和線型組織架構(gòu)間有潛在的異質(zhì)同態(tài)特性）

4、The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems（大的系統(tǒng)組織總是比小系統(tǒng)更傾向于分解）

Mike Amundsen的更多細(xì)節(jié)不展開了，感興趣可以自行搜索。

三、支持康威定律的證據(jù)

wikipedia在康威定律條目的Supporting evidence章節(jié)有如下描述。

麻省理工學(xué)院和哈佛商學(xué)院研究小組發(fā)表了支持康威定律的證據(jù)，他們使用“鏡像假設(shè)”作為康威定律的等效術(shù)語，發(fā)現(xiàn)“支持鏡像假設(shè)”的有力證據(jù)，“[產(chǎn)品]模塊化的顯著差異”與“分布式團(tuán)隊(duì)傾向于開發(fā)更多模塊化產(chǎn)品的觀點(diǎn)一致”。

馬里蘭大學(xué)的Nagappan、Murphy和Basili與微軟合作，以及芬蘭坦佩雷理工大學(xué)的Syeed和Hammouda的案例研究，同樣支持康威定律。

四、康威定律如何解釋微服務(wù)的合理性

了解了康威定律是什么，再來看看他如何在半個(gè)世紀(jì)前就奠定了微服務(wù)架構(gòu)的理論基礎(chǔ)。

• 人與人的溝通是非常復(fù)雜的，一個(gè)人的溝通精力是有限的，所以當(dāng)問題太復(fù)雜需要很多人解決的時(shí)候，我們需要做拆分組織來達(dá)成對(duì)溝通效率的管理

• 組織內(nèi)人與人的溝通方式?jīng)Q定了他們參與的系統(tǒng)設(shè)計(jì)，管理者可以通過不同的拆分方式帶來不同的團(tuán)隊(duì)間溝通方式，從而影響系統(tǒng)設(shè)計(jì)

• 如果子系統(tǒng)是內(nèi)聚的，和外部的溝通邊界是明確的，能降低溝通成本，對(duì)應(yīng)的設(shè)計(jì)也會(huì)更合理高效

• 復(fù)雜的系統(tǒng)需要通過容錯(cuò)彈性的方式持續(xù)優(yōu)化，不要指望一個(gè)大而全的設(shè)計(jì)或架構(gòu)，好的架構(gòu)和設(shè)計(jì)都是慢慢迭代出來的

帶來的具體的實(shí)踐建議是

• 我們要用一切手段提升溝通效率，比如slack，github，wiki。能2個(gè)人講清楚的事情，就不要拉更多人，每個(gè)人每個(gè)系統(tǒng)都有明確的分工，出了問題知道馬上找誰，避免踢皮球的問題。

• 通過MVP的方式來設(shè)計(jì)系統(tǒng)，通過不斷的迭代來驗(yàn)證優(yōu)化，系統(tǒng)應(yīng)該是彈性設(shè)計(jì)的。

• 你想要什么樣的系統(tǒng)設(shè)計(jì)，就架構(gòu)什么樣的團(tuán)隊(duì)，能扁平化就扁平化。最好按業(yè)務(wù)來劃分團(tuán)隊(duì)，這樣能讓團(tuán)隊(duì)自然的自治內(nèi)聚，明確的業(yè)務(wù)邊界會(huì)減少和外部的溝通成本，每個(gè)小團(tuán)隊(duì)都對(duì)自己的模塊的整個(gè)生命周期負(fù)責(zé)，沒有邊界不清，沒有無效的扯皮，inter-operate, not integrate。

• 做小而美的團(tuán)隊(duì)，人多會(huì)帶來溝通的成本，讓效率下降。亞馬遜的Bezos有個(gè)逗趣的比喻，如果2個(gè)披薩不夠一個(gè)團(tuán)隊(duì)吃的，那么這個(gè)團(tuán)隊(duì)就太大了。事實(shí)上一般一個(gè)互聯(lián)網(wǎng)公司小產(chǎn)品的團(tuán)隊(duì)差不多就是7，8人左右。

公司級(jí)的組織結(jié)構(gòu)設(shè)置看起來層次很高，回到最初的問題，你的小團(tuán)隊(duì)微服務(wù)到底拆分多少合適呢？

《How Do Committees Invent?》文中提到任務(wù)的拆解可以嵌套進(jìn)行，意思是先按照大力度拆，拆分出的部分繼續(xù)按照更細(xì)的粒度拆分，直到不需要拆分為止。

結(jié)合阿里姬望和我個(gè)人的經(jīng)驗(yàn)。如果你還是新手，那么你預(yù)期項(xiàng)目有幾個(gè)人開發(fā)就拆成幾個(gè)部分一般不會(huì)有大的問題；如果你比較有經(jīng)驗(yàn)，可以結(jié)合公司微服務(wù)的治理能力靈活發(fā)揮。

總之，只要說得清楚，運(yùn)維能力又能跟上，一般就是合理的！