http服務端架構演進

摘要

詳解http報文相關文章中我們介紹了http協議是如何工作的,那麼構建一個真實的網站還需要引入組件呢?一些常見的名詞到底是什麼含義呢?

  1. 什麼叫正向代理,什麼叫反向代理
  2. 服務代理與負載均衡的差別
  3. 有了nginx,爲啥還需要LVS
  4. 都有哪些負載均衡的方式

服務端演進

在前面文章中我們介紹過最簡單的一種客戶端-服務端響應模式,如下

這是http服務最簡單的一種形式,服務端就一層web服務器。

現在我們服務端變複雜了,用戶數增加了,併發量增加了。對我們服務端要求增加了

  • 服務能力:一臺服務器滿足不了這麼多的http的請求了。我們需要增加機器了,進行服務擴容了
  • 安全防護:開始有人對我們的服務進行網絡攻擊了,需要保護服務端服務器,限制ip地址
  • 網站升級: 網站上線後,需要提供7*24小時無間斷服務了,發佈新的版本,需要保證網站的可用。

代理服務

爲了解決這些問題,我們需要引入中間層也就是代理,在客戶端和服務端中間插入一箇中間環節,代理服務。代理,狹義上講就是不生產內容,只是轉發上下游的請求和響應。

代理服務按照是否匿名可以分爲

  • 匿名代理: 外部不知道真實機器,只知道代理服務器
  • 透明代理: 外界知道代理,也知道真實服務器

按照靠近客戶端還是服務端,分爲

  • 正向代理: 代理客戶端,代表着客戶端向服務器端發送請求
  • 反向代理: 代理服務端,代表着服務器向客戶端發送請求。

http協議對代理的支持

因爲http協議最開始並沒有考慮代理服務,設計的協議只是針對客戶端-服務器模式。根據我們通常的架構標準,http協議層是不用關心使用者是如何使用的,代理服務這種中間產物自然不用考慮。服務端有獲取客戶端ip的需求,所以Squid這個緩存代理軟件最先引入X-Forwarded-For頭字段,用來表示 客戶端的真實 IP。

格式如下,從客戶端到各個代理服務,記錄下每一層的轉發

X-Forwarded-For: client, proxy1, proxy2

這個需求是如此的普世,所以慢慢變成了標準,被各個代理服務廣泛使用,所以後來被寫入到RFC 7239標準之中了

代理協議

HTTP 協議本身對代理服務並沒有什麼說明,所以就衍生出了代理協議,代理協議是haproxy的作者Willy Tarreau於2010年開發和設計的一個Internet協議,通過爲tcp添加一個很小的頭信息,來方便的傳遞客戶端信息(協議棧、源IP、目的IP、源端口、目的端口等),在網絡情況複雜又需要獲取客戶IP時非常有用。

  • 多層NAT網絡
  • TCP代理(四層)或多層tcp代理
  • https反向代理http(某些情況下由於Keep-alive導致不是每次請求都傳遞x-forword-for)
  • https通信加密,不允許修改原始報文

另外由於每一層代理服務都需要解析http header 頭X-Forwarded-For,然後追加自己的地址,所以這個成本也比較高。所以代理協議也變成了剛需,雖然是haproxy提出來的,但是也被各大代理服務器支持了,如nginx、apache、squid。代理協議格式

PROXY TCP4/TCP6 客戶端ip 應答方ip 請求方端口號  應答方端口號 \r\n

這樣請求方解析第一行就可以拿到客戶端ip,不用再去處理http報文了。

負載均衡

負載均衡,其實就是分發請求。根據OSI七層協議

負載均衡分成兩種

  • 4層負載均衡,即工作在第四層傳輸層,利用ip地址端口進行請求轉發,因爲沒有其他操作,所以效率比較高
  • 七層負載均衡,即工作在第七層應用層,根據HTTP請求頭,URL信息轉發特定的主機。效率相對低一點。

nginx是七層負載均衡,LVS是四層負載均衡。

所以小型網站,nginx就足夠,當流量足夠大時,負載均衡成爲瓶頸了,就可以在前面引入了LVS一層。

關於具體的負載均衡算法,參考這邊文章,這裏不再贅述

安全防護

前面我們提到過安全防護也是代理服務的一大重要功能。爲了應對外部攻擊,需要引入網絡防火牆,WAF(Web Application Firewall)。工作在OSI 第七層,主要是對http報文進行更細緻的審覈,也就是各種filter。
比如

  • IP 黑白名單
  • DDOS攻擊
  • 各種注入

當服務的安全性要求沒那麼高時,或者對公司業務發展的ROI沒那麼高時,我們通常就在nginx層面配置一些規則即可。需求升級時,我們就要引入專門的模型,比如ModSecurity1。需求再升級時,引入外部雲廠商提供的WAF服務。

最終架構形式

http服務端架構演進和我們單應用架構演進有異曲同工之處。在業務不復雜的時候,可以使用單體模塊搞定(比如Nginx),當請求量增加,需求升級時,需要引入中間層來解決。當某個模塊要求增加時,需要解耦出單獨的模塊來處理。

所以整體上看,一箇中型的服務端架構如下圖。

參考

https://juejin.im/post/5ccaaf0af265da035e213490

https://www.cnblogs.com/xybaby/p/7867735.html

關注公衆號【方丈的寺院】,第一時間收到文章的更新,與方丈一起開始技術修行之路

在這裏插入圖片描述

相關閱讀
詳解http報文

詳解http報文(2)-web容器是如何解析http報文的

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章