默認
打賞 發表評論 2
即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?
閱讀(2908) | 評論(2 收藏2 淘帖1 1

本文引用了“薔薇Nina”的“Nginx 相關介紹(Nginx是什么?能干嘛?)”一文部分內容,感謝作者的無私分享。


1、引言


即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?_1.png

Nginx(及其衍生產品)是目前被大量使用的服務端反向代理和負載均衡方案,從某種意義上來講,Nginx幾乎是低成本、高負載Web服務端代名詞。

如此深入人心的Nginx,很多人也想當然的認為,在IM或消息推送等場景下是否也能使用Nginx來解決負載均衡問題?

另外,即時通訊網的論壇和QQ群里也經常有人問起,Nginx是否能支持TCP、UDP、WebSocket的負載均衡?

帶著上面的疑問,我們來開始本文的學習吧!

2、相關文章



3、Nginx的產生


沒有聽過Nginx?那么一定聽過它的"同行"Apache吧!Nginx同Apache一樣都是一種WEB服務器。基于REST架構風格,以統一資源描述符(Uniform Resources Identifier)URI或者統一資源定位符(Uniform Resources Locator)URL作為溝通依據,通過HTTP協議提供各種網絡服務。

然而,這些服務器在設計之初受到當時環境的局限,例如當時的用戶規模,網絡帶寬,產品特點等局限并且各自的定位和發展都不盡相同。這也使得各個WEB服務器有著各自鮮明的特點。

Apache的發展時期很長,而且是毫無爭議的世界第一大服務器。它有著很多優點:穩定、開源、跨平臺等等。它出現的時間太長了,它興起的年代,互聯網產業遠遠比不上現在。所以它被設計為一個重量級的。它不支持高并發的服務器。在Apache上運行數以萬計的并發訪問,會導致服務器消耗大量內存。操作系統對其進行進程或線程間的切換也消耗了大量的CPU資源,導致HTTP請求的平均響應速度降低。

這些都決定了Apache不可能成為高性能WEB服務器,輕量級高并發服務器Nginx就應運而生了。

俄羅斯的工程師Igor Sysoev,他在為Rambler Media工作期間,使用C語言開發了Nginx。Nginx作為WEB服務器一直為Rambler Media提供出色而又穩定的服務。

即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?_522d762853d52.jpg
▲ Igor Sysoev,Nginx的創始人

然后呢,Igor Sysoev將Nginx代碼開源,并且賦予自由軟件許可證。

由于以下原因:

  • 1)Nginx使用基于事件驅動架構,使得其可以支持數以百萬級別的TCP連接;
  • 2)高度的模塊化和自由軟件許可證使得第三方模塊層出不窮(這是個開源的時代啊~);
  • 3)Nginx是一個跨平臺服務器,可以運行在Linux,Windows,FreeBSD,Solaris,AIX,Mac OS等操作系統上;
  • 4)這些優秀的設計帶來的是極大的穩定性。

所以,Nginx火了!

4、Nginx最常見的用途、用法、使用場景


4.1概述


簡而言之,Nginx是:

  • 1)自由的、開源的、高性能的HTTP服務器和反向代理服務器;
  • 2)也是一個IMAP、POP3、SMTP代理服務器;
  • 3)可以作為一個HTTP服務器進行網站的發布處理;
  • 4)可以作為反向代理進行負載均衡的實現。

4.2什么是代理?


說到代理,首先我們要明確一個概念,所謂代理就是一個代表、一個渠道。

此時就涉及到兩個角色,一個是被代理角色,一個是目標角色,被代理角色通過這個代理訪問目標角色完成一些任務的過程稱為代理操作過程;如同生活中的專賣店~客人到adidas專賣店買了一雙鞋,這個專賣店就是代理,被代理角色就是adidas廠家,目標角色就是用戶。

4.3什么是正向代理?


說反向代理之前,我們先看看正向代理,正向代理也是大家最常接觸的到的代理模式,我們會從兩個方面來說關于正向代理的處理模式,分別從軟件方面和生活方面來解釋一下什么叫正向代理。

在如今的網絡環境下,我們如果由于技術需要要去訪問國外的某些網站,此時你會發現位于國外的某網站我們通過瀏覽器是沒有辦法訪問的,此時大家可能都會用一個操作FQ進行訪問,FQ的方式主要是找到一個可以訪問國外網站的代理服務器,我們將請求發送給代理服務器,代理服務器去訪問國外的網站,然后將訪問到的數據傳遞給我們!

