康威定律——這個50年前就被提出的微服務概念，你知多少？

概述

微服務架構是一種很是流行的新概念，即使可供以借鑑的經驗比較少，固然不能阻擋它成爲熱門話題與研究對象。

使人驚訝地是，其實微服務的概念早在五十多年前就已經被提出，多年來，好久研究代表了這些觀點的準確性。這就是本文所介紹的——康威定律。如今已經有不少企業正在嘗試使用它建立高效的微服務架構。

在這篇文章中最有名的一句話莫過於：

設計系統的企業受限於生產設計，這些設計是企業溝通結構的副本——Melvin Conway(1967)。

這意味着設計系統的企業，它們生產的設計等同於企業內的溝通結構。下圖說明了此概念：

該圖展示了企業現有溝通結構，簡單地說：企業結構等於系統設計。

做者這裏提到的系統並不侷限於應用系統，聽說這篇文章最初投稿於哈佛商業評論，但被拒絕，所以康威將其提交到了一個編程雜誌，因此被誤解爲只針對應用開發，起初，做者並無把這種理論做爲定律，只是描述了發現和結論，不過著名的《The Mythical Man-Month》一書介紹了Brooks的理論，並引用了康威的一些觀點，因而康威的理論被推崇成爲咱們如今所熟知的康威定律。

康威定律詳細介紹

在文章中，Mike Amundesn總結了一些核心觀點：

• 第必定律：企業溝通方式會經過系統設計表達出來
• 第二定律：再多的時間也沒辦法讓任務完美至極，但總有時間能將它完成
• 第三定律：線型系統和線型組織架構間有潛在的異質同態特性
• 第四定律：大系統比小系統更適用於任務分解

〓 康威第必定律

「人類是複雜的社會動物。」

其餘領域也提供了一些關於溝通和系統設計之間緊密關係的例證，對於一個複雜的系統，設計主題總會涉及到人們之間的交流，一個好的系統設計能解決這種溝通問題，不少老程序員都讀過《The Mythical Man-Month》，裏面的一些觀點都是這句話的佐證。

《The Mythical Man-Month》 這本書裏有一句使人難忘的話：在應用項目後期加大人員的投資，會更加拖慢它的速度。——Fred Brooks（1975）

增長開發者的數量以跟上緊湊的進度是許多企業常見的問題，雖然增長勞動以達到增長產出的目的是有意義的，但在溝通成本上也會大大增長——隨着項目或企業中的人員數量增長，溝通成本成指數級增加，它能夠經過公式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

這也就是互聯網創業公司通常都比較小的緣由，若是創業公司有太多的員工，Boos向每一個人介紹本身的想法，那麼風投估計也快花完了。

生物學家Dunbar在1992年提出了一個名爲Dunbar Number的理論：靈長類動物的大腦容量與它的族羣大小有關，而後推論出一些人類大腦可以維持的關係數量，例如，一個典型的人會有：

• 5個死黨
• 15個信任的朋友
• 35個通常的朋友
• 150個只打過照面的朋友

因此它們與上面提到的溝通成本有關，大腦只能維持這麼多的關係（在開發團隊中，這個數字可能更小）。

溝通的問題會影響系統設計，進而影響整個系統的開發效率以及最終結果。

〓 康威第二定律

羅馬不是一天建成的，學會先解決首要問題。

敏捷開發巨頭之一Erik Hollnagel 在他的書中闡述了相似的觀點：

問題太複雜？那麼不妨忽略沒必要要的細節。

沒有足夠的資源？放棄無用的功能。

——Erik Hollnagel（2009）

系統的複雜性、功能數量、市場競爭以及投資人的指望值都在增長，而人的智力是有上限的，沒有企業能說必定能找到合適的人，對於一個極其複雜的系統，總會有考慮不周全的地方，Erik認爲這個問題最好的解決辦法就是：不去管它。

在平常開發任務彙總會遇到一些問題如，產品經理提出的要求是否過於複雜？若是是，首先關注那些主要的需求，忽略次要的需求，產品經理的需求太多了？那就放棄一些功能。

據稱，Erik曾收到一家航空公司的顧問邀請，保證飛行系統的穩定性和安全性，他相信經過兩種方式能夠確保安全性：

• 常規安全：必須檢測和消除儘量多的錯誤
• 很是規安全：若出現錯誤，要及時處理，最快恢復服務

