本發明涉及通信技術領域，特別涉及服務異步交互方法、設備、系統和可讀介質。

背景技術：

隨著一個系統的功能和內容不斷壯大，單一的系統無法支撐日益增長的用戶體量。微服務的概念也是在這種環境下產生的，它是指導一個系統如何劃分為一個個獨立的系統，使服務之間相互解耦，從而提高服務的性能和穩定性。但解耦首要解決的問題是如何確保多個系統之間數據操作的一致性，也就是分布式事務如何保證最終一致性的方法。傳統的解決方法就是通過各個服務之間通過http請求進行同步操作，如果只涉及到1至2個系統還可以穩定運行。但是一旦涉及到更多個系統，則一旦某一個系統出問題，會導致其他系統也會受到牽連。

技術實現要素：

本發明的主要目的是提供服務異步交互方法、設備、系統和可讀介質，旨在增加系統之間同步操作的穩定性。

為實現上述目的，本發明提出的一種服務異步交互方法，用于多系統之間業務交互，所述服務異步交互方法包括如下步驟：

在接收到需要與另一系統進行業務交互的業務指令時，根據所述業務指令執行本地相關業務操作；

在所述業務操作成功時，調用消息通知與接收模塊，來將所述業務操作的傳遞信息封裝為通信消息，所述通信消息包括消息事務id以及消息發送和接受協議；

將所述通信消息發送至與所述另一系統之間部署的消息隊列，用以通過所述消息隊列發送至所述另一系統。

優選的，在所述業務操作成功時，所述服務異步交互方法還包括步驟：

在預設消息記錄表中記錄所述業務操作的業務操作消息，其中，所述業務操作消息包括所述消息事務id和推送狀態；

在接收到來自所述另一系統針對所述通信消息返回的返回消息時，根據所述返回消息更新所述業務操作消息的推送狀態。

優選的，所述服務異步交互方法還包括如下步驟：

定時輪詢所述消息記錄表，查詢推送狀態為失敗的通信消息；

在查詢到推送狀態為失敗的通信消息時，對所述推送狀態為失敗的通信消息進行重新發送。

優選的，所述消息隊列采用兔子消息隊列rabbitmq。

本發明提供的一種服務異步交互設備，所述服務異步交互設備包括處理器、存儲器和儲存于所述儲存器上的并可在處理器上運行的服務異步交互程序；所述服務異步交互程序被所述處理器執行時實現上述的服務異步交互方法的步驟。

本發明提供的可讀介質，用于計算機讀取，所述可讀介質上存儲有服務異步交互程序，所述服務異步交互程序被處理器執行時實現上述的服務異步交互方法的步驟。

本發明提供的一種服務異步交互系統，包括處理器、存儲器和儲存于所述儲存器上的用以實現多種服務的多個系統，所述服務異步交互系統還包括儲存在所述儲存器上的用于部署在多個所述系統之間的消息隊列集群；

所述系統在被所述處理器執行時，實現如下步驟：

在接收到需要與另一系統進行業務交互的業務指令時，根據所述業務指令執行相關業務操作；

在所述業務操作成功時，調用消息通知與接收模塊，來將所述業務操作的傳遞信息封裝為通信消息，所述通信消息包括消息事務id以及消息發送和接受協議；

將所述通信消息發送至與另一系統之間部署的消息隊列，用以通過所述消息隊列發送至另一系統；

所述系統在被所述處理器執行時，還包括實現如下步驟：

接受來自另一系統的通信消息；

根據所述通信消息進行處理，并且在處理完畢時將處理結果封裝為包括消息發送和接受協議的返回消息；

將所述返回消息發送至所述消息隊列，用以通過所述消息隊列發送至另一系統；

所述消息隊列集群在被所述處理器執行時，實現如下步驟：

在接收到所述系統的通信消息以及返回消息時，通過每個所述系統之間業務交互所分別使用的一個指定消息隊列來發送所述通信消息以及返回消息。

優選的，所述消息隊列集群在被所述處理器執行時，還包括實現消息隊列的持久化。

優選的，所述一系統在被所述處理器執行時，還實現如下步驟：

在所述業務操作成功時，在預設消息記錄表中記錄所述業務操作的業務操作消息，其中，所述業務操作消息包括所述消息事務id和推送狀態；

在接收到來自另一系統針對所述通信消息返回的返回消息時，根據所述返回消息更新所述業務操作消息的推送狀態。

優選的，所述一系統在被所述處理器執行時，還實現如下步驟：

定時輪詢所述消息記錄表，查詢推送狀態為失敗的通信消息；

