演進：Tengine從web代理服務器到分布式推送服務器

作者：上虛 2020-03-09 08:24:06

服務器

數(shù)據(jù)中心

分布式 Tengine 作為代理服務器，在集團有著廣泛的應用基礎，從 部署在 應用單機上的 Tengine ，到作為集群式部署的統(tǒng)一接入 Aserver ，可以說集團幾乎所有應用機器均運行著 Tengine 。當然， Tengine 的不同部署形態(tài)，其作用也不經(jīng)相同，這都得益于Tengine 作為優(yōu)秀的反向代理服務器，有著 高性能、低延遲、高可用 等特性。

成都創(chuàng)新互聯(lián)公司是一家專注于網(wǎng)站設計、網(wǎng)站建設與策劃設計,永順網(wǎng)站建設哪家好?成都創(chuàng)新互聯(lián)公司做網(wǎng)站,專注于網(wǎng)站建設十載,網(wǎng)設計領域的專業(yè)建站公司;建站業(yè)務涵蓋:永順等地區(qū)。永順做網(wǎng)站價格咨詢:13518219792

Tengine

Tengine 作為代理服務器，在集團有著廣泛的應用基礎，從 部署在 應用單機上的 Tengine ，到作為集群式部署的統(tǒng)一接入 Aserver ，可以說集團幾乎所有應用機器均運行著 Tengine 。當然， Tengine 的不同部署形態(tài)，其作用也不經(jīng)相同，這都得益于Tengine 作為優(yōu)秀的反向代理服務器，有著 高性能、低延遲、高可用 等特性。

[[317809]]

下圖是常見的統(tǒng)一接入模型：

當前HTTP長連接業(yè)務現(xiàn)狀

無論客戶端發(fā)起的請求是 HTTP2 還是 HTTP 1.1，Tengine 作為反向代理服務器，和應用服務器之間均是短連接(除非 Tengine 配置 keepalive )，如下圖所示：

Tengine 負責和客戶端進行長連接的?；?、和應用服務器使用具體負載均衡算法進行短連接調(diào)度。

當前HTTP的推送解決方案

通常推送的訴求，是需要定時的往端上發(fā)送數(shù)據(jù)，

輪詢

端上 定時發(fā)送請求來輪詢獲取業(yè)務數(shù)據(jù)。

這是最簡單且最容易想到的手段，但往往也是在實際項目中最不可能使用的方案。因為其缺點非常明顯：

1、較短間隔的輪詢請求會導致 Server 端無端的處理無用的 QPS ，且 QPS 與端的數(shù)量成線性正比

2、較長間隔的輪詢請求，其推送時效性無法保證

應用服務處理

即，Tengine 作為反向代理服務器只完成基本的轉(zhuǎn)發(fā)能力，業(yè)務 Hold 住 HTTP 的請求，并且在必要時，對其進行 response 。

 

缺點很明顯，應用需要自己維護該長連接的生命周期，而往往推送場景的使用者均是超大規(guī)模的終端設備，超大規(guī)模的長連接很明顯會消耗大量應用機器資源。

HTTP2 推送(Server Push)

實際上 HTTP2 的推送功能指的是單個 request 有多個 response ，與我們長連接通道持續(xù)傳輸數(shù)據(jù)的需求不匹配。

這里貼上 RFC 對 Server Push 功能的介紹，在這里就不再展開了。

  
 
 
 

   
  
  
  
HTTP/2 allows a server to pre-emptively send (or "push") responses 
   
  
  
  
   (along with corresponding "promised" requests) to a client in 
   
  
  
  
   association with a previous client-initiated request.  This can be 
   
  
  
  
   useful when the server knows the client will need to have those 
   
  
  
  
   responses available in order to fully process the response to the 
   
  
  
  
   original request. 
  
 
 
 

Tengine 單機推送

目前，主流開源 Nginx 模塊有支持單機推送功能 。

推送流程

實際上和 MQTT 的 SUB PUB 模式非常相似，只是用 HTTP 來實現(xiàn)而已，下面是具體流程如下：

 

1、A 發(fā)起請求，Tengine 劫持請求 Hold 住， Tengine 對其生產(chǎn)一個對應的 KeyA 。

2、B 若期望推送數(shù)據(jù)到 A ，可用 KeyA 作為參數(shù)(或者 Header )，發(fā)送 POST 數(shù)據(jù)到指定Tengine。

3、 Tengine 將收到的 B 的 POST 的數(shù)據(jù)，獲取到 KeyA 對應的連接，即可返回給 A 。

缺點

1、 B 需要感知 A 的存在 B

即當A的請求到達 Tengine 時， Tengine 需要旁路發(fā)送到 B ，即需要 告知 B ，A 的存在，并且 B 需要記錄 A 對應的 KeyA 。

解決方案：可以使用 Tengine 的 auth_request 功能，當然等價的也可以使用 Lua 的ngx.location.capture 方法。

2、Tengine 若是集群化部署，B 需要中心化存儲

B 通常是非單體應用，即由多個微服務組成，無論在哪個環(huán)節(jié)，當 B 需要推送消息到A時，顯然需要知道 A 在 Tengine 集群中的哪臺機器，故B應用中，至少某個微服務需要由中心化存儲(例如 redis、memcache )來決定將請求發(fā)送至哪臺 Tengine 。

 

Tengine實現(xiàn)方案

一、Tengine 自帶 中心 化存儲

Tengine 對 每個 TCP 連接生成一個 key(也可以使用請求 Header 等作為 Key )，在中心化存儲中保存 key 和對應機器ip的映射信息。應用只需要往Tengine集群的任意一臺機器推送數(shù)據(jù)，由 Tengine 來做分布式路由。下圖從推送角度描述了 Tengine 如何工作。

1、應用往 Tengine 集群隨機一臺機器推送，推送是攜帶對應的的 Key 以表示自己期望推送至哪個連接

2、Sc 收到 推送消息，在 Tair 中查找對應請求由哪臺 Tengine 機器維護，例如查找到該推送目的連接在 Sb 。

3、Sc 轉(zhuǎn)發(fā)到 Sb。

4、Sb 收到后，找到對應的客戶端連接，將數(shù)據(jù)推送至客戶端。

應用可以是用 vipserver 隨機查找 Tengine 機器， Tengine 也可以申請一個 vip/slb ，供業(yè)務訪問，依靠 vip/slb 的負載均衡能力，隨機訪問 Tengine 。

二、支持流式傳輸

通常，一個長連接希望能夠接受多個推送消息，而不是一個推送消息結(jié)束后再次新建， Tengine 依托其豐富的 HTTP 處理能力，使用 multipart/form-data ，是的推送數(shù)據(jù)擁有明確的 boundary ，多次推送數(shù)據(jù)都能有明確的分界線，客戶端只需單個連接，就能獲得多次推送數(shù)據(jù)。

三、多協(xié)議支持

Tengine 本身支持多種協(xié)議， 無論客戶端發(fā)起的是 HTTP 還是HTTP2，均能繼承上述推送功能。

四、高性能

Tengine 本身作為代理服務器，轉(zhuǎn)發(fā)性能是業(yè)界的標桿，我們在Tengine轉(zhuǎn)發(fā)流程加入了 中心化存儲能力使得 Tengine 有了分布式路由的功能。

 

網(wǎng)頁題目：演進：Tengine從Web代理服務器到分布式推送服務器
鏈接地址：http://m.5511xx.com/article/ccdhsdi.html