邱小俠

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

讀完需要

10

分鐘

速讀僅需 4 分鐘

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

1

? ?

概述

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

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

可能出乎很多人意料之外的一個事實是，微服務(wù)很多核心理念其實在半個世紀(jì)前的一篇文章中就被闡述過了，而且這篇文章中的很多論點在軟件開發(fā)飛速發(fā)展的這半個世紀(jì)中竟然一再被驗證，這就是康威定律（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è)計系統(tǒng)的組織，其產(chǎn)生的設(shè)計等同于組織之內(nèi)、組織之間的溝通結(jié)構(gòu)。

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

用通俗的說法就是：

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

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

2

? ?

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

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

第一定律

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

第二定律

- 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- 線型系統(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

? ?

定律說明

3.1

? ?

第一定律

人是復(fù)雜社會動物

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

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

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

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

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

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

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

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

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

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

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

• 親密（intimate）朋友: 5

• 信任（trusted）朋友: 15

• 酒肉（close）朋友: 35

• 照面（casual）朋友: 150

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

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

3.2

? ?

第二定律:

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

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

Problem too complicated? Ignore details.?

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

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

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

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

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

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

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

下面的圖很好的解釋了這個過程：

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

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

3.3

? ?

第三定律

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

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

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

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

3.4

? ?

第四定律

合久必分，分而治之

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

所以，一個大的組織因為溝通成本/管理問題，總為被拆分成一個個小團(tuán)隊。

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

• 人多管不過來啊，找?guī)讉€經(jīng)理幫我管，我管經(jīng)理

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

4

? ?

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

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

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

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

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

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

帶來的具體的實踐建議是：

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

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

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

• 做小而美的團(tuán)隊，人多會帶來溝通的成本，讓效率下降。亞馬遜的 Bezos 有個逗趣的比喻，如果 2 個披薩不夠一個團(tuán)隊吃的，那么這個團(tuán)隊就太大了。事實上一般一個互聯(lián)網(wǎng)公司小產(chǎn)品的團(tuán)隊差不多就是 7，8 人左右（包含前后端測試交互用研等，可能身兼數(shù)職）。

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

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

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

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

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

• 自動化運維（DevOps）

• 容錯

• 快速演化

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

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

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

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

總結(jié)

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

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