在查詢到推送狀態為失敗的通信消息時，對所述推送狀態為失敗的通信消息進行重新發送。

本發明所提供的服務異步交互方法、設備、系統和可讀介質，通過設置功能單一的系統，本地執行其業務，并且將傳遞信息通過封裝并且通過消息隊列傳遞至目標系統，則是各自在本地進行本地的業務邏輯操作，再將結果通過消息隊列的方式發送至另一系統。相對于通過http實現系統間的同步，本實施例實現了系統之間的異步交互，能夠增強系統的穩定性；進一步的，通過rabbitmq可以讓各個系統的服務業務之間解耦，無需復雜的http調用接口驗證。

附圖說明

為了更清楚地說明本發明實施例或現有技術中的技術方案，下面將對實施例或現有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發明的一些實施例，對于本領域普通技術人員來講，在不付出創造性勞動的前提下，還可以根據這些附圖示出的結構獲得其他的附圖。

圖1為本發明服務異步交互方法第一實施例的流程圖；

圖2為本發明服務異步交互方法第二實施例的流程圖；

圖3為本發明服務異步交互方法第三實施例的流程圖；

圖4為本發明服務異步交互設備一實施例的模塊示意圖；

圖5為本發明可讀介質一實施例的模塊示意圖；

圖6為本發明服務異步交互系統一實施例的模塊示意圖。

本發明目的的實現、功能特點及優點將結合實施例，參照附圖做進一步說明。

具體實施方式

應當理解，此處所描述的具體實施例僅僅用以解釋本發明，并不用于限定本發明。

請參看圖1，本發明服務異步交互方法第一實施例，用于多系統之間業務交互，所述服務異步交互方法包括如下步驟：

步驟s101，在接收到需要與另一系統進行業務交互的業務指令時，根據所述業務指令執行本地相關業務操作。

例如，當用戶在領券系統內激活了領券業務，則領券系統執行該領券的業務；而該領券的業務將用于訂單系統，用于在訂單系統內實施現金抵扣業務。則上述的領券業務需要與訂單系統進行業務交互。當領券系統接收到執行領券業務指令時，其在本地執行該業務直至該業務結束，例如向用戶展現領券動畫，以及領券金額，以及領券成功的提示等等。

步驟s102，在所述業務操作成功時，調用消息通知與接收模塊，來將所述業務操作的傳遞信息封裝為通信消息，所述通信消息包括消息事務id以及消息發送和接受協議。

繼續以上述領券業務作為例來說明：當用戶激活領券業務，領券系統通過審核，并沒有發現用戶有任何不合規之處，則代表用戶可以領用該優惠券。則領券系統執行發放優惠券的步驟，此時判定業務操作成功。若用戶不符合領取優惠券的要求，則拒絕向用戶發放優惠券，此時判定業務操作失敗。在領券系統中，領券系統可以獨立的完成其功能，無需關心訂單系統是否能正確處理所接收到的優惠券消息，從而領券系統功能較單一，結構較簡單地實現了其本身的領券功能。進一步的，當用戶獲得優惠券時，該優惠券需要與訂單系統交流通訊，因此領券你系統需要生成一個傳遞信息，通知訂單系統，該用戶具有優惠券。

而該傳遞信息，通過通知與接收模塊封裝而成。具體的，該消息通知與接收模塊的作用主要是生成一個唯一的消息事務id，供全局的消息使用，以達到區分各個消息的目的；另外此模塊會按照具體消息隊列的接口語法，封裝好消息的發送和接受的方法，對外提供服務。此模塊可以作為所有系統之間調用消息的共用模塊。即該通知與接收模塊可以是本系統存在的，也可以是多個系統共享使用的。

步驟s103，將所述通信消息發送至與所述另一系統之間部署的消息隊列，用以通過所述消息隊列發送至所述另一系統。

消息隊列可以采用優選采用灰兔消息隊列rabbitmq，rabbitmq是當前流行的開源消息隊列系統，用erlang語言開發，因為erlang天生就是一門分布式語言，因此便于實現集群，以及分布式系統。rabbitmq是amqp(高級消息隊列協議)的標準實現，可復用的企業消息系統。它遵循mozillapubliclicense開源協議。相對于其他的消息隊列，rabbitmq具有開源，穩定性好，以及符合amqp標準，因此為優秀的消息隊列選擇。

