關於架構的學習之三駕馬車

提及在某一領域起到重要引領和帶動做用的因素，咱們每每會想到一次詞語，那就是三駕馬車，今天，我有幸學習了一下架構的三駕馬車。這裏所說的三架馬車是指微服務、消息隊列和定時任務。以下圖所示，這裏是一個三駕馬車共同驅動的一個立體的互聯網項目的架構。無論項目是大是小，這個架構模板的形態一旦定型了以後就不太會變，區別只是咱們有更多的服務有更復雜的調用，更復雜的消息流轉，更多的Job，整個架構總體是可擴展的，並且不會變形，這個架構能夠在很長的一段時間內無需有大的調整。

微服務並非一個很新的概念，在10年前的時候我就開始實踐這個架構風格，在四個公司的項目中全面實現了微服務，愈來愈堅信這是很是適合互聯網項目的一個架構風格。不是說咱們的服務必定要跨物理機器進行遠程調用，而是咱們經過進行有意的設計讓咱們的業務在一開始的時候就按照領域進行分割，這能讓咱們對業務有更充分的理解，能讓咱們在以後的迭代中輕易在不一樣的業務模塊上進行耕耘，能讓咱們的項目開發愈來愈輕鬆，輕鬆來源於幾個方面：

1. 若是咱們能進行微服務化，那麼咱們必定事先通過比較完善的產品需求討論和領域劃分，每個服務精心設計本身領域內的表結構，這是一個很重要的設計過程，也決定了整個技術架構和產品架構是匹配的，對於All-In-One的架構每每會省略這一過程，需求到哪裏代碼寫到哪裏。

2. 咱們對服務的劃分和職責的定位若是是清晰的，對於新的需求，咱們就能知道須要在哪裏改怎麼樣的代碼，沒有複製粘貼的存在少了不少坑。

3. 咱們大多數的業務邏輯已經開發完畢，直接重用便可，咱們的新業務只是現有邏輯的聚合。在PRD評審後，開發獲得的結論是隻須要組合分別調用ABC三個服務的XYZ方法，而後在C服務中修改一下Z方法增長一個分支邏輯，就能夠構建起新的邏輯，這種爽快的感受不可思議。

消息隊列MQ的使用有下面幾個好處，或者說咱們每每處於這些目的來考慮引入MQ：

1. 異步處理：相似於訂單這樣的流程通常能夠定義出一個核心流程，這個流程用於處理核心訂單的狀態機，須要儘快同步落庫完成，而後圍繞訂單會衍生出一系列和用戶相關的庫存相關的後續的業務處理，這些處理徹底不須要卡在用戶點擊提交訂單的那剎那進行處理。下單只是一個確認合法受理訂單的過程，後續的不少事情均可以慢慢在幾十個模塊中進行流轉，這個流轉過程哪怕是消耗5分鐘，用戶也無需感覺到。

2. 流量洪峯：互聯網項目的一個特色是有的時候會作一些toC的促銷，免不了有一些流量洪峯，若是咱們引入了消息隊列在模塊之間做爲緩衝，那麼backend的服務能夠以本身既有的舒服的頻次來被動消耗數據，不會被強壓的流量擊垮。固然，作好監控是必不可少的，下面再細說一下監控。

3. 模塊解耦：隨着項目複雜度的上升，咱們會有各類來源於項目內部和外部的事件（用戶註冊登錄、投資、提現事件等），這些重要事件可能不斷有各類各樣的模塊（營銷模塊、活動模塊）須要關心，核心業務系統去調用這些外部體系的模塊，讓整個系統在內部糾纏在一塊兒顯然是不合適的，這個時候經過MQ進行解耦，讓各類各樣的事件在系統中進行鬆耦合流轉，模塊之間各司其職也相互沒有感知，這是比較適合的作法。

定時任務的需求有那麼幾類：

1. 如以前所說，跨服務調用，MQ通知不免會有不可達的問題，咱們須要有必定的機制進行補償。

2. 有一些業務是基於任務表進行驅動的，有關任務表的設計下面會詳細說明。

3. 有一些業務是定時按期來進行處理的，根本不須要實時進行處理（好比通知用戶紅包即將過時，和銀行進行日終對帳，給用戶出帳單等）。和2的區別在於，這裏的任務的執行時間和頻次是五花八門的，2的話通常而言是固定頻次的。