概述
微服務架構是一種非常流行的新概念，即便可供以借鑒的經驗比較少，當然不能阻擋它成為熱門話題與研究對象。
令人驚訝地是，其實微服務的概念早在五十多年前就已經被提出，多年來，很久研究表明了這些觀點的准確性。這就是本文所介紹的——康威定律。現在已經有很多企業正在嘗試使用它創建高效的微服務架構。
在這篇文章中最有名的一句話莫過於：
設計系統的企業受限於生產設計，這些設計是企業溝通結構的副本——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
容錯
快速發展