本發(fā)明涉及計(jì)算機(jī)技術(shù)及軟件領(lǐng)域，尤其涉及一種彈性云分布式海量請求處理的方法、裝置及系統(tǒng)。

背景技術(shù)：

隨著互聯(lián)網(wǎng)技術(shù)的不斷發(fā)展，通過客戶端發(fā)起的請求數(shù)量呈現(xiàn)海量增長，這一現(xiàn)象在電子商務(wù)領(lǐng)域較為突出，尤其是商家進(jìn)行各種促銷活動的時候。因此，對海量請求的及時處理就顯得尤為重要。因?yàn)楹Ａ康木W(wǎng)絡(luò)請求就像血栓一樣，一旦遇到瓶頸，就會堵塞整個血管。

為了及時響應(yīng)海量的請求，通常情況下需要使用集群、負(fù)載均衡技術(shù)；為了了解請求的先后，須知道請求時間，一般通過一個請求隊(duì)列來處理用戶請求；此外，集群后的請求，須經(jīng)過同步處理，否則分散在各個服務(wù)器上的請求無法排序。

以電子商務(wù)為例，現(xiàn)有技術(shù)中處理海量請求的機(jī)制如圖1所示，位于最前端的兩臺主機(jī)，主要做負(fù)載均衡，將請求卸載到多個Web服務(wù)器集群的每臺主機(jī)上；ZooKeeper集群主要作用是同步數(shù)據(jù)，例如限額數(shù)據(jù)等。這些請求會通過一個先進(jìn)先出的消息隊(duì)列，交給數(shù)據(jù)庫處理，并返回結(jié)果。

通常衡量一個Web系統(tǒng)的吞吐率的指標(biāo)是QPS(Query Per Second，每秒處理請求數(shù))。假設(shè)處理一個業(yè)務(wù)請求的平均響應(yīng)時間為100ms，系統(tǒng)內(nèi)有20臺Web服務(wù)器，配置MaxClients為500個(表示Apache的最大連接數(shù)目)。那么，Web系統(tǒng)的理論峰值QPS為(理想化的計(jì)算方式)：20*500/0.1＝100000(10萬QPS)。系統(tǒng)似乎很強(qiáng)大，1秒鐘可以處理完10萬的請求，5w/s的秒殺似乎是“紙老虎”。

但實(shí)際情況，在高并發(fā)的場景下，服務(wù)器都處于高負(fù)載的狀態(tài)，此時平均響應(yīng)時間會大大增加。因此，假設(shè)在5w/s的高并發(fā)狀態(tài)下，平均響應(yīng)時間從100ms變?yōu)?50ms(實(shí)際甚至更多)：20*500/0.25＝40000(4萬QPS)，此時，系統(tǒng)剩下了4w的QPS，面對5w每秒的請求，相差了1w。

同理，若某一個秒內(nèi)，20*500個可用連接進(jìn)程都在滿負(fù)荷工作中，卻仍然有1萬個新來請求，由于沒有連接進(jìn)程可用，系統(tǒng)陷入到異常狀態(tài)也是預(yù)期之內(nèi)。

因此處理海量請求時，需要根據(jù)響應(yīng)時間、服務(wù)器的CPU負(fù)載率、處理能力等動態(tài)決定集群個數(shù)。但上述現(xiàn)有技術(shù)無法支持動態(tài)擴(kuò)容。一旦出現(xiàn)問題，服務(wù)器運(yùn)維人員需要及時增加服務(wù)器數(shù)量，重新啟動服務(wù)等，這將花費(fèi)較長時間，且過程的復(fù)雜性、不確定性將給請求處理帶來較大風(fēng)險；此外，現(xiàn)有方案中沒有考慮到對用戶請求時間處理的公平性，一般以請求達(dá)到服務(wù)器的時間為請求開始時間，這對請求的發(fā)起方而言并不公平。

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

