本發(fā)明涉及一種數(shù)據(jù)服務(wù)領(lǐng)域，更具體的，涉及一種分布式集群數(shù)據(jù)服務(wù)方法及系統(tǒng)。

背景技術(shù)：

隨著互聯(lián)網(wǎng)行業(yè)的迅猛發(fā)展，組織業(yè)務(wù)的不斷擴(kuò)張，需求不斷的增加以及用戶量的不斷增加，技術(shù)框架面臨著越來(lái)越多的挑戰(zhàn)。一方面，隨著業(yè)務(wù)的擴(kuò)大，如何為用戶提供可靠的服務(wù)，如何有效處理用戶增多后導(dǎo)致并發(fā)請(qǐng)求數(shù)增多，導(dǎo)致的響應(yīng)慢的問(wèn)題，以及如何有效解決用戶增多后帶來(lái)的大數(shù)據(jù)量的問(wèn)題等。另外一方面，公司或者組織業(yè)務(wù)的不斷擴(kuò)張，需求不斷的增加，越來(lái)越多的人加入開(kāi)發(fā)團(tuán)隊(duì)，代碼庫(kù)也在急劇膨脹。當(dāng)前的技術(shù)趨勢(shì)對(duì)服務(wù)的維護(hù)成本、靈活性，測(cè)試成本、構(gòu)建成本要求越來(lái)越高。

而傳統(tǒng)的單體架構(gòu)采用統(tǒng)一的技術(shù)體系和標(biāo)準(zhǔn)，在開(kāi)發(fā)時(shí)，按模塊劃分，各模塊之間相對(duì)獨(dú)立；在部署時(shí)，系統(tǒng)當(dāng)作一個(gè)整體部署。

傳統(tǒng)的單體架構(gòu)難以滿足當(dāng)前互聯(lián)網(wǎng)技術(shù)的要求。

1.兼容性差

采用統(tǒng)一的技術(shù)標(biāo)準(zhǔn)，對(duì)技術(shù)的兼容性和對(duì)平臺(tái)的多樣性有限制，難以能滿足現(xiàn)在多樣化的平臺(tái)。

2.不利于業(yè)務(wù)擴(kuò)展或者變更

模塊之間獨(dú)立開(kāi)發(fā)，但存在重疊代碼，當(dāng)業(yè)務(wù)變更或者需要擴(kuò)展時(shí)，只能基于整個(gè)系統(tǒng)進(jìn)行變更或擴(kuò)展，無(wú)法針對(duì)某一個(gè)功能模塊按需變更或擴(kuò)展。

3.維護(hù)成本高

單體架構(gòu)接口冗長(zhǎng)而復(fù)雜，系統(tǒng)多次變更后，架構(gòu)會(huì)膨脹而且難以理解。

4.容錯(cuò)性差

單體架構(gòu)將系統(tǒng)作為一個(gè)整體構(gòu)建、部署，當(dāng)其中一個(gè)模塊出現(xiàn)異常，只能整個(gè)系統(tǒng)重新更新、構(gòu)建、部署。

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

本發(fā)明旨在至少解決現(xiàn)有技術(shù)中存在的技術(shù)問(wèn)題之一。

為實(shí)現(xiàn)上述目的，本發(fā)明設(shè)計(jì)一種分布式集群數(shù)據(jù)服務(wù)方法，包括以下步驟：

步驟S1，反向代理服務(wù)器接收用戶端發(fā)送的web請(qǐng)求，并將所述web請(qǐng)求轉(zhuǎn)發(fā)至web服務(wù)器；

步驟S2，web服務(wù)器將接收的所述web請(qǐng)求轉(zhuǎn)發(fā)至一個(gè)或多個(gè)處理節(jié)點(diǎn)；

步驟S3，所述一個(gè)或多個(gè)處理節(jié)點(diǎn)訪問(wèn)數(shù)據(jù)庫(kù)服務(wù)器，獲取數(shù)據(jù)庫(kù)服務(wù)器返回的結(jié)果；

步驟S4，處理節(jié)點(diǎn)將所述結(jié)果轉(zhuǎn)發(fā)至web服務(wù)器，所述web服務(wù)器根據(jù)接收到的所述結(jié)果進(jìn)行合并處理，再將合并后的結(jié)果發(fā)送至反向代理服務(wù)器；

步驟S5，所述代理服務(wù)器將接收到的所述合并后的結(jié)果發(fā)送至用戶端。

具體的，所述用戶端通過(guò)瀏覽器發(fā)送web請(qǐng)求，并且在用戶端發(fā)送web請(qǐng)求后，DNS服務(wù)器進(jìn)行請(qǐng)求地址的解析，獲取目的IP地址，并將所述web請(qǐng)求發(fā)送至目的地址處。

