邱小俠

阿里高級(jí)技術(shù)專家

讀完需要

10

分鐘

速讀僅需 4 分鐘

邱小俠，阿里巴巴集團(tuán)客戶體驗(yàn)事業(yè)群高級(jí)技術(shù)專家，阿里花名肥俠。2014年加入阿里巴巴，現(xiàn)在負(fù)責(zé)客戶體驗(yàn)驅(qū)動(dòng)及創(chuàng)新中心有關(guān)商家業(yè)務(wù)的開發(fā)工作。負(fù)責(zé)開發(fā)了商家維權(quán)中心和商家品控平臺(tái)，同時(shí)也負(fù)責(zé)集團(tuán)在線工作臺(tái)和知識(shí)庫(kù)的研發(fā)工作。擅長(zhǎng)Java核心技術(shù)、分布式系統(tǒng)與計(jì)算、開發(fā)框架與中間件、項(xiàng)目管理與軟件工程和架構(gòu)。

1

? ?

概述

關(guān)于微服務(wù)的介紹，網(wǎng)上已經(jīng)有很多文章了。

微服務(wù)大家都在追，也都覺(jué)得很對(duì)，但是似乎沒(méi)有很充足的理論基礎(chǔ)說(shuō)明這是正確的，給人的感覺(jué)是 不明覺(jué)厲 。前段時(shí)間看了 Mike Amundsen 《遠(yuǎn)距離條件下的康威定律——分布式世界中實(shí)現(xiàn)團(tuán)隊(duì)構(gòu)建》（是 Design RESTful API 的作者）一個(gè)分享，覺(jué)得很有幫助，結(jié)合自己的一些思考，整理了該演講的內(nèi)容。

可能出乎很多人意料之外的一個(gè)事實(shí)是，微服務(wù)很多核心理念其實(shí)在半個(gè)世紀(jì)前的一篇文章中就被闡述過(guò)了，而且這篇文章中的很多論點(diǎn)在軟件開發(fā)飛速發(fā)展的這半個(gè)世紀(jì)中竟然一再被驗(yàn)證，這就是康威定律（Conway's Law）。

在康威的這篇文章中，最有名的一句話就是：

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

中文直譯大概的意思就是：

設(shè)計(jì)系統(tǒng)的組織，其產(chǎn)生的設(shè)計(jì)等同于組織之內(nèi)、組織之間的溝通結(jié)構(gòu)。

看看下面的圖片，再想想 Apple 的產(chǎn)品、微軟的產(chǎn)品設(shè)計(jì)，就能形象生動(dòng)的理解這句話。

用通俗的說(shuō)法就是：

組織形式等同系統(tǒng)設(shè)計(jì)。

這里的系統(tǒng)按原作者的意思并不局限于軟件系統(tǒng)。據(jù)說(shuō)這篇文章最初投的哈佛商業(yè)評(píng)論，結(jié)果程序員屌絲的文章不入商業(yè)人士的法眼，無(wú)情被拒，康威就投到了一個(gè)編程相關(guān)的雜志，所以被誤解為是針對(duì)軟件開發(fā)的。最初這篇文章顯然不敢自稱定律（law），只是描述了作者自己的發(fā)現(xiàn)和總結(jié)。后來(lái)，在 Brooks Law 著名的人月神話中，引用這個(gè)論點(diǎn)，并將其“吹捧”成了現(xiàn)在我們熟知“康威定律”。

2

? ?

康威定律詳細(xì)介紹

Mike 從他的角度歸納這篇論文中的其他一些核心觀點(diǎn)，如下：

第一定律

- Communication dictates design- 組織溝通方式會(huì)通過(guò)系統(tǒng)設(shè)計(jì)表達(dá)出來(lái)

第二定律

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

第三定律

- 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)特性

第四定律

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

3

? ?

定律說(shuō)明

3.1

? ?

第一定律

人是復(fù)雜社會(huì)動(dòng)物