有鑒于此，本發(fā)明提供一種彈性云分布式海量請求處理的方法、裝置及系統(tǒng)，能夠在服務(wù)器無法應(yīng)對峰值時，瞬時自動擴(kuò)容，且根據(jù)海量請求的發(fā)起時間進(jìn)行公平排序，按照時間先后予以處理。

為實(shí)現(xiàn)上述目的，根據(jù)本發(fā)明的一個方面，提供了一種彈性云分布式海量請求處理的方法。

本發(fā)明實(shí)施例的一種彈性云分布式海量請求處理的方法包括：步驟一：云計(jì)算管理平臺創(chuàng)建容器，將消息隊(duì)列集群、ZooKeeper集群、服務(wù)實(shí)例、數(shù)據(jù)存儲集群分別構(gòu)建在容器上；步驟二：客戶端將包含時間的請求發(fā)送至負(fù)載均衡服務(wù)器，所述負(fù)載均衡服務(wù)器將所述請求分發(fā)至消息隊(duì)列集群，經(jīng)ZooKeeper集群同步后，將所述請求按時間先后進(jìn)行重排；步驟三：服務(wù)實(shí)例從消息隊(duì)列集群中獲取請求并處理，然后將處理結(jié)果保存至數(shù)據(jù)存儲集群，并返回客戶端；在步驟一至步驟三的過程中，云計(jì)算管理平臺監(jiān)控服務(wù)實(shí)例所在容器的狀態(tài)，當(dāng)狀態(tài)指標(biāo)超過預(yù)設(shè)閾值時，通過復(fù)制容器創(chuàng)建新容器，以提高處理速度。

可選地，所述云計(jì)算管理平臺基于OpenStack、Machine、Swarn、Compose中的一種或多種實(shí)現(xiàn)，所述容器為基于Linux的Docker。

可選地，所述包含時間的請求是指包含發(fā)送時間的時間戳的請求。

可選地，所述負(fù)載均衡服務(wù)器還包括：DNS負(fù)載均衡服務(wù)器和Nginx負(fù)載均衡服務(wù)器，以實(shí)現(xiàn)兩層負(fù)載均衡。

可選地，當(dāng)狀態(tài)指標(biāo)超過預(yù)設(shè)閾值時，通過復(fù)制容器創(chuàng)建新容器還包括：當(dāng)服務(wù)實(shí)例所在容器的CPU負(fù)載率、內(nèi)存占用量以及請求響應(yīng)時間中的其中一個或多個超過對應(yīng)的預(yù)設(shè)閾值時，通過復(fù)制容器創(chuàng)建新容器。

可選地，所述方法還包括：服務(wù)實(shí)例處理請求的過程中，利用面向切面編程的技術(shù)，記錄處理的開始和結(jié)束時間，作為對請求響應(yīng)時間的統(tǒng)計(jì)。

為實(shí)現(xiàn)上述目的，根據(jù)本發(fā)明的另一方面，提供了一種彈性云分布式海量請求處理的裝置。

本發(fā)明的一種彈性云分布式海量請求處理的裝置包括云計(jì)算管理平臺、容器、客戶端、負(fù)載均衡服務(wù)器，其中：云計(jì)算管理平臺創(chuàng)建容器，將消息隊(duì)列集群、ZooKeeper集群、服務(wù)實(shí)例、數(shù)據(jù)存儲集群分別構(gòu)建在容器上；客戶端將包含時間的請求發(fā)送至負(fù)載均衡服務(wù)器，所述負(fù)載均衡服務(wù)器將所述請求分發(fā)至消息隊(duì)列集群，經(jīng)ZooKeeper集群同步后，將所述請求按時間先后進(jìn)行重排；服務(wù)實(shí)例從消息隊(duì)列集群中獲取請求并處理，然后將處理結(jié)果保存至數(shù)據(jù)存儲集群，并返回客戶端；所述云計(jì)算管理平臺還用于監(jiān)控服務(wù)實(shí)例所在容器的狀態(tài)，當(dāng)狀態(tài)指標(biāo)超過預(yù)設(shè)閾值時，通過復(fù)制容器創(chuàng)建新容器，以提高處理速度。

