一、單服務器架構
小猿公司創立初期準備搭建一個電商網站銷售公司產品，因為公司創業初期用戶量不大而且著急上線，在資金有限的情況下公司購買了一臺服務器，將小猿團隊開發的網站放到服務器上這便算是正式上線了。
二、服務器集群
項目上線沒多久就暴露了很多問題：
- 單點問題（服務器宕機將導致整個系統不可用）
- 處理效率問題，單臺服務器可以接收的請求量十分有限，用戶量大的情況下響應速度大幅下降，甚至出現內存溢出。
遇到了以上問題就必須對服務架構進行調整了，通過商量小猿團隊決定增加服務器數量，這樣可以已解決單服務器請求壓力過大的問題，同時就算有部分服務器宕機了對外也能正常提供服務。
集群引入了幾個新問題：
- 每個服務器的ip地址不一樣，如何讓用戶知道到底要訪問哪一個？
- session問題，之前用戶登錄信息，購物車信息等等都是存在服務器的內存中，服務器集群后如何保證每個服務器共享session數據。
三、負載均衡
現在需要解決的就是讓每個服務器處理的請求數能竟可能的均衡一些，比如輪循機制。這就是負載均衡。
負載均衡器的主要工作就是接受用戶請求，並且根據一定的算法將請求分發給不同的服務器，架構調整後形成了下圖的模式
（集群帶來session的處理問題一般可以採用redis或者其他緩存服務器進行處理，這裡不展開討論了）
四、分佈式
隨著小猿公司的業務越來越負載，團隊的成員也越來越多，系統慢慢變的越來越龐大，又帶來了一些問題：
- 只是修改了某個業務的一些小功能卻需要把整個系統重新發布一次；
- 系統業務複雜，開發人員過多不好管理，開發效率低；
- 無法針對某個特定的業務擴大服務器處的理能力
於是想到了一個解決辦法，將系統按照模塊劃分成各個子系統，每個子系統有對應的團隊負責，各個子系統相互調用完成業務功能。
當然上圖的架構還是會存在單點問題，這時候可以和集群的技術相互結合來提高這個架構的穩定性
五、微服務
系統拆分後每個小系統都是一個完整獨立的業務系統，可以擁有自己獨立的一個數據庫，每個小系統也就是一個微服務，對外暴露出自身的API，通過微服務，可以很好的實現擴展，如雙十一活動的時候，訂單量激增，這時候可以考慮多部署幾臺交易系統來應對高強度的請求壓力，隨著系統數量的增加，我們還需要引入服務治理工具（如：Eureka），由它來管理好每個服務的健康狀況。
當然微服務架構同樣會引入許多新的問題需要處理，如分佈式事務、調用異常處理、權限驗證 等等一系列的問題，這裡就先不做擴展了，後續再繼續完善補充。
文末彩蛋 針對於上面所涉及到的知識點我總結出了各位面試中涉及的大部分架構面試資料（（包括Dubbo、Redis、Netty、zookeeper、Spring cloud、分佈式、高併發等）
有需要的可以轉發後臺私信我【Java】獲取資料領取方式！
部分資料圖分享
寫在最後：
歡迎大家關注我新開通的公眾號【風平浪靜如碼】，海量Java相關文章，學習資料都會在裡面更新，整理的資料也會放在裡面。
覺得寫的還不錯的就點個贊，加個關注唄！點關注，不迷路，持續更新！！！
閱讀更多 愛喝王老吉的劉某人 的文章