組織的溝通和系統(tǒng)設(shè)計(jì)之間的緊密聯(lián)系，在很多別的領(lǐng)域有類似的闡述。對(duì)于復(fù)雜的系統(tǒng)，聊設(shè)計(jì)就離不開聊人與人的溝通，解決好人與人的溝通問(wèn)題，才能有一個(gè)好的系統(tǒng)設(shè)計(jì)。相信幾乎每個(gè)程序員都讀過(guò)的《人月神話》（1975 年，感覺(jué)都是老古董了，經(jīng)典的就是經(jīng)得起時(shí)間考驗(yàn)）里面許多觀點(diǎn)都和這句話有異曲同工之妙。

比如《人月神話》中最著名的一句話就是

Adding manpower to a late software project makes it later --Fred Brooks, (1975)

Boss 們都聽(tīng)到了嗎？為了趕進(jìn)度加程序員就像用水去滅油鍋里的火一樣（無(wú)奈大家還是前赴后繼）。

為什么？人月神話也給出了很簡(jiǎn)潔的答案：溝通成本 = n(n-1)/2，溝通成本隨著項(xiàng)目或者組織的人員增加呈指數(shù)級(jí)增長(zhǎng)。是的，項(xiàng)目管理這個(gè)算法的復(fù)雜度是 O(n^2)。舉個(gè)例子

• 5 個(gè)人的項(xiàng)目組，需要溝通的渠道是 5*(5–1)/2 = 10

• 15 個(gè)人的項(xiàng)目組，需要溝通的渠道是 15*(15–1)/2 = 105

• 50 個(gè)人的項(xiàng)目組，需要溝通的渠道是 50*(50–1)/2 = 1,225

• 150 個(gè)人的項(xiàng)目組，需要溝通的渠道是 150*(150–1)/2 = 11,175

所以知道為什么互聯(lián)網(wǎng)創(chuàng)業(yè)公司都這么小了吧，必須小啊，不然等 CEO 和所有人講一遍創(chuàng)業(yè)的想法后，風(fēng)投的錢都燒完了。

Mike 還舉了一個(gè)非常有意思的理論，叫“Dunbar Number”，這是一個(gè)叫 Dunbar（廢話）生物學(xué)家在 1992 年最早提出來(lái)的。最初，他發(fā)現(xiàn)靈長(zhǎng)類的大腦容量和其對(duì)應(yīng)的族群大小有一定關(guān)聯(lián)，進(jìn)而推斷出人類的大腦能維系的關(guān)系的一些有趣估計(jì)。舉例來(lái)說(shuō)

• 親密（intimate）朋友: 5

• 信任（trusted）朋友: 15

• 酒肉（close）朋友: 35

• 照面（casual）朋友: 150

是不是和上面的溝通成本的數(shù)字很貌似有關(guān)聯(lián)？是的，我們的大腦智力只能支持我們維系這么多的關(guān)系。（大家都知道這不是程序猿擅長(zhǎng)的領(lǐng)域，在開發(fā)團(tuán)隊(duì)里，這個(gè)值應(yīng)該更小，估計(jì)和猿差不多 -_-凸 ）

溝通的問(wèn)題，會(huì)帶來(lái)系統(tǒng)設(shè)計(jì)的問(wèn)題，進(jìn)而影響整個(gè)系統(tǒng)的開發(fā)效率和最終產(chǎn)品結(jié)果。

3.2

? ?

第二定律:

一口氣吃不成胖子，先搞定能搞定的。

Eric Hollnagel 是敏捷開發(fā)社區(qū)的泰斗之一，在他《Efficiency-Effectiveness Trade Offs》 一書中解釋了類似的論點(diǎn)。

Problem too complicated? Ignore details.?

Not enough resources？Give up features.--Eric Hollnagel (2009)

系統(tǒng)越做越復(fù)雜，功能越來(lái)越多，外部市場(chǎng)的競(jìng)爭(zhēng)越來(lái)越劇烈，投資人的期待越來(lái)越高。但人的智力是有上限的，即使再牛逼的人，融到錢再多也不一定招到足夠多合適的人。對(duì)于一個(gè)巨復(fù)雜的系統(tǒng)，我們永遠(yuǎn)無(wú)法考慮周全。Eric 認(rèn)為，這個(gè)時(shí)候最好的解決辦法竟然是——“破罐子破摔”。

其實(shí)我們?cè)谌粘ｉ_發(fā)中也經(jīng)常碰到。產(chǎn)品經(jīng)理的需求太復(fù)雜了？適當(dāng)忽略一些細(xì)節(jié)，先抓主線。產(chǎn)品經(jīng)理的需求太多了？放棄一些功能。