具體的，所述反向服務(wù)器為Nginx服務(wù)器，所述web服務(wù)器為采用vertx的服務(wù)器，所述處理節(jié)點(diǎn)為采用vertx的節(jié)點(diǎn)。

優(yōu)選的，還存在監(jiān)控節(jié)點(diǎn)，其用于發(fā)送心跳報(bào)文至web服務(wù)器，用以確定web服務(wù)器的存活情況。

優(yōu)選的，所述監(jiān)控節(jié)點(diǎn)為采用hazelcast技術(shù)的節(jié)點(diǎn)。

具體的，當(dāng)所述監(jiān)控節(jié)點(diǎn)發(fā)現(xiàn)web服務(wù)器列表發(fā)生變化后，則通知所有已經(jīng)注冊(cè)的節(jié)點(diǎn)，更新最新的web服務(wù)器列表。

本發(fā)明另一方面還提供一種分布式集群數(shù)據(jù)服務(wù)系統(tǒng)，包括：

用戶端，用于發(fā)送web請(qǐng)求和接收結(jié)果；

反向代理服務(wù)器，用于接收用戶端發(fā)送的web請(qǐng)求，轉(zhuǎn)發(fā)至web服務(wù)器，和接收合并的結(jié)果信息轉(zhuǎn)發(fā)至用戶端；

Web服務(wù)器，用于接收反向代理服務(wù)器轉(zhuǎn)發(fā)的所述web請(qǐng)求，轉(zhuǎn)發(fā)至處理節(jié)點(diǎn)，和接收處理節(jié)點(diǎn)的結(jié)果，進(jìn)行合并處理，再轉(zhuǎn)發(fā)至反向代理服務(wù)器；

處理節(jié)點(diǎn)，用于接收web服務(wù)器轉(zhuǎn)發(fā)的web請(qǐng)求，轉(zhuǎn)發(fā)至數(shù)據(jù)庫(kù)服務(wù)器，和接收數(shù)據(jù)庫(kù)服務(wù)器返回的結(jié)果并轉(zhuǎn)發(fā)至web服務(wù)器；

數(shù)據(jù)庫(kù)服務(wù)器，用于接收處理節(jié)點(diǎn)發(fā)送的web請(qǐng)求，并返回結(jié)果至處理節(jié)點(diǎn)。

優(yōu)選的，還包括：

監(jiān)控節(jié)點(diǎn)，其用于發(fā)送心跳報(bào)文至web服務(wù)器，用以確定web服務(wù)器的存活情況。

具體的，所述反向服務(wù)器為Nginx服務(wù)器，所述web服務(wù)器為采用vertx的服務(wù)器，所述處理節(jié)點(diǎn)為采用vertx的節(jié)點(diǎn)。

具體的，所述監(jiān)控節(jié)點(diǎn)為采用hazelcast技術(shù)的節(jié)點(diǎn)。

分布式運(yùn)算的可彈性伸縮集群數(shù)據(jù)服務(wù)綜合應(yīng)用負(fù)載均衡和微服務(wù)技術(shù)，具有以下優(yōu)點(diǎn)：

一、分布式的服務(wù)集群，有效分配資源，保障了服務(wù)的有效性和能效性；

二、通過(guò)分解巨大單體式應(yīng)用為多個(gè)服務(wù)方法解決了復(fù)雜性問(wèn)題。在功能不變的情況下，應(yīng)用被分解為多個(gè)可管理的分支或服務(wù)。每個(gè)服務(wù)都有一個(gè)用RPC-或者消息驅(qū)動(dòng)API定義清楚的邊界。微服務(wù)架構(gòu)模式給采用單體式編碼方式很難實(shí)現(xiàn)的功能提供了模塊化的解決方案，由此，單個(gè)服務(wù)很容易開(kāi)發(fā)、理解和維護(hù)。

三、這種架構(gòu)使得每個(gè)服務(wù)都可以有專門(mén)開(kāi)發(fā)團(tuán)隊(duì)來(lái)開(kāi)發(fā)。開(kāi)發(fā)者可以自由選擇開(kāi)發(fā)技術(shù)，提供API服務(wù)。然后，這種自由意味著開(kāi)發(fā)者不需要被迫使用某項(xiàng)目開(kāi)始時(shí)采用的過(guò)時(shí)技術(shù)，他們可以選擇現(xiàn)在的技術(shù)。甚至于，因?yàn)榉?wù)都是相對(duì)簡(jiǎn)單，即使用現(xiàn)在技術(shù)重寫(xiě)以前代碼也不是很困難的事情。