對於像飛行系統這樣複雜的系統，無論測試人員的業務多麼純熟，也會忽略一些漏洞，所以Erik建議公司放棄創建一個完美系統的想法，儘可能去保證安全和正確性，經過不斷地飛行測試，去識別安全問題，確保系統可以在出現故障時自動回覆，下圖顯示了安全的不一樣解釋。

聽起來是否是很熟悉？沒錯，這就是咱們常說的持續集成和敏捷開發的概念。

而這個原則與互聯網公司維護的分佈式系統彈性設計也相同，即便單元測試覆蓋整個系統，也不不可能識別和修復分佈式系統中全部的缺陷，分佈式系統很容易出現錯誤，最佳解決方案不是消除全部問題，而是容許它們存在，在發生故障時實現自動恢復。

在由微服務組成的系統中，每一個微服務均可能中止響應，這是徹底正常的，只須要確保足夠的冗餘和備份，這就是彈性或高可用性設計。

〓 康威第三定律

建立獨立的子系統，減小溝通成本。

上圖表明瞭第必定律的團隊和系統設計之間的內部關係具體應用，簡單地說，須要創建一個適合自身系統的團隊，若是有一個前端團隊、Java後端開發團隊、DBA團隊和O&M團隊，那麼系統將會以下圖：

相反，若是系統是以業務邊界劃分的，按照業務目標去構建小的系統或產品，總體系統將會以下圖所示，即微服務架構：

團隊中微服務的理念應是Inter-Operate，而不是Integrate ，Inter-Operate是指定義系統邊界和接口，併爲整個團隊提供完整的堆棧，實現徹底的自制。如此就能下降系統間的依賴性，減小通訊成本。

〓 康威第四定律

前面提到，人類是複雜的社會動物，人與人之間的交流是很是複雜的，當涉及到一個系統時，人們常常選擇增長人力去減小複雜性，對於企業來講，該如何處理這樣的溝通問題？答案是：分而治之。

看看公司內，一名經理管理的員工通常少於15個，二三線經理管理的員工要更少，所以，大企業一般會將團隊拆成一個個小團隊或部門減小溝通成本及管理的問題，有一些須要考慮的場景：

• 創業的項目很好，拿到一大筆風投，再招募更多的程序員
• 人員太多，須要找幾個經理進行管理
• 康威定律好告訴咱們，能夠從系統設計中看出組織通訊的模式，每一個經理要對大系統的某一小部分負責，經過這種方式，它們和更大的系統間溝通有了便捷，所以大的系統也會被拆分紅一個個小系統。（微服務能夠更好地服務於此）。

〓 康威定律與微服務

再來看一下康威定律是如何在半個世紀前就奠基了微服務理論基礎的。

• 人與人之間的交流很複雜，每一個人的精力是有限的，所以當問題很複雜，須要協調地去解決時，須要將組織劃分進而提升溝通效率。
• 團隊成員工做的系統設計依賴於成員之間的溝通，管理人員能夠調整劃分模式，實現團隊之間的不一樣溝通方式，這也會影響系統的設計。
• 若是子系統有清晰的外部通訊便捷，那麼就能夠有效地下降通訊成本，響應地設計將更加適合和有效。
• 須要不斷優化一個複雜的系統，並容錯性和故障恢復率的幫助下進行優化，不要指望大而全面的設計或架構，由於它們的開發以迭代的方式發生。

如下是一些具體的實踐建議：

• 利用一切手段提升通訊效率，如Slack、Github和Wiki，且只與相關人員進行溝通，每一個人和每一個系統必須有明確的職責，在遇到問題時，知道該找誰去解決。
• 在MVP模式下設計一套系統，以迭代的方式優化及驗證，並確保系統的彈性。
• 採用與系統設計相一致的團隊，以扁平化和以業務爲基準的方式去簡化團隊，每一個小團隊之間必須有對應負責的模塊，避免模糊的界限，以避免在發生問題時互相推卸責任。
• 要作小而美的團隊，人員數量的增長會下降效率以及加大成本，亞馬遜CEO Jeff Bezos有個一個經驗法則：若是兩個披薩對於一個團隊來講不夠，那麼這個團隊就太大了。通常來講，一家互聯網公司的產品團隊由7到8我的組成（包括前端和後端測試、交互和用戶體驗師，一些人可能身兼數職）。

在查看如下微服務標準時，咱們能夠很容易地看到微服務與康威定律之間的密切關係：

• 由分佈式服務組成的系統
• 企業部門的業務線
• 開發優秀的產品
• Smart endpoints and dumb pipes
• DevOps
• 容錯
• 快速發展

原文做者： 雲棲團隊博客
原文連接：http://www.tuicool.com/articl...