網際網路架構的三馬車

這裡所說的三架馬車是指微服務、訊息佇列和定時任務。如下圖所示，這裡是乙個三駕馬車共同驅動的乙個立體的網際網路專案的架構。不管專案是大是小，這個架構模板的形態一旦定型了之後就不太會變，區別只是我們有更多的服務有更複雜的呼叫，更複雜的訊息流轉，更多的job，整個架構整體是可擴充套件的，而且不會變形，這個架構可以在很長的一段時間內無需有大的調整。

圖上畫了虛線框的都代表這個模組或專案是不包含太多業務邏輯的，純粹是一層皮（會呼叫服務但是不會觸碰資料庫）。黑色線的箭頭代表依賴關係，綠色和紅色箭頭分別是mq的傳送和訂閱訊息流的方向。

微服務

微服務並不是乙個很新的概念，這是非常適合網際網路專案的乙個架構風格。不是說我們的服務一定要跨物理機器進行遠端呼叫，而是我們通過進行有意的設計讓我們的業務在一開始的時候就按照領域進行分割，這能讓我們對業務有更充分的理解，能讓我們在之後的迭代中輕易在不同的業務模組上進行耕耘，輕鬆**於幾個方面：

1.如果我們能進行微服務化，那麼我們一定事先經過比較完善的產品需求討論和領域劃分，每乙個服務精心設計自己領域內的表結構，這是乙個很重要的設計過程，也決定了整個技術架構和產品架構是匹配的，對於all-in-one的架構往往會省略這一過程，需求到****寫到**。

2.我們對服務的劃分和職責的定位如果是清晰的，對於新的需求，我們就能知道需要在**改怎麼樣的**，沒有複製貼上的存在少了很多坑。

3.我們大多數的業務邏輯已經開發完畢，直接重用即可，我們的新業務只是現有邏輯的聚合。在prd評審後，開發得到的結論是只需要組合分別呼叫abc三個服務的xyz方法，然後在c服務中修改一下z方法增加乙個分支邏輯，就可以構建起新的邏輯，這種爽快的感覺難以想象。

4.在效能存在明顯瓶頸的時候，我們可以針對性地對某些服務增加更多機器進行擴容，而且因為服務的劃分，我們更清楚系統的瓶頸所在，從10000行**定位到一行效能存在問題的**是比較困難的，但是如果這10000行**已經是由10個服務構成的，那麼先定位到某個服務存在效能問題然後再針對這個服務進行分析一下子降低了定位問題的複雜度。

5.如果業務有比較大的變動需要下線，那麼我們可以肯定的是底層的公共服務是不會淘汰的，下線對應業務的聚合業務服務停掉流量入口，然後下線相關涉及到的基礎服務進行部分介面即可。如果擁有完善的服務治理平台，整個操作甚至無需改動**。

訊息佇列mq的使用有下面幾個好處，或者說我們往往處於這些目的來考慮引入mq：

1.非同步處理：類似於訂單這樣的流程一般可以定義出乙個核心流程，這個流程用於處理核心訂單的狀態機，需要盡快同步落庫完成，然後圍繞訂單會衍生出一系列和使用者相關的庫存相關的後續的業務處理，這些處理完全不需要卡在使用者點選提交訂單的那剎那進行處理。下單只是乙個確認合法受理訂單的過程，後續的很多事情都可以慢慢在幾十個模組中進行流轉，這個流轉過程哪怕是消耗5分鐘，使用者也無需感受到。

2.流量洪峰：網際網路專案的乙個特點是有的時候會做一些toc的**，免不了有一些流量洪峰，如果我們引入了訊息佇列在模組之間作為緩衝，那麼backend的服務可以以自己既有的舒服的頻次來被動消耗資料，不會被強壓的流量擊垮。當然，做好監控是必不可少的，下面再細說一下監控。

3.模組解耦：隨著專案複雜度的上公升，我們會有各種**於專案內部和外部的事件（使用者註冊登陸、投資、提現事件等），這些重要事件可能不斷有各種各樣的模組（營銷模組、活動模組）需要關心，核心業務系統去呼叫這些外部體系的模組，讓整個系統在內部糾纏在一起顯然是不合適的，這個時候通過mq進行解耦，讓各種各樣的事件在系統中進行松耦合流轉，模組之間各司其職也相互沒有感知，這是比較適合的做法。

4.訊息**：有一些訊息是會有多個接收者的，接收者的數量還是動態的（類似指責鏈的性質也是可能的），在這個時候如果上下游進行一對多的耦合就會更麻煩，對於這種情況就更適用使用mq進行解耦了。上游只管發訊息說現在發生了什麼事情，下游不管有多少人關心這個訊息，上游都是沒有感知的。

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

1.如之前所說，跨服務呼叫，mq通知難免會有不可達的問題，我們需要有一定的機制進行補償。

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

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

網際網路架構的三馬車

網際網路架構的三馬車

網際網路架構

網際網路架構

相關推薦