四、微服務(wù)架構(gòu)模式是每個(gè)微服務(wù)獨(dú)立的部署。開(kāi)發(fā)者不再需要協(xié)調(diào)其它服務(wù)部署對(duì)本服務(wù)的影響。這種改變可以加快部署速度。UI團(tuán)隊(duì)可以采用AB測(cè)試，快速的部署變化。微服務(wù)架構(gòu)模式使得持續(xù)化部署成為可能。

最后，可彈性的伸縮的微服務(wù)架構(gòu)模式使得每個(gè)服務(wù)獨(dú)立擴(kuò)展。可以根據(jù)每個(gè)服務(wù)的規(guī)模來(lái)部署滿足需求的規(guī)模。

附圖說(shuō)明

圖1示出了本發(fā)明分布式可彈性架構(gòu)示意圖；

圖2示出了本發(fā)明一種分布式集群數(shù)據(jù)服務(wù)方法的流程圖；

圖3示出了本發(fā)明微服務(wù)集群的示意框圖；

圖4示出了本發(fā)明服務(wù)之間的通信流程圖；

圖5示出了本發(fā)明一實(shí)施例的服務(wù)運(yùn)行流程圖；

圖6示出了本發(fā)明一種分布式集群數(shù)據(jù)服務(wù)系統(tǒng)的結(jié)構(gòu)框圖。

具體實(shí)施方式

為了能夠更清楚地理解本發(fā)明的上述目的、特征和優(yōu)點(diǎn)，下面結(jié)合附圖和具體實(shí)施方式對(duì)本發(fā)明進(jìn)行進(jìn)一步的詳細(xì)描述。需要說(shuō)明的是，在不沖突的情況下，本申請(qǐng)的實(shí)施例及實(shí)施例中的特征可以相互組合。

在下面的描述中闡述了很多具體細(xì)節(jié)以便于充分理解本發(fā)明，但是，本發(fā)明還可以采用其他不同于在此描述的方式來(lái)實(shí)施，因此，本發(fā)明的保護(hù)范圍并不受下面公開(kāi)的具體實(shí)施例的限制。

基于上述的單塊架構(gòu)，項(xiàng)目需要一個(gè)新的架構(gòu)，來(lái)解決單塊架構(gòu)缺點(diǎn)，以滿足業(yè)務(wù)快速發(fā)展、數(shù)據(jù)快速增長(zhǎng)、用戶快速增加。新架構(gòu)，基于微服務(wù)，來(lái)實(shí)現(xiàn)分布式運(yùn)算的可彈性伸縮集群數(shù)據(jù)服務(wù)框架，需要滿足下面的需求：

a、解耦、復(fù)雜度可控：在將應(yīng)用分解的同時(shí)，規(guī)避了原本復(fù)雜度無(wú)止境的積累。每一個(gè)微服務(wù)專注于單一功能，并通過(guò)定義良好的接口清晰表述服務(wù)邊界，可由一個(gè)小規(guī)模開(kāi)發(fā)團(tuán)隊(duì)完全掌控，易于保持高可維護(hù)性和開(kāi)發(fā)效率。

b、快速、獨(dú)立部署：可以獨(dú)立部署。當(dāng)某個(gè)微服務(wù)發(fā)生變更時(shí)無(wú)需編譯、部署整個(gè)應(yīng)用。使得發(fā)布更加高效，同時(shí)降低對(duì)生產(chǎn)環(huán)境所造成的風(fēng)險(xiǎn)，最終縮短應(yīng)用交付周期。

c、技術(shù)選型靈活：每個(gè)團(tuán)隊(duì)可以根據(jù)自身服務(wù)的需求和行業(yè)發(fā)展的現(xiàn)狀，自由選擇最適合的技術(shù)棧。

d、容錯(cuò)：當(dāng)某一組建發(fā)生故障時(shí)，在單一進(jìn)程的傳統(tǒng)架構(gòu)下，故障很有可能在進(jìn)程內(nèi)擴(kuò)散，形成應(yīng)用全局性的不可用。故障被隔離在單個(gè)服務(wù)中。設(shè)計(jì)良好，其他服務(wù)可通過(guò)重試、平穩(wěn)退化等機(jī)制實(shí)現(xiàn)應(yīng)用層面的容錯(cuò)。

e、彈性伸縮擴(kuò)展：應(yīng)用根據(jù)實(shí)際生產(chǎn)情況，架構(gòu)需要體現(xiàn)靈活性，可以快速進(jìn)行伸縮性、擴(kuò)展性。

