We are doomed, and RPC does not help

第一種死法：Big ball of Mud

架構裏最經常使用的反面案例是 big ball of mud。很大程度上能夠說打格子，把複雜的系統拆解成小格子是架構師最重要的工做。這個小格子有不少種名字，好比：組件，模塊，子系統，庫，bounded context林林種種。

可是仔細想一想？爲何須要打這些格子？爲何要把一個進程乾的活拆分出這麼多進程去幹？

一個東西打成多少個格子來作，不是受一種因素影響的。不一樣類型的應用，其面臨的主要挑戰是不一樣的，因此上面三種因素裏對解決方案的影響的權重就不一樣。

好比說：若是咱們作的是微信的架構。微信的主要架構問題是什麼？實際上是給海量低價值的用戶狀況下提供免費服務。微信的後臺架構裏決定因素的是成本，因此在騰訊的後臺業務裏決定架構師可否作得好，主導的是對計算機體系架構是否足夠精通。微信的kv存儲可以作到同城三園區容災，同時比競爭對手少一分備份達到一樣的數據安全性，這就是核心競爭力之一。在海量可是業務邏輯簡單的系統裏，主要要考慮是怎樣打格子能夠最大化利用現代計算機體系架構。也就是這些格式主要是爲了非功能性需求切分出來的。一個進程掛了就掛了，三個進程負載均衡就能夠作到很高的可用性。一個流程寫在一個函數內，一次執行須要很長時間，併發來跑可能須要不少進程。可是考慮SEDA的因素，可能把一個流程切成三個函數來寫，每一個函數獨立成不一樣的線程或者進程來併發能夠得到更好的總併發性能。等等這些，切分的模塊的時候考慮的是內核，cache友好，網卡帶寬，copy-less這些因素。若是咱們作的業務是海量的簡單邏輯的互聯網業務，不精通Linux內核,TCP/IP協議棧和算法與數據結構是沒法作一個好的架構師，打好格子作出高性能低成本的架構的。這個方面的架構師的典型表明是：Google 的 Jeff Dean，以及 Map/reduce Spanner 爲表明的經典分佈式架構。

可是系統是多種多樣的。除了海量簡單邏輯的業務，世界的另一端是業務極端複雜可是使用量並不大的架構，好比典型的企業流程自動化系統。在處理複雜業務的時候，業務架構就是主要的影響因素。什麼是業務架構？好比說電子商務要處理真實世界的商品交易流程，就須要把系統與真實世界的業務邊界對應起來。一個電子商務系統須要拆分紅「庫存管理系統」，「訂價系統」，「商品目錄系統」等等。這種拆分不是由於架構師精通紅黑樹，認爲這幾個模塊的數據結構不同必須分開，而是不這麼分的業務複雜度沒法控制。越是架構作得好的系統，其子系統越是能夠寫得簡單，由於每一個都只處理一個領域的業務邏輯，而不是把不一樣的業務邏輯交織地扯在一塊來寫。決定系統的架構必須跟着業務架構走的根本緣由在於普通人的腦容量是有限，不分治之，複雜度根本hold不住。這個方面的架構師典型表明是：Eric Evan 和 Udi Dahan，以及他們表明的領域驅動設計思想。

世界是多樣的，不少事情不是在臺面上的。擺在檯面上的拆分系統的理由每每是業務邏輯，性能與穩定性等等。實際上真正主宰一個系統的模塊怎麼拆分的實際上是組織架構。若是開發者向同一個管理40人左右的leader彙報，那麼這些命運緊密相關的人（從年終獎的角度）不管寫的系統是什麼很難不緊密耦合，若是兩個leader帶的團隊共同參與一個項目開發，很難去阻止他們把工做拆成兩個模塊來寫，中間再各自加一道隔離層來保護本身。要是哪天這哪一個團隊合了，或許他們作的第一件事情就是把兩個模塊給合回去，名義多是這樣開發效率更高。這個現象叫Conway's Law，最有名的架構師是：James Coplien，以及他所撰寫的Organization Patterns（http://orgpatterns.wikispaces.com/BookOutline）

big ball of mud的系統有三種死法：

• 由於性能和穩定性不知足要求而死，這個時候須要懂內核懂數據結構的架構師來好好作一下拆分。
• 由於業務邏輯複雜得hold不住而死，開發效率慢到爆，這個時候須要作過複雜業務的架構師來從新梳理一下模塊拆分。
• 由於軟件架構不符合組織架構，致使團隊間吵架吵到死的，這個時候老闆從新思考什麼樣的組織架構纔是合適的（大boss經過組織架構體現其纔是最終極的一切的架構師）。

