我們常見的大型網站，如百度、淘寶、京東等，都是一個分布式系統。這么復雜的系統也不是一天建成的，每個系統都經歷了漫長的演變過程。

[[277068]]

圖片來自 Pexels 

對于一個大型網站，主要有以下幾個特征：

• 支撐海量數據
• 非常高的訪問量

在大型網站中，其最核心的功能就是計算和存儲。因此系統演變過程也主要圍繞這兩點進行。

單機系統

在網站剛剛起步時，數據量、訪問量都非常小，通常情況下，只需一臺應用服務器就可以了。

單機部署方案

起步時，我們把所有資源全部打包到部署文件中(如 XXX.war)，其中包括：

• class 文件、依賴 jar 等。
• js、css、圖片等靜態資源。
• 對于用戶上傳文件的場景，直接在服務器上新建一個目錄，將上傳的文件放置在目錄即可。

然后，將打好的發布包放到 Web 容器中，比如 Tomcat，最后啟動容器，讓其直接對外提供服務。

該部署策略有以下幾個特征： 

• 用戶通過瀏覽器直接與 Java 應用程序進行交互(通常是 Tomcat)。
• Java 應用程序通過 JDBC 與本機的數據庫進行交互(如 MySQL)。
• 如果存在文件讀寫的需求，Java 應用程序通過文件接口直接對文件進行操作。

這時，有人會問，Java 應用程序直接對外，會不會存在一些安全或性能方面的問題呢?

是的，Tomcat 這種 Web 容器對鏈接的保持能力比較弱，當存在大量鏈接時，性能下降很快。

同時，Tomcat 并不擅長靜態資源的處理，對此，我們可以引入 Nginx，以緩解 Tomcat 的壓力。

單機部署方案進階

我們在單機部署基礎上，添加 Nginx，也就有了進階方案：

 

該方案存在以下特征：

• 用戶不在直接與 Java 應用程序進行交互，而是與 Nginx 進行交互。
• Tomcat 掛在 Nginx 后，對動態請求進行處理。
• 對于靜態資源的訪問，通過 Nginx 直接訪問文件系統。
• 當有文件寫需求時，通過 Java 應用程序直接寫入磁盤。

此時，架構顯得清晰很多，但我們發現一個問題，就是系統對靜態資源和動態資源的處理是完全不同的。

對于靜態資源的處理，相對簡單，只是簡單的文件讀寫。而，動態請求(也就是我們的業務承載者)會隨著業務的發展越來越復雜。

動靜分離部署方案

由于靜態請求與動態請求采用不同的處理策略，我們可以將其進行分離。

 

該部署方案存在以下特性：

• 通過不同的域名對動態請求和靜態請求進行分離。
• 新增靜態資源服務器，專門處理靜態請求，并在服務器上部署 Java 應用程序，處理文件寫需求;Nginx 只負責文件的讀操作。
• 對動態請求進行獨立部署，應用程序將文件的寫請求轉發到靜態服務器進行處理。

靜態資源服務器功能單一，部署繁瑣，有沒有一種更好的策略呢?

答案就是云服務，比如阿里云的 OSS 提供靜態資源存儲服務。CDN 提供訪問加速服務，兩者結合使用，就得到了一個海量容量并且性能超強的靜態資源服務器(集群)。

結合 OSS 和 CDN，靜態請求不會成為系統的瓶頸，因此，接下來只對動態請求進行討論。

隨著系統訪問量的增加，動態請求出現了明顯的瓶頸。

應用集群化部署

由于所有的動態請求全部由一臺應用服務器進行處理，當訪問量上升時，這臺服務就成了系統的瓶頸。

此時，我們需要將系統中的多個組件部署到不同的服務器上。

 

新部署有以下特征：

• 對 Nginx 進行獨立部署，形成 Web 集群。
• 對 Java 應用程序進行獨立部署，形成應用集群。
• 對數據庫進行獨立部署。
• Web 集群與應用集群間通過 HTTP 協議進行交互。
• 應用集群與數據庫間通過 JDBC 協議進行交互。

應用集群化，會面臨很多挑戰，主要的焦點是如何有效的分配用戶請求。

DNS 輪詢

首先要解決的問題便是，用戶如何將請求發送到不同的 Nginx 中，最常見的方式便是 DNS 輪詢。

大多域名注冊商都支持多條 A 記錄的解析，其實這就是 DNS 輪詢，DNS 服務器將解析請求按照 A 記錄的順序，逐一分配到不同的 IP 上，這樣就完成了簡單的負載均衡。

負載均衡器

這里的負載均衡器主要指的是 Nginx 的反向代理功能。當用戶請求發送到 Nginx 后，Nginx 需要決定將請求轉發到哪臺應用服務器上。

反向代理(Reverse Proxy)是指以代理服務器來接受 Internet 上的連接請求，然后將請求轉發給內部網絡上的服務器，并將從服務器上得到的結果返回給 Internet 上請求連接的客戶端，此時代理服務器對外就表現為一個反向代理服務器。

Nginx 對于后臺服務器配置比較靈活，可以同時配置多臺服務器，并根據負載策略將請求分發給后臺服務器。

會話問題

在單機時代，我們的請求只會發送到同一臺機器上，不存在會話問題。當將應用集群部署時，用戶的多次請求會發送到不同的應用服務器上。此時，如何對會話進行同步便是棘手問題。

①Session Sticky

這種方案主要由 Nginx 處理，讓同樣 Session 請求每次都發送到同一臺服務器進行處理。

Nginx 會將相同用戶的請求發送到同一臺應用服務器中。

這是最簡單的策略，但存在一定的問題：