可選地，所述云計(jì)算管理平臺基于OpenStack、Machine、Swarn、Compose中的一種或多種實(shí)現(xiàn)，所述容器為基于Linux的Docker。

可選地，所述包含時間的請求是指包含發(fā)送時間的時間戳的請求。

可選地，所述負(fù)載均衡服務(wù)器還包括：DNS負(fù)載均衡服務(wù)器和Nginx負(fù)載均衡服務(wù)器，以實(shí)現(xiàn)兩層負(fù)載率均衡。

可選地，所述云計(jì)算管理平臺還用于：當(dāng)服務(wù)實(shí)例所在容器的CPU負(fù)載率、內(nèi)存占用量以及請求響應(yīng)時間中的其中一個或多個超過對應(yīng)的預(yù)設(shè)閾值時，通過復(fù)制容器創(chuàng)建新容器。

可選地，所述裝置還用于：服務(wù)實(shí)例處理請求的過程中，利用面向切面編程的技術(shù)，記錄處理的開始和結(jié)束時間，作為對請求響應(yīng)時間的統(tǒng)計(jì)。

為實(shí)現(xiàn)上述目的，根據(jù)本發(fā)明的再一方面，提供了一種彈性云分布式海量請求處理的系統(tǒng)。

本發(fā)明的一種彈性云分布式海量請求處理的系統(tǒng)包括：存儲器和處理器；其中，所述存儲器存儲指令；所述處理器被配置為根據(jù)所述指令執(zhí)行下列步驟：步驟一：云計(jì)算管理平臺創(chuàng)建容器，將消息隊(duì)列集群、ZooKeeper集群、服務(wù)實(shí)例、數(shù)據(jù)存儲集群分別構(gòu)建在容器上；步驟二：客戶端將包含時間的請求發(fā)送至負(fù)載均衡服務(wù)器，所述負(fù)載均衡服務(wù)器將所述請求分發(fā)至消息隊(duì)列集群，經(jīng)ZooKeeper集群同步后，將所述請求按時間先后進(jìn)行重排；步驟三：服務(wù)實(shí)例從消息隊(duì)列集群中獲取請求并處理，然后將處理結(jié)果保存至數(shù)據(jù)存儲集群，并返回客戶端；在步驟一至步驟三的過程中，云計(jì)算管理平臺監(jiān)控服務(wù)實(shí)例所在容器的狀態(tài)，當(dāng)狀態(tài)指標(biāo)超過預(yù)設(shè)閾值時，通過復(fù)制容器創(chuàng)建新容器，以提高處理速度。

根據(jù)本發(fā)明的技術(shù)方案，通過基于容器的虛擬化實(shí)例構(gòu)建各應(yīng)用集群，從而可以在較少成本的基礎(chǔ)上實(shí)現(xiàn)海量請求的處理；通過利用云計(jì)算管理平臺管理容器，從而可以實(shí)現(xiàn)容器的快速創(chuàng)建，使得在服務(wù)器無法應(yīng)對峰值時，瞬時自動擴(kuò)容，提高服務(wù)處理性能；通過發(fā)起請求時，在請求中嵌入網(wǎng)絡(luò)同步時間，且在將分布在集群上的請求，經(jīng)過同步后按時間先后進(jìn)行排序，從而可以實(shí)現(xiàn)根據(jù)請求發(fā)起時間決定請求處理的先后順序；通過利用兩層負(fù)載均衡技術(shù)進(jìn)行請求的分發(fā)，從而可以使請求快速高效的分發(fā)至各服務(wù)實(shí)例。

附圖說明

