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

不知道大家開啟本文，有沒有留意文章所在的分類節點：雲端計算。其實我的本意，是要將微服務跟雲架構歸類在一起。因為他們都有著一個相同的存在目的：方便擴容！  

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

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

先說下我個人的經歷：我是做GPS防盜器系統的，硬體需要給後臺伺服器回發資料，所以硬體產品銷售的越好，我的系統就需要面對越來越多的壓力挑戰。 感謝經歷了這樣的一個過程，讓我深刻意識到了系統擴容架構設計的巨大價值。 我的專案裡，經歷過這麼三個階段：

第一階段：單機階段

單機應用，單程式應用，事實證明只能承載幾百裝置併發。

透過改造多執行緒，IOCP設計模型，可以承載20000以上的併發

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

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

手動分散式分離設計，網站，socket接收程式，快取，資料庫，使用自建機房獨立執行。事實證明，可以承載幾十萬裝置併發

瓶頸點：自建機房防火牆裝置有併發數限制，CISCO ASA 5515防火牆最大允許25萬連線。

第三階段：雲架構階段

雲架構設計，透過修改系統，實現自動擴容。這個時候，客戶端裝置數再多也沒事，因為 的 之後的 數量可以隨時新增和減少，目前已經達到了100多萬的裝置併發連線無壓力。

瓶頸點：僅限於我，將來資料庫壓力還需要進一步最佳化，但是目前併發裝置數上百萬毫無壓力，不過阿里雲的分散式資料庫DRDS似乎也能解決我的難點。

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

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

模組化功能，剛才我的案例都是基於整體系統拆分，實際上還有個最佳化空間就是改造成微服務。“微服務應用”舉例：

登入系統功能： 目前同時登陸使用者最多也就幾百人。登陸功能程式碼跟著網站整體釋出，負載均衡下需要一下子維護起來一下子更新幾十臺web機器，顯然太多餘。如果登陸功能這個“微服務”元件單獨釋出，那麼只用2臺web機器（“登入功能專用伺服器”）專門負載登陸功能戳戳有餘。將來這部分系統壓力增加，只需要增加一臺“登陸伺服器”即可。

查詢定位功能： 每個人的定位頁面都在高頻率重新整理訪問，雖然只有幾百人登陸，但是造成的訪問次數卻高達上萬次。怎麼辦？專門拿出十幾臺web伺服器，用於“定位查詢伺服器”。這樣，如果監控到定位功能有問題，只需要從這十幾臺“定位查詢伺服器”中排查問題！

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

所以導致現在觀點多種：

沒接觸過大專案的人覺得微服務就是個累贅；

接觸過大專案的人承認微服務的價值，卻不建議小專案使用微服務進行“高射炮打蚊子”

一直做大流量專案的人，提倡使用微服務。

【結論】

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

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

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

原文地址：   文章的更新編輯依此連結為準。歡迎關注源站原創文章！