本發(fā)明涉及一種代理應用以及系統(tǒng)，尤其涉及一種用于具有服務容器的主機系統(tǒng)的代理應用以及系統(tǒng)。

背景技術：

傳統(tǒng)保險行業(yè)中，軟件系統(tǒng)需要處理的業(yè)務量并不大，一個服務即使只部署一個節(jié)點也可以支撐大部分業(yè)務量；而對于產(chǎn)品形態(tài)碎片化、高頻化的互聯(lián)網(wǎng)保險場景，系統(tǒng)必須為分布式、集群化的部署，才能支撐每天數(shù)百上千萬的業(yè)務量。也就是說，每一個業(yè)務系統(tǒng)組件，都會部署多份，當每個服務實例啟動時，都會將當前服務實例所在的IP地址和端口號注冊到一個服務注冊中心(一種具備服務注冊功能的應用)。以此，當其他組件需要調用該服務時，需要調用服務對應的負載均衡器，而負載均衡器會從服務注冊中心獲取該服務實例的地址列表，從中選取一個進行真正的調用。

目前，由于Docker容器的出現(xiàn)(本發(fā)明中容器是指服務器中位于組件和平臺之間的接口集合，其為應用程序提供隔離的運行空間。Docker是一個開源的應用容器引擎，讓開發(fā)者可以打包他們的應用以及依賴包到一個可移植的容器中，然后發(fā)布到任何流行的Linux機器上，也可以實現(xiàn)虛擬化)，容器級虛擬化部署方案異?；馃?，被許多互聯(lián)網(wǎng)公司選用來替換原來基于物理機或虛擬機的部署方案。

但容器化部署與傳統(tǒng)的部署方案不同之處在于：傳統(tǒng)的部署方案中無論是物理機還是虛擬機，都具備一個固定的IP地址；而容器化部署方案中，容器可能會被隨機調度到主機集群中任意一臺機子上，其IP地址無法固化、且對外提供服務的端口地址也無法固化。因此，如果直接將傳統(tǒng)服務注冊、發(fā)現(xiàn)方案運用到容器化部署的系統(tǒng)中時，會遇到如下問題：

(1)傳統(tǒng)方案中，應用系統(tǒng)會固定一個對外提供服務的端口號，如8080，那么當系統(tǒng)啟動時，可以將應用系統(tǒng)所在主機的IP地址加上這個固定的端口號注冊到服務注冊中心中；而容器化部署時，由于其IP地址無法固化、且對外提供服務的端口地址也無法固化，因此不能以傳統(tǒng)方式注冊。

(2)傳統(tǒng)方案中，前端負載均衡器中會硬編碼后端服務的地址列表，或需要通過重啟負載均衡器來更新服務地址列表；而容器會隨時進行擴容、縮容、遷移等操作，即傳統(tǒng)方案中的負載均衡器無法動態(tài)獲取、更新后端服務的最新地址列表。

技術實現(xiàn)要素：

本發(fā)明的目的之一是提供一種用于具有服務容器的主機系統(tǒng)的代理應用，該代理應用可將所述服務容器對應的信息注冊到服務注冊中心。

根據(jù)上述目的，本發(fā)明提出了一種用于具有服務容器的主機系統(tǒng)的代理應用，其中：

所述代理應用設置于主機系統(tǒng)內(nèi)，所述代理應用對主機系統(tǒng)內(nèi)的服務容器進行監(jiān)聽，當發(fā)現(xiàn)服務容器的啟動接口或重啟接口被調用時，代理應用便將服務容器對應的服務信息和地址信息注冊到服務注冊中心；當監(jiān)聽到服務容器的停止接口被調用時，代理應用則從服務注冊中心刪除服務容器對應的服務信息和地址信息。

本發(fā)明所述的代理應用通過對服務容器進行監(jiān)聽，當發(fā)現(xiàn)服務容器的啟動接口或重啟接口被調用時，代理應用便將服務容器對應的服務信息和地址信息注冊到服務注冊中心；當監(jiān)聽到服務容器的停止接口被調用時，代理應用則從服務注冊中心刪除服務容器對應的服務信息和地址信息，從而將所述服務容器對應的信息注冊到服務注冊中心。該方案中，通過監(jiān)聽動態(tài)獲取地址信息(通常包括IP地址和端口地址)，從而解決了傳統(tǒng)注冊方案無法解決的容器化部署時地址信息的提取問題。

