本發(fā)明實施例涉及云計算領(lǐng)域，尤其涉及一種云系統(tǒng)消息分發(fā)方法，裝置和系統(tǒng)。
背景技術(shù)：
：云環(huán)境中，系統(tǒng)設(shè)計的最基本原則之一是水平擴(kuò)展，即通過增加集群節(jié)點來提高系統(tǒng)處理能力，因此，負(fù)荷分擔(dān)集群、分布式集群在云系統(tǒng)中應(yīng)用越來越廣泛。在負(fù)荷分擔(dān)集群中，后端多臺服務(wù)器(Server)組成業(yè)務(wù)處理集群，任一服務(wù)器節(jié)點可單獨處理客戶端(Client)的消息，Client通過負(fù)載均衡器(Loadbalancer)訪問Server，Loadbalancer按照配置的負(fù)載均衡算法把Client的消息分發(fā)給Server。分布式集群與負(fù)荷分擔(dān)集群的主要區(qū)別是Client的消息一般由多臺Server協(xié)同處理。客戶端代理(ClientAgent)作為協(xié)調(diào)者，把Client消息劃分為多個子消息，再分發(fā)給多個Server處理，并把多個Server的處理結(jié)果合并后返回Client。ClientAgent可按負(fù)載均衡算法選舉合適的Server。在負(fù)載均衡算法中，負(fù)載評估只考慮Server負(fù)載，即假設(shè)所有消息的處理成本是相同的，無法保證消息處理成本差異較大場景下的負(fù)載均衡，且長期運行后，由于Server運行環(huán)境變化，導(dǎo)致該Server處理特定消息失敗時，負(fù)載均衡算法無法有效隔離，導(dǎo)致集群處理消息成功率下降。為了解決消息間處理成本差異較大場景下的故障快速隔離，現(xiàn)有技術(shù)在Server端增加反饋機(jī)制，Server接收到的Loadbalancer或ClientAgent發(fā)送的消息中攜帶deadline字段，deadline用于指示需要完成消息處理的時間，Server接收到消息后，先評估能否滿足deadline，如滿足，則繼續(xù)處理，否則直接回應(yīng)答通知Loadbalancer或ClientAgent不能滿足deadline需求，Loadbalancer或ClientAgent重新選擇其他Server處理。隨著消息處理復(fù)雜度增加，Server端很難準(zhǔn)確評估能否滿足deadline要求，漏判誤判風(fēng)險高，而且網(wǎng)絡(luò)交互和Server端評估會帶來較大的開銷。技術(shù)實現(xiàn)要素：有鑒于此，本發(fā)明實施例公開了一種云系統(tǒng)消息分發(fā)方法，裝置和系統(tǒng)。第一方面，本申請?zhí)峁┝艘环N云系統(tǒng)分發(fā)方法，云系統(tǒng)包括客戶端(Client)，分發(fā)裝置和多個服務(wù)器(Server)節(jié)點，該方法包括：分發(fā)裝置將M個消息發(fā)送給第一服務(wù)器處理，并根據(jù)第一服務(wù)器的處理情況確定該M個消息中服務(wù)質(zhì)量(QoS，QualityOfService)差的N個消息，分發(fā)裝置提取該N個消息的共同消息特征，并記錄該共同消息特征與第一服務(wù)器的對應(yīng)關(guān)系，該對應(yīng)關(guān)系用于指示第一服務(wù)器處理具有該共同消息特征的消息的QoS差。其中，M為大于1的正整數(shù)，N為不大于M的正整數(shù)。分發(fā)裝置通過實際統(tǒng)計，識別出服務(wù)器不適合處理的消息的共同消息特征，并記錄服務(wù)器與消息特征之間的對應(yīng)關(guān)系，后續(xù)在進(jìn)行消息分發(fā)時，可以主動的避開不適合的服務(wù)器，避免了某個Server由于軟件老化(如內(nèi)存碎片)無法處理特定消息(如消息大小超過特定值)，從而引起的處理失敗或處理時間長或某個Server由于運行環(huán)境變化觸發(fā)軟件錯誤，從而處理特定消息(讀損壞的文件)時進(jìn)程異常退出等情況，提高了系統(tǒng)處理性能和成功率。根據(jù)第一方面，在第一方面第一種可能的實現(xiàn)方式中，分發(fā)裝置根據(jù)消息處理時間確定QoS差的消息。分發(fā)裝置確定該M個消息中QoS差的N個消息可以為：分發(fā)裝置確定處理時間大于預(yù)設(shè)時間閾值的N個消息，并將該N個消息作為QoS差的消息。分發(fā)裝置將M個消息發(fā)送給第一服務(wù)器處理后，會監(jiān)控第一服務(wù)器處理該M個消息中每個消息的處理時間。如果第一服務(wù)器對一個消息的處理時間大于預(yù)設(shè)時間閾值，或在預(yù)設(shè)時間閾值到達(dá)時還沒有收到該消息的應(yīng)答消息，則分發(fā)裝置記錄該消息。根據(jù)第一方面，在第一方面第二種可能的實現(xiàn)方式中，分發(fā)裝置根據(jù)M個消息中的每個消息的響應(yīng)消息，確定服務(wù)質(zhì)量差的N個消息，其中，N個消息中的每個消息的響應(yīng)消息中攜帶特征碼，該特征碼用于指示第一服務(wù)器處理該消息的服務(wù)質(zhì)量差。進(jìn)一步的，響應(yīng)消息中還可以攜帶QoS類型，例如，可以使用0表示禁止，1表示響應(yīng)時延長，2表示資源不足，3表示處理失敗等。根據(jù)第一方面或第一方面以上任一種可能的實現(xiàn)方式，在第一方面第三種可能的實現(xiàn)方式中，分發(fā)裝置記錄共同消息特征與第一服務(wù)器的對應(yīng)關(guān)系之后，該方法還包括：分發(fā)裝置接收來自客戶端的待分發(fā)消息，待分發(fā)消息具有該共同消息特征，分發(fā)裝置根據(jù)記錄的對應(yīng)關(guān)系和該共同消息特征確定第一服務(wù)器，并在第一服務(wù)器外的其他服務(wù)器中選擇第二服務(wù)器，并將待分發(fā)消息分發(fā)給第二服務(wù)器處理。分發(fā)裝置可以直接將待分發(fā)消息發(fā)送給第二服務(wù)器處理，也可以將待分發(fā)消息拆分為多個子消息，然后將其中的一個子消息發(fā)送給第二服務(wù)器處理。通過分發(fā)裝置記錄的對應(yīng)關(guān)系，在為待訪問消息選擇目標(biāo)服務(wù)器時，可以避開不適合的服務(wù)器，從而保證了處理成功率和效率。根據(jù)第一方面第三種可能的實現(xiàn)方式，在第一方面第四種可能的實現(xiàn)方式中，分發(fā)裝置在第一服務(wù)器外的服務(wù)器中選擇第二服務(wù)器為：分發(fā)裝置根據(jù)預(yù)設(shè)分發(fā)算法為待分發(fā)消息選擇預(yù)分配服務(wù)器，如果預(yù)分配服務(wù)器為第一服務(wù)器，則分發(fā)裝置為待分發(fā)消息選擇第二服務(wù)器，第二服務(wù)器為第一服務(wù)器的從節(jié)點。分布式集群中，為保證可靠性，1個子消息一般至少有2個服務(wù)器可以處理，如果目標(biāo)服務(wù)器是QoS差的服務(wù)器，則可以選擇目標(biāo)服務(wù)器的從服務(wù)器處理待分發(fā)消息。如果目標(biāo)服務(wù)器沒有從服務(wù)器或者目標(biāo)服務(wù)器的從服務(wù)器也是QoS差的服務(wù)器，則可以將待分發(fā)消息發(fā)送給目標(biāo)服務(wù)器處理或者直接給客戶端發(fā)送處理失敗的指示消息。根據(jù)第一方面或第一方面以上任一種可能的實現(xiàn)方式，在第一方面第五種可能的實現(xiàn)方式中，分發(fā)裝置記錄共同消息特征與第一服務(wù)器的對應(yīng)關(guān)系之后，該方法還包括：分發(fā)裝置接收來自客戶端的待分發(fā)消息，待分發(fā)消息具有該共同消息特征，分發(fā)裝置根據(jù)記錄的對應(yīng)關(guān)系和該共同消息特征確定第一服務(wù)器，調(diào)低第一服務(wù)器的權(quán)重，并使用動態(tài)分配算法為待分發(fā)消息選擇服務(wù)器。如果預(yù)設(shè)算法為動態(tài)分發(fā)算法，為了降低選擇QoS差的服務(wù)器的概率，分發(fā)裝置調(diào)低QoS差的服務(wù)器的權(quán)重，然后使用動態(tài)分發(fā)算法選擇目標(biāo)服務(wù)器。更具體的，分發(fā)裝置可以將QoS差的服務(wù)器的權(quán)重調(diào)整為0，以避免選擇QoS差的服務(wù)器。第二方面，本申請?zhí)峁┝艘环N可讀介質(zhì)，包括執(zhí)行指令，當(dāng)計算設(shè)備的處理器執(zhí)行該執(zhí)行指令時，該計算設(shè)備執(zhí)行以上第一方面或以上第一方面的任一種可能的實現(xiàn)方式中的方法。第三方面，本申請?zhí)峁┝艘环N計算設(shè)備，包括：處理器、存儲器和總線；存儲器用于存儲執(zhí)行指令，處理器與存儲器通過總線連接，當(dāng)計算設(shè)備運行時，處理器執(zhí)行存儲器存儲的執(zhí)行指令，以使計算設(shè)備執(zhí)行以上第一方面或以上第一方面的任一種可能的實現(xiàn)方式中的方法。第四方面，本申請?zhí)峁┮环N云系統(tǒng)消息分發(fā)裝置，云系統(tǒng)包括客戶端，該分發(fā)裝置和多個服務(wù)器，該分發(fā)裝置包括：分發(fā)單元，用于將M個消息發(fā)送給第一服務(wù)器處理，其中，M為大于1的正整數(shù)；確定單元，用于根據(jù)第一服務(wù)器的處理情況確定該M個消息中服務(wù)質(zhì)量差的N個消息，其中，N為不大于M的正整數(shù)；記錄單元，用于提取該N個消息的共同消息特征，并記錄共同消息特征與第一服務(wù)器的對應(yīng)關(guān)系該對應(yīng)關(guān)系用于指示第一服務(wù)器處理具有該共同消息特征的消息的QoS差。根據(jù)第四方面，在第四方面第一種可能的實現(xiàn)方式中，確定單元用于根據(jù)消息處理時間確定QoS差的消息。確定單元用于確定處理時間大于預(yù)設(shè)時間閾值的N個消息，并將該N個消息作為QoS差的消息。根據(jù)第四方面，在第四方面第二種可能的實現(xiàn)方式中，確定單元用于根據(jù)M個消息中的每個消息的響應(yīng)消息確定M個消息中服務(wù)質(zhì)量差的N個消息，其中，N個消息中的每個消息的響應(yīng)消息中攜帶特征碼，該特征碼用于指示第一服務(wù)器處理該消息的服務(wù)質(zhì)量差。根據(jù)第四方面或第四方面以上任一種可能的實現(xiàn)方式，在第四方面第二種可能的實現(xiàn)方式中，該分發(fā)裝置還包括接收單元，用于接收來自客戶端的待分發(fā)消息，待分發(fā)消息具有共同消息特征，分發(fā)單元還用于根據(jù)記錄單元記錄的對應(yīng)關(guān)系和該共同消息特征確定第一服務(wù)器，并在第一服務(wù)器外的服務(wù)器中選擇第二服務(wù)器，并將待分發(fā)消息分發(fā)給第二服務(wù)器處理。根據(jù)第四方面第三種可能的實現(xiàn)方式，在第四方面第四種可能的實現(xiàn)方式中，分發(fā)單元用于根據(jù)預(yù)設(shè)分發(fā)算法為待分發(fā)消息選擇預(yù)分配服務(wù)器，如果預(yù)分配服務(wù)器為第一服務(wù)器，則為待分發(fā)消息選擇第二服務(wù)器，第二服務(wù)器為第一服務(wù)器的從節(jié)點。根據(jù)第四方面或第四方面以上任一種可能的實現(xiàn)方式，在第四方面第五種可能的實現(xiàn)方式中，該分發(fā)裝置還包括接收單元，用于接收來自客戶端的待分發(fā)消息，待分發(fā)消息具有共同消息特征，分發(fā)單元還用于根據(jù)記錄單元記錄的對應(yīng)關(guān)系該共同消息特征確定第一服務(wù)器，調(diào)低第一服務(wù)器的權(quán)重，并使用動態(tài)分配算法為待分發(fā)消息選擇服務(wù)器。第四方面為第一方面方法對應(yīng)的裝置實現(xiàn)方式，第一方面或第一方面任一種可能的實現(xiàn)方式中的描述對應(yīng)適用于第四方面或第四方面任一種可能的實現(xiàn)方式，在此不再贅述。第五方面，本申請?zhí)峁┝艘环N分發(fā)系統(tǒng)，該系統(tǒng)包括客戶端，第四方面或第四方面以上任一種可能的實現(xiàn)方式中的分發(fā)裝置和多個服務(wù)器，該分發(fā)裝置用于將客戶端的消息分發(fā)給多個服務(wù)器處理。第五方面為第一方面方法對應(yīng)的系統(tǒng)實現(xiàn)方式，第一方面或第一方面任一種可能的實現(xiàn)方式中的描述對應(yīng)適用于第五方面或第五方面任一種可能的實現(xiàn)方式，在此不再贅述。根據(jù)本申請公開的技術(shù)方案，分發(fā)裝置通過對已分發(fā)消息的服務(wù)質(zhì)量的監(jiān)控，識別出分發(fā)給某一服務(wù)器的消息中服務(wù)質(zhì)量差的消息，例如，在消息處理成本差異較大場景下，大規(guī)模集群長時間運行后，某個服務(wù)器由于軟件老化(如內(nèi)存碎片)無法處理特定消息(如消息大小超過特定值)，而導(dǎo)致處理失敗或處理時間長，或者某個服務(wù)器由于運行環(huán)境變化觸發(fā)軟件錯誤，而導(dǎo)致處理特定消息(讀損壞的文件)時進(jìn)程異常退出。分發(fā)裝置提取服務(wù)質(zhì)量差的消息的共同消息特征，將此類消息特征和服務(wù)器的映射關(guān)系加入黑名單，后續(xù)盡量不再分發(fā)此類消息給該服務(wù)器或保證不再分發(fā)此類消息給該服務(wù)器，從而提高了系統(tǒng)處理性能和成功率，避免了服務(wù)器的反復(fù)故障。附圖說明下面將對實施例描述中所需要使用的附圖作簡單地介紹。圖1為依據(jù)本發(fā)明一實施例的云系統(tǒng)的邏輯結(jié)構(gòu)示意圖；圖2為依據(jù)本發(fā)明一實施例的云系統(tǒng)的邏輯結(jié)構(gòu)示意圖；圖3為依據(jù)本發(fā)明一實施例的分發(fā)裝置的硬件結(jié)構(gòu)示意圖；圖4為依據(jù)本發(fā)明一實施例的分發(fā)方法的示范性流程圖；圖5為依據(jù)本發(fā)明一實施例的分發(fā)方法的示范性流程圖；圖6為依據(jù)本發(fā)明一實施例的分發(fā)裝置的邏輯結(jié)構(gòu)示意圖；圖7為依據(jù)本發(fā)明一實施例的分發(fā)裝置的邏輯結(jié)構(gòu)示意圖。具體實施方式下面結(jié)合附圖，對本發(fā)明的實施例進(jìn)行描述。在云環(huán)境下，某個服務(wù)器可能因為節(jié)點故障或性能老化等原因，不適合處理特定消息類型的消息，否則可能會因為單點的性能下降，影響系統(tǒng)整體性能。為了實現(xiàn)特定消息類型對特定服務(wù)器的有效隔離，本發(fā)明實施例中，分發(fā)裝置實際監(jiān)控分發(fā)給某一服務(wù)器的消息的服務(wù)質(zhì)量(QoS，QualityOfService)，并記錄QoS差的消息，例如，處理時間均超過了預(yù)設(shè)的閾值(在預(yù)設(shè)的時間閾值內(nèi)服務(wù)器沒有向分發(fā)裝置返回處理結(jié)果)，或消息的響應(yīng)消息中攜帶了指示QoS差的特征碼，則分發(fā)裝置會提取QoS的消息的共同消息特征，并在黑名單中記錄提取的共同消息特征與該服務(wù)器的對應(yīng)關(guān)系，后續(xù)數(shù)據(jù)分發(fā)裝置在接收到新的消息時，會根據(jù)消息特征，過濾掉在黑名單中與該消息特征對應(yīng)的服務(wù)器，并在剩余的服務(wù)器中為該消息選擇合適的處理器節(jié)點。從而提高了系統(tǒng)處理性能和成功率，避免了服務(wù)器的反復(fù)故障。本發(fā)明實施例通過監(jiān)控服務(wù)器對消息的實際處理情況，實現(xiàn)了特定消息特征對特定服務(wù)器的隔離。圖1為一種云系統(tǒng)100的邏輯結(jié)構(gòu)示意圖，云系統(tǒng)100包括多個客戶端102，分發(fā)裝置104和多個服務(wù)器節(jié)點110。分發(fā)裝置104用于從客戶端102接收請求消息，并將客戶端102的請求消息分發(fā)給服務(wù)器節(jié)點110處理。其中，分發(fā)裝置104維護(hù)有服務(wù)器列表106和黑名單108。服務(wù)器列表106用于記錄分發(fā)裝置104可選的服務(wù)器節(jié)點110。黑名單108用于記錄服務(wù)器節(jié)點110與消息特征之間的對應(yīng)關(guān)系，消息特征對應(yīng)的服務(wù)器節(jié)點110對具有該消息特征的消息處理能力差，即服務(wù)器節(jié)點110對具有該消息特征的消息的服務(wù)質(zhì)量差，分發(fā)裝置104接收到具有該消息特征的消息后，會避免或盡量避免將具有該消息特征的消息分發(fā)給該消息特征對應(yīng)的服務(wù)器節(jié)點110處理，從而保證消息的處理速度。在分布式集群中，分發(fā)裝置104可以采用分布式的解決方案，如圖2所示，系統(tǒng)100中可以包含多個分發(fā)裝置104，多個分發(fā)裝置104可以按照需求部署在系統(tǒng)的不同位置。每一個分發(fā)裝置104可以連接部分或全部客戶端102，并連接部分或者全部服務(wù)器節(jié)點110，本發(fā)明實施例對此并不進(jìn)行限定。在負(fù)載分擔(dān)集群中，后端多臺服務(wù)器節(jié)點110組成業(yè)務(wù)處理集群，任一服務(wù)器節(jié)點110可單獨處理客戶端102的消息，分發(fā)裝置104接收到客戶端102發(fā)送的一個消息后，根據(jù)服務(wù)器列表106和黑名單108從多個服務(wù)器中為該消息選擇一個合適的服務(wù)器節(jié)點110，并將該消息發(fā)送給選擇的服務(wù)器節(jié)點110處理。分發(fā)裝置104可以根據(jù)黑名單108排除不合適的服務(wù)器，并采用負(fù)載均衡算法為消息在合適的服務(wù)器節(jié)點110中選擇服務(wù)器節(jié)點110，該負(fù)載均衡算法包括但不限于：隨機(jī)、輪詢、加權(quán)輪詢、動態(tài)輪詢、最快算法、最少連接、觀察算法、預(yù)判算法等。其中，隨機(jī)算法把負(fù)載分配到各個可用的服務(wù)器上，通過隨機(jī)數(shù)生成算法選取一個服務(wù)器，然后把消息發(fā)送給它。輪詢算法按順序把每個新的消息分配給下一個服務(wù)器，最終把所有消息平分給所有的服務(wù)器。加權(quán)輪詢算法中，每個服務(wù)器接受的消息數(shù)量是按權(quán)重比例分配的，這是對普通輪詢算法的改進(jìn)，例如，可以設(shè)定第三臺機(jī)器的處理能力是第一臺機(jī)器的兩倍，那么負(fù)載均衡器會把兩倍的消息數(shù)量分配給第3臺機(jī)器。動態(tài)輪詢算法類似于加權(quán)輪詢，但權(quán)重值可以基于對各個服務(wù)器的監(jiān)控，不斷更新，可以基于服務(wù)器的實時性能分析分配消息，例如，根據(jù)每個服務(wù)器的當(dāng)前消息數(shù)或者響應(yīng)時間等分配消息。最快算法基于所有服務(wù)器中的最快響應(yīng)時間分配消息。最少連接算法把新消息給當(dāng)前連接數(shù)目最少的服務(wù)器。觀察算法結(jié)合最小連接算法和最快算法來實施負(fù)載均衡，服務(wù)器根據(jù)當(dāng)前的連接數(shù)和響應(yīng)時間得到一個性能評估，性能評估越高，代表性能越好，會得到更多的連接。預(yù)判算法使用觀察算法來進(jìn)行性能評估，但是預(yù)判算法會通過分析性能的變化趨勢來判斷某臺服務(wù)器的性能正在改善還是降低。具有改善趨勢的服務(wù)器會得到更多的連接。在分布式集群中，客戶端102的消息一般由多臺服務(wù)器節(jié)點110協(xié)同處理。分發(fā)裝置104作為協(xié)調(diào)者，接收到客戶端102發(fā)送的一個消息后，將消息分解為多個子消息，并根據(jù)服務(wù)器列表106和黑名單108為該多個子消息選擇多個服務(wù)器節(jié)點110，并將該多個子消息發(fā)送給選擇的多個服務(wù)器節(jié)點110處理，然后把多個服務(wù)器節(jié)點110的處理結(jié)果合并后返回給客戶端102。如圖2所示，在分布式集群中，分發(fā)裝置104采用分布式布局方式，每一個分發(fā)裝置104在接收到客戶端102的消息后，會將消息拆分成多個子消息，并根據(jù)服務(wù)器列表106和黑名單108將子消息分發(fā)給多個服務(wù)器。具體的，分發(fā)裝置104使用消息分發(fā)算法將子消息分發(fā)給多個服務(wù)器。其中，消息分發(fā)算法包括但不限于靜態(tài)路由算法、哈希(Hash)算法和一致性Hash算法。靜態(tài)路由中，分發(fā)裝置104根據(jù)配置的路由表，把子消息分發(fā)給指定的服務(wù)器節(jié)點110。Hash算法中，分發(fā)裝置104根據(jù)消息中特定字段的Hash值選擇服務(wù)器，如先計算子消息中鍵(Key)字段的Hash值，再用Hash值除以服務(wù)器總數(shù)，取余數(shù)作為選擇的服務(wù)器的編號。在一致性Hash算法中，每個節(jié)點都有隨機(jī)分配的編號(ID)。分發(fā)裝置104使用內(nèi)容的關(guān)鍵字和節(jié)點的ID進(jìn)行一致性哈希運算并獲得鍵值，一致性哈希要求鍵值和節(jié)點ID處于同一值域。分布式集群中，為保證可靠性，1個子消息至少有2個服務(wù)器108可以處理，分發(fā)裝置104選擇時，可結(jié)合黑名單108按上述負(fù)載均衡算法選舉。本領(lǐng)域的技術(shù)人員應(yīng)當(dāng)明白，根據(jù)具體需要，系統(tǒng)100還可包含實現(xiàn)其他附加功能的硬件器件。此外，本領(lǐng)域的技術(shù)人員應(yīng)當(dāng)明白，系統(tǒng)100也可僅僅包含實現(xiàn)本發(fā)明實施例所必須的器件，而不必包含圖1或圖2中所示的全部器件。圖3為依據(jù)本發(fā)明一實施例的分發(fā)裝置104的硬件結(jié)構(gòu)示意圖，如圖3所示，分發(fā)裝置104包括:包括處理器302、存儲器304、輸入/輸出接口306、通信接口308和總線310。其中，處理器302、存儲器304、輸入/輸出接口306和通信接口308通過總線310實現(xiàn)彼此之間的通信連接。處理器302是分發(fā)裝置104的控制中心，用于執(zhí)行相關(guān)程序，以實現(xiàn)本發(fā)明實施例所提供的技術(shù)方案。處理器302可以采用通用的中央處理器(CentralProcessingUnit，CPU)，微處理器，應(yīng)用專用集成電路(ApplicationSpecificIntegratedCircuit，ASIC)，或者一個或多個集成電路，用于執(zhí)行相關(guān)程序，以實現(xiàn)本發(fā)明實施例所提供的技術(shù)方案。存儲器304可以是只讀存儲器(ReadOnlyMemory，ROM)，靜態(tài)存儲設(shè)備，動態(tài)存儲設(shè)備或者隨機(jī)存取存儲器(RandomAccessMemory，RAM)。存儲器304可以存儲操作系統(tǒng)和其他應(yīng)用程序。在通過軟件或者固件來實現(xiàn)本發(fā)明實施例提供的技術(shù)方案時，用于實現(xiàn)本發(fā)明實施例提供的技術(shù)方案的程序代碼保存在存儲器304中，并由處理器302來執(zhí)行。存儲器304可以與處理器302集成在一起或集成在處理器302的內(nèi)部，也可以是獨立于處理器302的一個或多個存儲單元。供處理器302執(zhí)行的程序代碼可以存儲在與其連接的外部存儲設(shè)備中或存儲器304中?？蛇x的，存儲器304為RAM，存儲在外部存儲設(shè)備內(nèi)部的程序代碼(例如，通信模塊和分發(fā)控制模塊等)被拷貝到存儲器304中，以供處理器302執(zhí)行。如圖3所示，分發(fā)裝置104的存儲器304中包含通信模塊和分發(fā)控制模塊。處理器302執(zhí)行分發(fā)控制模塊代碼，實現(xiàn)對接收到的消息的分發(fā)。除非另有說明，在本發(fā)明中，一個用于執(zhí)行特定功能的組件，例如，處理器302或存儲器304，可以通過配置一個通用的組件來執(zhí)行相應(yīng)功能來實現(xiàn)，也可以通過一個專門執(zhí)行特定功能的專用組件來實現(xiàn)，本申請并不對此進(jìn)行限定。輸入/輸出接口306用于接收輸入的數(shù)據(jù)和信息，輸出操作結(jié)果等數(shù)據(jù)。通信接口308使用例如但不限于收發(fā)器一類的收發(fā)裝置，來實現(xiàn)分發(fā)裝置104與其他設(shè)備或通信網(wǎng)絡(luò)之間的通信?？偩€310可包括一通路，在分發(fā)裝置104各個部件(例如處理器302、存儲器304、輸入/輸出接口306和通信接口308)之間傳送信息。應(yīng)注意，盡管圖3所示的計分發(fā)裝置104僅僅示出了處理器302、存儲器304、輸入/輸出接口306、通信接口308以及總線310，但是在具體實現(xiàn)過程中，本領(lǐng)域的技術(shù)人員應(yīng)當(dāng)明白，分發(fā)裝置104還包含實現(xiàn)正常運行所必須的其他器件。同時，根據(jù)具體需要，本領(lǐng)域的技術(shù)人員應(yīng)當(dāng)明白，分發(fā)裝置104還可包含實現(xiàn)其他附加功能的硬件器件。此外，本領(lǐng)域的技術(shù)人員應(yīng)當(dāng)明白，分發(fā)裝置104也可僅僅包含實現(xiàn)本發(fā)明實施例所必須的器件，而不必包含圖3中所示的全部器件。圖3所示的硬件結(jié)構(gòu)以及上述描述適用于本發(fā)明實施例所提供的各種消息分發(fā)裝置，適用于執(zhí)行本發(fā)明實施例所提供的各種消息分發(fā)方法。圖4為依據(jù)本發(fā)明一實施例的一種云系統(tǒng)消息分發(fā)方法400的示意性流程圖，云系統(tǒng)包括客戶端，分發(fā)裝置和多個服務(wù)器，如圖4所示，方法400包括：S402：分發(fā)裝置將M個消息發(fā)送給第一服務(wù)器處理。其中，M為大于1的正整數(shù)。分發(fā)裝置在接收到客戶端的的請求消息后，根據(jù)分發(fā)算法將M個消息分發(fā)給第一服務(wù)器。分發(fā)裝置分發(fā)給第一服務(wù)器的消息可以是從客戶端接收到的請求消息或者該請求消息的子消息，本發(fā)明實施例對此并不進(jìn)行限定。例如，在分布式集群中，分發(fā)裝置一般將從客戶端接收到的請求消息拆分為多個子消息，并將每一個子消息分發(fā)給一個服務(wù)器處理，而在負(fù)荷分擔(dān)集群中，分發(fā)裝置一般將從客戶端接收到的請求消息直接分發(fā)給一個服務(wù)器處理。S404：分發(fā)裝置確定該M個消息中服務(wù)質(zhì)量(QoS，QualityOfService)差的N個消息。其中，N為大于0，不大于M的正整數(shù)。分發(fā)裝置可以根據(jù)該M個消息中的每個消息的響應(yīng)消息，確定服務(wù)質(zhì)量差的N個消息，其中，該N個消息中的每個消息的響應(yīng)消息中攜帶特征碼，該特征碼用于指示該消息的服務(wù)質(zhì)量差。進(jìn)一步的，響應(yīng)消息中還攜帶QoS類型，例如，可以使用0表示禁止，1表示響應(yīng)時延長，2表示資源不足，3表示處理失敗等。分發(fā)裝置還可以根據(jù)消息處理時間確定QoS差的消息。分發(fā)裝置確定該M個消息中QoS差的N個消息可以為：分發(fā)裝置確定處理時間大于預(yù)設(shè)時間閾值的N個消息，并將該N個消息作為QoS差的消息。分發(fā)裝置將M個消息發(fā)送給第一服務(wù)器處理后，會監(jiān)控第一服務(wù)器處理該M個消息中每個消息的處理時間。如果第一服務(wù)器對一個消息的處理時間大于預(yù)設(shè)時間閾值，則分發(fā)裝置記錄該消息。其中，每個消息可以分別有一個預(yù)設(shè)時間閾值，該M個消息或部分消息也可以有共同的預(yù)設(shè)時間閾值，本發(fā)明實施例對此并不進(jìn)行限定。如果分發(fā)裝置將一個消息發(fā)送給第一服務(wù)器后，在該消息對應(yīng)的預(yù)設(shè)時間閾值內(nèi)，沒有收到該消息的應(yīng)答消息，則說明該消息的處理時間大于預(yù)設(shè)時間閾值。第一服務(wù)器對一個消息的處理時間可以為分發(fā)裝置將該消息發(fā)送給第一服務(wù)器的時刻到分發(fā)裝置接收到該消息的應(yīng)答消息之間的時間。應(yīng)理解，第一服務(wù)器處理對一個消息的處理時間可以有多種統(tǒng)計形式，本發(fā)明實施例對此并不進(jìn)行限定。S406：分發(fā)裝置提取該N個消息的共同消息特征，并記錄該共同消息特征與第一服務(wù)器的對應(yīng)關(guān)系。該共同消息特征可以為文件名(FileName)、數(shù)據(jù)大小(DataSize)、鍵(DataKey，即Key-Value中的Key)、分區(qū)ID(PartitionID)、卷ID(VolumeID)、客戶標(biāo)識(ClientFlag)、消息ID(MsgID)、業(yè)務(wù)類型(ServiceType)、用戶標(biāo)識(UserID)、消息類型(ReqID)等中的一種或多種。應(yīng)理解，以上描述僅僅是舉例說明，本發(fā)明實施例并不對共同消息特征的具體實現(xiàn)進(jìn)行限定。分發(fā)裝置可以將該共同消息特征與第一服務(wù)器的對應(yīng)關(guān)系記錄在一個黑名單中，該對應(yīng)關(guān)系用于表征第一服務(wù)器處理具有該共同消息特征的消息的服務(wù)質(zhì)量差。如表1所示，分發(fā)裝置記錄的黑名單的數(shù)據(jù)結(jié)構(gòu)可以包含以下信息。表1黑名單示范性數(shù)據(jù)結(jié)構(gòu)可選的，黑名單數(shù)據(jù)結(jié)構(gòu)中還可以包含服務(wù)質(zhì)量類型(QoSType)，服務(wù)質(zhì)量類型用于表征服務(wù)器處理消息的質(zhì)量。如表2所示，QoSType可以分為4個等級，每一個等級具有不同含義，應(yīng)理解，本發(fā)明實施例僅僅是舉例說明，在具體實現(xiàn)過程中，QoSType可以根據(jù)實際情況劃分為不同的等級。表2黑名單示范性數(shù)據(jù)結(jié)構(gòu)表3為依據(jù)本發(fā)明實施例的黑名單樣例。表3黑名單樣例AttrTypeAttrValueServerFileName/home/test.txtServer1DataKey1f553e4a-92fe-45bc-aea2-bffbf46903daServer3VolumeIDora_volumeServerMDataSize10240MBServer3其中，表3中，第一條含義：在Server1上訪問文件名為/home/test.txt的文件，會導(dǎo)致消息的服務(wù)質(zhì)量差，例如，處理時間大于預(yù)設(shè)時間閾值。第二條含義：在Server3上訪問Key為1f553e4a-92fe-45bc-aea2-bffbf46903da的數(shù)據(jù)，會導(dǎo)致消息的服務(wù)質(zhì)量差，例如，處理時間大于預(yù)設(shè)時間閾值。第三條含義：在ServerM上訪問卷ID為ora_volume的數(shù)據(jù)，會導(dǎo)致消息的服務(wù)質(zhì)量差，例如，處理時間大于預(yù)設(shè)時間閾值。第四條含義：在Server3上訪問數(shù)據(jù)大小大于等于10240MB的數(shù)據(jù)，會導(dǎo)致消息的服務(wù)質(zhì)量差，例如，處理時間大于預(yù)設(shè)時間閾值。進(jìn)一步的，黑名單中還可以包含服務(wù)質(zhì)量類型(QoSType)，例如，可以使用0表示禁止，1表示響應(yīng)時延長，2表示資源不足，3表示處理失敗等。如表4所示，表四為根據(jù)本發(fā)明一實施例的的黑名單樣例。表4黑名單樣例AttrTypeAttrValueServerQoSTypeFileName/home/test.txtServer10DataKey1f553e4a-92fe-45bc-aea2-bffbf46903daServer33VolumeIDora_volumeServerM1DataSize10240MBServer32其中，表4中，第一條含義：禁止在Server1上訪問文件名為/home/test.txt的文件，否則可能導(dǎo)致系統(tǒng)異常。第二條含義：在Server3上訪問Key為1f553e4a-92fe-45bc-aea2-bffbf46903da的數(shù)據(jù)處理失敗。第三條含義：在ServerM上訪問卷ID為ora_volume的數(shù)據(jù)時延長。第四條含義：在Server3上訪問數(shù)據(jù)大小大于等于10240MB的數(shù)據(jù)資源不足。在分布式集群中，系統(tǒng)存在多個分發(fā)裝置，每個分發(fā)裝置服務(wù)固定區(qū)域的客戶端。系統(tǒng)中還可以包含一個統(tǒng)計中心，每個分發(fā)裝置負(fù)責(zé)本身分發(fā)的消息的QoS統(tǒng)計，并根據(jù)統(tǒng)計結(jié)果更新黑名單，并將QoS統(tǒng)計結(jié)果上報給統(tǒng)計中心，統(tǒng)計中心接收各分發(fā)裝置上報的QoS統(tǒng)計結(jié)果后，綜合計算出全局黑名單，并將全局的黑名單同步到各分發(fā)裝置的黑名單。統(tǒng)計結(jié)果中包含上述消息特征與服務(wù)器之間的對應(yīng)關(guān)系，具體可以為每個分發(fā)裝置維護(hù)的黑名單。在具體實現(xiàn)過程中，該統(tǒng)計中心可以為多個分發(fā)裝置中的一個。該統(tǒng)計中心可以由所有的分發(fā)裝置投票選舉得到，統(tǒng)計中心故障后支持重新選舉。各分發(fā)裝置也可以分別將自身的統(tǒng)計結(jié)果存儲于一個公共存儲設(shè)備，隨后由每個分發(fā)裝置分別去公共存儲設(shè)備加載合并后的統(tǒng)計結(jié)果。在本發(fā)明實施例的另外一種實現(xiàn)方式中，每個分發(fā)裝置負(fù)責(zé)本身分發(fā)的消息的QoS統(tǒng)計，根據(jù)統(tǒng)計結(jié)果更新黑名單，并將自身的統(tǒng)計結(jié)果發(fā)送個其他分發(fā)裝置，每個分發(fā)裝置可以將接收到的其他分發(fā)裝置的統(tǒng)計結(jié)果加入自身維護(hù)的黑名單。應(yīng)理解，在分布式架構(gòu)下，分發(fā)裝置之間共享統(tǒng)計結(jié)果的方式多種多樣，本發(fā)明實施例僅僅是舉例說明，并不限定各分發(fā)裝置之間共享黑名單的方式?？蛇x的，分發(fā)裝置在接收到待分發(fā)消息后，首先識別待分發(fā)消息中是否攜帶黑名單中記錄的消息特征，如果識別出待分發(fā)消息中攜帶黑名單中記錄的消息特征，則分發(fā)裝置根據(jù)該消息特征和黑名單記錄的對應(yīng)關(guān)系確定該消息特征對應(yīng)的服務(wù)器，并在除該服務(wù)器外的服務(wù)器中為該待分發(fā)消息選擇目標(biāo)服務(wù)器。例如，如果分發(fā)裝置接收到的待分發(fā)消息中攜帶第一服務(wù)器對應(yīng)的上述共同消息特征，則分發(fā)裝置根據(jù)黑名單記錄的對應(yīng)關(guān)系和該共同消息特征確定第一服務(wù)器，并在第一服務(wù)器外的其他服務(wù)器中選擇第二服務(wù)器，并將待分發(fā)消息分發(fā)給第二服務(wù)器處理。在分布式集群中，分發(fā)裝置接收到待分發(fā)消息后，可以先根據(jù)消息分發(fā)算法為該待分發(fā)消息選擇預(yù)分配服務(wù)器，如果該預(yù)分配服務(wù)器為第一服務(wù)器，則分發(fā)裝置為待分發(fā)消息選擇第一服務(wù)器的從節(jié)點，則第二服務(wù)器為該第一服務(wù)器的從節(jié)點。應(yīng)理解，在本發(fā)明實施例中，分發(fā)裝置可以直接將待分發(fā)消息發(fā)送給第二服務(wù)器處理，也可以將待分發(fā)消息拆分為多個子消息，并將其中的一個或多個子消息發(fā)送給第二服務(wù)器處理。可選的，分發(fā)裝置在接收到待分發(fā)消息后，首先識別待分發(fā)消息中是否攜帶黑名單中記錄的消息特征，如果待分發(fā)消息中攜帶黑名單中記錄的消息特征，則分發(fā)裝置根據(jù)該消息特征和黑名單記錄的對應(yīng)關(guān)系確定該消息特征對應(yīng)的服務(wù)器，并調(diào)低該服務(wù)器的權(quán)重，然后使用動態(tài)分配算法為待分發(fā)消息選擇服務(wù)器。在這種實現(xiàn)方式中，通過調(diào)低服務(wù)器的權(quán)重，減小了選中第一服務(wù)器的概率。進(jìn)一步的，可以將該服務(wù)器的權(quán)重調(diào)為0，從而避免選取到該服務(wù)器。在消息處理成本差異較大場景下，大規(guī)模集群長時間運行后，某個Server由于軟件老化(如內(nèi)存碎片)無法處理特定消息(如消息大小超過特定值)時，可能導(dǎo)致處理失敗或處理時間長。根據(jù)本發(fā)明實施例公開的技術(shù)方案，分發(fā)裝置通過把此類消息和Server的映射關(guān)系加入黑名單，盡量不再分發(fā)此類消息給該Server，提高了系統(tǒng)處理性能和成功率。進(jìn)一步的，大規(guī)模集群長時間運行后，某個Server由于運行環(huán)境變化觸發(fā)軟件錯誤，可能導(dǎo)致處理特定消息(讀損壞的文件)時進(jìn)程異常退出，Server進(jìn)程重啟后，后續(xù)仍會收到此類消息而導(dǎo)致進(jìn)程反復(fù)重啟。根據(jù)本發(fā)明實施例，通過把此類消息和Server的映射關(guān)系加入黑名單，保證此類消息后續(xù)不會再分發(fā)給該Server，保證該Server不會反復(fù)故障。圖5為依據(jù)本發(fā)明一實施例的消息分發(fā)方法500的示范性流程圖，如圖5所示，方法500包括：S502：分發(fā)裝置接收待分發(fā)消息。分發(fā)裝置接收到待分發(fā)消息后，會提取待分發(fā)消息的消息特征。S504：分發(fā)裝置確定黑名單中是否存在與待分發(fā)消息的消息特征對應(yīng)的服務(wù)器，如果在黑名單中不存在與待分發(fā)消息的消息特征對應(yīng)的服務(wù)器，則執(zhí)行步驟506，如果在黑名單中存在與待分發(fā)消息的消息特征對應(yīng)的服務(wù)器，則執(zhí)行步驟508。分發(fā)裝置維護(hù)的黑名單中記錄有消息特征與服務(wù)器的對應(yīng)關(guān)系，該對應(yīng)關(guān)系用于指示與消息特征對應(yīng)的服務(wù)器處理具有該消息特征的消息的QoS差。黑名單的創(chuàng)建方式在圖4實施例已有描述，在此不再贅述。S506：分發(fā)裝置按照預(yù)設(shè)分發(fā)算法為待分發(fā)消息選擇服務(wù)器。因為不存在與待分發(fā)消息的消息特征相對應(yīng)的服務(wù)器，所以所有的可選的服務(wù)器都可以用來處理該待分發(fā)消息，分發(fā)裝置根據(jù)預(yù)設(shè)分發(fā)算法為待分發(fā)消息選擇目標(biāo)服務(wù)器，并將待分發(fā)消息分發(fā)給目標(biāo)服務(wù)器。S508:分發(fā)裝置根據(jù)不同的分發(fā)算法執(zhí)行不同的步驟，如果分發(fā)算法為輪詢算法或隨機(jī)算法，則執(zhí)行步驟S510，如果分發(fā)算法為動態(tài)分發(fā)算法，則執(zhí)行步驟S512，如果分發(fā)算法為靜態(tài)路由表，哈希算法或一致性哈希算法，則執(zhí)行步驟S514。S510：分發(fā)裝置在服務(wù)質(zhì)量差的服務(wù)器外的服務(wù)器中選擇目標(biāo)服務(wù)器。分發(fā)裝置可以先再可選服務(wù)器列表中將服務(wù)器差的服務(wù)器刪除，然后在剩余的服務(wù)器中輪詢或隨機(jī)選擇目標(biāo)服務(wù)器。服務(wù)質(zhì)量差的節(jié)點為黑名單中記錄的與待分發(fā)消息的消息特征對應(yīng)的服務(wù)器，目標(biāo)服務(wù)器為用于處理待分發(fā)消息的服務(wù)器。S512：分發(fā)裝置調(diào)低服務(wù)質(zhì)量差的服務(wù)器的權(quán)重，并在可選的服務(wù)器中選擇目標(biāo)服務(wù)器。如果預(yù)設(shè)算法為動態(tài)分發(fā)算法，為了降低選擇QoS差的服務(wù)器的概率，分發(fā)裝置調(diào)低QoS差的服務(wù)器的權(quán)重，然后使用動態(tài)分發(fā)算法選擇目標(biāo)服務(wù)器。更具體的，分發(fā)裝置可以將QoS差的服務(wù)器的權(quán)重調(diào)整為0，以避免選擇QoS差的服務(wù)器。S514：分發(fā)裝置根據(jù)預(yù)設(shè)算法選擇目標(biāo)服務(wù)器。如果分發(fā)算法是靜態(tài)路由表，哈希算法或一致性哈希算法，分發(fā)裝置可以現(xiàn)根據(jù)分發(fā)算法選擇目標(biāo)服務(wù)器，然后再判斷目標(biāo)服務(wù)器是否是QoS差的服務(wù)器。S516：分發(fā)裝置判斷目標(biāo)服務(wù)器是否為服務(wù)質(zhì)量差的服務(wù)器，如果目標(biāo)服務(wù)器為QoS差的服務(wù)器，則執(zhí)行步驟S518，如果目標(biāo)服務(wù)器不是QoS差的服務(wù)器，則將待分發(fā)消息分發(fā)給目標(biāo)服務(wù)器。S518：分發(fā)裝置判斷目標(biāo)服務(wù)器是否有可選的從服務(wù)器，如果目標(biāo)服務(wù)器存在可選的從服務(wù)器，則執(zhí)行步驟S520，如果目標(biāo)服務(wù)器不存在可選的從服務(wù)器，則可以將待分發(fā)消息分發(fā)給目標(biāo)服務(wù)器或直接給客戶端反饋處理失敗。分布式集群中，為保證可靠性，1個子消息一般至少有2個服務(wù)器可以處理，如果目標(biāo)服務(wù)器是QoS差的服務(wù)器，則可以選擇目標(biāo)服務(wù)器的從服務(wù)器處理待分發(fā)消息。如果目標(biāo)服務(wù)器沒有從服務(wù)器或者目標(biāo)服務(wù)器的從服務(wù)器也是QoS差的服務(wù)器，則可以將待分發(fā)消息發(fā)送給目標(biāo)服務(wù)器處理或者直接給客戶端發(fā)送處理失敗的指示消息，例如，如果黑名單中包含QoS等級，如果QoS等級是處理時間，則可以仍然將待分發(fā)消息發(fā)送給目標(biāo)服務(wù)器處理，如果QoS等級為禁止，則可以直接給客戶端發(fā)送處理失敗的指示消息。根據(jù)本申請公開的技術(shù)方案，分發(fā)裝置通過對已分發(fā)消息的服務(wù)質(zhì)量的監(jiān)控，識別出分發(fā)給某一服務(wù)器的消息中服務(wù)質(zhì)量差的消息，例如，在消息處理成本差異較大場景下，大規(guī)模集群長時間運行后，某個服務(wù)器由于軟件老化(如內(nèi)存碎片)無法處理特定消息(如消息大小超過特定值)，而導(dǎo)致處理失敗或處理時間長，或者某個服務(wù)器由于運行環(huán)境變化觸發(fā)軟件錯誤，而導(dǎo)致處理特定消息(讀損壞的文件)時進(jìn)程異常退出。分發(fā)裝置提取服務(wù)質(zhì)量差的消息的共同消息特征，將此類消息特征和服務(wù)器的映射關(guān)系加入黑名單，后續(xù)盡量不再分發(fā)此類消息給該服務(wù)器或保證不再分發(fā)此類消息給該服務(wù)器，從而提高了系統(tǒng)處理性能和成功率，避免了服務(wù)器的反復(fù)故障。圖6為依據(jù)本發(fā)明一實施例的一種分發(fā)裝置600的邏輯結(jié)構(gòu)示意圖，云系統(tǒng)中包含客戶端，分發(fā)裝置600和多個服務(wù)器，如圖6所示，裝置600包括分發(fā)單元602，確定單元604和記錄單元606。其中分發(fā)單元602用于將M個消息發(fā)送給第一服務(wù)器，其中，M為大于1的正整數(shù)。確定單元604用于確定M個消息中服務(wù)質(zhì)量差的N個消息，其中，N為不大于M的正整數(shù)。可選的，確定單元604用于根據(jù)消息處理時間確定QoS差的消息。確定單元604用于確定M個消息中服務(wù)質(zhì)量差的N個消息包括：確定單元604用于確定處理時間大于預(yù)設(shè)時間閾值的N個消息，并將該N個消息作為QoS差的消息。可選的，確定單元604用于確定M個消息中服務(wù)質(zhì)量差的N個消息包括：確定單元604用于根據(jù)M個消息中的每個消息的響應(yīng)消息，確定服務(wù)質(zhì)量差的N個消息，其中，N個消息中的每個消息的響應(yīng)消息中攜帶特征碼，特征碼用于指示服務(wù)質(zhì)量差。記錄單元606，用于提取N個消息的共同消息特征，并記錄共同消息特征與第一服務(wù)器的對應(yīng)關(guān)系。如圖7所示，裝置600還包括接收單元608，用于接收來自客戶端的待分發(fā)消息，待分發(fā)消息具有共同消息特征?？蛇x的，分發(fā)單元602用于根據(jù)記錄單元606記錄的對應(yīng)關(guān)系和該共同消息特征確定第一服務(wù)器，并在第一服務(wù)器外的服務(wù)器中選擇第二服務(wù)器，并將待分發(fā)消息分發(fā)給第二服務(wù)器處理。在一種具體的實現(xiàn)方式中，分發(fā)單元602用于根據(jù)預(yù)設(shè)分發(fā)算法為待分發(fā)消息選擇預(yù)分配服務(wù)器，如果預(yù)分配服務(wù)器為第一服務(wù)器，則為待分發(fā)消息選擇第二服務(wù)器，第二服務(wù)器為第一服務(wù)器的從節(jié)點。可選的，分發(fā)單元602用于根據(jù)記錄單元606記錄的對應(yīng)關(guān)系和該共同消息特征確定第一服務(wù)器，調(diào)低第一服務(wù)器的權(quán)重，并使用動態(tài)分配算法為待分發(fā)消息選擇服務(wù)器。分發(fā)單元602，確定單元604和記錄單元606可以由圖3所示的處理器302結(jié)合存儲器304來實現(xiàn)，更具體的，可以由處理器302執(zhí)行存儲器304中的分發(fā)控制模塊的程序代碼來實現(xiàn)。接收單元608可以由圖3所示的處理器302結(jié)合通信接口308來實現(xiàn)，更具體的，可以由處理器302執(zhí)行存儲器304中的通信模塊的程序代碼，以使通信接口308來實現(xiàn)接收單元608的功能。本發(fā)明實施例是云系統(tǒng)分發(fā)裝置的實施例，圖4和圖5實施例部分的特征描述，適用于本發(fā)明實施例，在此不再贅述。在本申請所提供的幾個實施例中，應(yīng)該理解到，所揭露的系統(tǒng)，設(shè)備和方法，可以通過其它的方式實現(xiàn)。例如，以上所描述的裝置實施例僅僅是示意性的，例如，所述模塊的劃分，僅僅為一種邏輯功能劃分，實現(xiàn)時可以有另外的劃分方式，例如多個模塊或組件可以結(jié)合或者可以集成到另一個系統(tǒng)，或一些特征可以忽略，或不執(zhí)行。另一點，所顯示或討論的相互之間的耦合或直接耦合或通信連接可以是通過一些接口，裝置或模塊的間接耦合或通信連接，可以是電性，機(jī)械或其它的形式。所述作為分離部件說明的模塊可以是或者也可以不是物理上分開的，作為模塊顯示的部件可以是或者也可以不是物理模塊，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡(luò)模塊上?？梢愿鶕?jù)實際的需要選擇其中的部分或者全部模塊來實現(xiàn)本實施例方案的目的。另外，在本發(fā)明各個實施例中的各功能模塊可以集成在一個處理模塊中，也可以是各個模塊單獨物理存在，也可以兩個或兩個以上模塊集成在一個模塊中。上述集成的模塊既可以采用硬件的形式實現(xiàn)，也可以采用硬件加軟件功能模塊的形式實現(xiàn)。上述以軟件功能模塊的形式實現(xiàn)的集成的模塊，可以存儲在一個計算機(jī)可讀取存儲介質(zhì)中。上述軟件功能模塊存儲在一個存儲介質(zhì)中，包括若干指令用以使得一臺計算機(jī)設(shè)備(可以是個人計算機(jī)，服務(wù)器，或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行本發(fā)明各個實施例所述方法的部分步驟。而前述的存儲介質(zhì)包括：移動硬盤、只讀存儲器、隨機(jī)存取存儲器、磁碟或者光盤等各種可以存儲程序代碼的介質(zhì)。最后應(yīng)說明的是：以上實施例僅用以說明本發(fā)明的技術(shù)方案，而非對其限制；盡管參照前述實施例對本發(fā)明進(jìn)行了詳細(xì)的說明，本領(lǐng)域的普通技術(shù)人員應(yīng)當(dāng)理解：其依然可以對前述各實施例所記載的技術(shù)方案進(jìn)行修改，或者對其中部分技術(shù)特征進(jìn)行等同替換；而這些修改或者替換，并不使相應(yīng)技術(shù)方案的本質(zhì)脫離本發(fā)明各實施例技術(shù)方案的保護(hù)范圍。當(dāng)前第1頁1 2 3