在昨天的文章《「後端」聊聊微服務（Microservice）的那些事兒》中提到并不是所有的項目或公司都适合微服務。那如果确實需要微服務技術就必須知道其基礎理論，例如本篇提到的康威定律。歡迎閱讀~
一、概述
這些年大家都在追微服務，也都覺得很對，但是似乎沒有很充足的理論基礎說明這是正确的，給人的感覺是 不明覺厲 。前段時間看了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
- 大的系統組織總是比小系統更傾向于分解
2.1 人是複雜社會動物
- 第一定律
- 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
是不是和上面的溝通成本的數字很貌似有關聯？是的，我們的大腦智力隻能支援我們維系這麼多的關系。（大家都知道這不是程式猿擅長的領域，在開發團隊裡，這個值應該更小，估計和猿差不多 -_-凸 ）
溝通的問題，會帶來系統設計的問題，進而影響整個系統的開發效率和最終産品結果。
2.2 一口氣吃不成胖子，先搞定能搞定的
- 第二定律:
- 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）。
2.3 種瓜得瓜，做獨立自治的字系統減少溝通成本
- 第三定律
- 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是定義好系統的邊界和接口，在一個團隊内全棧，讓團隊自治，原因就是因為如果團隊按照這樣的方式組建，将溝通的成本維持在系統内部，每個子系統就會更加内聚，彼此的依賴耦合能變弱，跨系統的溝通成本也就能降低。
2.4 合久必分，分而治之
- 第四定律
- 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）
- 容錯
- 快速演化
文章來源：https://developer.aliyun.com/article/8611