本發(fā)明所述的代理應用可使用Go語言開發(fā)，并可用于對于本地(即當前主機系統(tǒng))服務容器的對應信息的注冊。

進一步地，本發(fā)明所述的代理應用中，采用開源服務consul作為所述服務注冊中心。

上述方案中，Consul是Go語言編寫的應用，具備服務注冊和分布式鍵值存儲功能。

進一步地，本發(fā)明所述的代理應用中，當發(fā)現(xiàn)服務容器的啟動接口或重啟接口被調用時，代理應用還將服務容器的服務、服務容器的HTTP接口調用地址以及服務容器的服務的負載權重的至少其中之一注冊到服務注冊中心。

上述方案中，負載權重表示分配多少請求流量到該服務容器。

進一步地，本發(fā)明所述及上述任一代理應用中，所述代理應用定時對已注冊到服務注冊中心的服務容器進行健康檢查，并接收反饋的響應；當接收的響應為服務容器的服務處于亞健康狀態(tài)時，代理應用在服務注冊中心修改服務容器的服務的負載權重；當接收的響應為服務容器的服務處于不健康狀態(tài)時，代理應用從服務注冊中心刪除該條服務信息和地址信息。

上述方案中，健康狀態(tài)是指服務對外提供其所應達到的功能的能力水平，包括該服務所在容器的健康狀態(tài)(如CPU用量、內(nèi)存容量、磁盤用量)，服務自身的健康狀態(tài)(如堆、棧內(nèi)存使用情況，垃圾回收狀態(tài))等等。

本發(fā)明的另一目的是提供一種用于具有服務容器的主機系統(tǒng)的系統(tǒng)，該系統(tǒng)可實現(xiàn)對所述服務容器對應的信息的注冊。

基于上述發(fā)明目的，本發(fā)明還提供了一種用于具有服務容器的主機系統(tǒng)的系統(tǒng)，其包括：

服務注冊中心；

如本發(fā)明或上述任意一項所述的代理應用，其與所述服務注冊中心數(shù)據(jù)連接。

本發(fā)明所述的系統(tǒng)由于包括所述代理應用，還包括與該代理應用數(shù)據(jù)連接的服務注冊中心，因此該系統(tǒng)可實現(xiàn)對所述服務容器對應的信息的注冊。

進一步地，本發(fā)明所述的系統(tǒng)還包括負載均衡器，其對服務注冊中心的注冊信息的變化進行監(jiān)聽，當服務注冊中心的注冊信息發(fā)生變化時，所述負載均衡器先動態(tài)更新其路由表，再接收新的請求。

上述方案中，負載均衡器可基于Go語言開發(fā)。由于更新路由表非?？焖?通常在50ms左右)，因此基本不可能對當前正在處理的請求或新到的請求造成任何影響，即路由表的更新對外部無影響、不可知。

更進一步地，上述系統(tǒng)中，所述注冊信息的變化包括：新的服務信息和地址信息被注冊，已有的服務信息和地址信息被刪除以及負載權重值被修改的至少其中之一。

更進一步地，上述系統(tǒng)中，所述負載均衡器通過Go語言并發(fā)模型中提供的執(zhí)行選擇器語法動態(tài)更新路由表。

更進一步地，上述系統(tǒng)中，所述負載均衡器采用prefix tree作為路由表的存儲結構。

上述方案中，負載均衡器使用prefix tree(前綴樹，數(shù)據(jù)結構Trie數(shù))作為路由表的存儲結構，加快了服務請求的路由匹配速度。

本發(fā)明所述的代理應用，其與傳統(tǒng)的服務注冊、服務發(fā)現(xiàn)以及負載均衡相比具有以下優(yōu)點：

(1)對應用系統(tǒng)無任何侵入：傳統(tǒng)方案中，要么采用無服務注冊中心，然后在負載均衡器中硬編碼寫死后端服務地址列表的方案，要么就在服務端系統(tǒng)中添加額外代碼，使得服務啟動時可以向服務注冊中心注冊當前服務信息。而本發(fā)明則通過代理應用監(jiān)聽服務容器執(zhí)行的命令，來動態(tài)注冊、反注冊以及調整權重，即不需要硬編碼，也無需對應用系統(tǒng)添加任何額外代碼。