本實施例所提供的服務異步交互方法，通過設置功能單一的系統，本地執行其業務，并且將傳遞信息通過封裝并且通過消息隊列傳遞至目標系統，則是各自在本地進行本地的業務邏輯操作，再將結果通過消息隊列的方式發送至另一系統。相對于通過http實現系統間的同步，本實施例實現了系統之間的異步交互，能夠增強系統的穩定性；進一步的，通過rabbitmq可以讓各個系統的服務業務之間解耦，無需復雜的http調用接口驗證。

其中，異步雙方不需要共同的時鐘，也就是接收方不知道發送方什么時候發送，所以在發送的信息中就要有提示接收方開始接收的信息，如開始位，同時在結束時有停止位。

解耦就是用數學方法將兩種運動分離開來處理問題，常用解耦方法就是忽略或簡化對所研究問題影響較小的一種運動，只分析主要的運動。從而使得系統的變量降低，使得系統更穩定。在解耦控制問題中，基本目標是設計一個控制裝置，使構成的多變量控制系統的每個輸出變量僅由一個輸入變量完全控制，且不同的輸出由不同的輸入控制。

全局事務：資源管理器管理和協調的事務，可以跨越多個數據庫和進程。

請參看圖2，本發明服務異步交互方法第二實施例，本實施例以第一實施例為基礎，新增了步驟，具體如下：

步驟s201，本步驟與第一實施例的步驟s101相同，具體請參看上述實施例，在此不再贅述。

步驟s202，本步驟與第一實施例的步驟s102相同，具體請參看上述實施例，在此不再贅述。

步驟s203，本步驟與第一實施例的步驟s103相同，具體請參看上述實施例，在此不再贅述。

步驟s204，在預設消息記錄表中記錄所述業務操作的業務操作消息，其中，所述業務操作消息包括所述消息事務id和推送狀態。

步驟s205，在接收到來自所述另一系統針對所述通信消息返回的返回消息時，根據所述返回消息更新所述業務操作消息的推送狀態。

本實施例，通過記錄業務操作消息至消息記錄表中，則可以實現對每一業務操作進行追溯的效果。從而便于復查以及核對消息等后續工作。

請參看圖3，本發明服務異步交互方法第三實施例，本實施例以第二實施例為基礎，新增了步驟，具體如下：

步驟s301，本步驟與第一實施例的步驟s201相同，具體請參看上述實施例，在此不再贅述。

步驟s302，本步驟與第一實施例的步驟s202相同，具體請參看上述實施例，在此不再贅述。

步驟s303，本步驟與第一實施例的步驟s203相同，具體請參看上述實施例，在此不再贅述。

步驟s304，本步驟與第一實施例的步驟s204相同，具體請參看上述實施例，在此不再贅述。

步驟s305，本步驟與第一實施例的步驟s205相同，具體請參看上述實施例，在此不再贅述。

步驟s306，定時輪詢所述消息記錄表，查詢推送狀態為失敗的通信消息。

定時的時間，可以是5秒，1分鐘或者10分鐘等等。

步驟s307，在查詢到推送狀態為失敗的通信消息時，對所述推送狀態為失敗的通信消息進行重新發送。

本實施例，通過定時輪詢所述消息記錄表，則可以了解發送失敗的消息，進一步重發這些消息，從而建立了錯誤補償機制。錯誤補償機制能夠保證一些消息發送失敗，能夠進行重新發送，確保消息抵達到其他系統的服務。

請參看圖4，本發明服務異步交互設備一實施例，所述服務異步交互設備1000包括處理器1100、存儲器1200和儲存于所述儲存器1200上的并可在處理器1100上運行的服務異步交互程序1300；所述服務異步交互程序1300被所述處理器1100執行時實現如上述任一實施例的服務異步交互方法的步驟。

所述服務異步交互方法被處理器1100執行時，所實現的步驟參看上述實施例，在此不再贅述。

由于本實施例所提供的服務異步交互設備1000，包括了上述服務異步交互方法的全部技術特征，因此也具有上述服務異步交互方法的全部有益效果，在此不再贅述。

請參看圖5，本發明可讀介質一實施例，用于計算機讀取，所述可讀介質2000上存儲有服務異步交互程序2100，所述服務異步交互程序2100被處理器執行時實現如上述任一實施例的服務異步交互方法的步驟。

所述服務異步交互方法被處理器執行時，所實現的步驟參看上述實施例，在此不再贅述。

由于本實施例所提供的可讀介質，包括了上述服務異步交互方法的全部技術特征，因此也具有上述服務異步交互方法的全部有益效果，在此不再贅述。

