[發明專利]基于消息隊列的業務處理方法、裝置、設備及存儲介質

在審

• 申請號: 202011577513.0
• 申請日: 2020-12-28
• 公開（公告）號: CN112527534A
• 公開（公告）日: 2021-03-19
• 發明（設計）人: 李澤青
• 申請（專利權）人: 平安普惠企業管理有限公司
• 主分類號: G06F9/54
• 分類號: G06F9/54;G06F16/22;G06F21/62
• 代理公司: 北京市京大律師事務所 11321
• 代理人: 姚維

本發明涉及大數據技術領域，公開了一種基于消息隊列的業務處理方法、裝置、設備及存儲介質，用于提高解決消息隊列異常問題的效率。基于消息隊列的業務處理方法包括：根據預設白名單列表和預設讀寫權限列表對業務消息訪問請求進行校驗，得到校驗結果；當校驗結果為校驗失敗時，生成并發送包含訪問權限存在異常的警示信息；當校驗結果為校驗成功，并且目標消息隊列的消息消費狀態為堵塞狀態時，通過預設熔斷限流策略重新處理業務消息訪問請求；在對業務消息訪問請求處理過程中，基于業務消息標識生成并發送消息軌跡數據。此外，本發明還涉及區塊鏈技術，消息軌跡數據可存儲于區塊鏈節點中。

技術領域

本發明涉及大數據技術的風險管控領域，尤其涉及一種基于消息隊列的業務處理方法、裝置、設備及存儲介質。

背景技術

在企業微服務架構設計中，服務治理占了非常重要的位置。一般的服務治理包括熔斷限流、調用追蹤、監控告警、故障隔離和服務降級等。但是大部分服務治理框架和治理內容都是針對遠程過程調用RPC框架，例如開源分布式服務框架dubbo或者微服務基礎框架springcloud。一方面很少企業使用消息隊列作關鍵性系統調用，因為多了一個中間件對系統整體性能和吞吐量具有一定影響；另一方面現有技術對消息隊列治理相對簡單，只需要旁路收集消息即可實現。

但是當消息隊列作為系統關鍵性節點時，以上治理方式就略顯不足。因為消息隊列讓上下游解耦，普通的治理方式可能會丟失發送端和消費端的相關信息，如處理耗時和處理結果等。而且消息隊列相關的權限管理也存在不足，導致消息隊列存在發生故障率高，以及解決消息隊列異常問題的效率低的問題。

發明內容

本發明提供了一種基于消息隊列的業務處理方法、裝置、設備及存儲介質，用于降低消息隊列的故障率，以及提高了解決消息隊列異常問題的效率。

為實現上述目的，本發明第一方面提供了一種基于消息隊列的業務處理方法，包括：獲取業務消息訪問請求，根據預設白名單列表和預設讀寫權限列表對所述業務消息訪問請求進行校驗，得到校驗結果，所述業務消息訪問請求具有唯一的業務消息標識；當所述校驗結果為校驗失敗時，生成包含訪問權限存在異常的警示信息，對所述警示信息進行日志記錄，并向消息生產終端發送所述警示信息；當所述校驗結果為校驗成功時，獲取目標消息隊列的消息消費狀態，若所述目標消息隊列的消息消費狀態為堵塞狀態，則生成并返回包含消息隊列存在異常的提示信息，并通過預設熔斷限流策略重新處理所述業務消息訪問請求；在對所述業務消息訪問請求處理過程中，基于所述業務消息標識生成消息軌跡數據，并將所述消息軌跡數據發送至目標終端，以使得所述目標終端按照所述消息軌跡數據繪制并展示對應的消息軌跡點序列。

可選的，在本發明第一方面的第一種實現方式中，所述獲取業務消息訪問請求，根據預設白名單列表和預設讀寫權限列表對所述業務消息訪問請求進行校驗，得到校驗結果，所述業務消息訪問請求具有唯一的業務消息標識，包括：監聽并攔截業務消息訪問請求，對所述業務消息訪問請求進行參數解析，得到消息生產終端地址和目標業務系統編號，所述業務消息訪問請求具有唯一的業務消息標識；判斷所述消息生產終端地址和所述目標業務系統編號是否存在于預設白名單列表中；若所述消息生產終端地址或所述目標業務系統編號不存在于預設白名單列表中，則獲取校驗結果，并確定所述校驗結果為校驗失敗；若所述消息生產終端地址和所述目標業務系統編號均存在于預設白名單列表中，則獲取目標消息主題和目標消息標簽，并判斷所述目標消息主題和所述目標消息標簽是否存在于預設讀寫權限列表中；若所述目標消息主題或所述目標消息標簽不存在于預設讀寫權限列表中，則獲取校驗結果，并確定所述校驗結果為校驗失敗；若所述目標消息主題和所述目標消息標簽均存在于預設讀寫權限列表中，則獲取校驗結果，并確定所述校驗結果為校驗成功。