轉：微服務架構的理論基礎 - 康威定律

轉自：https://yq.aliyun.com/articles/8611

微服務架構的理論基礎 - 康威定律

 

 

摘要可能出乎不少人意料以外的一個事實是，微服務不少核心理念其實在半個世紀前的一篇文章中就被闡述過了，並且這篇文章中的不少論點在軟件開發飛速發展的這半個世紀中居然一再被驗證，這就是康威定律。前段時間看了Mike Amundsen 《遠距離條件下的康威定律——分佈式世界中實現團隊構建》在InfoQ上的一個分

概述

關於微服務的介紹，能夠參考微服務那點事。

微服務是最近很是火熱的新概念，你們都在追，也都以爲很對，可是彷佛沒有很充足的理論基礎說明這是正確的，給人的感受是 不明覺厲 。前段時間看了Mike Amundsen 《遠距離條件下的康威定律——分佈式世界中實現團隊構建》（是Design RESTful API的做者）在InfoQ上的一個分享，以爲頗有幫助，結合本身的一些思考，整理了該演講的內容。

可能出乎不少人意料以外的一個事實是，微服務不少核心理念其實在半個世紀前的一篇文章中就被闡述過了，並且這篇文章中的不少論點在軟件開發飛速發展的這半個世紀中居然一再被驗證，這就是康威定律（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著名的人月神話中，引用這個論點，並將其「吹捧」成了如今咱們熟知「康威定律」。

康威定律詳細介紹

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
  • 大的系統組織老是比小系統更傾向於分解

人是複雜社會動物

• 第必定律
  • Communication dictates design
  • 組織溝通方式決定系統設計

組織的溝通和系統設計之間的緊密聯繫，在不少別的領域有相似的闡述。對於複雜的系統，聊設計就離不開聊人與人的溝通，解決好人與人的溝通問題，纔能有一個好的系統設計。相信幾乎每一個程序員都讀過的《人月神話》（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

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

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

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

• 第二定律:
  • There is never enough time to do something right, but there is always enough time to do it over
  • 時間再多一件事情也不可能作的完美，但總有時間作完一件事情

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）。

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

• 第三定律
  • There is a homomorphism from the linear graph of a system to the linear graph of its design organization
  • 線型系統和線型組織架構間有潛在的異質同態特性

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

相反，若是你的系統是按照業務邊界劃分的，你們按照一個業務目標去把本身的模塊作出小系統，小產品的話，你的大系統就會長成下面的樣子，即微服務的架構

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

合久必分，分而治之

• 第四定律
  • The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems
  • 大的系統組織老是比小系統更傾向於分解

前面說了，人是複雜的社會動物，人與人的經過很是複雜。可是當咱們面對複雜系統時，又每每只能經過增長人力來解決。這時，咱們的組織通常是如何解決這個溝通問題的呢？Divide and conquer,分而治之。你們看看本身的公司的組織，是否是一個一線經理通常都是管理15我的如下的？二線經理再管理更少的一線？三線再管理更少的，以此類推。（這裏徹底沒有暗示開發經理比程序猿更難管理）

因此，一個大的組織由於溝通成本/管理問題，總爲被拆分紅一個個小團隊。

• 創業的想法太好了，反正風投錢多，多招點程序猿
• 人多管不過來啊，找幾個經理幫我管，我管經理
• 最後， 康威定律 告訴咱們組織溝通的方式會在系統設計上有所表達，每一個經理都被賦予必定的職責去作大系統的某一小部分，他們和大系統便有了溝通的邊界，因此大的系統也會所以被拆分紅一個個小團隊負責的小系統（微服務是一種好的模式）

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

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

• 人與人的溝通是很是複雜的，一我的的溝通精力是有限的，因此當問題太複雜須要不少人解決的時候，咱們須要作拆分組織來達成對溝通效率的管理
• 組織內人與人的溝通方式決定了他們參與的系統設計，管理者能夠經過不一樣的拆分方式帶來不一樣的團隊間溝通方式，從而影響系統設計
• 若是子系統是內聚的，和外部的溝通邊界是明確的，能下降溝通成本，對應的設計也會更合理高效
• 複雜的系統須要經過容錯彈性的方式持續優化，不要期望一個大而全的設計或架構，好的架構和設計都是慢慢迭代出來的

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

• 咱們要用一切手段提高溝通效率，好比slack，github，wiki。能2我的講清楚的事情，就不要拉更多人，每一個人每一個系統都有明確的分工，出了問題知道立刻找誰，避免踢皮球的問題。
• 經過MVP的方式來設計系統，經過不斷的迭代來驗證優化，系統應該是彈性設計的。
• 你想要什麼樣的系統設計，就架構什麼樣的團隊，能扁平化就扁平化。最好按業務來劃分團隊，這樣能讓團隊天然的自治內聚，明確的業務邊界會減小和外部的溝通成本，每一個小團隊都對本身的模塊的整個生命週期負責，沒有邊界不清，沒有無效的扯皮，inter-operate, not integrate。
• 作小而美的團隊，人多會帶來溝通的成本，讓效率降低。亞馬遜的Bezos有個逗趣的比喻，若是2個披薩不夠一個團隊吃的，那麼這個團隊就太大了。事實上通常一個互聯網公司小產品的團隊差很少就是7，8人左右（包含先後端測試交互用研等，可能身兼數職）。

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

• 分佈式服務組成的系統
• 按照業務而不是技術來劃分組織
• 作有生命的產品而不是項目
• Smart endpoints and dumb pipes（個人理解是強服務個體和弱通訊）
• 自動化運維（DevOps）
• 容錯
• 快速演化

參考資料

• 遠距離條件下的康威定律——分佈式世界中實現團隊構建，本文圖片來源該ppt截圖
• Conway‘s Law in wiki
• Conway's Law Homepage