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

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

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

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

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

第一階段：單機階段

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

通過改造多線程，IOCP設計模型，可以承載20000以上的并發

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

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

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

瓶頸點：自建機房防火墻設備有并發數限制，CISCO ASA 5515防火墻最大允許25萬連接。

第三階段：云架構階段

云架構設計，通過修改系統，實現自動擴容。這個時候，客戶端設備數再多也沒事，因為 阿里云 的 SLB 之后的 ECS服務器 數量可以隨時添加和減少，目前已經達到了100多萬的設備并發連接無壓力。

瓶頸點：僅限于我，將來數據庫壓力還需要進一步優化，但是目前并發設備數上百萬毫無壓力，不過阿里云的分布式數據庫DRDS似乎也能解決我的難點。

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

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

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

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

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

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

所以導致現在觀點多種：

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

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

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

【結論】

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

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

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

原文地址：  https://www.opengps.cn/Blog/View.aspx?id=279  文章的更新編輯依此鏈接為準。歡迎關注源站原創文章！