支付業務系統的服務控制管理組件裝置的製作方法
2023-05-01 16:01:42
本發明涉及支付業務技術領域，特別涉及一種支付業務系統的服務控制管理組件裝置。
背景技術：
隨著中國經濟的快速增長和支付電子化發展，支付活動日益頻繁，市場對支付系統的處理能力提出更高要求。現有支付業務系統均採用集中式應用處理架構，每個業務系統僅包括一個業務處理單元與相關的業務關聯繫統進行交互，對待支付業務進行處理，業務數據統一存儲在單個資料庫中，支付業務系統採用集中式的應用處理架構存在以下問題：
1)可擴展性不強：隨著業務量的持續快速增長，單個資料庫處理出現性能瓶頸，集中式的處理架構無法實現處理能力的橫向收縮，僅通過縱向擴展來提升業務處理容量，不僅成本較高，且存在擴展極限。
2)應用架構不夠靈活：系統運行對單一廠商的軟硬體設備依賴性太強，無法靈活適應多樣化靈活部署的需求，也不適應國家對關鍵業務信息系統自主可控的安全要求。
通過上述可知，現有支付業務系統普遍採用集中式應用處理架構，隨著業務量的增大，處理能力達到飽和並會積聚風險，為應對未來高業務容量、高吞吐量的處理需求，支付業務系統應用架構由集中式調整為分布式為必然趨勢。
然而，現有技術中，難以實現支付業務系統由集中式應用處理架構調整為分布式架構，或需要對現有支付業務系統進行大量複雜的改造，需要耗費很大的成本。
技術實現要素：
本發明實施例提供了一種支付業務系統的服務控制管理組件裝置，用以方便將支付業務系統由集中式處理架構調整為分布式架構，支付業務系統為分布式支付業務系統，包括：多個業務處理單元和與多個業務處理單元交互的多個業務關聯繫統，服務控制管理組件裝置包括：服務管理組件和多個路由組件，其中：
服務管理組件，用於接收每個業務處理單元的信息，根據每個業務處理單元的信息，配置每個業務處理單元應處理待支付業務的策略，將策略發送至多個路由組件；
每個路由組件，設置在與多個業務處理單元交互的每一個業務關聯繫統，每個路由組件與服務管理組件連接，用於根據策略，以及支付業務系統接收的待支付業務，從多個業務處理單元中確定出一個處理待支付業務的業務處理單元，將確定出的業務處理單元的信息提供給業務關聯繫統；
業務關聯繫統根據確定出的業務處理單元的信息，與確定出的業務處理單元進行交互；確定出的業務處理單元根據與業務關聯繫統的交互，處理待支付業務。
在一個實施例中，業務處理單元的信息包括以下其中之一或任意組合：業務處理單元的名稱、業務處理單元待處理業務的隊列信息、業務處理單元的狀態信息、業務處理單元的業務受理範圍信息、業務處理單元的備用業務處理單元信息和業務處理單元所在數據中心的信息。
在一個實施例中，業務處理單元的業務受理範圍信息包括：發起行的行號、接收行的行號和報文類型；
服務管理組件具體用於：接收每個業務處理單元的業務受理範圍信息，根據業務受理範圍信息，配置每個業務處理單元應處理待支付業務的策略，將策略發送至多個路由組件；
每個業務處理單元應處理待支付業務的策略包括：
根據報文類型和發起行的行號，配置的每個業務處理單元應處理待支付業務的策略；
或，根據報文類型和接收行的行號，配置的每個業務處理單元應處理待支付業務的策略；
或，根據報文類型，配置的每個業務處理單元應處理待支付業務的策略。
在一個實施例中，路由組件具體用於：
接收根據待支付業務生成的業務關鍵字信息；
根據業務關鍵字信息，以及每個業務處理單元應處理待支付業務的策略，從多個業務處理單元中確定出一個處理待支付業務的業務處理單元；
將確定出的業務處理單元的信息提供給業務關聯繫統。
在一個實施例中，服務管理組件還用於接收每個業務處理單元對業務關聯繫統公共消息的預訂消息，將預訂消息發送至多個路由組件；
路由組件還用於將預訂消息提供給業務關聯繫統；
業務關聯繫統根據預訂消息，將公共消息發送至預訂了公共消息的業務處理單元。
在一個實施例中，服務管理組件包括：
信息接收模塊，用於接收每個業務處理單元的信息；
信息處理模塊，與信息接收模塊連接，用於根據每個業務處理單元的信息，配置每個業務處理單元應處理待支付業務的策略；
第一網絡通信模塊，用於將策略發送至多個路由組件。
在一個實施例中，信息接收模塊具體用於：接收每個業務處理單元的變更信息；
信息處理模塊具體用於：根據每個業務處理單元的變更信息，重新配置每個業務處理單元應處理待支付業務的策略；
第一網絡通信模塊具體用於：將重新配置的每個業務處理單元應處理待支付業務的策略發送至多個路由組件。
在一個實施例中，信息接收模塊具體用於：接收監控系統pams發來的業務處理單元的狀態信息，以及業務處理單元各個節點的狀態信息；
信息處理模塊具體用於：根據監控系統pams發來的業務處理單元的狀態信息，以及業務處理單元各個節點的狀態信息，維護業務處理單元以及業務處理單元各個節點。
在一個實施例中，信息接收模塊具體用於：接收每個業務處理單元各個節點的可用情況信息；
信息處理模塊具體用於：根據每個業務處理單元各個節點的可用情況信息，判斷每個業務處理單元的可用情況，根據每個業務處理單元的可用情況，配置每個業務處理單元應處理待支付業務的策略；
第一網絡通信模塊具體用於：將根據每個業務處理單元的可用情況，配置的每個業務處理單元應處理待支付業務的策略發送至多個路由組件。
在一個實施例中，服務管理組件具體用於：接收每個業務處理單元及其備用業務處理單元的信息，根據每個業務處理單元及其備用業務處理單元的信息，配置每個業務處理單元應處理待支付業務的策略，將策略發送至多個路由組件。
在一個實施例中，路由組件包括：第二網絡通信模塊、信息更新模塊、共享內存區和路由接口，其中：
第二網絡通信模塊，與服務管理組件連接，用於接收每個業務處理單元應處理待支付業務的策略；
信息更新模塊，用於將每個業務處理單元應處理待支付業務的策略更新至共享內存區，根據策略，以及支付業務系統接收的待支付業務，從多個業務處理單元中確定出一個處理待支付業務的業務處理單元；
路由接口，用於連接與業務處理單元交互的業務關聯繫統和信息更新模塊，將確定出的業務處理單元的信息提供給業務關聯繫統。
在一個實施例中，共享內存區包括：主共享內存區和備共享內存區；
信息更新模塊具體用於：
將每個業務處理單元應處理待支付業務的策略更新至備共享內存區；
將所述備共享內存區變更為主共享內存區，將原主共享內存區變更為備共享內存區；
根據變更後主共享內存區內的策略，以及支付業務系統接收的待支付業務，從多個業務處理單元中確定出一個處理待支付業務的業務處理單元。
在一個實施例中，路由組件具體用於將每個業務處理單元應處理待支付業務的策略存儲在共享內存區，供業務關聯繫統調用；共享內存區包括：主共享內存區和備共享內存區；
服務管理組件具體用於：
將每個業務處理單元應處理待支付業務的策略發送至各個路由組件，接收各個路由組件發來的策略已更新至備共享內存區的響應信息；
將路由組件共享內存區加鎖通知信息發送至各個路由組件，接收各個路由組件發來的路由組件共享內存區加鎖完畢響應信息；
將路由組件主備內存切換信息發送至各個路由組件，接收各個路由組件發來的路由組件主備內存切換完畢響應信息；
將路由組件共享內存區解鎖通知信息發送至各個路由組件，接收各個路由組件發來的路由組件共享內存區解鎖完畢響應信息；
路由組件具體用於：
接收服務管理組件發來的每個業務處理單元應處理待支付業務的策略，將策略更新至備共享內存區，發送策略已更新至備共享內存區的響應信息至服務管理組件；
接收服務管理組件發來的路由組件共享內存區加鎖通知信息，對共享內存區進行加鎖，將路由組件共享內存區加鎖完畢響應信息發送至服務管理組件；
接收服務管理組件發來的路由組件主備內存切換信息，將原備共享內存區變更為主共享內存區，將原主共享內存區變更為備共享內存區，將路由組件主備內存切換完畢響應信息發送至服務管理組件；
接收路由組件共享內存區解鎖通知信息，對共享內存區進行解鎖，將路由組件共享內存區解鎖完畢響應信息發送至服務管理組件。
本發明實施例提供的服務控制管理組件裝置通過：服務管理組件接收每個業務處理單元的信息，根據每個業務處理單元的信息，配置每個業務處理單元應處理待支付業務的策略，將策略發送至多個路由組件；通過：每個路由組件，設置在與多個業務處理單元交互的每一個業務關聯繫統，每個路由組件與服務管理組件連接，用於根據策略，以及支付業務系統接收的待支付業務，從多個業務處理單元中確定出一個處理待支付業務的業務處理單元，將確定出的業務處理單元的信息提供給業務關聯繫統，業務關聯繫統根據確定出的業務處理單元的信息，與確定出的業務處理單元進行交互；確定出的業務處理單元根據與業務關聯繫統的交互，處理待支付業務，實現了支付業務系統由集中式應用處理架構調整為分布式架構，具有良好的橫向可伸縮性，由多個業務處理單元並行處理業務，極大地提升了業務處理容量，提高了業務處理效率，保證了業務連續運行能力，具體理由如下：
首先，由於本發明實施例提供的技術方案將配置策略集中在服務管理組件，將根據所述策略，確定處理待支付業務的業務處理單元的決策集中在路由組件，對與業務處理單元交互的上層業務關聯繫統僅需進行簡單的適應性改造，即可實現分布式業務處理，為支付業務系統由集中式處理架構調整為分布式提供了便利性和可靠性，簡化了現有支付業務系統改造成本，降低了軟硬體採購成本；
另外，服務管理組件根據不同的業務處理單元的信息，配置不同策略，即根據不同的業務處理單元的軟硬體設備，分配給該業務處理單元相應處理能力的業務，這樣業務處理單元可靈活部署，選用多廠商的多類型伺服器、作業系統及資料庫，支持多種類型的軟硬體平臺。
附圖說明
此處所說明的附圖用來提供對本發明的進一步理解，構成本申請的一部分，並不構成對本發明的限定。在附圖中：
圖1是本發明實施例中支付業務系統的服務控制管理組件裝置的結構示意圖；
圖2是本發明實施例中服務控制管理組件裝置具體應用實例的結構示意圖；
圖3是本發明另一實施例中支付業務系統的服務控制管理組件裝置結構示意圖；
圖4是本發明實施例中服務管理組件同步發送信息至路由組件相互通信示意圖。
具體實施方式
為使本發明的目的、技術方案和優點更加清楚明白，下面結合實施方式和附圖，對本發明做進一步詳細說明。在此，本發明的示意性實施方式及其說明用於解釋本發明，但並不作為對本發明的限定。
隨著中國經濟的快速增長和支付電子化發展，支付活動日益頻繁，市場對支付系統的處理能力提出更高要求。主要表現在以下三方面：
1)業務處理容量越來越大；
2)業務處理效率越來越高；
3)業務連續運行能力越來越強。
為達到上述三方面的要求，本發明實施構建的服務控制管理組件由服務管理組件和路由組件構成，其中：路由組件部署在各個業務關聯繫統(例如：軋差系統nets和支付報文傳輸系統pmts等)上，以動態連結庫的形式提供接口供上層應用(例如：軋差系統nets和支付報文傳輸系統pmts等)調用，可以與位於中心的服務管理組件通過網絡連接形成星型結構。服務管理組件提供統一的ui管理界面，支持業務處理單元信息、路由信息(包括：每個業務處理單元應處理待支付業務的策略和每個業務處理單元對業務關聯繫統公共消息的預訂消息等)的靈活配置，作為信息源，會主動將最新的路由信息(包括：每個業務處理單元應處理待支付業務的策略和每個業務處理單元對業務關聯繫統公共消息的預訂消息等)分發至各個路由組件，路由組件根據本地緩存的信息(例如：根據每個業務處理單元的信息，配置的每個業務處理單元應處理待支付業務的策略)為上層業務系統(例如：軋差系統nets和支付報文傳輸系統pmts等)提供路由決策。下面對該服務控制管理組件進行詳細介紹。
本發明實施例提供了一種支付業務系統的服務控制管理組件裝置，用以方便將支付業務系統由集中式處理架構調整為分布式架構，支付業務系統為分布式支付業務系統，包括：多個業務處理單元和與多個業務處理單元交互的多個業務關聯繫統，每個業務處理單元對應一個獨立的資料庫，圖1是本發明實施例中支付業務系統的服務控制管理組件裝置的結構示意圖，如圖1所示，服務控制管理組件裝置包括：服務管理組件100和路由組件200，其中：
服務管理組件100，用於接收每個業務處理單元的信息，根據每個業務處理單元的信息，配置每個業務處理單元應處理待支付業務的策略，將所述策略發送至多個路由組件；
每個路由組件200，設置在與多個業務處理單元交互的每一個業務關聯繫統，每個路由組件與所述服務管理組件連接，用於根據所述策略，以及支付業務系統接收的待支付業務，從多個業務處理單元中確定出一個處理待支付業務的業務處理單元，將確定出的業務處理單元的信息提供給業務關聯繫統；
所述業務關聯繫統根據確定出的業務處理單元的信息，與確定出的業務處理單元進行交互；確定出的業務處理單元根據與業務關聯繫統的交互，處理待支付業務。
具體實施時，本發明實施例提供的服務控制管理組件裝置中服務管理組件可以接收銀行工作人員輸入每個業務處理單元的信息，例如：每個業務處理單元的名稱、業務受理範圍信息、備用業務處理單元信息和業務處理單元所在的數據中心信息等信息。當然，也可以接收各個路由組件實時發來的信息，例如：每個業務處理單元的隊列信息和狀態信息等等。服務管理組件可以根據每個業務處理單元的信息，配置每個業務處理單元應處理的待支付業務策略，即根據每個業務處理單元的實際配置情況，制定該業務處理單元應處理的待支付業務策略，也可以稱作：將不同的支付業務分配給具體哪個業務處理單元的策略。配置完成後，將策略發送至每個路由組件。路由組件根據支付業務系統接收到的待支付業務，以及從服務管理組件接收到的每個業務處理單元應處理的待支付業務策略，確定多個業務關聯繫統應該與那個業務關聯繫統交互，該確定的業務處理單元，根據與多個業務關聯繫統的交互，對待支付業務進行處理。
與現有技術相比較，本發明實施例提供的服務控制管理組件裝置，為集中式支付業務系統向分布式支付業務系統遷移提供便利性和可靠性，具有良好的橫向可伸縮性，由多個業務處理單元並行處理業務，極大地提升了業務處理容量，提高了業務處理效率，保證了業務連續運行能力，具體理由如下：
首先，由於本發明實施例提供的技術方案將配置策略集中在服務管理組件，將根據所述策略，確定處理待支付業務的業務處理單元的決策集中在路由組件，與業務處理單元交互的上層業務關聯繫統僅需進行簡單的適應性改造，即可實現分布式業務處理，為支付業務系統由集中式處理架構調整為分布式提供了便利性和可靠性，簡化了現有支付業務系統改造成本，降低了軟硬體採購成本；
另外，服務管理組件根據不同的業務處理單元的信息，配置不同策略，即根據不同的業務處理單元的軟硬體設備，分配給該業務處理單元相應處理能力的業務處理單元，這樣業務處理單元部署可靈活選用多廠商的多類型伺服器、作業系統及資料庫，支持多種類型的軟硬體平臺。
具體實施時，與業務處理單元交互的業務關聯繫統可以包括：支付報文傳輸系統(pmts)、軋差系統(nets)和業務匯總核對子系統等等，請參見附圖2以及下表1，如圖2所示，每個業務處理單元還對應一個獨立的資料庫，該資料庫可以存儲對應業務處理單元的處理過程信息等等。
在一個實施例中，業務處理單元的信息包括以下其中之一或任意組合：業務處理單元的名稱、業務處理單元待處理業務的隊列信息、業務處理單元的狀態信息、業務處理單元的業務受理範圍信息、業務處理單元的備用業務處理單元信息和業務處理單元所在數據中心的信息。
具體實施時，業務處理單元的隊列信息指的是，業務處理單元待處理的支付業務隊列信息。
在一個實施例中，業務處理單元的業務受理範圍信息包括：發起行的行號、接收行的行號和報文類型；
服務管理組件具體用於：接收每個業務處理單元的業務受理範圍信息，根據業務受理範圍信息，配置每個業務處理單元應處理待支付業務的策略，將策略發送至多個路由組件；
每個業務處理單元應處理待支付業務的策略包括：
根據報文類型和發起行的行號，配置的每個業務處理單元應處理待支付業務的策略；
或，根據報文類型和接收行的行號，配置的每個業務處理單元應處理待支付業務的策略；
或，根據報文類型，配置的每個業務處理單元應處理待支付業務的策略。
具體實施時，通過服務管理組件的ui界面管理業務處理單元及業務處理單元的各個節點信息，業務處理單元業務受理範圍劃分規則如下(即服務管理組件是如何根據每個業務處理單元的信息，配置每個業務處理單元應處理待支付業務的策略的)：
(1)根據報文類型和發起行的行號，配置的每個業務處理單元應處理待支付業務的策略，包括以下兩種情況：
①發起行主動發起的業務報文，依據報文類型和發起行行號組合作為業務劃分規則。劃分業務規則時，假設一筆網銀貸記業務由發起行banka發送給接收行bankb。則報文類型為網銀貸記業務，發起行行號為banka的業務報文由網銀業務處理單元1受理。
②由發起行發起的針對(1)類業務的業務狀態查詢/業務撤銷申請/業務明細核對申請/業務明細核對下載申請報文，需要匹配原業務，依據報文類型和發起行行號組合作為業務劃分規則。劃分業務規則時，假設一筆業務狀態查詢報文由發起行banka發送給網銀系統ibps。則報文類型為業務狀態查詢，發起行行號為banka的業務報文由網銀業務處理單元1受理。如此，可與業務處理單元1的網銀貸記業務相匹配。
(2)根據報文類型和接收行的行號，配置的每個業務處理單元應處理待支付業務的策略：
由接收行發起的針對(1)類的回執報文，需要匹配原業務，依據報文類型和接收行行號組合作為業務劃分規則。劃分業務規則時，假設一筆網銀貸記回執業務由接收行bankb發送給發起行banka。則報文類型為網銀貸記回執業務，接收行行號為banka的業務報文由網銀業務處理單元1受理。如此，可與業務處理單元1的網銀貸記業務相匹配。
(3)根據報文類型，配置的每個業務處理單元應處理待支付業務的策略：對第三方貸記及回執業務，涉及三方機構，依據報文類型作為業務劃分規則。
在一個實施例中，路由組件具體用於：
接收根據待支付業務生成的業務關鍵字信息；
根據業務關鍵字信息，以及每個業務處理單元應處理待支付業務的策略，從多個業務處理單元中確定出一個處理待支付業務的業務處理單元；
將確定出的業務處理單元的信息提供給業務關聯繫統。
下面結合圖2(在圖2中主機平臺實例、業務實例1，以及業務實例n均是本發明實施中提到的業務處理單元，圖2中業務關聯繫統的英文含義請參見下表1)，以支付業務為網銀貸記業務為例，說明本發明實施例提供的服務控制管理組件裝置如何實施的。
假設有一筆支付業務：網銀貸記業務，該網銀貸記業務為：發起行為banka，接收行為bankb，期望通過劃分業務受理範圍實現將該筆報文路由至業務處理單元1(業務實例1)處理，則採用服務控制管理組件的具體業務處理流程如下：
(1)節點及業務處理單元註冊：從服務管理組件錄入業務處理單元1(業務處理實例1)的相關信息，該錄入的功能可以通過下文提到的信息接收模塊來實現，包含業務處理單元的業務受理範圍信息(詳見下文的詳細介紹)，即由發起行banka發起網銀貸記業務、及由接收行bankb接收的網銀貸記回執業務均有業務處理單元1受理(該描述可以成為配置策略)。
(2)廣播路由信息：服務管理組件將業務處理單元1註冊後的最新路由信息(即可以包括：根據每個業務處理單元的信息，配置的每個業務處理單元應處理待支付業務的策略)廣播至所有路由組件，本發明實施例中提到的路由信息可以包括：每個業務處理單元應處理待支付業務的策略，以及下文提到的每個業務處理單元對業務關聯繫統公共消息的預訂消息(訂閱消息)等。
(3)更新共享內存區：路由組件按照同步更新機制(下文進行詳細介紹)將最新路由信息串進行解析，並更新至共享內存區(關於更新共享內存區的過程詳見下文)。
(4)業務處理：支付業務系統收到了用戶的一筆網銀貸記業務：發起行為banka，接收行為bankb，與業務處理單元交互的業務關聯繫統：支付報文傳輸系統(pmts)根據待支付業務生成的業務關鍵字信息，例如：發起行為banka，接收行為bankb，將該業務關鍵字信息發送給路由組件，路由組件根據該業務關鍵字信息，以及所述每個業務處理單元應處理待支付業務的策略，確定多個業務關聯繫統(例如：支付報文傳輸系統(pmts)、軋差系統(nets)和業務匯總核對子系統等)應該與哪個業務關聯繫統交互，從多個業務處理單元中確定出一個處理待支付業務的業務處理單元1；支付報文傳輸系統(pmts)通過查詢路由組件，了解了應該與業務處理單元1通信，根據確定出的業務處理單元1的信息，將該筆網銀貸記業務發送至確定出的業務處理單元1，業務處理單元1根據通過與業務關聯繫統(例如：支付報文傳輸系統(pmts)、軋差系統(nets)和業務匯總核對子系統等)的交互，對待支付業務進行處理。處理完成後，該業務處理單元1(例如圖2中的網銀系統ibps)會將該筆網銀貸記業務轉發至接收行bankb，緊接著，支付報文傳輸系統(pmts)收到一筆網銀貸記回執業務：發起行為bankb，接收行為banka，同上描述，通過調用路由組件進行路由，將該筆報文發送至業務處理單元1處理，正好與原網銀貸記業務在同一業務處理單元1處理，可匹配到原業務。
在一個實施例中，服務管理組件還用於接收每個業務處理單元對業務關聯繫統公共消息的預訂消息，將預訂消息發送至多個路由組件；
路由組件還用於將預訂消息提供給業務關聯繫統；
業務關聯繫統根據預訂消息，將公共消息發送至預訂了公共消息的業務處理單元。
具體實施時，通過服務管理組件的ui界面管理消息訂閱範圍，傳統的集中式的一個業務處理單元轉變為分布式的多個業務處理單元後，為解決業務關聯繫統服務間交互由一對一變為多變多後產生的公共消息發送問題，引入消息訂閱機制，即：業務關聯繫統向業務處理單元發送公共消息時，通過查詢路由組件的訂閱信息(預訂消息)，向所有已訂閱的業務處理單元廣播發送公共消息。如圖2所示，以網銀系統(ibps)實例訂閱公共控制管理系統(ccms)的系統狀態變更通知報文為例，ccms向ibps發送系統狀態變更通知報文時，先查詢路由組件的有哪些ibps實例訂閱了該報文，再逐個向訂閱了該報文的ibps實例(業務處理單元)發送報文，提高了支付業務系統的可靠性和支付效率。
在一個實施例中，如圖3所示，服務管理組件可以包括：
信息接收模塊101，用於接收每個業務處理單元的信息；
信息處理模塊102，與信息接收模塊連接，用於根據每個業務處理單元的信息，配置每個業務處理單元應處理待支付業務的策略；
第一網絡通信模塊103，用於將策略發送至多個路由組件。
具體實施時，信息接收模塊101還可以接收：
(1)訂閱信息(預訂消息，下文對該訂閱消息進行了詳細介紹)，如系統號(公共控制管理系統ccms和軋差系統nets等的系統號)、報文類型、訂閱者、訂閱範圍等。
(2)業務處理單元的節點信息，如節點名稱、所屬業務處理單元、節點ip、節點埠號、節點存活狀態(可用狀態)等，具體實施時，本發明實施例中提到的節點指的是每個業務處理單元中的每臺計算機(計算節點)，或伺服器等。
(3)參數信息，包含服務管理組件的ip地址、埠號、及可用性信息等(新增第一個實例時需要)。
下面對服務管理組件的各個模塊進行詳細介紹。
在一個實施例中，信息接收模塊具體用於：接收每個業務處理單元的變更信息；
信息處理模塊具體用於：根據每個業務處理單元的變更信息，重新配置每個業務處理單元應處理待支付業務的策略；
第一網絡通信模塊具體用於：將重新配置的每個業務處理單元應處理待支付業務的策略發送至多個路由組件。
具體實施時，業務處理單元的信息發生變更時，根據變更後的業務處理單元的信息，重新配置每個業務處理單元應處理待支付業務的策略，即進行路由消息的補發，保證了支付系統支付的可靠性。
具體實施時，業務處理單元的信息發生變更的原因可以體現為：當服務管理組件判斷業務處理單元處理待支付業務不符合預設指標值時，這時就需要根據每個業務處理單元的變更信息，重新配置每個業務處理單元應處理待支付業務的策略。
業務處理單元處理待支付業務不符合預設指標值指的是：業務處理單元的處理能力超過單個業務處理單元預設的處理能力，其衡量指標是報文響應時間和吞吐量不符合支付業務系統(例如：網銀系統ibps)的性能指標，出現處理瓶頸。舉個例子：例如對第三方貸記及回執業務，涉及三方機構，如果第三方貸記及回執業務量過大，超過了單個實例的處理能力，也無法有效解決性能問題，此時，可依據報文標識號按實例個數取模，對業務進行均衡劃分，實現真正意義上的水平可擴展，具體理由為：每個報文的報文標識號具有唯一性，按照實例個數n取模，可保證業務報文被均衡的分發至n個網銀業務實例處理，從而實現業務的均衡劃分。
上述方案也正體現了：分布式支付業務處理場景下，部署同一支付業務系統的多個業務處理單元，每個業務處理單元包含多個節點，統一對外提供一致的服務，但是業務處理單元之間有著明確的業務範圍劃分，因此，通過調整各業務處理單元的業務受理範圍，可將業務在各業務處理單元間均衡劃分，從而實現支付業務系統並發處理能力的極大提升。
在一個實施例中，信息接收模塊具體用於：接收監控系統pams發來的業務處理單元的狀態信息，以及業務處理單元各個節點的狀態信息；
信息處理模塊具體用於：根據監控系統pams發來的業務處理單元的狀態信息，以及業務處理單元各個節點的狀態信息，維護業務處理單元以及業務處理單元各個節點。
具體實施時，服務管理組件可以維護節點健康狀態，具體過程可以包括：支付應用監控系統pams定時監控節點健康狀態(即可用狀態或故障狀態等)，並將業務處理單元以及業務處理單元各個節點的存活狀態信息(即可用狀態或故障狀態信息等)發送至服務管理組件；服務管理組件根據監控的業務處理單元以及業務處理單元各個節點的狀態信息，維護業務處理單元以及業務處理單元各個節點，保證了支付業務系統支付的可靠性。
在一個實施例中，信息接收模塊具體用於：接收每個業務處理單元各個節點的可用情況信息；
信息處理模塊具體用於：根據每個業務處理單元各個節點的可用情況信息，判斷每個業務處理單元的可用情況，根據每個業務處理單元的可用情況，配置每個業務處理單元應處理待支付業務的策略；
第一網絡通信模塊具體用於：將根據每個業務處理單元的可用情況，配置的每個業務處理單元應處理待支付業務的策略發送至多個路由組件。
具體實施時，一個業務處理單元可包含多個節點，當單個業務處理單元的所有節點均不可用時，判斷該業務處理單元為不可用；反之，若單個業務處理單元有一個及以上節點可用時，判斷業務處理單元為可用，根據每個業務處理單元的可用情況，配置每個業務處理單元應處理待支付業務的策略，保證了支付業務系統支付的可靠性。
在一個實施例中，服務管理組件具體用於：接收每個業務處理單元及其備用業務處理單元的信息，根據每個業務處理單元及其備用業務處理單元的信息，配置每個業務處理單元應處理待支付業務的策略，將策略發送至多個路由組件。
具體實施時，分布式支付業務系統的每個業務處理單元都設置一個備用業務處理單元，服務管理組件在配置策略時，將業務處理單元的備用業務處理單元信息也考慮在內，在業務處理單元出現故障或不可用時，利用該業務處理單元的備用業務處理單元進行業務處理，這樣實例(業務處理單元)間通過互為備份可實現業務自動接管，從而提供更高的業務連續運行能力，降低了單實例節點的可靠性要求，例如：由於每個業務處理單元都設置一個備用業務處理單元，因此，在配置業務處理單元時，可以選用配置相對低，價格相對便宜的伺服器等，業務處理單元部署可選用多廠商多類型的伺服器、作業系統及資料庫，支持多種類型的軟硬體平臺等。
在一個實施例中，路由組件200可以包括：路由接口201、第二網絡通信模塊202、信息更新模塊203和共享內存區204，其中：
第二網絡通信模塊202，與服務管理組件連接，用於接收每個業務處理單元應處理待支付業務的策略；
信息更新模塊203，用於將每個業務處理單元應處理待支付業務的策略更新至共享內存區204，根據策略，以及支付業務系統接收的待支付業務，從多個業務處理單元中確定出一個處理待支付業務的業務處理單元；
路由接口201，用於連接與業務處理單元交互的業務關聯繫統和信息更新模塊203，將確定出的業務處理單元的信息提供給業務關聯繫統。
具體實施時，與路由接口201連接的業務關聯繫統包括如下表1所示的業務關聯繫統(調用方)，下表1中也示出了路由接口201具體包括哪些類型的接口、功能及與之連接的業務關聯繫統。
表1
在一個實施例中，共享內存區可以包括：主共享內存區和備共享內存區；
信息更新模塊具體用於：
將每個業務處理單元應處理待支付業務的策略更新至備共享內存區；
將所述備共享內存區變更為主共享內存區，將原主共享內存區變更為備共享內存區；
根據變更後主共享內存區內的策略，以及支付業務系統接收的待支付業務，從多個業務處理單元中確定出一個處理待支付業務的業務處理單元。
具體實施時，信息更新模塊203先將每個業務處理單元應處理待支付業務的策略更新至備共享內存區，然後進行主備切換：將備共享內存區更換為主共享內存區，將原主共享內存區更換為備共享內存區，確保了路由信息(包括業務處理單元應處理待支付業務的策略)在多個路由組件的同步更新，保證業務處理正確性與一致性。
服務管理組件對處理支付業務的業務處理單元信息進行管理和存儲，並將變更後的路由信息組織為消息串發送給所有的消息路由組件，為保證多個節點間路由信息的同步更新與啟用，服務管理組件採用四階段同步生效機制，以保證廣播的路由信息同步更新至所有路由組件，本發明實施例中，路由消息可以包括：預訂的公共消息(訂閱消息)、策略等等。下面結合圖4，對這四階段同步生效機制進行詳細介紹。
在一個實施例中，路由組件具體用於將每個業務處理單元應處理待支付業務的策略存儲在共享內存區，供業務關聯繫統調用；共享內存區包括：主共享內存區和備共享內存區；
服務管理組件具體用於：
將每個業務處理單元應處理待支付業務的策略發送至各個路由組件，接收各個路由組件發來的策略已更新至備共享內存區的響應信息；
將路由組件共享內存區加鎖通知信息發送至各個路由組件，接收各個路由組件發來的路由組件共享內存區加鎖完畢響應信息；
將路由組件主備內存切換信息發送至各個路由組件，接收各個路由組件發來的路由組件主備內存切換完畢響應信息；
將路由組件共享內存區解鎖通知信息發送至各個路由組件，接收各個路由組件發來的路由組件共享內存區解鎖完畢響應信息；
路由組件具體用於：
接收服務管理組件發來的每個業務處理單元應處理待支付業務的策略，將策略更新至備共享內存區，發送策略已更新至備共享內存區的響應信息至服務管理組件；
接收服務管理組件發來的路由組件共享內存區加鎖通知信息，對共享內存區進行加鎖，將路由組件共享內存區加鎖完畢響應信息發送至服務管理組件；
接收服務管理組件發來的路由組件主備內存切換信息，將原備共享內存區變更為主共享內存區，將原主共享內存區變更為備共享內存區，將路由組件主備內存切換完畢響應信息發送至服務管理組件；
接收路由組件共享內存區解鎖通知信息，對共享內存區進行解鎖，將路由組件共享內存區解鎖完畢響應信息發送至服務管理組件。
下面結合圖4，舉個例子以說明本發明實施例提供的四階段同步生效機制如何實施。
(1)一階段：服務管理組件組織「路由變更預通知報文」(包括每個業務處理單元應處理待支付業務的策略)並廣播至各個路由組件，路由組件收到「路由變更預通知報文」後，嘗試更新備用共享內存區，並依據更新狀態組織「路由變更預響應報文」(包括：策略已更新至備共享內存區的響應信息)回復至服務管理組件。
服務管理組件收到各個路由組件反饋的「路由變更預響應報文」後，確認是否所有的路由組件均已成功更新備用內存區。如果是，則進入(2)二階段。否則，轉至1a)。
1a)記錄錯誤日誌，轉入人工處理，查看問題原因。
(2)二階段：服務管理組件組織「路由變更加鎖通知報文」(包括：路由組件共享內存區加鎖通知信息)並廣播至各個路由組件，路由組件收到「路由變更加鎖通知報文」後，嘗試對主共享內存區和備共享內存區加鎖，加鎖成功後業務系統無法訪問路由組件，處於鎖等待狀態，並依據加鎖狀態組織「路由變更加鎖響應報文」(包括：路由組件共享內存區加鎖完畢響應信息)回復至服務管理組件。
服務管理組件收到各個路由組件反饋的「路由變更加鎖響應報文」後，確認是否所有的路由組件均已成功對共享內存加鎖。如果是，則進入(3)三階段；否則，轉至2a)。
2a)記錄錯誤日誌，轉至人工處理，查看問題原因。
(3)三階段：服務管理組件組織「路由變更切換通知報文」(包括：路由組件主備內存切換信息)並廣播至各個路由組件，路由組件收到「路由變更切換通知報文」後，嘗試切換共享內存區的主備標識(即將原備共享內存區變更為主共享內存區，將原主共享內存區變更為備共享內存區)，並依據切換狀態組織「路由變更切換響應報文」(包括：路由組件主備內存切換完畢響應信息)回復至服務管理組件。
服務管理組件收到各個路由組件反饋的「路由變更切換響應報文」(包括：路由組件主備內存切換完畢響應信息)後，確認是否所有的路由組件均已成功對完成主備內存的切換。如果是，則進入(4)四階段；否則，轉至3a)。
3a)進入(4)四階段。
(4)四階段：服務管理組件組織「路由變解鎖通知報文」(包括：路由組件共享內存區解鎖通知信息)並廣播至各個路由組件，路由組件收到「路由變更解鎖通知報文」後，嘗試對主共享內存區和備共享內存區解鎖，解鎖成功後支付業務系統繼續進行，並依據解鎖狀態組織「路由變更解鎖響應報文」回復至服務管理組件。
服務管理組件收到各個路由組件反饋的「路由變更解鎖響應報文」(包括：路由組件共享內存區解鎖完畢響應信息)後，確認是否所有的路由組件均已成功解鎖共享內存。如果是，則路由變更信息廣播已成功；否則，轉至4a)。
4a)記錄錯誤日誌，轉至人工處理。
具體實施時，上述四階段的消息同步機制中，在進行主備內存切換時，即：將原備共享內存區變更為主共享內存區，將原主共享內存區變更為備共享內存區時，進行加鎖和解鎖的過程原因是：主共享內存區供路由決策使用，即各個業務關聯繫統調用路由組件的存儲信息時，是調用主共享內存區的存儲內容，更新共享內存和路由決策是兩個異步的過程，分屬不同的進程，因此會涉及到對共享區的互斥讀寫。因此，在進行主備內存切換時，對主共享內存區和備共享內存區進行加鎖，加鎖成功後各個業務關聯繫統無法訪問路由組件，處於鎖等待狀態，待主備內存切換完畢時，各個業務關聯繫統可以訪問路由組件，保證了各個業務關聯繫統調用路由消息(包括策略和訂閱消息)的準確性，即保證了支付業務系統處理支付業務的可靠性。
另外，服務管理組件也可以根據上述四階段的消息同步機制，將上述預訂的公共消息(訂閱消息)發送至各個路由組件，與路由組件進行通信。
本發明實施例實現了如下技術效果：本發明通過構建服務控制管理組件裝置，支持支付業務系統由集中式應用處理架構調整為分布式架構，具有良好的橫向可伸縮性，由多個業務處理單元並行處理支付業務，極大地提升了支付業務處理容量，提高了支付業務的處理效率，保證了支付業務的連續運行能力，同時簡化了現有支付業務系統改造，降低了軟硬體採購成本。
顯然，本領域的技術人員應該明白，上述的本發明實施例的各模塊或各步驟可以用通用的計算裝置來實現，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網絡上，可選地，它們可以用計算裝置可執行的程序代碼來實現，從而，可以將它們存儲在存儲裝置中由計算裝置來執行，並且在某些情況下，可以以不同於此處的順序執行所示出或描述的步驟，或者將它們分別製作成各個集成電路模塊，或者將它們中的多個模塊或步驟製作成單個集成電路模塊來實現。這樣，本發明實施例不限制於任何特定的硬體和軟體結合。
以上所述僅為本發明的優選實施例而已，並不用於限制本發明，對於本領域的技術人員來說，本發明實施例可以有各種更改和變化。凡在本發明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發明的保護範圍之內。