一篇讀懂分佈式架構下的負載均衡技術：分類、原理、算法、常見方案等

一、引言

關於「負載均衡」的解釋，百度詞條裏：負載均衡，英文叫Load Balance，意思就是將請求或者數據分攤到多個操做單元上進行執行，共同完成工做任務。

負載均衡（Load Balance）創建在現有網絡結構之上，它提供了一種廉價有效透明的方法擴展網絡設備和服務器的帶寬、增長吞吐量、增強網絡數據處理能力、提升網絡的靈活性和可用性。

負載均衡有兩方面的含義：

1）首先，大量的併發訪問或數據流量分擔到多臺節點設備上分別處理，減小用戶等待響應的時間；

2）其次，單個重負載的運算分擔到多臺節點設備上作並行處理，每一個節點設備處理結束後，將結果彙總，返回給用戶，系統處理能力獲得大幅度提升。

簡單來講就是：

1）其一是將大量的併發處理轉發給後端多個節點處理，減小工做響應時間；

2）其二是將單個繁重的工做轉發給後端多個節點處理，處理完再返回給負載均衡中心，再返回給用戶。

目前負載均衡技術大多數是用於提升諸如在Web服務器、FTP服務器和其它關鍵任務服務器上的Internet服務器程序的可用性和可伸縮性。

總之，它的目的就經過調度集羣，達到最佳化資源使用，最大化吞吐率，最小化響應時間，避免單點過載的問題。

內容概述：本文將從負載均衡技術的分類、技術原理、常見實現算法、經常使用方案等入手，爲您詳細講解負載均衡技術的方方面面。這其中，四層和七層負載均衡技術最爲經常使用，它們也是本文介紹的重點。

內容點評：對於IM或消息推送應用的開發者來講，本文所介紹的傳統負載均衡技術，可能對於IM等即時通信分佈式場景來講，沒有辦法直接套用。緣由是IM這類socket長鏈接場景，所處的網絡通訊層級比較低，並且即時通信相關的技術實現跟具體的業務邏輯緊密相關，於是沒法像HTTP短鏈接這樣基於標準化的負載均衡方法來實現。但本文所介紹的負載均衡原理、算法和一些方案實現，仍然能夠爲IM或消息推送應用的開發者帶來一些借鑑和參考意義，值得深 入一讀。

補充：另外一篇《快速理解高性能HTTP服務端的負載均衡技術原理》，也講述了負載均衡方面的知識，有興趣也能夠閱讀之。

（本文同步發佈於：http://www.52im.net/thread-2494-1-1.html）

二、相關文章

深刻閱讀如下文章，有助於您更好地理解本篇內容：

• 《網絡編程懶人入門(一)：快速理解網絡通訊協議（上篇）》
• 《網絡編程懶人入門(二)：快速理解網絡通訊協議（下篇）》
• 《網絡編程懶人入門(三)：快速理解TCP協議一篇就夠》
• 《騰訊資深架構師乾貨總結：一文讀懂大型分佈式系統設計的方方面面》
• 《快速理解高性能HTTP服務端的負載均衡技術原理》
• 《新手入門：零基礎理解大型分佈式架構的演進歷史、技術原理、最佳實踐》
• 《通俗易懂：基於集羣的移動端IM接入層負載均衡方案分享》
• 《IM開發基礎知識補課：正確理解前置HTTP SSO單點登錄接口的原理》

三、負載均衡分類

TCP/IP協議的OSI模型：

 

（本圖高清版，請從《計算機網絡通信協議關係圖（中文珍藏版）[附件下載]》一文中下載之）

根據OSI模型可將負載均衡分爲：

1）二層負載均衡（通常是用虛擬mac地址方式，外部對虛擬MAC地址請求，負載均衡接收後分配後端實際的MAC地址響應）；

2）三層負載均衡（通常採用虛擬IP地址方式，外部對虛擬的ip地址請求，負載均衡接收後分配後端實際的IP地址響應）；