f、功能特定：?jiǎn)蝹€(gè)服務(wù)一般完成某個(gè)特定的功能，比如消息管理、客戶管理等等。每一個(gè)服務(wù)都有自己的業(yè)務(wù)邏輯和適配器。

本方案整合多種開(kāi)源技術(shù)（Nginx+Vert.x+hazelcast）來(lái)實(shí)現(xiàn)分布式運(yùn)算的可彈性伸縮集群數(shù)據(jù)服務(wù)。Vert.x是一個(gè)開(kāi)源的異步無(wú)阻塞的java框架。hazelcast是一個(gè)開(kāi)源的分布式框架。Nginx是一個(gè)輕量級(jí)的高性能HTTP和反向代理服務(wù)器。

圖1示出了本發(fā)明分布式可彈性架構(gòu)示意圖。

如圖1所示，系統(tǒng)框架中配置多個(gè)服務(wù)器構(gòu)成服務(wù)集群，實(shí)現(xiàn)負(fù)載均衡。用戶端發(fā)出請(qǐng)求，使用DNS負(fù)載均衡，每次域名解析會(huì)根據(jù)負(fù)載均衡算法計(jì)算出一個(gè)不同的IP地址返回，瀏覽器根據(jù)該ip地址，訪問(wèn)真實(shí)的物理主機(jī)。

在DNS后端，使用了Nginx，實(shí)現(xiàn)了反向代理負(fù)載均衡。Nginx接收到請(qǐng)求后，根據(jù)負(fù)載均衡算法計(jì)算出一臺(tái)真實(shí)的物理器的地址，并將請(qǐng)求轉(zhuǎn)發(fā)給真實(shí)服務(wù)器，真實(shí)服務(wù)器處理完后，將響應(yīng)返回給反向代理服務(wù)器，反向代理服務(wù)器再將該響應(yīng)返回給用戶。

微服務(wù)集群中，根據(jù)業(yè)務(wù)功能和職責(zé)的完整性構(gòu)建多個(gè)微服務(wù)，系統(tǒng)根據(jù)服務(wù)的注冊(cè)和發(fā)現(xiàn)機(jī)制，將請(qǐng)求發(fā)給微服務(wù)處理。

圖2示出了本發(fā)明一種分布式集群數(shù)據(jù)服務(wù)方法的流程圖。

如圖2所示，本發(fā)明的一種分布式集群數(shù)據(jù)服務(wù)方法包括：

步驟S1，反向代理服務(wù)器接收用戶端發(fā)送的web請(qǐng)求，并將所述web請(qǐng)求轉(zhuǎn)發(fā)至web服務(wù)器；

步驟S2，web服務(wù)器將接收的所述web請(qǐng)求轉(zhuǎn)發(fā)至一個(gè)或多個(gè)處理節(jié)點(diǎn)；

步驟S3，所述一個(gè)或多個(gè)處理節(jié)點(diǎn)訪問(wèn)數(shù)據(jù)庫(kù)服務(wù)器，獲取數(shù)據(jù)庫(kù)服務(wù)器返回的結(jié)果；

步驟S4，處理節(jié)點(diǎn)將所述結(jié)果轉(zhuǎn)發(fā)至web服務(wù)器，所述web服務(wù)器根據(jù)接收到的所述結(jié)果進(jìn)行合并處理，再將合并后的結(jié)果發(fā)送至反向代理服務(wù)器；

步驟S5，所述代理服務(wù)器將接收到的所述合并后的結(jié)果發(fā)送至用戶端。

具體的，所述用戶端通過(guò)瀏覽器發(fā)送web請(qǐng)求，并且在用戶端發(fā)送web請(qǐng)求后，DNS服務(wù)器進(jìn)行請(qǐng)求地址的解析，獲取目的IP地址，并將所述web請(qǐng)求發(fā)送至目的地址處。

具體的，所述反向服務(wù)器為Nginx服務(wù)器，所述web服務(wù)器為采用vertx的服務(wù)器，所述處理節(jié)點(diǎn)為采用vertx的節(jié)點(diǎn)。

優(yōu)選的，還存在監(jiān)控節(jié)點(diǎn)，其用于發(fā)送心跳報(bào)文至web服務(wù)器，用以確定web服務(wù)器的存活情況。

優(yōu)選的，所述監(jiān)控節(jié)點(diǎn)為采用hazelcast技術(shù)的節(jié)點(diǎn)。

