不知道大家打開本文，有沒有留意文章所在的分類節點：雲計算。其實我的本意，是要將微服務跟雲架構歸類在一起。因爲他們都有着一個相同的存在目的：方便擴容！
擴容。對於遇到過系統瓶頸，需要擴容的系統，恭喜你，你的系統一定是快速發展，遇到了訪問量上升的情況！
【雲架構，系統擴容案例】
先說下我個人的經歷：我是做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 文章的更新編輯依此鏈接爲準。歡迎關注源站原創文章！