接收終端建立連接。
[0030]在本實施例中，當(dāng)在上述步驟201中確定出一個或多個消息接收終端后，可以進一步檢測每個消息發(fā)送終端是否能和消息接收終端成功的建立連接，也就是對消息接收終端進行“健康檢查”。由于機器本身故障或其它原因，有可能出現(xiàn)消息發(fā)送終端無法與某一個消息接收終端建立連接的情況，如果消息發(fā)送終端直接將消息發(fā)送給這樣的消息接收終端，就會導(dǎo)致消息發(fā)送失敗的問題。因此，在進行消息發(fā)送前，需要對消息發(fā)送終端和消息接收終端之間的連接情況進行檢測。例如，可以由消息發(fā)送終端向每一個消息接收終端發(fā)送連接請求，如果該請求得到了消息接收終端的正常響應(yīng)，則認為二者之間可以正常連接，該消息接收終端是“健康”的，否則認為二者之間無法正常連接，該消息接收終端是“不健康”的。
[0031]繼而，在步驟203中，通過遠程過程調(diào)用協(xié)議，向一個能夠建立連接的消息接收終端發(fā)送消息。
[0032]當(dāng)在上述步驟202中確定出消息發(fā)送終端能夠與一個或多個消息接收終端建立連接后，可以通過遠程過程調(diào)用(Remote Procedure Call，RPC)協(xié)議，向一個能夠建立連接的消息接收終端發(fā)送消息。其中，RPC是一種通過網(wǎng)絡(luò)從遠程計算機程序上請求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。RPC協(xié)議可以假定某些傳輸協(xié)議的存在，從而為通信程序之間攜帶信息數(shù)據(jù)。RPC通?？梢圆捎每蛻魴C/服務(wù)器模式。在本實施例中，消息發(fā)送終端可以是一個客戶機，而消息接收終端可以是一個服務(wù)器。消息發(fā)送終端可以向一個能夠建立連接的消息接收終端發(fā)起RPC調(diào)用，并通過RPC協(xié)議向該終端發(fā)送消息。這樣，消息發(fā)送終端在發(fā)送消息時，可以選取一個“健康”的消息接收終端進行發(fā)送。在這種情況下，即使有某個消息接收終端宕機，也不會影響整個集群的正常運行。
[0033]在本實施例的一個可選實現(xiàn)方式中，消息發(fā)送方法還包括:采用輪詢調(diào)度的方式，從多個能夠建立連接的消息接收終端中確定出一個向其發(fā)送消息的消息接收終端。輪詢調(diào)度(Round-Robin Scheduling)的原理是每一次把來自用戶的請求輪流分配給內(nèi)部中的服務(wù)器，從I開始，直到N (內(nèi)部服務(wù)器個數(shù))，然后重新開始循環(huán)。在本實施例中，可以采用輪詢調(diào)度的方式，確定出向哪一個消息接收終端發(fā)送消息，并且該消息接收終端可以與消息發(fā)送終端成功建立連接。這種確定唯一消息接收終端的方式十分簡潔，無需記錄當(dāng)前所有連接的狀態(tài)，降低了系統(tǒng)消耗。
[0034]最后，在步驟204中，接收消息接收終端返回的消息處理結(jié)果。
[0035]當(dāng)在上述步驟203中將消息發(fā)送給一個消息接收終端后，消息接收終端可以對接收到的消息進行處理，例如，根據(jù)消息中的參數(shù)進行計算等然后再將消息處理結(jié)果發(fā)回給消息發(fā)送終端。此時，消息發(fā)送終端就可以接收消息接收終端返回的消息處理結(jié)果。本領(lǐng)域技術(shù)人員可以理解，這個消息處理結(jié)果返回的步驟也可以是通過RPC協(xié)議完成的。
[0036]本實施例提供的消息發(fā)送方法，可以通過命名服務(wù)確定消息接收終端，解耦了消息發(fā)送和接收終端，使得消息發(fā)送終端與消息接收終端之間可以直接通過遠程過程調(diào)用協(xié)議進行消息傳輸，避免了消息隊列的不利影響，減少了消息到達的延遲。
[0037]請進一步參考圖3，其示出了本申請消息接收方法的一個實施例的流程300。
[0038]如圖3所示，在步驟301中，啟動遠程過程調(diào)用協(xié)議的監(jiān)聽端口。
[0039]在本實施例中，可以首先啟動遠程過程調(diào)用協(xié)議，即RPC協(xié)議的監(jiān)聽端口。該端口可以是消息接收終端上用于進行RPC調(diào)用的端口。
[0040]接著，在步驟302中，若通過監(jiān)聽端口檢測到由消息發(fā)送終端發(fā)送的消息，則通過遠程過程調(diào)用協(xié)議接收消息。
[0041]在本實施例中，當(dāng)在上述步驟301中啟動端口監(jiān)聽后，如果通過監(jiān)聽端口檢測到由消息發(fā)送終端發(fā)送給本端口的消息，也就是檢測到消息發(fā)送終端所發(fā)送的消息中，指定的目標(biāo)端口是自己的端口號時，則可以通過RPC協(xié)議接收該消息。
[0042]最后，在步驟303中，對消息進行處理，并將消息處理結(jié)果返回消息發(fā)送終端。
[0043]當(dāng)在上述步驟302中接收到消息后，消息接收終端可以對接收到的消息進行處理，例如，根據(jù)消息中的參數(shù)進行計算等然后再將消息處理結(jié)果發(fā)回給消息發(fā)送終端。此時，消息發(fā)送終端就可以接收消息接收終端返回的消息處理結(jié)果。
[0044]圖4是本申請中OpenStack的Nova組件中各模塊之間進行通信的示意圖。如圖4所示，除了 Api模塊和Scheduler模塊之間不能直接通信外，Nova組件中的Ap1、Scheduler和Conductor、Compute模塊，以及Conductor和Compute模塊之間都可以直接進行通信。由于各個模塊之間都是通過RPC協(xié)議直接進行通信，從而避免了消息隊列的不利影響，減少了消息到達的延遲。
[0045]請進一步參考圖5，其示出了本申請消息發(fā)送終端的一個實施例的結(jié)構(gòu)示意圖。
[0046]如圖5所示，本實施例的消息發(fā)送終端500包括:確定模塊510、檢測模塊520、消息發(fā)送模塊530和結(jié)果接收模塊540。
[0047]確定模塊510，用于通過命名服務(wù)確定至少一個消息接收終端。
[0048]檢測模塊520，用于檢測是否能夠與消息接收終端建立連接。
[0049]消息發(fā)送模塊530，用于通過遠程過程調(diào)用協(xié)議，向一個能夠建立連接的消息接收終端發(fā)送消息。
[0050]結(jié)果接收模塊540，接收消息接收終端返回的消息處理結(jié)果。
[0051]在本實施例的一個可選實現(xiàn)方式中，確定模塊510進一步用于，基于待發(fā)送消息的主題，通過命名服務(wù)獲取消息接收終端的部署信息；根據(jù)部署信息，確定至少一個消息接收終端。
[0052]在本實施例的一個可選實現(xiàn)方式中，消息發(fā)送終端500還包括:
[0053]輪訓(xùn)模塊，用于采用輪詢調(diào)度的方式，從多個能夠建立連接的消息接收終端中確定出一個向其發(fā)送消息的消息接收終端。
[0054]請進一步參考圖6，其示出了本申請消息接收終端的一個實施例的結(jié)構(gòu)示意圖。
[0055]如圖6所示，本實施例的消息接收終端600包括:啟動模塊610、消息接收模塊620和消息處理模塊630。
[0056]啟動模塊610，用于啟動遠程過程調(diào)用協(xié)議的監(jiān)聽端口。
[0057]消息接收模塊620，用于若通過監(jiān)聽端口檢測到由消息發(fā)送終端發(fā)送的消息，則通過遠程過程調(diào)用協(xié)議接收消息。
[0058]消息處理模塊630，用于對消息進行處理，并將消息處理結(jié)果返回消息發(fā)送終端。
[0059]應(yīng)當(dāng)理解，圖5和6中記載的諸單元或模塊與參考圖2和3描述的方法中的各個步驟相對應(yīng)。由此，上文針對方法描述的操作和特征同樣適用于圖5和6中的終端及其中包含的單元或模塊，在此不再贅述。
[0060]請進一步參考圖7，其示出了本申請消息發(fā)送系統(tǒng)的一個實施例的結(jié)構(gòu)示意圖。
[0061]如圖7所示，本實施例的消息發(fā)送系統(tǒng)700包括:消息發(fā)送終端710和消息接收終端 720。
[0062]消息發(fā)送終端710，用于通過命名服務(wù)確定至少一個消息接收終端720 ;檢測是否能夠與消息接收終端720建立連接；通過遠程過程調(diào)用協(xié)議，向一個能夠建立連接的消息接收終端720發(fā)送消息；以及接收消息接收終端720返回的消息處理結(jié)果。
[0063]消息接收終端720，用于啟動遠程過程調(diào)用協(xié)議的監(jiān)聽端口 ；若通過監(jiān)聽端口檢測到由消息發(fā)送終端710發(fā)送的消息，則通過遠程過程調(diào)用協(xié)議接收消息；對消息進行處理，并將消息處理結(jié)果返回消息發(fā)送終端710。
[0064]在本實施例的一個可選實現(xiàn)方式中，消息發(fā)送終端710和消息接收終端720均為OpenStack組件中