3）四層負載均衡（在三次負載均衡的基礎上，用 ip+port 接收請求，再轉發到對應的機器）；

4）七層負載均衡（根據虛擬的url或是IP，主機名接收請求，再轉向相應的處理服務器）。

這其中，最多見的是四層和七層負載均衡，也是本文接下來介紹的重點。

當客戶端發起請求，會通過層層的封裝，發給服務器，服務器收到請求後通過層層的解析，獲取到對應的內容。

下圖是一個典型的HTTP請求分層傳遞原理：

 

四、二層負載均衡

二層負債均衡是基於數據鏈路層的負債均衡，即讓負債均衡服務器和業務服務器綁定同一個虛擬IP（即VIP），客戶端直接經過這個VIP進行請求。

那麼如何區分相同IP下的不一樣機器呢？沒錯，經過MAC物理地址，每臺機器的MAC物理地址都不同，當負載均衡服務器接收到請求以後，經過改寫HTTP報文中以太網首部的MAC地址，按照某種算法將請求轉發到目標機器上，實現負載均衡。

這種方式負載方式雖然控制粒度比較粗，可是優勢是負載均衡服務器的壓力會比較小，負載均衡服務器只負責請求的進入，不負責請求的響應（響應是有後端業務服務器直接響應給客戶端），吞吐量會比較高。

 

五、三層負載均衡

三層負載均衡是基於網絡層的負載均衡，通俗的說就是按照不一樣機器不一樣IP地址進行轉發請求到不一樣的機器上。

這種方式雖然比二層負載多了一層，但從控制的顆粒度上看，並無比二層負載均衡更有優點，而且，因爲請求的進出都要通過負載均衡服務器，會對其形成比較大的壓力，性能也比二層負載均衡要差。

 

六、四層負載均衡

四層的負載均衡就是基於IP+端口的負載均衡：在三層負載均衡的基礎上，經過發佈三層的IP地址（VIP），而後加四層的端口號，來決定哪些流量須要作負載均衡，對須要處理的流量進行NAT處理，轉發至後臺服務器，並記錄下這個TCP或者UDP的流量是由哪臺服務器處理的，後續這個鏈接的全部流量都一樣轉發到同一臺服務器處理。

對應的負載均衡器稱爲四層交換機（L4 switch），主要分析IP層及TCP/UDP層，實現四層負載均衡。

此種負載均衡器不理解應用協議（如HTTP/FTP/MySQL等等），常見例子有：LVS，F5。

七、七層負載均衡

七層的負載均衡就是基於虛擬的URL或主機IP的負載均衡：在四層負載均衡的基礎上（沒有四層是絕對不可能有七層的），再考慮應用層的特徵，好比同一個Web服務器的負載均衡，除了根據VIP加80端口辨別是否須要處理的流量，還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。

舉個例子，若是你的Web服務器分紅兩組，一組是中文語言的，一組是英文語言的，那麼七層負載均衡就能夠當用戶來訪問你的域名時，自動辨別用戶語言，而後選擇對應的語言服務器組進行負載均衡處理。

對應的負載均衡器稱爲七層交換機（L7 switch），除了支持四層負載均衡之外，還有分析應用層的信息，如HTTP協議URI或Cookie信息，實現七層負載均衡。此種負載均衡器能理解應用協議，常見例子有：  haproxy，MySQL Proxy。

八、四層負載均衡和七層負載均衡的區別

8.1 技術原理上的區別

所謂四層負載均衡，也就是主要經過報文中的目標地址和端口，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。

