使用「微服務+雲架構」輕鬆應對系統擴容！

不知道你們打開本文，有沒有留意文章所在的分類節點：雲計算。其實個人本意，是要將微服務跟雲架構歸類在一塊兒。由於他們都有着一個相同的存在目的：方便擴容！

擴容。對於遇到過系統瓶頸，須要擴容的系統，恭喜你，你的系統必定是快速發展，遇到了訪問量上升的狀況！

【雲架構，系統擴容案例】

先說下我我的的經歷：我是作GPS防盜器系統的，硬件須要給後臺服務器回發數據，因此硬件產品銷售的越好，個人系統就須要面對愈來愈多的壓力挑戰。感謝經歷了這樣的一個過程，讓我深入意識到了系統擴容架構設計的巨大價值。個人項目裏，經歷過這麼三個階段：

第一階段：單機階段

單機應用，單進程應用，事實證實只能承載幾百設備併發。

經過改造多線程，IOCP設計模型，能夠承載20000以上的併發

瓶頸點：難以突破單機應用的併發能力，每次遇到難點都得重構。在個人案例裏，就是能夠增長到30000負載，增長不到50000萬負載！

第二階段：手動拆分多服務器階段

手動分佈式分離設計，網站，socket接收程序，緩存，數據庫，使用自建機房獨立運行。事實證實，能夠承載幾十萬設備併發

瓶頸點：自建機房防火牆設備有併發數限制，CISCO ASA 5515防火牆最大容許25萬鏈接。

第三階段：雲架構階段

雲架構設計，經過修改系統，實現自動擴容。這個時候，客戶端設備數再多也沒事，由於阿里雲的SLB以後的ECS服務器數量能夠隨時添加和減小，目前已經達到了100多萬的設備併發鏈接無壓力。

瓶頸點：僅限於我，未來數據庫壓力還須要進一步優化，可是目前併發設備數上百萬毫無壓力，不過阿里雲的分佈式數據庫DRDS彷佛也能解決個人難點。

【微服務，模塊化應用案例】

個人案例下，重點解釋了雲架構的做用，沒有重點介紹微服務的做用。可是實際上，在幾回改造過程當中，已經使用了一點點微服務的功能：

模塊化功能，剛纔個人案例都是基於總體系統拆分，實際上還有個優化空間就是改形成微服務。「微服務應用」舉例：

登陸系統功能：目前同時登錄用戶最多也就幾百人。登錄功能代碼跟着網站總體發佈，負載均衡下須要一會兒維護起來一會兒更新幾十臺web機器，顯然太多餘。若是登錄功能這個「微服務」組件單獨發佈，那麼只用2臺web機器（「登陸功能專用服務器」）專門負載登錄功能戳戳有餘。未來這部分系統壓力增長，只須要增長一臺「登錄服務器」便可。

查詢定位功能：每一個人的定位頁面都在高頻率刷新訪問，雖然只有幾百人登錄，可是形成的訪問次數卻高達上萬次。怎麼辦？專門拿出十幾臺web服務器，用於「定位查詢服務器」。這樣，若是監控到定位功能有問題，只須要從這十幾臺「定位查詢服務器」中排查問題！

結論：微服務的目的在於軟件開發層面的功能化拆分。對於使用微服務：小項目用起來費力，大項目用起來省心。

因此致使如今觀點多種：

沒接觸過大項目的人以爲微服務就是個累贅；

接觸過大項目的人認可微服務的價值，卻不建議小項目使用微服務進行「高射炮打蚊子」

一直作大流量項目的人，提倡使用微服務。

【結論】

微服務的價值：在於未來訪問量上升時，精準調控某一個瓶頸點的功能，主要屬於開發層面的儲備

雲架構的價值：在於訪問量上升時，直接增長服務器數量擴大系統承載閾值，主要屬於運維層面的儲備

微服務+雲架構：大型系統的重要組合！

原文地址： www.opengps.cn/Blog/View.a… 文章的更新編輯依此連接爲準。歡迎關注源站原創文章！