附圖用于更好地理解本發(fā)明，不構(gòu)成對本發(fā)明的不當(dāng)限定。其中：

圖1是現(xiàn)有技術(shù)的海量請求處理的方法的架構(gòu)的示意圖；

圖2是根據(jù)本發(fā)明實(shí)施例的彈性云分布式海量請求處理的方法的主要步驟的示意圖；

圖3是根據(jù)本發(fā)明實(shí)施例的彈性云分布式海量請求處理的方法的主要流程的示意圖；

圖4是根據(jù)本發(fā)明實(shí)施例的彈性云分布式海量請求處理的裝置的主要模塊的示意圖；

圖5是根據(jù)本發(fā)明實(shí)施例的彈性云分布式海量請求處理的系統(tǒng)的主要部分的示意圖。

具體實(shí)施方式

以下結(jié)合附圖對本發(fā)明的示范性實(shí)施例做出說明，其中包括本發(fā)明實(shí)施例的各種細(xì)節(jié)以助于理解，應(yīng)當(dāng)將它們認(rèn)為僅僅是示范性的。因此，本領(lǐng)域普通技術(shù)人員應(yīng)當(dāng)認(rèn)識到，可以對這里描述的實(shí)施例做出各種改變和修改，而不會背離本發(fā)明的范圍和精神。同樣，為了清楚和簡明，以下的描述中省略了對公知功能和結(jié)構(gòu)的描述。

本發(fā)明實(shí)施例的技術(shù)方案基于云計(jì)算管理平臺進(jìn)行容器的創(chuàng)建和管理。容器是構(gòu)建在操作系統(tǒng)上的虛擬化實(shí)例，其中，各容器有自己虛擬的IP，基于一宿主機(jī)操作系統(tǒng)可構(gòu)建多個容器。

在不同的容器集群上可以根據(jù)需求構(gòu)建相關(guān)應(yīng)用，本發(fā)明實(shí)施例中分別在容器上構(gòu)建消息隊(duì)列集群、分布式同步服務(wù)(例如可以但不限于是ZooKeeper)集群、服務(wù)實(shí)例以及數(shù)據(jù)存儲集群。然后將通過客戶端發(fā)起的海量請求利用負(fù)載均衡服務(wù)器發(fā)送至消息隊(duì)列集群上，經(jīng)過同步后，對海量請求按照時間先后進(jìn)行排序。構(gòu)建在容器中的服務(wù)實(shí)例獲取消息隊(duì)列中的請求進(jìn)行處理，并將處理后數(shù)據(jù)保存在構(gòu)建在數(shù)據(jù)存儲集群中。在海量請求處理的過程中，云計(jì)算管理平臺監(jiān)控各容器的狀態(tài)，當(dāng)容器的狀態(tài)指標(biāo)超過預(yù)設(shè)閾值后，通過復(fù)制容器構(gòu)建新容器。

圖2是根據(jù)本發(fā)明實(shí)施例的彈性云分布式海量請求處理的方法的主要步驟的示意圖。

如圖2所示，本發(fā)明實(shí)施例的彈性云分布式海量請求處理的方法的主要步驟如下：

步驟一：云計(jì)算管理平臺創(chuàng)建容器，將消息隊(duì)列集群、ZooKeeper集群、服務(wù)實(shí)例、數(shù)據(jù)存儲集群分別構(gòu)建在容器上；

步驟二：客戶端將包含時間的請求發(fā)送至負(fù)載均衡服務(wù)器，所述負(fù)載均衡服務(wù)器將所述請求分發(fā)至消息隊(duì)列集群，經(jīng)ZooKeeper集群同步后，將所述請求按時間先后進(jìn)行重排；

步驟三：服務(wù)實(shí)例從消息隊(duì)列集群中獲取請求并處理，然后將處理結(jié)果保存至數(shù)據(jù)存儲集群，并返回客戶端；

