原文地址：https://yq.aliyun.com/articles/8611（肥俠）著作權歸原作者是所有。 概述 關於微服務的介紹，可以參考微服務那點事。 微服務是最近非常火熱的新概念，大家都在追，也都覺得很對，但是似乎沒有很充足的理論基礎說明這是正確的，給人的感覺是 不明覺厲 。前段時間看了M ...
原文地址：https://yq.aliyun.com/articles/8611（肥俠）著作權歸原作者是所有。
概述
關於微服務的介紹，可以參考微服務那點事。
微服務是最近非常火熱的新概念，大家都在追，也都覺得很對，但是似乎沒有很充足的理論基礎說明這是正確的，給人的感覺是 不明覺厲 。前段時間看了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）
- 容錯
- 快速演化