請參看圖6本發明服務異步交互系統一實施例，所述服務異步交互系統3000，包括處理器3100、存儲器3200和儲存于所述儲存器3200上的用以實現多種服務的多個系統。所述服務異步交互系統3000還包括儲存在所述儲存器3200上的用于部署在多個所述系統之間的消息隊列集群3500。其中，本實施例中，多個系統以其中的第一系統3300和第二系統3400為例來舉例說明。處理器3100可以是一個也可以是多個，儲存器3200也可以是一個或多個，同樣整個服務異步交互系統可以設置在一臺服務器上，也可以設置在多臺服務器上，例如第一系統3300位于一臺服務器上，第二系統3400位于另一臺服務器上等等。

所述第一系統3300在被所述處理器3100執行時，實現如下步驟：

在接收到需要與第二系統3400進行業務交互的業務指令時，根據所述業務指令執行相關業務操作。

例如，當用戶在領券系統內激活了領券業務，則領券系統執行該領券的業務；而該領券的業務將用于訂單系統，用于在訂單系統內實施現金抵扣業務。則上述的領券業務需要與訂單系統進行業務交互。當領券系統接收到執行領券業務指令時，其在本地執行該業務直至該業務結束，例如向用戶展現領券動畫，以及領券金額，以及領券成功的提示等等。

在所述業務操作成功時，調用消息通知與接收模塊，來將所述業務操作的傳遞信息封裝為通信消息，所述通信消息包括消息事務id以及消息發送和接受協議。

繼續以上述領券業務作為例來說明：當用戶激活領券業務，領券系統通過審核，并沒有發現用戶有任何不合規之處，則代表用戶可以領用該優惠券。則領券系統執行發放優惠券的步驟，此時判定業務操作成功。若用戶不符合領取優惠券的要求，則拒絕向用戶發放優惠券，此時判定業務操作失敗。在領券系統中，領券系統可以獨立的完成其功能，無需關心訂單系統是否能正確處理所接收到的優惠券消息，從而領券系統功能較單一，結構較簡單地實現了其本身的領券功能。進一步的，當用戶獲得優惠券時，該優惠券需要與訂單系統交流通訊，因此領券你系統需要生成一個傳遞信息，通知訂單系統，該用戶具有優惠券。

而該傳遞信息，通過通知與接收模塊封裝而成。具體的，該消息通知與接收模塊的作用主要是生成一個唯一的消息事務id，供全局的消息使用，以達到區分各個消息的目的；另外此模塊會按照具體消息隊列的接口語法，封裝好消息的發送和接受的方法，對外提供服務。此模塊可以作為所有系統之間調用消息的共用模塊。即該通知與接收模塊可以是本系統存在的，也可以是多個系統共享使用的。

將所述通信消息發送至與第二系統3400之間部署的消息隊列，用以通過所述消息隊列發送至第二系統3400。

本實施例中，第一系統3300既包括本身業務所需的業務代碼，還在業務代碼中集成了消息通知與接收模塊。同理，第二系統3400也既包括本身業務所需的業務代碼，還在業務代碼中集成了消息通知與接收模塊。

所述第一系統3300在被所述處理器執行時，還包括實現如下步驟：

接受來自第二系統3400的通信消息；

根據所述通信消息進行處理，并且在處理完畢時將處理結果封裝為包括消息發送和接受協議的返回消息；

將所述返回消息發送至所述消息隊列，用以通過所述消息隊列發送至第二系統3400。

所述消息隊列集群在被所述處理器執行時，實現如下步驟：

在接收到所述第一系統3300的通信消息以及返回消息時，通過每個系統之間業務交互所分別使用的一個指定消息隊列，來發送所述通信消息以及返回消息。

本實施例中，為了系統穩定以及便于維護，每個系統之間業務的交互需要分別使用一個消息隊列進行消息通信，不可共用一個消息隊列。進一步的，隊列的名字可以取得相對有意義，如商品系統和訂單系統交互的隊列可以叫shop_order_queue，從而達到后期容易維護的效果。

消息隊列可以采用優選采用灰兔消息隊列rabbitmq，rabbitmq是當前流行的開源消息隊列系統，用erlang語言開發，因為erlang天生就是一門分布式語言，因此便于實現集群，以及分布式系統。rabbitmq是amqp(高級消息隊列協議)的標準實現，可復用的企業消息系統。它遵循mozillapubliclicense開源協議。相對于其他的消息隊列，rabbitmq具有開源，穩定性好，以及符合amqp標準，因此為優秀的消息隊列選擇。

