邱小俠

阿里高級技術專家

讀完需要

10

分鐘

速讀僅需 4 分鐘

邱小俠，阿里巴巴集團客戶體驗事業群高級技術專家，阿里花名肥俠。2014年加入阿里巴巴，現在負責客戶體驗驅動及創新中心有關商家業務的開發工作。負責開發了商家維權中心和商家品控平臺，同時也負責集團在線工作臺和知識庫的研發工作。擅長Java核心技術、分布式系統與計算、開發框架與中間件、項目管理與軟件工程和架構。

1

? ?

概述

關于微服務的介紹，網上已經有很多文章了。

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

可能出乎很多人意料之外的一個事實是，微服務很多核心理念其實在半個世紀前的一篇文章中就被闡述過了，而且這篇文章中的很多論點在軟件開發飛速發展的這半個世紀中竟然一再被驗證，這就是康威定律（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)

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

設計系統的組織，其產生的設計等同于組織之內、組織之間的溝通結構。

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

用通俗的說法就是：

組織形式等同系統設計。

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

2

? ?

康威定律詳細介紹

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

第一定律

- Communication dictates design- 組織溝通方式會通過系統設計表達出來

第二定律

- 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- 線型系統和線型組織架構間有潛在的異質同態特性

第四定律

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

3

? ?

定律說明

3.1

? ?

第一定律

人是復雜社會動物

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

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

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

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

為什么？人月神話也給出了很簡潔的答案：溝通成本 = n(n-1)/2，溝通成本隨著項目或者組織的人員增加呈指數級增長。是的，項目管理這個算法的復雜度是 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

所以知道為什么互聯網創業公司都這么小了吧，必須小啊，不然等 CEO 和所有人講一遍創業的想法后，風投的錢都燒完了。

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

• 親密（intimate）朋友: 5

• 信任（trusted）朋友: 15

• 酒肉（close）朋友: 35

• 照面（casual）朋友: 150

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

溝通的問題，會帶來系統設計的問題，進而影響整個系統的開發效率和最終產品結果。

3.2

? ?

第二定律:

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

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

Problem too complicated? Ignore details.?

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

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

其實我們在日常開發中也經常碰到。產品經理的需求太復雜了？適當忽略一些細節，先抓主線。產品經理的需求太多了？放棄一些功能。

據說 Eric 被一家航空公司請去做安全咨詢顧問，復雜保證飛機飛行系統的穩定性和安全性。Eric 認為做到安全有兩種方式：

• 常規的安全指的是盡可能多的發現并消除錯誤的部分，達到絕對安全，這是理想。

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

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

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

聽著很耳熟不是嗎？這不就是 持續集成 和敏捷開發嗎？的確就是。

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

3.3

? ?

第三定律

種瓜得瓜，做獨立自治的字系統減少溝通成本

這是康威第一定律組織和設計間內在關系的一個具體應用。更直白的說，你想要什么樣的系統，就搭建什么樣的團隊。如果你的團隊分成前端團隊，Java 后臺開發團隊，DBA 團隊，運維團隊，你的系統就會長成下面的樣子：

相反，如果你的系統是按照業務邊界劃分的，大家按照一個業務目標去把自己的模塊做出小系統，小產品的話，你的大系統就會長成下面的樣子，即微服務的架構

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

3.4

? ?

第四定律

合久必分，分而治之

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

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

• 創業的想法太好了，反正風投錢多，多招點程序猿

• 人多管不過來啊，找幾個經理幫我管，我管經理

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

4

? ?

康威定律如何解釋微服務的合理性

了解了康威定律是什么，再來看看他如何在半個世紀前就奠定了微服務架構的理論基礎。

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

• 組織內人與人的溝通方式決定了他們參與的系統設計，管理者可以通過不同的拆分方式帶來不同的團隊間溝通方式，從而影響系統設計

• 如果子系統是內聚的，和外部的溝通邊界是明確的，能降低溝通成本，對應的設計也會更合理高效

• 復雜的系統需要通過容錯彈性的方式持續優化，不要指望一個大而全的設計或架構，好的架構和設計都是慢慢迭代出來的

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

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

• 通過 MVP 的方式來設計系統，通過不斷的迭代來驗證優化，系統應該是彈性設計的。

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

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

再對應下衡量微服務的標準，我們很容易會發現他們之間的密切關系：

• 分布式服務組成的系統

• 按照業務而不是技術來劃分組織

• 做有生命的產品而不是項目

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

• 自動化運維（DevOps）

• 容錯

• 快速演化

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

想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。