一文簡述服務器架構的演變過程：集羣—分佈式—微服務

1、單服務器架構

小猿公司創立初期準備搭建一個電商網站銷售公司產品，由於公司創業初期用戶量不大並且着急上線，在資金有限的狀況下公司購買了一臺服務器，將小猿團隊開發的網站放到服務器上這便算是正式上線了。

2、服務器集羣

項目上線沒多久就暴露了不少問題：

• 單點問題（服務器宕機將致使整個系統不可用）
• 處理效率問題，單臺服務器能夠接收的請求量十分有限，用戶量大的狀況下響應速度大幅降低，甚至出現內存溢出。

遇到了以上問題就必須對服務架構進行調整了，經過商量小猿團隊決定增長服務器數量，這樣能夠已解決單服務器請求壓力過大的問題，同時就算有部分服務器宕機了對外也能正常提供服務。

集羣引入了幾個新問題：

• 每一個服務器的ip地址不同，如何讓用戶知道到底要訪問哪個？
• session問題，以前用戶登陸信息，購物車信息等等都是存在服務器的內存中，服務器集羣后如何保證每一個服務器共享session數據。

3、負載均衡

如今須要解決的就是讓每一個服務器處理的請求數能竟可能的均衡一些，好比輪循機制。這就是負載均衡。

負載均衡器的主要工做就是接受用戶請求，而且根據必定的算法將請求分發給不一樣的服務器，架構調整後造成了下圖的模式

（集羣帶來session的處理問題通常能夠採用redis或者其餘緩存服務器進行處理，這裏不展開討論了）

4、分佈式

隨着小猿公司的業務愈來愈負載，團隊的成員也愈來愈多，系統慢慢變的愈來愈龐大，又帶來了一些問題：

• 只是修改了某個業務的一些小功能卻須要把整個系統從新發布一次；
• 系統業務複雜，開發人員過多很差管理，開發效率低；
• 沒法針對某個特定的業務擴大服務器處的理能力

因而想到了一個解決辦法，將系統按照模塊劃分紅各個子系統，每一個子系統有對應的團隊負責，各個子系統相互調用完成業務功能。

固然上圖的架構仍是會存在單點問題，這時候能夠和集羣的技術相互結合來提升這個架構的穩定性

5、微服務

系統拆分後每一個小系統都是一個完整獨立的業務系統，能夠擁有本身獨立的一個數據庫，每一個小系統也就是一個微服務，對外暴露出自身的API，經過微服務，能夠很好的實現擴展，如雙十一活動的時候，訂單量激增，這時候能夠考慮多部署幾臺交易系統來應對高強度的請求壓力，隨着系統數量的增長，咱們還須要引入服務治理工具（如：Eureka），由它來管理好每一個服務的健康情況。

固然微服務架構一樣會引入許多新的問題須要處理，如分佈式事務、調用異常處理、權限驗證 等等一系列的問題，這裏就先不作擴展了，後續再繼續完善補充。

寫在最後：

歡迎你們關注個人公衆號【風平浪靜如碼】，海量Java相關文章，學習資料都會在裏面更新，整理的資料也會放在裏面。

以爲寫的還不錯的就點個贊，加個關注唄！點關注，不迷路，持續更新！！！