具體的，當(dāng)所述監(jiān)控節(jié)點(diǎn)發(fā)現(xiàn)web服務(wù)器列表發(fā)生變化后，則通知所有已經(jīng)注冊(cè)的節(jié)點(diǎn)，更新最新的web服務(wù)器列表。

圖3示出了本發(fā)明微服務(wù)集群的示意框圖。

如圖3所示，其示出了微服務(wù)集群中的架構(gòu)。其中包括應(yīng)用層、服務(wù)層、數(shù)據(jù)層。并且每個(gè)層中還包括不同的微服務(wù)。

同時(shí)，本發(fā)明還基于微服務(wù)劃分的基本原則：

1)功能完整性、職責(zé)單一性。

2)粒度適中，團(tuán)隊(duì)可接受。

3)彈性伸縮。

4)獨(dú)立部署和生命周期管理。

微服務(wù)的劃分策略有兩種：

1) 縱向，根據(jù)應(yīng)用層、服務(wù)層、數(shù)據(jù)層的方向劃分；

2)橫向，在每一縱向中根據(jù)功能和職責(zé)不同，劃分為一個(gè)個(gè)“微業(yè)務(wù)”。

通過(guò)分解巨大單體式應(yīng)用為多個(gè)服務(wù)方法解決了復(fù)雜性問(wèn)題，為了降低微服務(wù)的耦合性，把系統(tǒng)中各業(yè)務(wù)關(guān)聯(lián)的功能盡量抽取出來(lái)，沉淀為公共組件或者公共服務(wù)，逐漸形成穩(wěn)定的核心服務(wù)，使每個(gè)微服務(wù)得以“獨(dú)善其身”，每一個(gè)微服務(wù)能夠獨(dú)立開(kāi)發(fā)、維護(hù)、部署。

圖4示出了本發(fā)明服務(wù)之間的通信流程圖。

如圖4所示，Event bus是Vert.x的神經(jīng)系統(tǒng)，微服務(wù)之間的通信主要通過(guò)Event bus+Hazelcast實(shí)現(xiàn)。

Vert.x支持分布式與多核利用。通過(guò)Hazelcast管理各個(gè)Vert.x節(jié)點(diǎn)的信息，然后通過(guò) EventBus在節(jié)點(diǎn)之間互相發(fā)消息，同時(shí)Vert.x還能支持應(yīng)用的高可用。Vert.x的執(zhí)行單元叫verticle，即程序的入口。verticle分兩種，一種是基于EventLoop的適合 I/O密集型的，還有一種是適合CPU密集型的worker verticle。而verticle之間相互通信只能通過(guò)Eventbus，可以支持point to point 的通信，也可以支持publish & subscribe通信方式。

所有業(yè)務(wù)邏輯其實(shí)都會(huì)跑在Netty里的EventLoop上，而EventLoop通過(guò)循環(huán)事件隊(duì)列來(lái)執(zhí)行所有的業(yè)務(wù)邏輯，這樣可以把一些I/O操作頻繁的事件及時(shí)從CPU上剝離開(kāi)來(lái)，最后通過(guò)注冊(cè)一個(gè)回調(diào)Handler來(lái)處理所有的事件回調(diào)。

Worker verticle主要是用來(lái)處理同步處理的。比如第三方框架沒(méi)有異步接口，最典型就是JDBC。所以可以通過(guò)worker verticle來(lái)退化到傳統(tǒng)的基于多線程模型的實(shí)現(xiàn)。這也是匹配一些原項(xiàng)目的手段。

Vert.x節(jié)點(diǎn)通過(guò)EventBus互相通信， EventBus通過(guò)HazelCast來(lái)獲取整個(gè)集群里的節(jié)點(diǎn)信息。每一個(gè)verticle其實(shí)都是一個(gè)線程，這樣可以充分利用多核。

圖5示出了本發(fā)明一實(shí)施例的服務(wù)運(yùn)行流程圖。