(2)無中斷熱更新負載均衡器的路由表：利用Go語言的執(zhí)行選擇器的特性，一旦監(jiān)聽到服務注冊信息發(fā)生任何改動，可以在不影響當前處理請求和新到的處理請求的情況下完成路由表的更新，不需要重啟負載均衡器，也幾乎不會對請求造成任何影響。

(3)根據(jù)服務的健康檢查情況和系統(tǒng)資源消耗情況自動動態(tài)調整服務路由權重。

(4)代理應用根據(jù)啟動的服務容器信息自動捕獲系統(tǒng)對外的服務地址，毫秒級的更新速度，高度適用容器化部署場景。

(5)可應用于互聯(lián)網(wǎng)保險業(yè)務，可實現(xiàn)基于Docker容器的容器級虛擬化部署方案，提高應用開發(fā)效率和資源利用率。

本發(fā)明所述的系統(tǒng)，其同樣具有上述效果。

附圖說明

圖1為本發(fā)明所述的用于具有服務容器的主機系統(tǒng)的代理應用在一種實施方式下的流程圖。

圖2為本發(fā)明所述的用于具有服務容器的主機系統(tǒng)的系統(tǒng)在一種實施方式下的結構圖。

圖3為本發(fā)明所述的用于具有服務容器的主機系統(tǒng)的系統(tǒng)在另一種實施方式下的結構圖。

圖4為圖3所示系統(tǒng)在一種實施方式下的流程圖。

具體實施方式

下面將結合說明書附圖和具體的實施例來對本發(fā)明所述的用于具有服務容器的主機系統(tǒng)的代理應用以及系統(tǒng)進行進一步地詳細說明，但是該詳細說明不構成對本發(fā)明的限制。

以下實施方式中的用于具有服務容器的主機系統(tǒng)的代理應用以及系統(tǒng)(包括其內(nèi)部組件)可以為軟件模塊，其通過運行在相應的硬件設備上實現(xiàn)其功能。以下實施方式可用于互聯(lián)網(wǎng)保險業(yè)務場景，服務容器可以是Docker容器。

圖1顯示了本發(fā)明所述的用于具有服務容器的主機系統(tǒng)的代理應用在一種實施方式下的流程。如圖1所示，該代理應用設置于主機系統(tǒng)內(nèi)，該代理應用對主機系統(tǒng)內(nèi)的服務容器進行監(jiān)聽，當發(fā)現(xiàn)服務容器的啟動接口或重啟接口被調用時，代理應用便將服務容器對應的服務信息和地址信息注冊到服務注冊中心；當監(jiān)聽到服務容器的停止接口被調用時，代理應用則從服務注冊中心刪除服務容器對應的服務信息和地址信息。

在某些實施方式下，采用開源服務consul作為服務注冊中心。

在某些實施方式下，當發(fā)現(xiàn)服務容器的啟動接口或重啟接口被調用時，代理應用還將服務容器的服務、服務容器的HTTP接口調用地址以及服務容器的服務的負載權重的至少其中之一注冊到服務注冊中心。

在某些實施方式下，代理應用定時對已注冊到服務注冊中心的服務容器進行健康檢查，并接收反饋的響應；當接收的響應為服務容器的服務處于亞健康狀態(tài)時，代理應用在服務注冊中心修改服務容器的服務的負載權重；當接收的響應為服務容器的服務處于不健康狀態(tài)時，代理應用從服務注冊中心刪除該條服務信息和地址信息。

圖2顯示了本發(fā)明所述的用于具有服務容器的主機系統(tǒng)的系統(tǒng)在一種實施方式下的結構。如圖2所示，該系統(tǒng)包括：服務注冊中心2；如本發(fā)明或上述任意一項代理應用1，其與服務注冊中心2數(shù)據(jù)連接。

圖3顯示了本發(fā)明所述的用于具有服務容器的主機系統(tǒng)的系統(tǒng)在另一種實施方式下的結構。如圖3所示，本發(fā)明的系統(tǒng)在圖2所示系統(tǒng)基礎上還包括負載均衡器3，其對服務注冊中心2的注冊信息的變化進行監(jiān)聽，當服務注冊中心2的注冊信息發(fā)生變化時，負載均衡器3先動態(tài)更新其路由表，再接收新的請求。

