1、大型網站的自強之路
當年馬雲籌辦阿里巴巴的時候並沒有說我要做個大型網站，搞個雙11，成交額做到千億級別；馬化騰也沒有說以后我要做個通訊工具，讓13億乃至更多用戶都成為我們的用戶……我們現如今看到的各個大型網站或產品都是一步步踏踏實實走過來的，在各種坑和故障中成長起來的。
1.1、一台電腦就是服務器
做過課程設計或者畢業設計的計算機相關的同學都應該有過搭建項目的經驗。畫一堆界面，結合js和后台實現數據的展現，當然還要有數據來源——數據庫，啟動一個容器比如tomcat，那么我們就可以在本機上訪問我們的網站了。想必沒有比這還簡單的網站了吧，自己的電腦就充當了服務器的角色，應用和數據庫都部署在了自己的電腦上。
1.2、我們需要豐富網站的功能
隨着一個單機網站的不斷完善，用戶的增長，我們不再也不能只是一個完成繳費或者完成選課的單一功能的網站應用。我們需要從各個維度把這些應用分離開來，比如一個電商網站，我們有用戶、商品和交易三個基本模塊。
用戶
- 用戶注冊
- 用戶管理
商品
- 商品展示
- 商品管理
交易
- 訂單系統
- 交易管理
隨着應用的分塊，數據庫中表的划分也會相應變化。大概的結構圖如下
1.3、應用數據庫分離
不管是2.1中的電腦即服務器，還是2.2中的應用和DB放在同一服務器上，這兩種都沒有將應用和DB做分離。隨着我們應用網站的訪問量逐漸增多，對於服務器的壓力也增大了，我們需要考慮分離應用和數據庫以保證應用更加穩定。
相比2.2，我們只是將應用模塊和DB模塊部署在兩台服務器上，這樣各自的服務出現問題不會影響對應的模塊，同時也減輕了原來一台服務器的壓力。
1.4激增的訪問讓應用服務器走向集群
當應用服務器承受的壓力越來越大時，我們考慮將應用服務器走向集群化。大概結構如下：
注意
因為這里使用了多個應用服務器，Session就不再像單應用服務器那樣只有一個可選，這時候對於多個應用服務器，可能會出現這次的請求是被A應用服務處理，但是下一次就會被B應用服務器處理，應用Http是無狀態，所以需要借助Session實現有狀態，但是顯然這里Session無法完成這個“艱巨”的任務。
針對這個問題，解決方法較多。比如可以在請求和服務器之間加一個負載均衡器，讓負載均衡器維系請求和服務器之間的對應關系，如果發現是張三發來的請求那就扔到服務器A上處理，如果是李四的就扔到服務器B上處理。
還有一種處理方法是添加一個同步操作，在兩個服務器之間完成Session同步，這樣不管服務器A還是B都會有全集的Session集合了，那么誰處理就顯得不重要了。
1.5、數據庫扛不住了，讀寫分離
這個時候我們不能再把自己的應用網站成為小網站了，我們的數據量和訪問量空前的增長以至於數據庫有些hold不住了。所以我們需要將數據庫進行讀寫分離了，畢竟我們一般的網站應用讀數據庫占得比重比較多。大概的結構如下：
從圖中可以看出，用於讀的數據庫可以直接被應用讀取，同時它與主庫之間需要及時同步，當應用需要向主庫寫入數據時，則需要將寫入的數據通過到DB Read數據庫中，保證數據的實時性和准確性。
讀寫分離還有更多的延伸，包括使用緩存以及數據庫的垂直和水平拆分等，后面再說吧。
如果您覺得閱讀本文對您有幫助，請點一下“推薦”按鈕，您的“推薦”將是我最大的寫作動力！如果您想持續關注我的文章，請掃描二維碼，關注JackieZheng的微信公眾號，我會將我的文章推送給您，並和您一起分享我日常閱讀過的優質文章。
