從單機到分散式的架構漫談系列

1. 摩爾定律

當價格不變時，集成電路上可容納的元器件的數目，約每隔18-24個月便會增加一倍，性能也將提升一倍。換言之，每一美元所能買到的電腦性能，將每隔18-24個月翻一倍以上。這一定律揭示了信息技術進步的速度。 但現在，這種發展軌跡要告一段落。由於同樣小的空間里集成越來越多的硅電路，產生的熱量也越來越大，這種原本兩年處理能力加倍的速度已經慢慢下滑。所以不言而喻，單機的性能會遇到瓶頸，這僅僅是從性能來看。即使不從性能來看，如果一個機器的性能足夠，那麼也會存在單點故障的問題，所以我們需要分散式的高可用。

2. 分散式

單機拓展到分散式：

輸入/輸出變化

分散式系統通過網路連接多個節點組成，那麼輸入/輸出可以分為兩種，一種是通過互相連接的多個節點，在接受其他節點傳來的信息時，該節點可以看作輸入/輸出設備，另外一種就是傳統的人機交互輸入/輸出設備。

控制變化

分散式系統通過網路連接多個節點組成，每一個節點是通過消息的傳遞進行協調，在請求發起方和請求處理方中間有一個控制器，所有的請求通過中央控制器來進行負載均衡，中央控制器可以分為：硬體負載均衡和軟體負載均衡。

3.傳統單體應用

傳統的單體應用的應用鏈路比較簡單，就以WEB應用舉例，基本都是MVC的模式。Controller層，Service層，Dao層，數據請求的流向由上層逐層向下。

這是從代碼結構來看，然後就將其打包發布到Tomcat裡面，可能隨著訪問量的越來越多，單台機器的處理性能不足，就需要加入新的伺服器，這時候就需要做一個負載均衡，在請求到後端業務邏輯的的前面，現在使用的是Nginx作為反向代理。同時將一些靜態的資源文件放在前端，這樣後端的Tomcat伺服器直接處理具體的業務請求。類似於這樣最簡單的結構：

與此同時加入了負載均衡，就會產生一個session的問題。在單體應用上面，會話保存在單機上，請求也都是由一個機器來處理，所以不會出現問題。web伺服器變成了多台之後，如何保證同一會話請求都在同一個web伺服器上面處理？常用的有這麼幾種可選方案：

Session Sticky

在負載均衡那台伺服器裡面，將同一個請求發送到相同的web server上處理即可。同時也會帶來一些問題，如果有一台web server宕機，那麼這台機器上的seesion會丟失，如果有登錄狀態那麼用戶需要重新登錄。session是http層進行解析的，如果要保證同一個session在同一台機器，那麼需要在這裡進行轉換，這一層的開銷也是不能忽略掉的；如果負載均衡是一個有狀態的，需要將會話和web服務進行映射，如果機器宕機，在恢復的過程也是具有很大的挑戰。

Session Replication

將兩台的session進行同步，如果同步session的數據造成了網路開銷，只要session數據有變化，就需要將同步到所有其他機器上，機器越多，同步帶來的網路開銷也就越大；如果每台web伺服器都要保存所有的session，整個集群的session就會很多，每台機器保存session消耗的內存也會很嚴重。

Session集中管理

相比於Session Replication來說，減少了多台機器的網路同步，不過相對於單體的session來說，就是增加了延遲，不過在實際的工程化中，這些都是內網訪問，所以問題不大。但是會存在單體失敗的情況，這樣就會影響我們的使用。

隨著業務的發展，數據量和訪問量都是在增長的。對現在的互聯網來說，有很多場景都是讀多寫少，這種情況直接反映到資料庫上面，那麼對於這樣的情況我們將數據進行讀寫分離。

web server 的讀請求去讀取dbForRead，如果是寫請求則寫入db資料庫，這裡MySQL採用的是master-slave，有可能會出現不一致的情況，當然在MySQL 5.7 以後，可以使用mysql group replication。

與此同時，為了彌補關係型資料庫的不足，引入分散式存儲系統。雖然我們在平時使用的是單機資料庫，提供了較強的單機事務支持，但在其他方面會有不適合的場景。常見的分散式是大家熟知的分散式文件系統、分散式Key-Value系統和分散式資料庫。分散式文件系統就是在分散式環境中由多個節點組成的功能與單機系統一樣的文件系統，它是弱化格式的，內容的格式需要使用者自己組織；而分散式Key-Value系統相對分散式文件系統嚴格一些；分散式資料庫對數據格式限定更加嚴格。

數據進行讀寫分離過後，又遇到了瓶頸，那就是進行業務的垂直／水平拆分。水平拆分過後對業務是會帶來一定的影響，首先，訪問用戶信息的應用系統需要解決SQL路由的問題。為現在的用戶信息分在兩個資料庫中，需要在進行資料庫操作時，了解需要操作的資料庫在哪裡。此外，主鍵的處理也會變得不同，原來以單個資料庫的一些機制需要變化，例如原來使用MySQL表上的自增欄位，現在不能簡單繼續使用，並且在不同的資料庫中也不能直接使用一些資料庫限制來保證主鍵不重複。最後由於同一業務數據被拆分到了不同的資料庫中，因此一些查詢需要從兩個資料庫讀取，如果數據量太大而需要分頁，就會比較難處理。

也許將所有的功能集成在一個單體的應用裡面，會給開發帶來很多的問題，所以我們才需要拆分應用，以應用服務化的形式呈現給使用方。當然搜索對於一個系統來說必不可少，對於快速查找絕對是一個利器。以及在進行服務化的過程，難免會用消息隊列來進行解耦和非同步操作。

至此我們通過不斷的演進，我們的系統架構圖如下：

出處：

版權申明：內容來源網路，版權歸原創者所有。除非無法確認，我們都會標明作者及出處，如有侵權煩請告知，我們會立即刪除並表示歉意。謝謝。

架構文摘

互聯網應用架構丨架構技術丨大型網站丨大數據丨機器學習

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！