三架馬車是指微服務、訊息佇列和定時任務。如下圖所示，這裡是乙個三駕馬車共同驅動的乙個立體的網際網路專案的架構。不管專案是大是小，這個架構模板的形態一旦定型了之後就不太會變，區別只是我們有更多的服務有更複雜的呼叫，更複雜的訊息流轉，更多的job，整個架構整體是可擴充套件的，而且不會變形，這個架構可以在很長的一段時間內無需有大的調整。
圖上畫了虛線框的都代表這個模組或專案是不包含太多業務邏輯的，純粹是一層皮（會呼叫服務但是不會觸碰資料庫）。黑色線的箭頭代表依賴關係，綠色和紅色箭頭分別是mq的傳送和訂閱訊息流的方向。具體在後文都會進一步詳細說明。
微服務微服務並不是乙個很新的概念，在10年前的時候我就開始實踐這個架構風格，在四個公司的專案中全面實現了微服務，越來越堅信這是非常適合網際網路專案的乙個架構風格。不是說我們的服務一定要跨物理機器進行遠端呼叫，而是我們通過進行有意的設計讓我們的業務在一開始的時候就按照領域進行分割，這能讓我們對業務有更充分的理解，能讓我們在之後的迭代中輕易在不同的業務模組上進行耕耘，能讓我們的專案開發越來越輕鬆，輕鬆**於幾個方面：
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的話一般而言是固定頻次的。
使用這套簡單的架構既能夠有很強的擴充套件餘地，複雜程度上或者說工作量上不會比all-in-one的架構多多少，看到這裡你可能覺得並不同意這個觀點。其實這個還是要看團隊的積累的，如果團隊大家熟悉這套架構體系，玩轉微服務多年的話，那麼其實很多問題會在編碼的過程中直接考慮進去，很多時候設計也可以認為是乙個熟能生巧的活，做了多了自然知道什麼東西應該放在**，怎麼去分怎麼去合，所以並不會有太多的額外時間成本。這三駕馬車構成的這麼一套簡單實用的架構方案我認為可以適用於大多數的網際網路專案，只是有些網際網路專案會更偏重其中的某一方面弱化另一方面，希望本文對你有用。
網際網路架構的三馬車
這裡所說的三架馬車是指微服務 訊息佇列和定時任務。如下圖所示，這裡是乙個三駕馬車共同驅動的乙個立體的網際網路專案的架構。不管專案是大是小，這個架構模板的形態一旦定型了之後就不太會變，區別只是我們有更多的服務有更複雜的呼叫，更複雜的訊息流轉，更多的job，整個架構整體是可擴充套件的，而且不會變形，這個...
網際網路架構
網際網路架構，主要追求的是高可用，可擴充套件 這兩個特性 在這裡做了一些個人的總結，算是給2014年的工作做個總結。推陳出新 一定要做的，死守積累會逐漸丟失人才，但凡技術公司都會不斷更新技術 kiss原則 keep it stupid優秀的 都會很簡單，簡單理解，簡單更改，能把複雜的事情做簡單是一種...
網際網路架構
使用者在同一時間內大量的訪問伺服器，tomcat伺服器併發能力為 200 250左右 jvm調優為1000 硬體條件 物理伺服器處理能力 網路頻寬 2.1 分布式計算 由多個執行緒，共同來完成某項特定的任務，拆合問題 2.2 分布式系統 distributed system 是建立在網路之上的軟體系...