如圖5所示，用戶端發(fā)送web請(qǐng)求至Nginx服務(wù)器，然后轉(zhuǎn)發(fā)至web服務(wù)器，再轉(zhuǎn)發(fā)至處理節(jié)點(diǎn)。其中，web服務(wù)器和處理節(jié)點(diǎn)為一個(gè)或者多個(gè)，具體可根據(jù)實(shí)際的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)決定。處理節(jié)點(diǎn)訪問(wèn)數(shù)據(jù)庫(kù)服務(wù)器，獲取數(shù)據(jù)庫(kù)服務(wù)器的返回結(jié)果，再返回處理結(jié)果至web服務(wù)器處，web服務(wù)器將結(jié)果進(jìn)行合并處理，再發(fā)送至Nginx服務(wù)器，Nginx服務(wù)器再發(fā)送至用戶端處進(jìn)行顯示。其中，hazelcast節(jié)點(diǎn)實(shí)時(shí)對(duì)web服務(wù)器進(jìn)行監(jiān)控。hazelcast節(jié)點(diǎn)是監(jiān)控節(jié)點(diǎn)，通過(guò)心跳監(jiān)控在其注冊(cè)的服務(wù)器的存活情況。新的微服務(wù)節(jié)點(diǎn)一旦建立，可以往將監(jiān)控節(jié)點(diǎn)注冊(cè)服務(wù)。一旦hazelcast發(fā)現(xiàn)注冊(cè)的服務(wù)列表發(fā)生變動(dòng)，會(huì)往通知所有已注冊(cè)的節(jié)點(diǎn)，最新的存活節(jié)點(diǎn)列表。

處理節(jié)點(diǎn)主要功能是處理數(shù)據(jù)。每次新增一個(gè)處理節(jié)點(diǎn)，都會(huì)到監(jiān)控節(jié)點(diǎn)注冊(cè)為一個(gè)新的節(jié)點(diǎn)。處理節(jié)點(diǎn)可以隨著需要的增加而不斷增加，實(shí)現(xiàn)了業(yè)務(wù)的拓展性。

圖6示出了本發(fā)明一種分布式集群數(shù)據(jù)服務(wù)系統(tǒng)的結(jié)構(gòu)框圖。

如圖6所示，本發(fā)明還提供一種分布式集群數(shù)據(jù)服務(wù)系統(tǒng)，包括：

用戶端，用于發(fā)送web請(qǐng)求和接收結(jié)果；

反向代理服務(wù)器，用于接收用戶端發(fā)送的web請(qǐng)求，轉(zhuǎn)發(fā)至web服務(wù)器，和接收合并的結(jié)果信息轉(zhuǎn)發(fā)至用戶端；

Web服務(wù)器，用于接收反向代理服務(wù)器轉(zhuǎn)發(fā)的所述web請(qǐng)求，轉(zhuǎn)發(fā)至處理節(jié)點(diǎn)，和接收處理節(jié)點(diǎn)的結(jié)果，進(jìn)行合并處理，再轉(zhuǎn)發(fā)至反向代理服務(wù)器；

處理節(jié)點(diǎn)，用于接收web服務(wù)器轉(zhuǎn)發(fā)的web請(qǐng)求，轉(zhuǎn)發(fā)至數(shù)據(jù)庫(kù)服務(wù)器，和接收數(shù)據(jù)庫(kù)服務(wù)器返回的結(jié)果并轉(zhuǎn)發(fā)至web服務(wù)器；

數(shù)據(jù)庫(kù)服務(wù)器，用于接收處理節(jié)點(diǎn)發(fā)送的web請(qǐng)求，并返回結(jié)果至處理節(jié)點(diǎn)。

優(yōu)選的，還包括：

監(jiān)控節(jié)點(diǎn)，其用于發(fā)送心跳報(bào)文至web服務(wù)器，用以確定web服務(wù)器的存活情況。

具體的，所述反向服務(wù)器為Nginx服務(wù)器，所述web服務(wù)器為采用vertx的服務(wù)器，所述處理節(jié)點(diǎn)為采用vertx的節(jié)點(diǎn)。

具體的，所述監(jiān)控節(jié)點(diǎn)為采用hazelcast技術(shù)的節(jié)點(diǎn)。

一般web請(qǐng)求都是從瀏覽器發(fā)起，首先通過(guò)DNS解析獲取IP地址，然后通過(guò)http協(xié)議發(fā)送請(qǐng)求到對(duì)應(yīng)的IP。

在DNS解析過(guò)程中，DNS服務(wù)器可以進(jìn)行一次負(fù)載均衡實(shí)現(xiàn)請(qǐng)求的分發(fā)，此種操作可以減輕反向代理服務(wù)器的壓力，但是本方案中并不會(huì)涉及這方面的內(nèi)容，所以略過(guò)不說(shuō)。

反向代理服務(wù)器nginx轉(zhuǎn)發(fā)web請(qǐng)求。反向代理服務(wù)器本身無(wú)法處理任何請(qǐng)求，只是負(fù)責(zé)web請(qǐng)求的轉(zhuǎn)發(fā)。這里存在一個(gè)轉(zhuǎn)發(fā)規(guī)則的配置過(guò)程。因?yàn)閚ginx要實(shí)現(xiàn)web請(qǐng)求的轉(zhuǎn)發(fā)，需要知道微服務(wù)web節(jié)點(diǎn)的存在并且知道每個(gè)微服務(wù)web節(jié)點(diǎn)能夠處理的web請(qǐng)求。