• Web 服務器重啟 Session 丟失。
• 負載均衡需要進行應用層解析(第 7 層)，性能損耗較大。
• 負載均衡器變為一個有狀態的點，不易容災。

②Session Replication

會話問題的根源在于 Session 由多個應用維護，我們可以使用某種機制，在多臺 Web 服務間進行 Session 的數據同步。

由 Session 同步器在各個 Java 應用程序間完成 Session 的同步，最終使每個服務器中都存在所有用戶的 Session 數據。

這個方案的問題：

• 造成網絡開銷。
• 每臺 Web 服務器都保存所有的 Session，內存開銷大。

③集中式 Session

我們可以將 Session 從 Web 服務中抽取出來，并對其進行集中存儲。

將 Session 信息保存到 Session 存儲集群中，Java 應用程序不在負責 Session 的存儲。

這個方案的問題：

• 讀取 Session 引入了網絡開銷。
• 存儲設施問題影響應用。

④Cookie Based Session

還可以將 Session 數據放在 Cookie 中，然后在 Web 服務器上從 Cookie 中生成對應的 Session 數據。

將 Session 數據編碼到 Cookie 中，每次 Java 應用程序使用 Session 時，都從 Cookie 中重建 Session。

該方案的問題：

• 受到 Cookie 大小的限制。
• 存在安全性問題。
• 每次都攜帶巨大的 Cookie，帶寬消耗嚴重。
• 每次都進行 Session 數據恢復，加大應用服務器的負擔。

隨著系統訪問量的持續增加，面對大量的數據讀取請求，數據庫有些不堪重負。此時，我們需要對數據庫進行優化。

數據庫讀寫分離

通常情況下，數據庫的讀會成為系統的瓶頸。對此，我們可以使用數據庫主從機制，通過添加多個從庫來減緩讀壓力。

與之前部署相比，該架構只是為數據庫增加了若干個從庫：

• 對數據庫實施主從部署策略。
• 對于數據的寫請求，只能在主庫上進行。
• 對于數據的讀請求，可以在任意的從庫上進行。
• 主庫與從庫間，通過數據庫同步策略進行數據同步。

由于主庫與從庫間的數據同步需要時間，會出現數據不一致的情況，這塊是業務上需要慎重考慮的一點。

隨著業務越來越復雜，對功能和性能的要求也越來越高，最常見的便是數據庫 like 語句性能已經無法滿足需求;對于某些熱點數據的訪問，其性能也下降很快。

此時，我們需要引入其他組件來有針對性的解決問題。

引入搜索和緩存

針對數據庫的 like 語句，通常情況下，是通過引入搜索引擎來解決;而熱點數據的訪問加速，是通過引入緩存服務來解決。

該架構的特征如下：

• 添加搜索集群，用以提升數據檢索性能。
• 添加緩存集群，用以提升熱點數據訪問性能。

在對數據查詢進行優化后，慢慢的系統的寫性能成為了瓶頸。此時，需要對數據的寫性能進行擴展。

數據庫分庫分表

隨著數據量的增長，寫請求量的增加，數據庫的寫入逐漸成為了瓶頸。常規的寫性能優化便是對數據庫進行分庫分表。

垂直拆分

將不同的業務數據放到不同的數據庫實例中。

水平切分

把同一個表中的數據拆分到多個數據庫中。

隨著研發團隊的規模越來越多，大家同時在一個項目中進行開發，導致頻繁的沖突和相互影響。

此時，會將整個應用程序根據功能模塊進行拆分，從而形成多個子網站或子頻道。

應用垂直拆分

面對一個巨無霸式的應用，就像面對一團毛線團，總有一種無法下手的感覺。對此，可以將其進行拆分，將其拆分為多個應用，每個應用獨立開發、獨立部署、獨立維護。

該部署方案更加靈活，大大降低維護成本：

• 通過不同的域名或 URL 將整個系統分解為多個子系統。
• 用戶通過瀏覽器將各子系統拼接成一個完整的系統。
• 各系統間存在少量交互，甚至沒有交互。

問題慢慢展現出來，系統間公共部分沒有統一維護點，同樣的功能、同樣的代碼分布在各個系統中。

當然，我們可以通過發布 jar 包的方式，共享功能代碼;但當 jar 升級時，就需要所有的子系統同步升級，運維開銷巨大。此時，我們需要引入服務化架構。

服務化架構

我們可以將通用功能封裝成一個服務，獨立開發、獨立部署、獨立維護。

在該方案中，我們將業務邏輯進行了進一步拆分：

• 整理各個系統間通用業務功能，將其封裝為服務，以承載核心業務邏輯，構建成服務集群。
• 原來的子系統或子頻道，變成薄薄的一層，不承載核心業務，只是根據業務流程對業務服務進行編排。
• 應用服務與業務服務間通過 HTTP 或其他協議進行通信，常見的包括 Dubbo、Thrift 等。

服務化解決了系統之間的直接調用問題，也就是常說的 RPC，整個系統的協調點全部由應用服務完成。

這種架構適用于多種場景，但在一些需要異步處理的極端場景就顯得有心無力了。此時，我們需要引入消息中間件。

引入消息隊列

服務化解決了直接調用問題，對于異步調用，最常見的便是消息中間件。

相比之前的架構，變化很小，只是在各個業務服務間添加了另外的一種調用方式。

小結

冰凍三尺非一日之寒，一個大型系統的構建也不是一朝一夕的事情。我們需要根據業務情況、數據量情況、請求量情況對系統進行合理規劃。

切記，架構不是越復雜越好，而是“適合自己的便是最好的”。