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

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

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

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

先說下我個人的經曆：我是做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

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