此外，在步驟一至步驟三的過程中，云計(jì)算管理平臺監(jiān)控服務(wù)實(shí)例所在容器的狀態(tài)，當(dāng)狀態(tài)指標(biāo)超過預(yù)設(shè)閾值時，通過復(fù)制容器創(chuàng)建新容器，以提高處理速度。

本發(fā)明實(shí)施例中的負(fù)載均衡服務(wù)器還可包括：DNS負(fù)載均衡服務(wù)器和Nginx負(fù)載均衡服務(wù)器，以實(shí)現(xiàn)兩層負(fù)載均衡。第一層是由DNS服務(wù)商可以提供。第二層主要通過Nginx做轉(zhuǎn)發(fā)。Nginx是高效率的負(fù)載均衡轉(zhuǎn)發(fā)器，它可以根據(jù)按照權(quán)重、輪詢等方式將網(wǎng)絡(luò)請求分發(fā)給各個服務(wù)的實(shí)例。每個實(shí)例服務(wù)跑在Docker虛擬機(jī)上，每個虛擬機(jī)不止是跑一個實(shí)例服務(wù)。

其中，云計(jì)算管理平臺可以基于OpenStack、Machine、Swarn、Compose中的一種或多種實(shí)現(xiàn)，本發(fā)明實(shí)施例中采用OpenStack進(jìn)行管理。OpenStack是一個開源軟件，它提供了一個部署云的平臺。為虛擬計(jì)算或存儲服務(wù)的公有/私有云，提供可擴(kuò)展的、靈活的云計(jì)算。OpenStack包含了一組開源項(xiàng)目，主要項(xiàng)目有Compute(Nova)，Object Storage(Swift)，Image Service(Glance)。Nova提供虛擬計(jì)算服務(wù)，Swift提供存儲服務(wù)，Glance提供虛擬機(jī)鏡像的注冊、分發(fā)服務(wù)。此外，本發(fā)明實(shí)施例中的容器為基于Linux的Docker。本發(fā)明實(shí)施例的容器并不局限與此，只要是能實(shí)現(xiàn)本發(fā)明中虛擬化云計(jì)算的其它容器均可用來在本發(fā)明實(shí)施例中進(jìn)行應(yīng)用的構(gòu)建和請求的處理。

本發(fā)明實(shí)施例中，Docker就是一個應(yīng)用程序執(zhí)行容器，類似虛擬機(jī)的概念。但是與虛擬化技術(shù)的不同之處在于下面幾點(diǎn)：

一、虛擬化技術(shù)依賴物理CPU和內(nèi)存，是硬件級別的；而Docker構(gòu)建在操作系統(tǒng)上，利用操作系統(tǒng)的容器化containerization技術(shù)，所以Docker甚至可以在虛擬機(jī)上運(yùn)行；

二、虛擬化系統(tǒng)一般都是指操作系統(tǒng)鏡像，比較復(fù)雜，稱為“系統(tǒng)”；而Docker開源而且輕量，稱為“容器”，單個容器適合部署少量應(yīng)用，比如部署一個Redis、一個Memcached；

三、傳統(tǒng)的虛擬化技術(shù)使用快照來保存狀態(tài)；而Docker在保存狀態(tài)上不僅更為輕便和低成本，而且引入了類似源代碼管理機(jī)制，將容器的快照歷史版本一一記錄，切換成本很低；

四、傳統(tǒng)的虛擬化技術(shù)在構(gòu)建系統(tǒng)的時候較為復(fù)雜，需要大量的人力；而Docker可以通過Dockfile來構(gòu)建整個容器，重啟和構(gòu)建速度很快。更重要的是Dockfile可以手動編寫，這樣應(yīng)用程序開發(fā)人員可以通過發(fā)布Dockfile來指導(dǎo)系統(tǒng)環(huán)境和依賴，這樣對于持續(xù)交付十分有利。Dockerfile可以基于已經(jīng)構(gòu)建好的容器鏡像，創(chuàng)建新容器。Dockerfile可以通過社區(qū)分享和下載，有利于該技術(shù)的推廣。