上述這樣的代理模式稱為正向代理:

  • 1)正向代理最大的特點是客戶端非常明確要訪問的服務器地址;
  • 2)服務器只清楚請求來自哪個代理服務器,而不清楚來自哪個具體的客戶端;
  • 3)正向代理模式屏蔽或者隱藏了真實客戶端信息。

來看個示意圖(我把客戶端和正向代理框在一塊,同屬于一個環境,后面我有介紹):
即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?_2.jpg

客戶端必須設置正向代理服務器,當然前提是要知道正向代理服務器的IP地址,還有代理程序的端口。

如下圖所示:
即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?_3.jpg

總結來說:正向代理,"它代理的是客戶端,代客戶端發出請求",是一個位于客戶端和原始服務器(origin server)之間的服務器,為了從原始服務器取得內容,客戶端向代理發送一個請求并指定目標(原始服務器),然后代理向原始服務器轉交請求并將獲得的內容返回給客戶端。客戶端必須要進行一些特別的設置才能使用正向代理。

正向代理的用途:

  • 1)訪問原來無法訪問的資源,如Google;
  • 2) 可以做緩存,加速訪問資源;
  • 3)對客戶端訪問授權,上網進行認證;
  • 4)代理可以記錄用戶訪問記錄(上網行為管理),對外隱藏用戶信息。

4.4什么是反向代理?


明白了什么是正向代理,我們繼續看關于反向代理的處理方式。

舉例如我大天朝的某寶網站,每天同時連接到網站的訪問人數已經爆表,單個服務器遠遠不能滿足人民日益增長的購買欲望了,此時就出現了一個大家耳熟能詳的名詞:分布式部署。

所謂分布式部署,也就是通過部署多臺服務器來解決訪問人數限制的問題。某寶網站中大部分功能也是直接使用Nginx進行反向代理實現的,并且通過封裝Nginx和其他的組件之后起了個高大上的名字:Tengine,有興趣的童鞋可以訪問Tengine的官網查看具體的信息:http://tengine.taobao.org/

那么反向代理具體是通過什么樣的方式實現的分布式的集群操作呢,我們先看一個示意圖(我把服務器和反向代理框在一塊,同屬于一個環境,后面我有介紹),如下圖所示。

即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?_4.jpg

通過上述的圖解大家就可以看清楚了:多個客戶端給服務器發送的請求,Nginx服務器接收到之后,按照一定的規則分發給了后端的業務處理服務器進行處理了。此時~請求的來源也就是客戶端是明確的,但是請求具體由哪臺服務器處理的并不明確了,Nginx扮演的就是一個反向代理角色。

客戶端是無感知代理的存在的,反向代理對外都是透明的,訪問者并不知道自己訪問的是一個代理。因為客戶端不需要任何配置就可以訪問。

反向代理,"它代理的是服務端,代服務端接收請求",主要用于服務器集群分布式部署的情況下,反向代理隱藏了服務器的信息。

反向代理的作用:

  • 1)保證內網的安全,通常將反向代理作為公網訪問地址,Web服務器是內網;
  • 2)負載均衡,通過反向代理服務器來優化網站的負載。

典型的項目場景:

通常情況下,我們在實際項目操作時,正向代理和反向代理很有可能會存在在一個應用場景中,正向代理代理客戶端的請求去訪問目標服務器,目標服務器是一個反向單利服務器,反向代理了多臺真實的業務處理服務器。

具體的拓撲圖如下:
即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?_5.jpg

4.5正向代理和反向代理的區別


截了一張圖來說明正向代理和反向代理二者之間的區別,如下圖。

即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?_6.jpg

圖解如下:

  • 1)在正向代理中,Proxy和Client同屬于一個LAN(圖中方框內),隱藏了客戶端信息;
  • 2)在反向代理中,Proxy和Server同屬于一個LAN(圖中方框內),隱藏了服務端信息。

實際上,Proxy在兩種代理中做的事情都是替服務器代為收發請求和響應,不過從結構上看正好左右互換了一下,所以把后出現的那種代理方式稱為反向代理了。

4.6Nginx的負載均衡技術