在某些實施方式下，上述系統(tǒng)中，注冊信息的變化包括：新的服務信息和地址信息被注冊，已有的服務信息和地址信息被刪除以及負載權重值被修改的至少其中之一。

在某些實施方式下，上述系統(tǒng)中，負載均衡器3通過Go語言并發(fā)模型中提供的執(zhí)行選擇器語法動態(tài)更新路由表。

在某些實施方式下，上述系統(tǒng)中，負載均衡器3采用prefix tree作為路由表的存儲結構。

圖4顯示了圖3所示系統(tǒng)在一種實施方式下的流程。如圖4所示，結合參考圖3，該流程包括：

步驟110：采用開源服務consul作為服務注冊中心2。代理應用1對主機系統(tǒng)內(nèi)的服務容器進行監(jiān)聽(例如監(jiān)聽主機上的Docker守護進程)。此外代理應用1還定時對已注冊到服務注冊中心的服務容器進行健康檢查，并接收反饋的響應。由于服務容器內(nèi)服務都是通過HTTP接口方式對外提供服務，因此代理應用1會每隔三秒對服務容器服務地址的“/health”服務進行健康檢查請求(即：如果服務容器的服務地址為10.253.100.100:31224，則健康檢查的訪問路徑為10.253.100.100:31224/health)。

步驟120：當代理應用1發(fā)現(xiàn)服務容器的啟動接口或重啟接口被調用時，轉到步驟130；當代理應用1監(jiān)聽到服務容器的停止接口被調用時，或者當代理應用1接收的響應為服務容器的服務處于不健康狀態(tài)時，轉到步驟140；當代理應用1接收的響應為服務容器的服務處于亞健康狀態(tài)時，轉到步驟150。其中，如果返回的響應的Http Response StatusCode為2開頭，則認為服務健康。當StatusCode為3開頭或主機CPU、內(nèi)存消耗超過70％的閾值時，則視為亞健康。如果StatusCode以4開頭，則視為不健康。

步驟130：代理應用1將服務容器對應的服務信息和地址信息注冊到服務注冊中心2。此外還將服務容器的服務地址、服務容器的服務、服務容器的HTTP接口調用地址以及服務容器的服務的負載權重注冊到服務注冊中心2。服務注冊中心2更新注冊信息。其中，負載權重表示分配多少請求流量到該服務容器，默認情況下設置為-1，表示與其他服務實例均攤所有流量。轉到步驟160。

步驟140：代理應用1從服務注冊中心2刪除(即反注冊)服務容器對應的服務信息和地址信息。此外還從服務注冊中心2刪除(即反注冊)服務容器的服務、服務容器的HTTP接口調用地址以及服務容器的服務的負載權重。服務注冊中心2更新注冊信息。轉到步驟160。

步驟150：代理應用1在服務注冊中心2修改服務容器的服務的負載權重。服務注冊中心2更新注冊信息。轉到步驟160。修改規(guī)則如下：如果當前的設置為-1，即均攤，則修改為均攤后的百分比的一半；如果當前的設置不為-1，則修改為當前值的一半。

步驟160：負載均衡器3對服務注冊中心2的注冊信息的變化進行監(jiān)聽，當服務注冊中心2的注冊信息發(fā)生變化時，負載均衡器3先動態(tài)更新其路由表(在負載權重變化時相應修改路由表權重值)，再接收新的請求。

上述方案可以在對服務或服務容器本身無任何侵入的情況下，使得服務信息和地址信息在服務容器啟動或停止時自動被注冊到服務注冊中心中，而服務前端的負載均衡器可以在很短時間(例如1s)內(nèi)完成服務發(fā)現(xiàn)并在不中斷當前正在處理的系統(tǒng)調用的情況下熱更新(即不重啟負載均衡器的情況下)后端服務地址列表。

需要注意的是，以上列舉的僅為本發(fā)明的具體實施例，顯然本發(fā)明不限于以上實施例，隨之有著許多的類似變化。本領域的技術人員如果從本發(fā)明公開的內(nèi)容直接導出或聯(lián)想到的所有變形，均應屬于本發(fā)明的保護范圍。