rabbit模式大概分為以下三種：單一模式、普通模式、鏡像模式。其中，普通模式和鏡像模式為集群模式。本實施例的rabbitmq集群則可以采用普通模式或鏡像模式。

普通模式：默認的集群模式。

對于queue來說，消息實體只存在于其中一個節點，a、b兩個節點僅有相同的元數據，即隊列結構。

當消息進入a節點的queue中后，consumer從b節點拉取時，rabbitmq會臨時在a、b間進行消息傳輸，把a中的消息實體取出并經過b發送給consumer。優選的consumer盡量連接每一個節點，從中取消息。即對于同一個邏輯隊列，要在多個節點建立物理queue。否則無論consumer連a或b，出口總在a，會產生瓶頸。

但是，該模式存在一個問題就是當a節點故障后，b節點無法取到a節點中還未消費的消息實體。因此，優選的所述消息隊列集群在被所述處理器執行時，還包括實現消息隊列的持久化。在做了持久化后，則可以等a節點恢復后，再可被消費；從而保證數據的穩定性。

其中，持久化可以包括：將交換機置為可持久，將通道置為可持久，以及消息發送時設置可持久。當消息可持久化時，若mq服務中斷，再次啟動消費者獲取消息，消息依然能夠恢復。

鏡像模式：把需要的隊列做成鏡像隊列，存在于多個節點，屬于rabbitmq的ha方案。

該模式解決了上述普通模式存在的問題，其實質和普通模式不同之處在于，消息實體會主動在鏡像節點間同步，而不是在consumer取數據時臨時拉取。

該模式由于需要較強的系統性能以及較寬裕的網絡帶寬條件。因此該模式在對可靠性要求較高的場合中適用。

本實施例服務異步交互系統的消息隊列，采用rabbitmq集群方案，能夠更高效和方便的實現多系統之間的分布式布局。

本實施例所提供的服務異步交互系統，通過設置功能單一的系統，本地執行其業務，并且將傳遞信息通過封裝并且通過消息隊列傳遞至目標系統，則是各自在本地進行本地的業務邏輯操作，再將結果通過消息隊列的方式發送至另一系統。相對于通過http實現系統間的同步，本實施例實現了系統之間的異步交互，能夠增強系統的穩定性；進一步的，通過rabbitmq可以讓各個系統的服務業務之間解耦，無需復雜的http調用接口驗證。

優選的，所述第一系統3300在被所述處理器3100執行時，還實現如下步驟：

在所述業務操作成功時，在預設消息記錄表中記錄所述業務操作的業務操作消息，其中，所述業務操作消息包括所述消息事務id和推送狀態。

在接收到來自第二系統3400針對所述通信消息返回的返回消息時，根據所述返回消息更新所述業務操作消息的推送狀態。

本實施例，通過記錄業務操作消息至消息記錄表中，則可以實現對每一業務操作進行追溯的效果。從而便于復查以及核對消息等后續工作。

優選的，所述第一系統3300在被所述處理器3100執行時，還實現如下步驟：

定時輪詢所述消息記錄表，查詢推送狀態為失敗的通信消息；定時的時間，可以是5秒，1分鐘或者10分鐘等等。

在查詢到推送狀態為失敗的通信消息時，對所述推送狀態為失敗的通信消息進行重新發送。

本實施例，通過定時輪詢所述消息記錄表，則可以了解發送失敗的消息，進一步重發這些消息，從而建立了錯誤補償機制。錯誤補償機制能夠保證一些消息發送失敗，能夠進行重新發送，確保消息抵達到其他系統的服務。

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

上述本發明實施例序號僅僅為了描述，不代表實施例的優劣。

通過以上的實施方式的描述，本領域的技術人員可以清楚地了解到上述實施例方法可借助軟件加必需的通用硬件平臺的方式來實現，當然也可以通過硬件，但很多情況下前者是更佳的實施方式。基于這樣的理解，本發明的技術方案本質上或者說對現有技術做出貢獻的部分可以以軟件產品的形式體現出來，該計算機軟件產品存儲在一個存儲介質(如rom/ram、磁碟、光盤)中，包括若干指令用以使得一臺終端(可以是手機，計算機，服務器，空調器，或者網絡設備等)執行本發明各個實施例所述的方法。

上面結合附圖對本發明的實施例進行了描述，但是本發明并不局限于上述的具體實施方式，上述的具體實施方式僅僅是示意性的，而不是限制性的，本領域的普通技術人員在本發明的啟示下，在不脫離本發明宗旨和權利要求所保護的范圍情況下，還可做出很多形式，這些均屬于本發明的保護之內。