我們已經明確了所謂代理服務器的概念,那么接下來,Nginx扮演了反向代理服務器的角色,它是以依據什么樣的規則進行請求分發的呢?不用的項目應用場景,分發的規則是否可以控制呢?

這里提到的客戶端發送的、Nginx反向代理服務器接收到的請求數量,就是我們說的負載量。

請求數量按照一定的規則進行分發到不同的服務器處理的規則,就是一種均衡規則。

所以~將服務器接收到的請求按照規則分發的過程,稱為負載均衡。

負載均衡在實際項目操作過程中,有硬件負載均衡和軟件負載均衡兩種,硬件負載均衡也稱為硬負載,如F5負載均衡,相對造價昂貴成本較高,但是數據的穩定性安全性等等有非常好的保障,如中國移動中國聯通這樣的公司才會選擇硬負載進行操作;更多的公司考慮到成本原因,會選擇使用軟件負載均衡,軟件負載均衡是利用現有的技術結合主機硬件實現的一種消息隊列分發機制。

即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?_7.jpg

Nginx支持的負載均衡調度算法方式如下:

  • 1)weight輪詢(默認,常用):接收到的請求按照權重分配到不同的后端服務器,即使在使用過程中,某一臺后端服務器宕機,Nginx會自動將該服務器剔除出隊列,請求受理情況不會受到任何影響。 這種方式下,可以給不同的后端服務器設置一個權重值(weight),用于調整不同的服務器上請求的分配率;權重數據越大,被分配到請求的幾率越大;該權重值,主要是針對實際工作環境中不同的后端服務器硬件配置進行調整的。
  • 2)ip_hash(常用):每個請求按照發起客戶端的ip的hash結果進行匹配,這樣的算法下一個固定ip地址的客戶端總會訪問到同一個后端服務器,這也在一定程度上解決了集群部署環境下session共享的問題。
  • 3)fair:智能調整調度算法,動態的根據后端服務器的請求處理到響應的時間進行均衡分配,響應時間短處理效率高的服務器分配到請求的概率高,響應時間長處理效率低的服務器分配到的請求少;結合了前兩者的優點的一種調度算法。但是需要注意的是Nginx默認不支持fair算法,如果要使用這種調度算法,請安裝upstream_fair模塊。
  • 4)url_hash:按照訪問的url的hash結果分配請求,每個請求的url會指向后端固定的某個服務器,可以在Nginx作為靜態服務器的情況下提高緩存效率。同樣要注意Nginx默認不支持這種調度算法,要使用的話需要安裝Nginx的hash軟件包。

5、Nginx對TCP、UDP、WebSocket的負載均衡支持


5.1概述


準確地說,對于熟悉Nginx的使用者來講,上面的章節所介紹的內容都是針對Nginx最擅長的Http協議來講的,這也是Nginx最為成功的應用場景。隨著Nginx的不斷升級和進化,開發者們對于Nginx能支持更為底層的TCP、UDP以及HTML5里才出現的WebSocket協議頗為期待,好在這一切已經成真!

Nginx從1.3版開始支持WebSocket協議的反向代理(負載均衡),從1.9.0版本開始支持TCP協議反向代理(負載均衡),從1.9.13開始支持UDP協議反向代理(負載均衡)。

從原理上說,Nginx對于UDP或TCP的反向代理(負載均衡)是一致的,而WebSocket協議實際是就是TCP協議的應用層協議,因此本節我們將介紹Nginx對TCP協議反向代理(負載均衡)的支持。

Nginx對于經典的HTTP協議,也就是我們通常所說的“七層負載均衡”,它實際上工作在第七層“應用層”。而對于更為底層的TCP協議來說,負載均衡就是我們通常所說的“四層負載均衡”,工作在“網絡層”和“傳輸層”。例如,LVS(Linux Virtual Server,Linux虛擬服務)和F5(一種硬件負載均衡設備),也是屬于“四層負載均衡”。

即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?_2-1.jpg

5.2TCP負載均衡的執行原理


當Nginx從監聽端口收到一個新的客戶端鏈接時,立刻執行路由調度算法,獲得指定需要連接的服務IP,然后創建一個新的上游連接,連接到指定服務器。

即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?_2-2.jpg

