演進(jìn)：Tengine從web代理服務(wù)器到分布式推送服務(wù)器

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

服務(wù)器

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

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

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

Tengine

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

[[317809]]

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

當(dāng)前HTTP長連接業(yè)務(wù)現(xiàn)狀

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

Tengine 負(fù)責(zé)和客戶端進(jìn)行長連接的保活、和應(yīng)用服務(wù)器使用具體負(fù)載均衡算法進(jìn)行短連接調(diào)度。

當(dāng)前HTTP的推送解決方案

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

輪詢

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

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

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

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

應(yīng)用服務(wù)處理

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

 

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

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 單機(jī)推送

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

推送流程

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

 

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

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

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

缺點

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

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

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

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

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

 

Tengine實現(xiàn)方案

一、Tengine 自帶 中心 化存儲

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

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

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

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

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

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

二、支持流式傳輸

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

三、多協(xié)議支持

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

四、高性能

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

 

網(wǎng)站欄目：演進(jìn)：Tengine從Web代理服務(wù)器到分布式推送服務(wù)器
當(dāng)前網(wǎng)址：http://m.fisionsoft.com.cn/article/ccdhsdi.html