此外，Docker的還具有如下特性：

文件系統(tǒng)隔離：每個進(jìn)程容器運(yùn)行在完全獨(dú)立的根文件系統(tǒng)里。

資源隔離：可以使用Cgroup為每個進(jìn)程容器分配不同的系統(tǒng)資源，例如CPU和內(nèi)存。

網(wǎng)絡(luò)隔離：每個進(jìn)程容器運(yùn)行在自己的網(wǎng)絡(luò)命名空間里，擁有自己的虛擬接口和IP地址。

寫時復(fù)制：采用寫時復(fù)制方式創(chuàng)建根文件系統(tǒng)，這讓部署變得極其快捷，并且節(jié)省內(nèi)存和硬盤空間。

日志記錄：Docker將會收集和記錄每個進(jìn)程容器的標(biāo)準(zhǔn)流(stdout/stderr/stdin)，用于實(shí)時檢索或批量檢索。

變更管理：容器文件系統(tǒng)的變更可以提交到新的映像中，并可重復(fù)使用以創(chuàng)建更多的容器。無需使用模板或手動配置。

交互式shell：Docker可以分配一個虛擬終端并關(guān)聯(lián)到任何容器的標(biāo)準(zhǔn)輸入上，例如運(yùn)行一個一次性交互shell。

本發(fā)明實(shí)施例中的ZooKeeper及消息隊(duì)列集群，主要是多個Docker中構(gòu)建的ZooKeeper集群和RabbitMQ集群(消息隊(duì)列并不限于RabbitMQ，還可以是Redis)，來同步分布式Docker集群上各個服務(wù)數(shù)據(jù)。本發(fā)明實(shí)施例中的數(shù)據(jù)存儲集群主要用于將用戶操作數(shù)據(jù)存儲到相關(guān)的數(shù)據(jù)集群存儲服務(wù)器，主要是多個Docker集群中構(gòu)建的MySQL。

圖3是根據(jù)本發(fā)明實(shí)施例的彈性云分布式海量請求處理的方法的主要流程的示意圖。以下結(jié)合圖3對本發(fā)明實(shí)施例的彈性云分布式海量請求處理的方法的主要流程進(jìn)行詳細(xì)介紹。

如圖3所示，本發(fā)明實(shí)施例的彈性云分布式海量請求處理的方法的主要流程如下：

一、客戶端發(fā)送秒殺請求時，通過連接網(wǎng)絡(luò)同步時間服務(wù)器，例如NTP、GPS獲取網(wǎng)絡(luò)同步時間，在請求中帶入標(biāo)識發(fā)送時間的時間戳；

二、將海量秒殺請求發(fā)送至負(fù)載均衡服務(wù)器；

三、通過負(fù)載均衡服務(wù)器(包括DNS負(fù)載率均衡、Nginx負(fù)載率均衡兩層負(fù)載均衡)將海量請求分發(fā)到RabbitMQ集群的工作隊(duì)列中，也可以用Redis集群。其中，RabbitMQ是實(shí)現(xiàn)AMQP(高級消息隊(duì)列協(xié)議)的消息中間件的一種，最初起源于金融系統(tǒng)，用于在分布式系統(tǒng)中存儲轉(zhuǎn)發(fā)消息。Redis是高速的基于內(nèi)存的緩存系統(tǒng)。兩者都可以存儲請求的消息；

四、在Redis集群或者RabbitMQ消息隊(duì)列中的請求隊(duì)列信息，通過一個重排服務(wù)，根據(jù)時間先后進(jìn)行不斷重排，再重新存儲到RabbitMQ或者Redis集群中；(Redis可以通過ZooKeeper實(shí)現(xiàn)分布式緩存)

五、通過一個讀取線程，讀取在Redis或者RabbitMQ中的消息，并發(fā)送到多個Docker中的服務(wù)實(shí)例里；