據(jù)說(shuō) Eric 被一家航空公司請(qǐng)去做安全咨詢顧問(wèn)，復(fù)雜保證飛機(jī)飛行系統(tǒng)的穩(wěn)定性和安全性。Eric 認(rèn)為做到安全有兩種方式：

• 常規(guī)的安全指的是盡可能多的發(fā)現(xiàn)并消除錯(cuò)誤的部分，達(dá)到絕對(duì)安全，這是理想。

• 另一種則是彈性安全，即使發(fā)生錯(cuò)誤，只要及時(shí)恢復(fù)，也能正常工作，這是現(xiàn)實(shí)。

對(duì)于飛機(jī)這樣的復(fù)雜系統(tǒng)，再牛逼的人也無(wú)法考慮到漏洞的方方面面，所以 Eric 建議放棄打造完美系統(tǒng)的想法，而是通過(guò)不斷的試飛，發(fā)現(xiàn)問(wèn)題，確保問(wèn)題發(fā)生時(shí)，系統(tǒng)能自動(dòng)復(fù)原即可，而不追求飛行系統(tǒng)的絕對(duì)正確和安全。

下面的圖很好的解釋了這個(gè)過(guò)程：

聽(tīng)著很耳熟不是嗎？這不就是 持續(xù)集成 和敏捷開發(fā)嗎？的確就是。

另一方面，這和互聯(lián)網(wǎng)公司維護(hù)的分布式系統(tǒng)的彈性設(shè)計(jì)也是一個(gè)道理。對(duì)于一個(gè)分布式系統(tǒng)，我們幾乎永遠(yuǎn)不可能找到并修復(fù)所有的 bug，單元測(cè)試覆蓋 1000%也沒(méi)有用，錯(cuò)誤流淌在分布式系統(tǒng)的血液里。解決方法不是消滅這些問(wèn)題，而是容忍這些問(wèn)題，在問(wèn)題發(fā)生時(shí)，能自動(dòng)回復(fù)，微服務(wù)組成的系統(tǒng)，每一個(gè)微服務(wù)都可能掛掉，這是常態(tài)，我們只有有足夠的冗余和備份即可。即所謂的 彈性設(shè)計(jì)（Resilience） 或者叫高可用設(shè)計(jì)（High Availability）。

3.3

? ?

第三定律

種瓜得瓜，做獨(dú)立自治的字系統(tǒng)減少溝通成本

這是康威第一定律組織和設(shè)計(jì)間內(nèi)在關(guān)系的一個(gè)具體應(yīng)用。更直白的說(shuō)，你想要什么樣的系統(tǒng)，就搭建什么樣的團(tuán)隊(duì)。如果你的團(tuán)隊(duì)分成前端團(tuán)隊(duì)，Java 后臺(tái)開發(fā)團(tuán)隊(duì)，DBA 團(tuán)隊(duì)，運(yùn)維團(tuán)隊(duì)，你的系統(tǒng)就會(huì)長(zhǎng)成下面的樣子：

相反，如果你的系統(tǒng)是按照業(yè)務(wù)邊界劃分的，大家按照一個(gè)業(yè)務(wù)目標(biāo)去把自己的模塊做出小系統(tǒng)，小產(chǎn)品的話，你的大系統(tǒng)就會(huì)長(zhǎng)成下面的樣子，即微服務(wù)的架構(gòu)

微服務(wù)的理念團(tuán)隊(duì)間應(yīng)該是 inter-operate, not integrate 。inter-operate 是定義好系統(tǒng)的邊界和接口，在一個(gè)團(tuán)隊(duì)內(nèi)全棧，讓團(tuán)隊(duì)自治，原因就是因?yàn)槿绻麍F(tuán)隊(duì)按照這樣的方式組建，將溝通的成本維持在系統(tǒng)內(nèi)部，每個(gè)子系統(tǒng)就會(huì)更加內(nèi)聚，彼此的依賴耦合能變?nèi)?#xff0c;跨系統(tǒng)的溝通成本也就能降低。

3.4

? ?

第四定律

合久必分，分而治之