若是一個系統兼具三個難點，簡直難到爆：首先對延遲及其敏感，須要超級懂計算機體系的人。其次業務邏輯很複雜，須要很強的建模能力。同時又開發工做量巨大，須要不少人蔘與從而引入各類政治問題。金融衍生品交易等領域可能符合這些特徵。假如微信的架構師來作辦公自動化系統，上來就搞共享內存和高性能隊列，我只能呵呵了。

第二種死法：Dependency Hell or RPC Hell

這是淘寶的某我的寫的ppt的截圖。QZone的後臺其實也差很少。互聯網如今解決big ball of mud的所謂最佳實踐就是「微服務」。把一個大的系統拆成小的服務，用RPC一級級鏈接起來。A調用B，B再調用C。一個用戶的請求要通過n個團隊的系統轉一圈出來。如今幹什麼事情都要講求資歷，而資歷每每又和業務成功是掛鉤的。淘寶的業務牛x了，意味着其架構就是天衣無縫的麼？固然我沒有身披某某大公司技術副總裁的光環，而自動具備資格來評價這個問題。可是僅僅從一些技術細節的狹窄視角來看，這個架構也是有不少問題的，我稱之爲dependency hell：

一、從業務解耦的角度來看：RPC與共享數據庫沒有本質區別，拆開以後兩個系統仍然是強依賴

這很糟糕

可是改爲這樣就真的更好了麼？服務C和DB沒有什麼本質區別。

二、從非功能需求的角度。RPC依賴雙方是綁死的。屢次RPC調用疊加的可用性是疊加降低的，每一個點都要保證本身的高可用，這對基礎設施（運維自動化，集羣管控）提出了很高的要求。並且對升級的依賴關係形成了很大挑戰，哪一個升級會影響哪一個。同時對於容量規劃簡直是災難，誰都不知道一個服務降級以後對其餘全部依賴的方的雪崩效應究竟是如何的。像QZone爲了理解本身的後臺服務架構究竟是怎樣互相依賴的，已經開始用上網絡抓包的手段了，由於已經沒有人知道這個網狀的關係究竟是怎樣的了。從一個具體的技術細節來看，RPC調用須要主調方保留上下文的context在內存中（以及tcp socket），下游相應越慢對上游保留context的壓力就越大。固然這一切均可以經過加機器，更好的負載均衡，更好的高可用機制來彌補。無非就是請幾個高工來作集羣管理系統，再加上機器和帶寬費用嘛。大部分互聯網公司的估值不是由於這個公司如何能節省成本，而是如何能花錢。因此非功能性需求不是決定性因素。

三、從組織架構的角度，要想得到最大的效率，必需要團隊自治。RPC Hell的後果是每一個團隊都與其餘團隊緊耦合了。作個小功能，也須要拉一個跨組織架構的虛擬團隊來協調接口。每一個開發者脫離了所謂的那個線下環境就沒法開發了，每一個功能都有n個rpc call別人的系統，而別人的系統固然是咱們本身搭不起來的。由於你去搭A系統的時候就會發現依賴B系統，B系統依賴C系統。在沒有很好的基礎設施支撐的狀況下，好比分佈式日誌收集，docker的開發環境管理。開發者在這個微服務架構下是欲死欲仙的，幹什麼都是聯調。每一個人都對別的團隊作阻塞的call，體現出來是平常開發也是阻塞的。老闆爲了提升總體開發團隊的產出，就是加線程的方式，招更多的人。而招更多人爲了職級晉升又須要把組織架構劃分得更加的細。這個和網絡異步編程的原理實際上是同樣的。

其實在我看來，這種RPC的解法的來源應該是來自於這個循環：

需求作不完=>那麼加人吧=>加人沒有坑，那麼加坑吧=>我是leader我作主，我們拆分模塊吧=>模塊拆分哪家強，RPC誰都懂，那就上吧=>繼續循環

RPC可能不是最優的解法

誠然，BAT都是RPC嵌套的解法。誠然，我也不是什麼專家。可是拆分子系統顯然不是隻有RPC一途，Event Driven的架構其實歷史一樣悠久。

具體的作法三言兩語講不清楚。最好有實際的案例。這裏有兩個很是具體的案例：

電子商務的案例：http://pan.baidu.com/s/1i3o6J7f

醫療記錄的案例：http://pan.baidu.com/s/1c05BXLm

星巴克：http://pan.baidu.com/s/1eQvy31g