六、對消息隊(duì)列中的請求進(jìn)行處理，通過面向切面編程(AOP)的方式，記錄下處理開始的時間和結(jié)束的時間，方便統(tǒng)計(jì)響應(yīng)時間；對請求完成處理后，訪問數(shù)據(jù)存儲集群，本發(fā)明實(shí)施例中為MySQL數(shù)據(jù)庫，更新請求處理結(jié)果后，將處理結(jié)果返回至客戶端；

七、上述過程中OpenStack對多個Docker集群進(jìn)行管理。通過監(jiān)控服務(wù)實(shí)例所在的Docker的CPU負(fù)載率、內(nèi)存占用量、請求響應(yīng)時間、硬盤負(fù)載率、網(wǎng)絡(luò)流量等指標(biāo)，如果CPU負(fù)載率、內(nèi)存或者響應(yīng)時間大于設(shè)定的相應(yīng)閾值，自動將服務(wù)實(shí)例所在的Docker，通過OpenStack的組件進(jìn)行復(fù)制并啟動；

八、當(dāng)服務(wù)實(shí)例增多，響應(yīng)變快，CPU負(fù)載率或內(nèi)存隨之降低。

根據(jù)本發(fā)明實(shí)施例的彈性云分布式海量請求處理的方法可以看出，通過基于容器的虛擬化實(shí)例構(gòu)建各應(yīng)用集群，從而可以在較少成本的基礎(chǔ)上實(shí)現(xiàn)海量請求的處理；通過利用云計(jì)算管理平臺管理容器，從而可以實(shí)現(xiàn)容器的快速創(chuàng)建，使得在服務(wù)器無法應(yīng)對峰值時，瞬時自動擴(kuò)容，提高服務(wù)處理性能；通過發(fā)起請求時，在請求中嵌入網(wǎng)絡(luò)同步時間，且在將分布在集群上的請求，經(jīng)過同步后按時間先后進(jìn)行排序，從而可以實(shí)現(xiàn)根據(jù)請求發(fā)起時間決定請求處理的先后順序；通過利用兩層負(fù)載均衡技術(shù)進(jìn)行請求的分發(fā)，從而可以使請求快速高效的分發(fā)至各服務(wù)實(shí)例。

圖4是根據(jù)本發(fā)明實(shí)施例的彈性云分布式海量請求處理的裝置的主要模塊的示意圖。

如圖4所示，本發(fā)明實(shí)施例的彈性云分布式海量請求處理的裝置40包括云計(jì)算管理平臺401、容器402、客戶端403、負(fù)載均衡服務(wù)器404，其中：

云計(jì)算管理平臺401創(chuàng)建容器402，將消息隊(duì)列集群、ZooKeeper集群、服務(wù)實(shí)例、數(shù)據(jù)存儲集群分別構(gòu)建在容器402上；客戶端403將包含時間的請求發(fā)送至負(fù)載均衡服務(wù)器404，所述負(fù)載均衡服務(wù)器404將所述請求分發(fā)至消息隊(duì)列集群，經(jīng)ZooKeeper集群同步后，將所述請求按時間先后進(jìn)行重排；服務(wù)實(shí)例從消息隊(duì)列集群中獲取請求并處理，然后將處理結(jié)果保存至數(shù)據(jù)存儲集群，并返回客戶端403；所述云計(jì)算管理平臺401還用于監(jiān)控服務(wù)實(shí)例所在容器402的狀態(tài)，當(dāng)狀態(tài)指標(biāo)超過預(yù)設(shè)閾值時，通過復(fù)制容器402創(chuàng)建新容器402，以提高處理速度。

其中，前述包含時間的請求是指包含發(fā)送時間的時間戳的請求。

本發(fā)明實(shí)施例中，云計(jì)算管理平臺401基于OpenStack、Machine、Swarn、Compose中的一種或多種實(shí)現(xiàn)，所述容器402為基于Linux的Docker。