TCP負載均衡支持Nginx原有的調度算法,包括Round Robin(默認,輪詢調度),哈希(選擇一致)等。同時,調度信息數據也會和健壯性檢測模塊一起協作,為每個連接選擇適當的目標上游服務器。如果使用Hash負載均衡的調度方法,你可以使用$remote_addr(客戶端IP)來達成簡單持久化會話(同一個客戶端IP的連接,總是落到同一個服務server上)。

和其他upstream模塊一樣,TCP的stream模塊也支持自定義負載均和的轉發權重(配置“weight=2”),還有backup和down的參數,用于踢掉失效的上游服務器。max_conns參數可以限制一臺服務器的TCP連接數量,根據服務器的容量來設置恰當的配置數值,尤其在高并發的場景下,可以達到過載保護的目的。

Nginx監控客戶端連接和上游連接,一旦接收到數據,則Nginx會立刻讀取并且推送到上游連接,不會做TCP連接內的數據檢測。Nginx維護一份內存緩沖區,用于客戶端和上游數據的寫入。如果客戶端或者服務端傳輸了量很大的數據,緩沖區會適當增加內存的大小。

即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?_2-3.jpg

當Nginx收到任意一方的關閉連接通知,或者TCP連接被閑置超過了proxy_timeout配置的時間,連接將會被關閉。對于TCP長連接,我們更應該選擇適當的proxy_timeout的時間,同時,關注監聽socke的so_keepalive參數,防止過早地斷開連接。

即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?_2--.png

5.3服務健壯性監控


TCP負載均衡模塊支持內置健壯性檢測,一臺上游服務器如果拒絕TCP連接超過proxy_connect_timeout配置的時間,將會被認為已經失效。在這種情況下,Nginx立刻嘗試連接upstream組內的另一臺正常的服務器。連接失敗信息將會記錄到Nginx的錯誤日志中。

即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?_2-4.jpg

如果一臺服務器,反復失敗(超過了max_fails或者fail_timeout配置的參數),Nginx也會踢掉這臺服務器。服務器被踢掉60秒后,Nginx會偶爾嘗試重連它,檢測它是否恢復正常。如果服務器恢復正常,Nginx將它加回到upstream組內,緩慢加大連接請求的比例。

之所“緩慢加大”,因為通常一個服務都有“熱點數據”,也就是說,80%以上甚至更多的請求,實際都會被阻擋在“熱點數據緩存”中,真正執行處理的請求只有很少的一部分。在機器剛剛啟動的時候,“熱點數據緩存”實際上還沒有建立,這個時候爆發性地轉發大量請求過來,很可能導致機器無法“承受”而再次掛掉。以mysql為例子,我們的mysql查詢,通常95%以上都是落在了內存cache中,真正執行查詢的并不多。

其實,無論是單臺機器或者一個集群,在高并發請求場景下,重啟或者切換,都存在這個風險。

解決的途徑主要是兩種:

  • 1)請求逐步增加,從少到多,逐步積累熱點數據,最終達到正常服務狀態;
  • 2)提前準備好“常用”的數據,主動對服務做“預熱”,預熱完成之后,再開放服務器的訪問。

TCP負載均衡原理上和LVS等是一致的,工作在更為底層,性能會高于原來HTTP負載均衡不少。但是,不會比LVS更為出色,LVS被置于內核模塊,而Nginx工作在用戶態,而且,Nginx相對比較重。

6、Nginx能否實現IM的負載均衡?


6.1概述


從上一節內容來看,Nginx是可以實現TCP、UDP、WebSocket協議的反向代碼(負載均衡)的,既然如此,那么基于TCP、UDP或者WebSocket協議的IM聊天系統來說,是否能通過Nginx直接實現IM的負載均衡呢?

要回答這個問題,我們首先來不同的長連接場景下,具體的數據走向情況。

為了方便敘述,以下基于TCP、UDP或者WebSocket協議實現的socket長連接,我們簡稱為socket長連接。

6.2Nginx所支持的長連接反向代理數據走向能力


對于利于Nginx實現的socket長連接,數據走向如下圖所示:
即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?_QQ截圖20190606234945.jpg

如上圖,即:

  • 1)客戶端通過Nginx反向代理到一臺socket長連接服務器;
  • 2)客戶端可以與建立連接的socket長連接服務器進行雙向通信(即客戶端->socket長連接服務器、和socket長連接服務器->客戶端兩個方向)。