前面說(shuō)了，人是復(fù)雜的社會(huì)動(dòng)物，人與人的通過(guò)非常復(fù)雜。但是當(dāng)我們面對(duì)復(fù)雜系統(tǒng)時(shí)，又往往只能通過(guò)增加人力來(lái)解決。這時(shí)，我們的組織一般是如何解決這個(gè)溝通問(wèn)題的呢？Divide and conquer,分而治之。大家看看自己的公司的組織，是不是一個(gè)一線經(jīng)理一般都是管理 15 個(gè)人以下的？二線經(jīng)理再管理更少的一線？三線再管理更少的，以此類推。（這里完全沒(méi)有暗示開發(fā)經(jīng)理比程序猿更難管理）

所以，一個(gè)大的組織因?yàn)闇贤ǔ杀?管理問(wèn)題，總為被拆分成一個(gè)個(gè)小團(tuán)隊(duì)。

• 創(chuàng)業(yè)的想法太好了，反正風(fēng)投錢多，多招點(diǎn)程序猿

• 人多管不過(guò)來(lái)啊，找?guī)讉€(gè)經(jīng)理幫我管，我管經(jīng)理

• 最后， 康威定律 告訴我們組織溝通的方式會(huì)在系統(tǒng)設(shè)計(jì)上有所表達(dá)，每個(gè)經(jīng)理都被賦予一定的職責(zé)去做大系統(tǒng)的某一小部分，他們和大系統(tǒng)便有了溝通的邊界，所以大的系統(tǒng)也會(huì)因此被拆分成一個(gè)個(gè)小團(tuán)隊(duì)負(fù)責(zé)的小系統(tǒng)（微服務(wù)是一種好的模式）

4

? ?

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

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

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

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

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

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

帶來(lái)的具體的實(shí)踐建議是：

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

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

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

• 做小而美的團(tuán)隊(duì)，人多會(huì)帶來(lái)溝通的成本，讓效率下降。亞馬遜的 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 人左右（包含前后端測(cè)試交互用研等，可能身兼數(shù)職）。

再對(duì)應(yīng)下衡量微服務(wù)的標(biāo)準(zhǔn)，我們很容易會(huì)發(fā)現(xiàn)他們之間的密切關(guān)系：

• 分布式服務(wù)組成的系統(tǒng)

• 按照業(yè)務(wù)而不是技術(shù)來(lái)劃分組織

• 做有生命的產(chǎn)品而不是項(xiàng)目

• Smart endpoints and dumb pipes（我的理解是強(qiáng)服務(wù)個(gè)體和弱通信）

• 自動(dòng)化運(yùn)維（DevOps）

• 容錯(cuò)

• 快速演化

原文出處：?https://yq.aliyun.com/articles/8611?

想要加入中生代架構(gòu)群的小伙伴，請(qǐng)?zhí)砑尤汉匣锶?strong>大白的微信

申請(qǐng)備注（姓名+公司+技術(shù)方向）才能通過(guò)哦！

? ?END ? ?? #接力技術(shù)，鏈接價(jià)值#精彩推薦1.?可能是全網(wǎng)最通俗易懂的微服務(wù)架構(gòu)改造解讀2.?導(dǎo)致微服務(wù)失敗的 11 個(gè)原因 3.?停！你不需要微服務(wù) 4.?胡忠想|微博微服務(wù)架構(gòu)的Service Mesh實(shí)踐之路漫畫推薦1.?漫畫：程序員和產(chǎn)品經(jīng)理撕得真是太太太太厲害了 2.?漫畫：程序員真的是太太太太太太太太難了！3.?漫畫：普通程序員 vs 優(yōu)秀程序員 4.?漫畫：35歲的IT何去何從？ 5.?漫畫：從修燈泡來(lái)看各種 IT 崗位，你是哪一種？ 6. 漫畫：一批90后已經(jīng)30歲了，更扎心的是…7. 圖解：這才是程序員加班的真正原因！8.?漫畫：中國(guó)互聯(lián)網(wǎng)往事(2000-2020)未來(lái)的CTO們點(diǎn)下在看支持小編吧，叩謝！

總結(jié)

以上是生活随笔為你收集整理的阿里高级技术专家邱小侠：微服务架构的理论基础 - 康威定律的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。