閱讀筆記--互聯網架構：屢試不爽的架構三馬車

經上網查找，互聯網架構的演變

1 最初是前端一個web 加一個DB的結構

 

這種結構，web容易掛掉，業務就會終止，因爲高可用的需求，出現了下面這樣的架構

2 加了一個web，兩個web之間是主備的關係，一個掛了，另外一個來代替，用來解決高可用問題

 

3 以後發現這樣的架構支持的訪問量不夠了，前端撐不住那麼大的訪問量，由於前端的訪問量和DB的落庫有大概是10比1的比例，前端訪問10個，會有1個可以落庫，因此隨着訪問量的增長，前端先扛不住了，這個時候主、備結構已經不能解決高可用的問題，因此在web前面加了一個ngx，做爲負載均衡進行訪問的轉發，這個時候，web和web之間的主備關係就不存在了，在ngx進行轉發的時候會有一個session保持的操做，再後來就出現無狀態的概念，在兩個web之間進行輪詢，給誰都行

 

4當無狀態的概念出來之後，web這一層就能夠進行屢次的橫向擴展，這是第一次質的飛越

 

後來人們以爲一個ngx也會出問題，就設計了主、備結構的ngx

 

5 後來主、備ngx結構也不知足需求了，就在ngx前面加了一個lvs，lvs負責把請求轉發給nginx

 

本篇文章所說的三架馬車是指微服務、消息隊列和定時任務。以下圖所示，這裏是一個三駕馬車共同驅動的一個立體的互聯網項目的架構。無論項目是大是小，這個架構模板的形態一旦定型了以後就不太會變，區別只是咱們有更多的服務有更復雜的調用，更復雜的消息流轉，更多的Job，整個架構總體是可擴展的，並且不會變形，這個架構能夠在很長的一段時間內無需有大的調整。

微服務

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

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

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

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

4. 在性能存在明顯瓶頸的時候，咱們能夠針對性地對某些服務增長更多機器進行擴容，並且由於服務的劃分，咱們更清楚系統的瓶頸所在，從10000行代碼定位到一行性能存在問題的代碼是比較困難的，可是若是這10000行代碼已是由10個服務構成的，那麼先定位到某個服務存在性能問題而後再針對這個服務進行分析一會兒下降了定位問題的複雜度。

5. 若是業務有比較大的變更須要下線，那麼咱們能夠確定的是底層的公共服務是不會淘汰的，下線對應業務的聚合業務服務停掉流量入口，而後下線相關涉及到的基礎服務進行部分接口便可。若是擁有完善的服務治理平臺，整個操做甚至無需改動代碼。

服務必定是立體的，不是在一個層次上的，如上圖，咱們的服務有三個層次：

聚合業務服務：高層次的串起來整個流程的具備完整業務形態的業務服務。和基礎業務服務不一樣的是，這裏是在完整描述一方面的業務，這個業務每每是由各類基礎業務拼裝組合起來的。和不一樣外部合做方的不一樣合做形式，給用戶提供的產品的不一樣服務形態，都決定了聚合業務服務會有業務流程上的差別化，若是把此類服務下放到基礎業務服務中，那麼基礎業務服務會有各類if-else邏輯（根據產品類型、用戶類型進行各類if-else），隨着業務的合做不合做，需求變更，基礎業務服務會腐化得很厲害，爲了不這個狀況，咱們把變更的多的聚合業務邏輯放到獨立的業務服務中。通常而言，聚合業務服務由於表明了獨立的業務流程，它們之間是不會進行相互調用的，可是它們必定會調用大量的各種基礎業務服務。在第一點裏說的標有藍色字體的a~d這些服務都是此類服務。這個層次的服務的業務邏輯更可能是在表達業務流程的複雜性和差別性，不會涉及到具體怎麼處理帳戶信息、帳務信息、用戶信息，不會涉及到怎麼處理具體的投資人和借款人的交易。好比對於預定這類業務形態，它關注的是先要預定資產，而後再由系統進行自動投資，底層徹底依賴於投資人交易服務來作整個交易的過程。

基礎業務服務：某一個領域業務相關的服務。此類服務之間是容許相互調用的，好比投資人交易服務和借款人交易服務免不了須要和用戶服務、資產服務、帳戶帳務服務進行通信作相關的用戶信息查詢、標的信息查詢、記帳等業務操做。之因此投資人交易服務和借款人交易服務定位爲基礎業務服務是由於，它們處理的是仍是某一個具體方面的業務，並非全流程，在這個抽象層次上，業務不是那麼容易變更的，對於複雜的各類業務形態（好比預定交易、自動復投交易、等額本息交易）會在這些服務之上造成聚合業務服務。在第一點裏說的標有綠色字體的e~k這些服務都是此類服務。在這個層次的服務雖然擁有大量的業務邏輯，可是其實已經享受到了很大層度的公共基礎服務的重用了，並且和本身業務耦合較弱的額外邏輯每每沒有在本服務中堆積，由更多專職的基礎業務服務來承擔了這部分邏輯。

公共基礎服務：負責某一個方面的基礎業務（沒有什麼領域業務邏輯在裏面），能夠是自治的處理某一個方面的基礎業務，也能夠和外部通信實現某一個方面的功能，服務之間是不會相互調用的，可是會被聚合業務服務和基礎業務服務調用。在第一點裏說的標有橙色字體的l~n這些服務都是此類服務。若是之後和外部的合做有變更，由於咱們已經定義了對外的服務契約，能夠輕易替換這個服務來更換合做的第三方，系統其他的地方几乎不須要修改。全部的三方對接都建議獨立出公共基礎服務，若是同一個業務對接多個三方渠道，好比推送對接了極光和個推，甚至公共基礎服務還能夠由一個抽象聚合的推送服務，下面再路由到具體的極光推送和個推推送服務。