微服務(wù)web節(jié)點(diǎn)主要功能是轉(zhuǎn)發(fā)請(qǐng)求到多個(gè)微服務(wù)處理節(jié)點(diǎn)，合并數(shù)據(jù)并返回。在此過(guò)程中hazelcast節(jié)點(diǎn)作為一個(gè)監(jiān)控節(jié)點(diǎn)會(huì)監(jiān)控所有微服務(wù)節(jié)點(diǎn)的存活情況，并且及時(shí)通知微服務(wù)的所有節(jié)點(diǎn)，這樣就能保證web節(jié)點(diǎn)可以知道其他節(jié)點(diǎn)的存活情況，保證數(shù)據(jù)不會(huì)轉(zhuǎn)發(fā)到死節(jié)點(diǎn)。通過(guò)知道現(xiàn)有的存活節(jié)點(diǎn)，web節(jié)點(diǎn)也會(huì)通過(guò)負(fù)載均衡算法給節(jié)點(diǎn)發(fā)送請(qǐng)求。

hazelcast節(jié)點(diǎn)是監(jiān)控節(jié)點(diǎn)，通過(guò)心跳監(jiān)控在其注冊(cè)的服務(wù)器的存活情況。新的微服務(wù)節(jié)點(diǎn)一旦建立，可以往將監(jiān)控節(jié)點(diǎn)注冊(cè)服務(wù)。一旦hazelcast發(fā)現(xiàn)注冊(cè)的服務(wù)列表發(fā)生變動(dòng)，會(huì)往通知所有已注冊(cè)的節(jié)點(diǎn)，最新的存活節(jié)點(diǎn)列表。

處理節(jié)點(diǎn)主要功能是處理數(shù)據(jù)。每次新增一個(gè)處理節(jié)點(diǎn)，都會(huì)到監(jiān)控節(jié)點(diǎn)注冊(cè)為一個(gè)新的節(jié)點(diǎn)。處理節(jié)點(diǎn)可以隨著需要的增加而不斷增加，實(shí)現(xiàn)了業(yè)務(wù)的拓展性。

數(shù)據(jù)庫(kù)服務(wù)器節(jié)點(diǎn)，存儲(chǔ)和處理數(shù)據(jù)。

本發(fā)明利用微服務(wù)架構(gòu)，基于JVM、輕量級(jí)、高性能的特性進(jìn)行開(kāi)發(fā)；對(duì)每個(gè)服務(wù)，提供了監(jiān)控接口、由監(jiān)控中心、通過(guò)對(duì)監(jiān)控接口進(jìn)行數(shù)據(jù)采集、實(shí)現(xiàn)服務(wù)監(jiān)控；集群節(jié)點(diǎn)去中心化，整個(gè)微服務(wù)集群沒(méi)有中心化節(jié)點(diǎn)，任何節(jié)點(diǎn)宕機(jī)均不會(huì)影響集群中其他節(jié)點(diǎn)對(duì)外提供服務(wù)。；容器化設(shè)計(jì)，使用反向依賴注入的設(shè)計(jì)模式可以將每個(gè)服務(wù)的按照業(yè)務(wù)需要的粒度進(jìn)行劃分。

應(yīng)理解，說(shuō)明書(shū)通篇中提到的“一個(gè)實(shí)施例”或“一實(shí)施例”意味著與實(shí)施例有關(guān)的特定特征、結(jié)構(gòu)或特性包括在本發(fā)明的至少一個(gè)實(shí)施例中。因此，在整個(gè)說(shuō)明書(shū)各處出現(xiàn)的“在一個(gè)實(shí)施例中”或“在一實(shí)施例中”未必一定指相同的實(shí)施例。此外，這些特定的特征、結(jié)構(gòu)或特性可以任意適合的方式結(jié)合在一個(gè)或多個(gè)實(shí)施例中。應(yīng)理解，在本發(fā)明的各種實(shí)施例中，上述各過(guò)程的序號(hào)的大小并不意味著執(zhí)行順序的先后，各過(guò)程的執(zhí)行順序應(yīng)以其功能和內(nèi)在邏輯確定，而不應(yīng)對(duì)本發(fā)明實(shí)施例的實(shí)施過(guò)程構(gòu)成任何限定。上述本發(fā)明實(shí)施例序號(hào)僅僅為了描述，不代表實(shí)施例的優(yōu)劣。