以常見的TCP爲例，負載均衡設備在接收到第一個來自客戶端的SYN 請求時，即經過上述方式選擇一個最佳的服務器，並對報文中目標IP地址進行修改(改成後端服務器IP），直接轉發給該服務器。TCP的鏈接創建，即三次握手是客戶端和服務器直接創建的，負載均衡設備只是起到一個相似路由器的轉發動做。在某些部署狀況下，爲保證服務器回包能夠正確返回給負載均衡設備，在轉發報文的同時可能還會對報文原來的源地址進行修改。

 

所謂七層負載均衡，也稱爲「內容交換」，也就是主要經過報文中的真正有意義的應用層內容，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。

以常見的TCP爲例，負載均衡設備若是要根據真正的應用層內容再選擇服務器，只能先代理最終的服務器和客戶端創建鏈接(三次握手)後，纔可能接受到客戶端發送的真正應用層內容的報文，而後再根據該報文中的特定字段，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。負載均衡設備在這種狀況下，更相似於一個代理服務器。負載均衡和前端的客戶端以及後端的服務器會分別創建TCP鏈接。因此從這個技術原理上來看，七層負載均衡明顯的對負載均衡設備的要求更高，處理七層的能力也必然會低於四層模式的部署方式。

8.2 應用場景的需求

七層應用負載的好處，是使得整個網絡更"智能化"。參考這篇《利用負載均衡優化和加速HTTP應用》，就能夠基本上了解這種方式的優點所在。

例如訪問一個網站的用戶流量，能夠經過七層的方式，將對圖片類的請求轉發到特定的圖片服務器並可使用緩存技術；將對文字類的請求能夠轉發到特定的文字服務器並可使用壓縮技術。

固然這只是七層應用的一個小案例，從技術原理上，這種方式能夠對客戶端的請求和服務器的響應進行任意意義上的修改，極大的提高了應用系統在網絡層的靈活性。不少在後臺，例如Nginx或者Apache上部署的功能能夠前移到負載均衡設備上，例如客戶請求中的Header重寫，服務器響應中的關鍵字過濾或者內容插入等功能。

另一個經常被提到功能就是安全性。網絡中最多見的SYN Flood攻擊，即黑客控制衆多源客戶端，使用虛假IP地址對同一目標發送SYN攻擊，一般這種攻擊會大量發送SYN報文，耗盡服務器上的相關資源，以達到Denial of Service(DoS)的目的。

從技術原理上也能夠看出，四層模式下這些SYN攻擊都會被轉發到後端的服務器上；而七層模式下這些SYN攻擊天然在負載均衡設備上就截止，不會影響後臺服務器的正常運營。另外負載均衡設備能夠在七層層面設定多種策略，過濾特定報文，例如SQL Injection等應用層面的特定攻擊手段，從應用層面進一步提升系統總體安全。

如今的7層負載均衡，主要仍是着重於應用HTTP協議，因此其應用範圍主要是衆多的網站或者內部信息平臺等基於B/S開發的系統。 4層負載均衡則對應其餘TCP應用，例如IM即時通信、實時消息推送等socket長鏈接系統。

8.3 七層應用須要考慮的問題

七層應用須要考慮的問題：

1）是否真的必要：七層應用的確能夠提升流量智能化，同時必不可免的帶來設備配置複雜，負載均衡壓力增高以及故障排查上的複雜性等問題。在設計系統時須要考慮四層七層同時應用的混雜狀況。

2）是否真的能夠提升安全性：例如SYN Flood攻擊，七層模式的確將這些流量從服務器屏蔽，但負載均衡設備自己要有強大的抗DDoS能力，不然即便服務器正常而做爲中樞調度的負載均衡設備故障也會致使整個應用的崩潰。

3）是否有足夠的靈活度：七層應用的優點是可讓整個應用的流量智能化，可是負載均衡設備須要提供完善的七層功能，知足客戶根據不一樣狀況的基於應用的調度。最簡單的一個考覈就是可否取代後臺Nginx或者Apache等服務器上的調度功能。可以提供一個七層應用開發接口的負載均衡設備，可讓客戶根據需求任意設定功能，才真正有可能提供強大的靈活性和智能性。

8.4 整體對比

四層負載均衡和七層負載均衡技術的整體對比：

1）智能性：七層負載均衡因爲具有OIS七層的全部功能，因此在處理用戶需求上能更加靈活，從理論上講，七層模型能對用戶的全部跟服務端的請求進行修改。例如對文件header添加信息，根據不一樣的文件類型進行分類轉發。四層模型僅支持基於網絡層的需求轉發，不能修改用戶請求的內容。

2）安全性：七層負載均衡因爲具備OSI模型的所有功能，能更容易抵禦來自網絡的攻擊；四層模型從原理上講，會直接將用戶的請求轉發給後端節點，沒法直接抵禦網絡攻擊。

3）複雜度：四層模型通常比較簡單的架構，容易管理，容易定位問題；七層模型架構比較複雜，一般也須要考慮結合四層模型的混用狀況，出現問題定位比較複雜。

4）效率比：四層模型基於更底層的設置，一般效率更高，但應用範圍有限；七層模型須要更多的資源損耗，在理論上講比四層模型有更強的功能，如今的實現更可能是基於http應用。

九、負載均衡技術的常見具體應用方案

目前有許多不一樣的負載均衡技術實現用以知足不一樣的應用需求，下面從負載均衡所採用的設備對象（軟/硬件負載均衡），應用的OSI網絡層次（網絡層次上的負載均衡），及應用的地理結構（本地/全局負載均衡）等來分類。

9.1 軟/硬件負載均衡

軟件負載均衡解決方案：是指在一臺或多臺服務器相應的操做系統上安裝一個或多個附加軟件來實現負載均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl，Keepalive+ipvs等，它的優勢是基於特定環境，配置簡單，使用靈活，成本低廉，能夠知足通常的負載均衡需求。軟件解決方案缺點也較多，由於每臺服務器上安裝額外的軟件運行會消耗系統不定量的資源，越是功能強大的模塊，消耗得越多，因此當鏈接請求特別大的時候，軟件自己會成爲服務器工做成敗的一個關鍵；軟件可擴展性並非很好，受到操做系統的限制；因爲操做系統自己的Bug，每每會引發安全問題。

硬件負載均衡解決方案：是直接在服務器和外部網絡間安裝負載均衡設備，這種設備一般是一個獨立於系統的硬件，咱們稱之爲負載均衡器。因爲專門的設備完成專門的任務，獨立於操做系統，總體性能獲得大量提升，加上多樣化的負載均衡策略，智能化的流量管理，可達到最佳的負載均衡需求。負載均衡器有多種多樣的形式，除了做爲獨立意義上的負載均衡器外，有些負載均衡器集成在交換設備中，置於服務器與Internet連接之間，有些則以兩塊網絡適配器將這一功能集成到PC中，一塊鏈接到Internet上，一塊鏈接到後端服務器羣的內部網絡上。

軟件負載均衡與硬件負載均衡的對好比下。

1）軟件負載均衡：

優勢：是需求環境明確，配置簡單，操做靈活，成本低廉，效率不高，能知足普通的企業需求；

缺點：依賴於系統，增長資源開銷；軟件的優劣決定環境的性能；系統的安全，軟件的穩定性均會影響到整個環境的安全。

2）硬件負載均衡：

優勢：是獨立於系統，總體性能大量提高，在功能、性能上優於軟件方式；智能的流量管理，多種策略可選，能達到最佳的負載均衡效果；

缺點：是價格昂貴。

9.2 本地/全局負載均衡

負載均衡從其應用的地理結構上分爲本地負載均衡(Local Load Balance)和全局負載均衡(Global Load Balance，也叫地域負載均衡)，本地負載均衡是指對本地的服務器羣作負載均衡，全局負載均衡是指對分別放置在不一樣的地理位置、有不一樣網絡結構的服務器羣間做負載均衡。

本地負載均衡能有效地解決數據流量過大、網絡負荷太重的問題，而且不需花費昂貴開支購置性能卓越的服務器，充分利用現有設備，避免服務器單點故障形成數據流量的損失。其有靈活多樣的均衡策略把數據流量合理地分配給服務器羣內的服務器共同負擔。即便是再給現有服務器擴充升級，也只是簡單地增長一個新的服務器到服務羣中，而不需改變現有網絡結構、中止現有的服務。 

全局負載均衡主要用於在一個多區域擁有本身服務器的站點，爲了使全球用戶只以一個IP地址或域名就能訪問到離本身最近的服務器，從而得到最快的訪問速度，也可用於子公司分散站點分佈廣的大公司經過Intranet（企業內部互聯網）來達到資源統一合理分配的目的。

9.3 網絡層次上的負載均衡

針對網絡上負載太重的不一樣瓶頸所在，從網絡的不一樣層次入手，咱們能夠採用相應的負載均衡技術來解決現有問題。 

隨着帶寬增長，數據流量不斷增大，網絡核心部分的數據接口將面臨瓶頸問題，原有的單一線路將很難知足需求，並且線路的升級又過於昂貴甚至難以實現，這時就能夠考慮採用鏈路聚合（Trunking）技術。

鏈路聚合技術（第二層負載均衡）將多條物理鏈路看成一條單一的聚合邏輯鏈路使用，網絡數據流量由聚合邏輯鏈路中全部物理鏈路共同承擔，由此在邏輯上增大了鏈路的容量，使其能知足帶寬增長的需求。

現代負載均衡技術一般操做於網絡的第四層或第七層。第四層負載均衡將一個Internet上合法註冊的IP地址映射爲多個內部服務器的IP地址，對每次 TCP鏈接請求動態使用其中一個內部IP地址，達到負載均衡的目的。在第四層交換機中，此種均衡技術獲得普遍的應用，一個目標地址是服務器羣VIP（虛擬 IP，Virtual IP address）鏈接請求的數據包流經交換機，交換機根據源端和目的IP地址、TCP或UDP端口號和必定的負載均衡策略，在服務器IP和VIP間進行映射，選取服務器羣中最好的服務器來處理鏈接請求。

第七層負載均衡控制應用層服務的內容，提供了一種對訪問流量的高層控制方式，適合對HTTP服務器羣的應用。第七層負載均衡技術經過檢查流經的HTTP報頭，根據報頭內的信息來執行負載均衡任務。

第七層負載均衡優勢表如今以下幾個方面： 

1）經過對HTTP報頭的檢查，能夠檢測出HTTP400、500和600系列的錯誤信息，於是能透明地將鏈接請求從新定向到另外一臺服務器，避免應用層故障；

2）可根據流經的數據類型（如判斷數據包是圖像文件、壓縮文件或多媒體文件格式等），把數據流量引向相應內容的服務器來處理，增長系統性能；

3）能根據鏈接請求的類型，如是普通文本、圖象等靜態文檔請求，仍是asp、cgi等的動態文檔請求，把相應的請求引向相應的服務器來處理，提升系統的性能及安全性。

第七層負載均衡缺點表如今以下幾個方面： 

1）第七層負載均衡受到其所支持的協議限制（通常只有HTTP），這樣就限制了它應用的普遍性；

2）第七層負載均衡檢查HTTP報頭會佔用大量的系統資源，勢必會影響到系統的性能，在大量鏈接請求的狀況下，負載均衡設備自身容易成爲網絡總體性能的瓶頸。

十、經常使用的負載均衡算法

經常使用的負載均衡算法分爲兩類：

1）一種是靜態負載均衡；

2）一種是動態負載均衡。

10.1 靜態均衡算法

【10.1.1】輪詢法：

將請求按順序輪流地分配到每一個節點上，不關心每一個節點實際的鏈接數和當前的系統負載。

優勢：簡單高效，易於水平擴展，每一個節點知足字面意義上的均衡；

缺點：沒有考慮機器的性能問題，根據木桶最短木板理論，集羣性能瓶頸更多的會受性能差的服務器影響。

 

【10.1.2】隨機法：

將請求隨機分配到各個節點。由機率統計理論得知，隨着客戶端調用服務端的次數增多，其實際效果愈來愈接近於平均分配，也就是輪詢的結果。

優缺點和輪詢類似。

 

【10.1.3】源地址哈希法：

源地址哈希的思想是根據客戶端的IP地址，經過哈希函數計算獲得一個數值，用該數值對服務器節點數進行取模，獲得的結果即是要訪問節點序號。採用源地址哈希法進行負載均衡，同一IP地址的客戶端，當後端服務器列表不變時，它每次都會落到到同一臺服務器進行訪問。

優勢：相同的IP每次落在同一個節點，能夠人爲干預客戶端請求方向，例如灰度發佈；

缺點：若是某個節點出現故障，會致使這個節點上的客戶端沒法使用，沒法保證高可用。當某一用戶成爲熱點用戶，那麼會有巨大的流量涌向這個節點，致使冷熱分佈不均衡，沒法有效利用起集羣的性能。因此當熱點事件出現時，通常會將源地址哈希法切換成輪詢法。

 

【10.1.4】加權輪詢法：

不一樣的後端服務器可能機器的配置和當前系統的負載並不相同，所以它們的抗壓能力也不相同。給配置高、負載低的機器配置更高的權重，讓其處理更多的請；而配置低、負載高的機器，給其分配較低的權重，下降其系統負載，加權輪詢能很好地處理這一問題，並將請求順序且按照權重分配到後端。

加權輪詢算法要生成一個服務器序列，該序列中包含n個服務器。n是全部服務器的權重之和。在該序列中，每一個服務器的出現的次數，等於其權重值。而且，生成的序列中，服務器的分佈應該儘量的均勻。好比序列{a, a, a, a, a, b, c}中，前五個請求都會分配給服務器a，這就是一種不均勻的分配方法，更好的序列應該是：{a, a, b, a, c, a, a}。

優勢：能夠將不一樣機器的性能問題歸入到考量範圍，集羣性能最優最大化；

缺點：生產環境複雜多變，服務器抗壓能力也沒法精確估算，靜態算法致使沒法實時動態調整節點權重，只能粗糙優化。

 

【10.1.5】加權隨機法：

與加權輪詢法同樣，加權隨機法也根據後端機器的配置，系統的負載分配不一樣的權重。不一樣的是，它是按照權重隨機請求後端服務器，而非順序。

【10.1.6】鍵值範圍法：

根據鍵的範圍進行負債，好比0到10萬的用戶請求走第一個節點服務器，10萬到20萬的用戶請求走第二個節點服務器……以此類推。

優勢：容易水平擴展，隨着用戶量增長，能夠增長節點而不影響舊數據；

缺點：容易負債不均衡，好比新註冊的用戶活躍度高，舊用戶活躍度低，那麼壓力就全在新增的服務節點上，舊服務節點性能浪費。並且也容易單點故障，沒法知足高可用。

 

（注：以上所提到的單點故障，均可以用主從方式來解決，從節點監聽主節點心跳，當發現主節點死亡，從節點切換成主節點頂替上去。這裏能夠思考一個問題，怎麼設計集羣主從能夠最大程度上下降成本）

10.2 動態負債均衡算法

【10.2.1】最小鏈接數法：

根據每一個節點當前的鏈接狀況，動態地選取其中當前積壓鏈接數最少的一個節點處理當前請求，儘量地提升後端服務的利用效率，將請求合理地分流到每一臺服務器。俗稱閒的人不能閒着，你們一塊兒動起來。

優勢：動態，根據節點情況實時變化；

缺點：提升了複雜度，每次鏈接斷開須要進行計數；

實現：將鏈接數的倒數當權重值。

【10.2.2】最快響應速度法：

根據請求的響應時間，來動態調整每一個節點的權重，將響應速度快的服務節點分配更多的請求，響應速度慢的服務節點分配更少的請求，俗稱能者多勞，扶貧救弱。

優勢：動態，實時變化，控制的粒度更細，跟靈敏；

缺點：複雜度更高，每次須要計算請求的響應速度；

實現：能夠根據響應時間進行打分，計算權重。

【10.2.3】觀察模式法：

觀察者模式是綜合了最小鏈接數和最快響應度，同時考量這兩個指標數，進行一個權重的分配。

附錄：更多架構設計方案的文章精選

[1] 有關IM架構設計的文章：
《淺談IM系統的架構設計》
《簡述移動端IM開發的那些坑：架構設計、通訊協議和客戶端》
《一套海量在線用戶的移動端IM架構設計實踐分享(含詳細圖文)》
《一套原創分佈式即時通信(IM)系統理論架構方案》
《從零到卓越：京東客服即時通信系統的技術架構演進歷程》
《蘑菇街即時通信/IM服務器開發之架構選擇》
《騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT》
《微信後臺基於時間序的海量數據冷熱分級架構設計實踐》
《微信技術總監談架構：微信之道——大道至簡(演講全文)》
《如何解讀《微信技術總監談架構：微信之道——大道至簡》》
《快速裂變：見證微信強大後臺架構從0到1的演進歷程（一）》
《17年的實踐：騰訊海量產品的技術方法論》
《移動端IM中大規模羣消息的推送如何保證效率、實時性？》
《現代IM系統中聊天消息的同步和存儲方案探討》
《IM開發基礎知識補課(二)：如何設計大量圖片文件的服務端存儲架構？》
《IM開發基礎知識補課(三)：快速理解服務端數據庫讀寫分離原理及實踐建議》
《IM開發基礎知識補課(四)：正確理解HTTP短鏈接中的Cookie、Session和Token》
《WhatsApp技術實踐分享：32人工程團隊創造的技術神話》
《微信朋友圈千億訪問量背後的技術挑戰和實踐總結》
《王者榮耀2億用戶量的背後：產品定位、技術架構、網絡方案等》
《IM系統的MQ消息中間件選型：Kafka仍是RabbitMQ？》
《騰訊資深架構師乾貨總結：一文讀懂大型分佈式系統設計的方方面面》
《以微博類應用場景爲例，總結海量社交系統的架構設計步驟》
《快速理解高性能HTTP服務端的負載均衡技術原理》
《子彈短信光鮮的背後：網易雲信首席架構師分享億級IM平臺的技術實踐》
《知乎技術分享：從單機到2000萬QPS併發的Redis高性能緩存實踐之路》
《IM開發基礎知識補課(五)：通俗易懂，正確理解並用好MQ消息隊列》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》
《新手入門：零基礎理解大型分佈式架構的演進歷史、技術原理、最佳實踐》
《一套高可用、易伸縮、高併發的IM羣聊、單聊架構方案設計實踐》
《阿里技術分享：深度揭祕阿里數據庫技術方案的10年變遷史》
《阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路》
>> 更多同類文章 ……

[2] 更多其它架構設計相關文章：
《騰訊資深架構師乾貨總結：一文讀懂大型分佈式系統設計的方方面面》
《快速理解高性能HTTP服務端的負載均衡技術原理》
《子彈短信光鮮的背後：網易雲信首席架構師分享億級IM平臺的技術實踐》
《知乎技術分享：從單機到2000萬QPS併發的Redis高性能緩存實踐之路》
《新手入門：零基礎理解大型分佈式架構的演進歷史、技術原理、最佳實踐》
《阿里技術分享：深度揭祕阿里數據庫技術方案的10年變遷史》
《阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路》
《達達O2O後臺架構演進實踐：從0到4000高併發請求背後的努力》
《優秀後端架構師必會知識：史上最全MySQL大表優化方案總結》
《小米技術分享：解密小米搶購系統千萬高併發架構的演進和實踐》
《一篇讀懂分佈式架構下的負載均衡技術：分類、原理、算法、常見方案等》
>> 更多同類文章 ……

（本文同步發佈於：http://www.52im.net/thread-2494-1-1.html）