簡而言之,Nginx能實現的長連接數據走向能力為:

  • 1)Client to Server方向(簡稱c2s):即客戶端向長連接服務端發送數據的能力;
  • 2)Server to Client方向(簡稱s2c):即長連接服務端向客戶端發送數據的能力。

6.3IM聊天軟件需要的長連接數據走向能力


對于IM聊天應用來說,必須具備的數據走向能力為:

  • 1)Client to Server方向(簡稱c2s):即客戶端向長連接服務端發送數據的能力;
  • 2)Server to Client方向(簡稱s2c):即長連接服務端向客戶端發送數據的能力;
  • 3)Client to Client方向(簡稱c2c):即客戶端向客戶端發送數據的能力。

IM聊天應用中的3種數據走向,對應的典型功能邏輯場景:

  • 1)Client to Server方向(簡稱c2s):通常用于客戶端向IM長連接服務端發起指令,比如:發起加好友請求、發送一條陌生人聊天消息、發送一條群聊消息等;
  • 2)Server to Client方向(簡稱s2c):通常用于服務端主動向客戶端推送指令,比如:向客戶端轉達加好友請求、轉發陌生人聊天消息、擴散寫式的發送群聊消息(給所有群成員)、系統通知等;
  • 3)Client to Client方向(簡稱c2c):即客戶端向客戶端發送數據的能力,比如:一條正常的好友聊天消息就是由客戶端A發送給客戶端B(當然這不一定是P2P技術實現)。

6.4結論


顯然,如上節所講,Nginx所實現的TCP、UDP或者WebSocket協議的反向代理(負載均衡),只能實現c2s、s2c兩種數據走向,而IM聊天應用中是必須需要c2s、s2c、c2c 共3種消息走向。對于c2c這種數據走向,顯然是IM特有的場景需求,要讓Nginx這種通用解決方案來提供,就有點牽強了。

我們可以得出結論:我們是無法通過Nginx直接實現IM的負載均衡的。

換句話講,如果真能通過Nginx直接實現IM的負載均衡,那IM的服務端在處理高并發、高吞吐時,就可以像Http協議一樣安逸啦!

6.5例外


不過,對于即時通訊網所關注的另一技術范疇——消息推送系統(或類似系統),是完全可以通過Nginx直接實現消息推送的負載均衡的,因為恰好消息推送系統也只需要c2s、s2c兩種數據走向,并不需要c2c這種橫向的數據交互。

附錄:有關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的艱辛成長之路
社交軟件紅包技術解密(一):全面解密QQ紅包技術方案——架構、技術實現等
社交軟件紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進
社交軟件紅包技術解密(三):微信搖一搖紅包雨背后的技術細節
社交軟件紅包技術解密(四):微信紅包系統是如何應對高并發的
社交軟件紅包技術解密(五):微信紅包系統是如何實現高可用性的
社交軟件紅包技術解密(六):微信紅包系統的存儲層架構演進實踐
社交軟件紅包技術解密(七):支付寶紅包的海量高并發技術實踐
社交軟件紅包技術解密(八):全面解密微博紅包技術方案
社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等
即時通訊新手入門:一文讀懂什么是Nginx?它能否實現IM的負載均衡?
>> 更多同類文章 ……

即時通訊網 - 即時通訊開發者社區! 來源: - 即時通訊開發者社區!

上一篇:社交軟件紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等

本帖已收錄至以下技術專輯

推薦方案
評論 2
引用:Client to Client方向(簡稱c2c):即客戶端向客戶端發送數據的能力,比如:一條正常的好友聊天消息就是由客戶端A發送給客戶端B(當然這不一定是P2P技術實現)。

c2c 需要服務端嗎
引用:摸魚中 發表于 2019-06-10 11:06
c2c 需要服務端嗎

c2c不是p2p。
c2c依然是走服務器中轉
但如果要做多實例負載,當兩個人登陸在不同的實例上時,兩個服務端實例間怎么通信?
這是nginx解決不了,也不應該去解決的.
這說的是橫向通信能力了。
im難搞就在這里

簽名: 《對比主流分布式MQ消息隊列,媽媽再也不擔心我的技術選型了》http://www.uktmgv.tw/thread-2625-1-1.html
打賞樓主 ×
使用微信打賞! 使用支付寶打賞!

返回頂部
曾氏料二肖中特