需要說(shuō)明的是，在本文中，術(shù)語(yǔ)“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過(guò)程、方法、物品或者裝置不僅包括那些要素，而且還包括沒(méi)有明確列出的其他要素，或者是還包括為這種過(guò)程、方法、物品或者裝置所固有的要素。在沒(méi)有更多限制的情況下，由語(yǔ)句“包括一個(gè)……”限定的要素，并不排除在包括該要素的過(guò)程、方法、物品或者裝置中還存在另外的相同要素。

在本申請(qǐng)所提供的幾個(gè)實(shí)施例中，應(yīng)該理解到，所揭露的設(shè)備和方法，可以通過(guò)其它的方式實(shí)現(xiàn)。以上所描述的設(shè)備實(shí)施例僅僅是示意性的，例如，所述單元的劃分，僅僅為一種邏輯功能劃分，實(shí)際實(shí)現(xiàn)時(shí)可以有另外的劃分方式，如：多個(gè)單元或組件可以結(jié)合，或可以集成到另一個(gè)系統(tǒng)，或一些特征可以忽略，或不執(zhí)行。另外，所顯示或討論的各組成部分相互之間的耦合、或直接耦合、或通信連接可以是通過(guò)一些接口，設(shè)備或單元的間接耦合或通信連接，可以是電性的、機(jī)械的或其它形式的。

上述作為分離部件說(shuō)明的單元可以是、或也可以不是物理上分開(kāi)的，作為單元顯示的部件可以是、或也可以不是物理單元；既可以位于一個(gè)地方，也可以分布到多個(gè)網(wǎng)絡(luò)單元上；可以根據(jù)實(shí)際的需要選擇其中的部分或全部單元來(lái)實(shí)現(xiàn)本實(shí)施例方案的目的。

另外，在本發(fā)明各實(shí)施例中的各功能單元可以全部集成在一個(gè)處理單元中，也可以是各單元分別單獨(dú)作為一個(gè)單元，也可以兩個(gè)或兩個(gè)以上單元集成在一個(gè)單元中；上述集成的單元既可以采用硬件的形式實(shí)現(xiàn)，也可以采用硬件加軟件功能單元的形式實(shí)現(xiàn)。

本領(lǐng)域普通技術(shù)人員可以理解：實(shí)現(xiàn)上述方法實(shí)施例的全部或部分步驟可以通過(guò)程序指令相關(guān)的硬件來(lái)完成，前述的程序可以存儲(chǔ)于計(jì)算機(jī)可讀取存儲(chǔ)介質(zhì)中，該程序在執(zhí)行時(shí)，執(zhí)行包括上述方法實(shí)施例的步驟；而前述的存儲(chǔ)介質(zhì)包括：移動(dòng)存儲(chǔ)設(shè)備、只讀存儲(chǔ)器（Read Only Memory，ROM）、磁碟或者光盤(pán)等各種可以存儲(chǔ)程序代碼的介質(zhì)。

或者，本發(fā)明上述集成的單元如果以軟件功能模塊的形式實(shí)現(xiàn)并作為獨(dú)立的產(chǎn)品銷售或使用時(shí)，也可以存儲(chǔ)在一個(gè)計(jì)算機(jī)可讀取存儲(chǔ)介質(zhì)中?；谶@樣的理解，本發(fā)明實(shí)施例的技術(shù)方案本質(zhì)上或者說(shuō)對(duì)現(xiàn)有技術(shù)做出貢獻(xiàn)的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來(lái)，該計(jì)算機(jī)軟件產(chǎn)品存儲(chǔ)在一個(gè)存儲(chǔ)介質(zhì)中，包括若干指令用以使得一臺(tái)計(jì)算機(jī)設(shè)備（可以是個(gè)人計(jì)算機(jī)、服務(wù)器、或者網(wǎng)絡(luò)設(shè)備等）執(zhí)行本發(fā)明各個(gè)實(shí)施例所述方法的全部或部分。而前述的存儲(chǔ)介質(zhì)包括：移動(dòng)存儲(chǔ)設(shè)備、ROM、磁碟或者光盤(pán)等各種可以存儲(chǔ)程序代碼的介質(zhì)。

以上所述，僅為本發(fā)明的具體實(shí)施方式，但本發(fā)明的保護(hù)范圍并不局限于此，任何熟悉本技術(shù)領(lǐng)域的技術(shù)人員在本發(fā)明揭露的技術(shù)范圍內(nèi)，可輕易想到變化或替換，都應(yīng)涵蓋在本發(fā)明的保護(hù)范圍之內(nèi)。因此，本發(fā)明的保護(hù)范圍應(yīng)以所述權(quán)利要求的保護(hù)范圍為準(zhǔn)。