大型分散式Web系統的架構演進
【前言】
我們以 Java Web 為例，來搭建一個簡單的電商系統，看看這個系統可以如何一步步演變。
該系統具備的功能：
使用者模組：使用者註冊和管理
商品模組：商品展示和管理
交易模組：建立交易和管理
【正文】
階段一、單機構建網站
網站的初期，我們經常會在單機上跑我們所有的程式和軟體。此時我們使用一個容器，如Tomcat、Jetty、Jboss，然後直接使用JSP/Servlet技術，或者使用一些開源的框架如Maven + Spring + Struts + Hibernate、Maven + Spring + Spring MVC + Mybatis。最後再選擇一個數據庫管理系統來儲存資料，如MySQL、SqlServer、Oracle，然後通過JDBC進行資料庫的連線和操作。
把以上的所有軟體包括資料庫、應用程式都裝載同一臺機器上，應用跑起來了，也算是一個小系統了。此時系統結果如下：
階段二、應用伺服器與資料庫分離
隨著網站的上線，訪問量逐步上升，伺服器的負載慢慢提高，在伺服器還沒有超載的時候，我們應該就要做好準備，提升網站的負載能力。假如我們程式碼層面已難以優化，在不提高單臺機器的效能的情況下，採用增加機器是一個不錯的方式，不僅可以有效地提高系統的負載能力，而且價效比高。
增加的機器用來做什麼呢？此時我們可以把資料庫伺服器和Web伺服器拆分開來，這樣不僅提高了單臺機器的負載能力，也提高了容災能力。
應用伺服器與資料庫分開後的架構如下圖所示：
階段三、應用伺服器叢集
隨著訪問量繼續增加，單臺應用伺服器已經無法滿足需求了。在假設資料庫伺服器沒有壓力的情況下，我們可以把應用伺服器從一臺變成了兩臺甚至多臺
我們以增加了一臺應用伺服器為例，增加後的系統結構圖如下：
系統演變到這裡，將會出現下面四個問題：
1. 使用者的請求由誰來轉發到到具體的應用伺服器？
2. 有那些轉發的演算法和策略可以使用？
3. 應用伺服器如何返回使用者的請求？
4. 使用者如果每次訪問到的伺服器不一樣，那麼如何維護session的一致性？
針對以上問題，常用的解決方案如下：
1、負載均衡的問題
一般以下有5種解決方案：
1. HTTP重定向
HTTP重定向就是應用層的請求轉發。使用者的請求其實已經到了HTTP重定向負載均衡伺服器，伺服器根據演算法要求使用者重定向，使用者收到重定向請求後，再次請求真正的叢集
優點：簡單易用；
缺點：效能較差。
2. DNS域名解析負載均衡
DNS域名解析負載均衡就是在使用者請求DNS伺服器，獲取域名對應的IP地址時，DNS伺服器直接給出負載均衡後的伺服器IP。
優點：交給DNS，不用我們去維護負載均衡伺服器；
缺點：當一個應用伺服器掛了，不能及時通知DNS，而且DNS負載均衡的控制權在域名服務商那裡，網站無法做更多的改善和更強大的管理。
3. 反向代理伺服器
在使用者的請求到達反向代理伺服器時（已經到達網站機房），由反向代理伺服器根據演算法轉發到具體的伺服器。常用的Apache，Nginx都可以充當反向代理伺服器。
優點：部署簡單；
缺點：代理伺服器可能成為效能的瓶頸，特別是一次上傳大檔案。
4. IP層負載均衡
在請求到達負載均衡器後，負載均衡器通過修改請求的目的IP地址，從而實現請求的轉發，做到負載均衡。
優點：效能更好；
缺點：負載均衡器的寬頻成為瓶頸。
5. 資料鏈路層負載均衡
在請求到達負載均衡器後，負載均衡器通過修改請求的MAC地址，從而做到負載均衡，與IP負載均衡不一樣的是，當請求訪問完伺服器之後，直接返回客戶。而無需再經過負載均衡器。
2、叢集排程轉發演算法
1. rr輪詢排程演算法
顧名思義，輪詢分發請求。
優點：實現簡單
缺點：不考慮每臺伺服器的處理能力
2. wrr加權排程演算法
我們給每個伺服器設定權值Weight，負載均衡排程器根據權值排程伺服器，伺服器被呼叫的次數跟權值成正比。
優點：考慮了伺服器處理能力的不同
3. sh原地址雜湊演算法
提取使用者IP，根據雜湊函式得出一個key，再根據靜態對映表，查處對應的value，即目標伺服器IP。過目標機器超負荷，則返回空。
優點：實現同一個使用者訪問同一個伺服器。
4. dh目標地址雜湊演算法
原理同上，只是現在提取的是目標地址的IP來做雜湊。
優點：實現同一個使用者訪問同一個伺服器。
5. lc最少連線演算法
優先把請求轉發給連線數少的伺服器。
優點：使得叢集中各個伺服器的負載更加均勻。
6. wlc加權最少連線演算法
在lc的基礎上，為每臺伺服器加上權值。演算法為：（活動連線數 * 256 + 非活動連線數） ÷ 權重，計算出來的值小的伺服器優先被選擇。
優點：可以根據伺服器的能力分配請求。
7. sed最短期望延遲演算法
其實sed跟wlc類似，區別是不考慮非活動連線數。演算法為：（活動連線數 +1 ) * 256 ÷ 權重，同樣計算出來的值小的伺服器優先被選擇。
8. nq永不排隊演算法
改進的sed演算法。我們想一下什麼情況下才能“永不排隊”，那就是伺服器的連線數為0的時候，那麼假如有伺服器連線數為0，均衡器直接把請求轉發給它，無需經過sed的計算。
9. LBLC基於區域性性最少連線演算法
負載均衡器根據請求的目的IP地址，找出該IP地址最近被使用的伺服器，把請求轉發之。若該伺服器超載，最採用最少連線數演算法。
10. LBLCR帶複製的基於區域性性最少連線演算法
負載均衡器根據請求的目的IP地址，找出該IP地址最近使用的“伺服器組”，注意，並不是具體某個伺服器，然後採用最少連線數從該組中挑出具體的某臺伺服器出來，把請求轉發之。若該伺服器超載，那麼根據最少連線數演算法，在叢集的非本伺服器組的伺服器中，找出一臺伺服器出來，加入本伺服器組，然後把請求轉發。
3、叢集請求返回模式問題
1. NAT
負載均衡器接收使用者的請求，轉發給具體伺服器，伺服器處理完請求返回給均衡器，均衡器再重新返回給使用者。
2. DR
負載均衡器接收使用者的請求，轉發給具體伺服器，伺服器出來玩請求後直接返回給使用者。需要系統支援IP Tunneling協議，難以跨平臺。
3. TUN
同上，但無需IP Tunneling協議，跨平臺性好，大部分系統都可以支援。
4、叢集Session一致性問題
1. Session Sticky
Session sticky就是把同一個使用者在某一個會話中的請求，都分配到固定的某一臺伺服器中，這樣我們就不需要解決跨伺服器的session問題了，常見的演算法有ip_hash演算法，即上面提到的兩種雜湊演算法。
優點：實現簡單；
缺點：應用伺服器重啟則session消失。
2. Session Replication
Session replication就是在叢集中複製session，使得每個伺服器都儲存有全部使用者的session資料。
優點：減輕負載均衡伺服器的壓力，不需要要實現ip_hasp演算法來轉發請求；
缺點：複製時網路頻寬開銷大，訪問量大的話Session佔用記憶體大且浪費。
3. Session資料集中儲存
Session資料集中儲存就是利用資料庫來儲存session資料，實現了session和應用伺服器的解耦。
優點：相比Session replication的方案，叢集間對於寬頻和記憶體的壓力大幅減少；
缺點：需要維護儲存Session的資料庫。
4. Cookie Base
Cookie base就是把Session存在Cookie中，由瀏覽器來告訴應用伺服器我的session是什麼，同樣實現了session和應用伺服器的解耦。
優點：實現簡單，基本免維護。
缺點：cookie長度限制，安全性低，頻寬消耗。
值得一提的是：
Nginx目前支援的負載均衡演算法有wrr、sh（支援一致性雜湊）、fair（lc）。但Nginx作為均衡器的話，還可以一同作為靜態資源伺服器。
Keepalived + ipvsadm比較強大，目前支援的演算法有：rr、wrr、lc、wlc、lblc、sh、dh
Keepalived支援叢集模式有：NAT、DR、TUN
Nginx本身並沒有提供session同步的解決方案，而Apache則提供了session共享的支援。
解決了以上的問題之後，系統的結構如下：
階段四、資料庫讀寫分離化
上面我們總是假設資料庫負載正常，但隨著訪問量的的提高，資料庫的負載也在慢慢增大。那麼可能有人馬上就想到跟應用伺服器一樣，把資料庫一份為二再負載均衡即可。
但對於資料庫來說，並沒有那麼簡單。假如我們簡單的把資料庫一分為二，然後對於資料庫的請求，分別負載到A機器和B機器，那麼顯而易見會造成兩臺資料庫資料不統一的問題。那麼對於這種情況，我們可以先考慮使用讀寫分離和主從複製的方式。
讀寫分離後的系統結構如下：
這個結構變化後也會帶來兩個問題：
主從資料庫之間資料同步問題。
應用對於資料來源的選擇問題。
解決方案：
使用MySQL自帶的Master + Slave的方式實現主從複製。
採用第三方資料庫中介軟體，例如MyCat。MyCat是從Cobar發展而來的，而Cobar是阿里開源的資料庫中介軟體，後來停止開發。MyCat是國內比較好的MySql開源資料庫分庫分表中介軟體。
階段五、用搜索引擎緩解讀庫的壓力
資料庫做讀庫的話，常常對模糊查詢力不從心，即使做了讀寫分離，這個問題還未能解決。以我們所舉的交易網站為例，釋出的商品儲存在資料庫中，使用者最常使用的功能就是查詢商品，尤其是根據商品的標題來查詢對應的商品。對於這種需求，一般我們都是通過like功能來實現的，但是這種方式的代價非常大，而且結果非常不準確。此時我們可以使用搜尋引擎的倒排索引來完成。
搜尋引擎具有的優點：它能夠大大提高查詢速度和搜尋準確性。
引入搜尋引擎的開銷
帶來大量的維護工作，我們需要自己實現索引的構建過程，設計全量/增加的構建方式來應對非實時與實時的查詢需求。
需要維護搜尋引擎叢集
搜尋引擎並不能替代資料庫，它解決了某些場景下的精準、快速、高效的“讀”操作，是否引入搜尋引擎，需要綜合考慮整個系統的需求。
引入搜尋引擎後的系統結構如下：
階段六、用快取緩解讀庫的壓力
常用的快取機制包括頁面級快取、應用資料快取和資料庫快取。
應用層和資料庫層的快取
隨著訪問量的增加，逐漸出現了許多使用者訪問同一部分熱門內容的情況，對於這些比較熱門的內容，沒必要每次都從資料庫讀取。我們可以使用快取技術，例如可以使用Google的開源快取技術Guava或者使用Memecahed作為應用層的快取，也可以使用Redis作為資料庫層的快取。
另外，在某些場景下，關係型資料庫並不是很適合，例如我想做一個“每日輸入密碼錯誤次數限制”的功能，思路大概是在使用者登入時，如果登入錯誤，則記錄下該使用者的IP和錯誤次數，那麼這個資料要放在哪裡呢？假如放在記憶體中，那麼顯然會佔用太大的內容；假如放在關係型資料庫中，那麼既要建立資料庫表，還要簡歷對應的Java bean，還要寫SQL等等。而分析一下我們要儲存的資料，無非就是類似{ip:errorNumber}這樣的key:value資料。對於這種資料，我們可以用NOSQL資料庫來代替傳統的關係型資料庫。
頁面快取
除了資料快取，還有頁面快取。比如使用HTML5的localstroage或者Cookie。除了頁面快取帶來的效能提升外，對於併發訪問且頁面置換頻率小的頁面，應儘量使用頁面靜態化技術。
優點：減輕資料庫的壓力， 大幅度提高訪問速度；
缺點：需要維護快取伺服器，提高了編碼的複雜性。
值得一提的是：
快取叢集的排程演算法不同與上面提到的應用伺服器和資料庫。最好採用一致性雜湊算，這樣才能提高命中率。
加入快取後的系統結構如下：
階段七、資料庫水平拆分與垂直拆分
我們的網站演進到現在，交易、商品、使用者的資料都還在同一個資料庫中。儘管採取了增加快取和讀寫分離的方式，但隨著資料庫的壓力繼續增加，資料庫資料量的瓶頸越來越突出，此時，我們可以有資料垂直拆分和水平拆分兩種選擇。
資料垂直拆分
垂直拆分的意思是把資料庫中不同的業務資料拆分到不同的資料庫中，結合現在的例子，就是把交易、商品、使用者的資料分開。
優點：
解決了原來把所有業務放在一個數據庫中的壓力問題；
可以根據業務的特點進行更多的優化。
缺點：
需要維護多個數據庫的狀態一致性和資料同步。
問題：
需要考慮原來跨業務的事務；
跨資料庫的Join。
解決問題方案：
應該在應用層儘量避免跨資料庫的分散式事務，如果非要跨資料庫，儘量在程式碼中控制。
通過第三方中介軟體來解決，如上面提到的MyCat，MyCat提供了豐富的跨庫Join方案，詳情可參考MyCat官方文件。
資料垂直拆分後的結構如下：
資料水平拆分
資料水平拆分就是把同一個表中的資料拆分到兩個甚至多個資料庫中。產生資料水平拆分的原因是某個業務的資料量或者更新量到達了單個數據庫的瓶頸，這時就可以把這個表拆分到兩個或更多個數據庫中。
優點：
如果能克服以上問題，那麼我們將能夠很好地對資料量及寫入量增長的情況。
問題：
訪問使用者資訊的應用系統需要解決SQL路由的問題，因為現在使用者資訊分在了兩個資料庫中，需要在進行資料操作時瞭解需要操作的資料在哪裡。
主鍵 的處理也變得不同，例如原來自增欄位，現在不能簡單地繼續使用。
如果需要分頁查詢，那就更加麻煩。
解決問題方案：
我們還是可以通過可以解決第三方中介軟體，如MyCat。MyCat可以通過SQL解析模組對我們的SQL進行解析，再根據我們的配置，把請求轉發到具體的某個資料庫。 我們可以通過UUID保證唯一或自定義ID方案來解決。
MyCat也提供了豐富的分頁查詢方案，比如先從每個資料庫做分頁查詢，再合併資料做一次分頁查詢等等。
資料水平拆分後的結構如下：
階段八、應用的拆分
按微服務拆分應用
隨著業務的發展，業務越來越多，應用越來越大。我們需要考慮如何避免讓應用越來越臃腫。這就需要把應用拆開，從一個應用變為倆個甚至更多。還是以我們上面的例子，我們可以把使用者、商品、交易拆分開。變成“使用者、商品”和“使用者，交易”兩個子系統。
拆分後的結構：
問題：
這樣拆分後，可能會有一些相同的程式碼，如使用者相關的程式碼，商品和交易都需要使用者資訊，所以在兩個系統中都保留差不多的操作使用者資訊的程式碼。如何保證這些程式碼可以複用是一個需要解決的問題。
解決問題：
通過走服務化SOA的路線來解決頻繁公共的服務。
走SOA服務化治理道路
為了解決上面拆分應用後所出現的問題，我們把公共的服務拆分出來，形成一種服務化的模式，簡稱SOA。
採用服務化之後的系統結構：
優點：
相同的程式碼不會散落在不同的應用中了，這些實現放在了各個服務中心，使程式碼得到更好的維護。
我們把對資料庫的互動業務放在了各個服務中心，讓前端的Web應用更注重與瀏覽器互動的工作。
問題：
如何進行遠端的服務呼叫？
解決方法：
可以通過下面的引入訊息中介軟體來解決。
階段九、引入訊息中介軟體
隨著網站的繼續發展，的系統中可能出現不同語言開發的子模組和部署在不同平臺的子系統。此時我們需要一個平臺來傳遞可靠的，與平臺和語言無關的資料，並且能夠把負載均衡透明化，能在呼叫過程中收集並分析呼叫資料，推測出網站的訪問增長率等等一系列需求，對於網站應該如何成長做出預測。開源訊息中介軟體有阿里的Dubbo，可以搭配Google開源的分散式程式協調服務Zookeeper實現伺服器的註冊與發現。
引入訊息中介軟體後的結構：
總結
以上的演變過程只是一個例子，並不適合所有的網站，實際中網站演進過程與自身業務和不同遇到的問題有密切的關係，沒有固定的模式。只有認真的分析和不斷地探究，才能發現適合自己網站的架構。
出處：https://juejin.im/post/5b4c4e566fb9a04f83464102
版權申明：內容來源網路，版權歸原創者所有。除非無法確認，我們都會標明作者及出處，如有侵權煩請告知，我們會立即刪除並表示歉意。謝謝。
架構文摘
ID：ArchDigest
網際網路應用架構丨架構技術丨大型網站丨大資料丨機器學習
更多精彩文章，請點選下方：閱讀原文