把多個相關(guān)的操作進行合并, 并部署到同一個邏輯資源中進行計算. 這樣可以減少集群資源管理的overhead, 也可以讓整個集群的負載被更好的利用.
問題
云端系統(tǒng)往往處理大量相互不同的操作, 一般設(shè)計上為了能錯誤隔離. 會把不同的任務(wù)隔離到不同的資源框架中. 實際上從Cgroup到Docker, 我們一直在調(diào)度上做資源隔離相關(guān)的工作.
在這種設(shè)計模式下, 常見的就是不同的任務(wù)跑在不同的虛擬平臺上, 甚至是多層虛擬平臺上. 每個docker里面跑一個組件, 組件與組件之間溝通, 設(shè)計上是低耦合的, 但是平臺管理復(fù)雜度比較高
解決
為了降低管理的復(fù)雜度, 以及消息傳遞的成本. 我們試圖把相互關(guān)聯(lián)的任務(wù)放在同一個邏輯資源池里. 可以理解成我們把多個業(yè)務(wù)上相互關(guān)聯(lián)的docker直接merge成一個fat docker來管理.
決策
這種模式和當(dāng)前的主流思路是明顯相反的, 它的缺點也很多, 就不累述了. 包括因為資源高度集中導(dǎo)致錯誤隔離比較弱, 因為每次分配一大片資源導(dǎo)致資源復(fù)用程度低等等.
如果一個公司的全部要求都是end-to-end的速度, 那么對業(yè)務(wù)端的workflow自動壓縮成一個串行work, 然后預(yù)分配成片的資源確實是有效的. 但是這種場景如果往深里討論, 為什么要使用云端的架構(gòu)呢? 直接上基于C/C++ GO的自由框架不是更快么?
實際上我們也做過類似場景的自有框架, 通過切掉絕大部分沒用的東西讓整個處理層變的薄到不行, 反正一條信息的價值只有那1s(量化投資), 所以生產(chǎn)系統(tǒng)連info級日志打印都可以省掉, 掛了就掛了, 掛了當(dāng)時再修復(fù)毫無意義, 每天的投資時間點就那么兩三個, 錯過第一個后邊2小時有交易點的概率非常低. 有大把的時間在悔恨中找BUG, 代碼要非常非常薄, 薄到能一眼看出來bug是什么.
微軟可能自己都沒有在Azure里使用過這種設(shè)計模式, 直接略過好了.