負(fù)載均衡服務(wù)器404還可以包括：DNS負(fù)載均衡服務(wù)器404和Nginx負(fù)載均衡服務(wù)器404，以實(shí)現(xiàn)兩層負(fù)載均衡。

此外，云計(jì)算管理平臺401還可用于：當(dāng)服務(wù)實(shí)例所在容器402的CPU負(fù)載率、內(nèi)存占用量以及請求響應(yīng)時間中的其中一個或多個超過對應(yīng)的預(yù)設(shè)閾值時，通過復(fù)制容器402創(chuàng)建新容器402。其中，請求響應(yīng)時間可以采用但不限于下述方式獲?。悍?wù)實(shí)例處理請求的過程中，利用面向切面編程的技術(shù)，記錄處理的開始和結(jié)束時間，作為對請求響應(yīng)時間的統(tǒng)計(jì)。

圖5是根據(jù)本發(fā)明實(shí)施例的彈性云分布式海量請求處理的系統(tǒng)的主要部分的示意圖。

本發(fā)明實(shí)施例的一種彈性云分布式海量請求處理的系統(tǒng)50包括：存儲器501和處理器502；其中，存儲器501存儲指令；處理器502被配置為根據(jù)所述指令執(zhí)行下列步驟：步驟一：云計(jì)算管理平臺創(chuàng)建容器，將消息隊(duì)列集群、ZooKeeper集群、服務(wù)實(shí)例、數(shù)據(jù)存儲集群分別構(gòu)建在容器上；步驟二：客戶端將包含時間的請求發(fā)送至負(fù)載均衡服務(wù)器，所述負(fù)載均衡服務(wù)器將所述請求分發(fā)至消息隊(duì)列集群，經(jīng)ZooKeeper集群同步后，將所述請求按時間先后進(jìn)行重排；步驟三：服務(wù)實(shí)例從消息隊(duì)列集群中獲取請求并處理，然后將處理結(jié)果保存至數(shù)據(jù)存儲集群，并返回客戶端；在步驟一至步驟三的過程中，云計(jì)算管理平臺監(jiān)控服務(wù)實(shí)例所在容器的狀態(tài)，當(dāng)狀態(tài)指標(biāo)超過預(yù)設(shè)閾值時，通過復(fù)制容器創(chuàng)建新容器，以提高處理速度。

從以上描述可以看出，通過基于容器的虛擬化實(shí)例構(gòu)建各應(yīng)用集群，從而可以在較少成本的基礎(chǔ)上實(shí)現(xiàn)海量請求的處理；通過利用云計(jì)算管理平臺管理容器，從而可以實(shí)現(xiàn)容器的快速創(chuàng)建，使得在服務(wù)器無法應(yīng)對峰值時，瞬時自動擴(kuò)容，提高服務(wù)處理性能；通過發(fā)起請求時，在請求中嵌入網(wǎng)絡(luò)同步時間，且在將分布在集群上的請求，經(jīng)過同步后按時間先后進(jìn)行排序，從而可以實(shí)現(xiàn)根據(jù)請求發(fā)起時間決定請求處理的先后順序；通過利用兩層負(fù)載均衡技術(shù)進(jìn)行請求的分發(fā)，從而可以使請求快速高效的分發(fā)至各服務(wù)實(shí)例。

上述具體實(shí)施方式，并不構(gòu)成對本發(fā)明保護(hù)范圍的限制。本領(lǐng)域技術(shù)人員應(yīng)該明白的是，取決于設(shè)計(jì)要求和其他因素，可以發(fā)生各種各樣的修改、組合、子組合和替代。任何在本發(fā)明的精神和原則之內(nèi)所作的修改、等同替換和改進(jìn)等，均應(yīng)包含在本發(fā)明保護(hù)范圍之內(nèi)。