鑒於上述問題，本公開提供了一種支付防抖方法及裝置。利用該方法及裝置，對於本次支付從發現系統出現抖動時起的業務請求到最後一次業務請求均返回模擬的正常結果，具有支付鏈路多階段防抖能力，減少系統抖動對業務帶來的影響以及業務損失。
根據本公開的一個態樣，提供了一種支付防抖方法，包括：攔截客戶端在支付過程中發送到服務端的當前業務請求，所述當前業務請求至少包括唯一階段標識，其中，所述支付過程包括多個支付階段，以及所述唯一階段標識用於唯一標識所述當前業務請求所對應的支付階段；基於與所述當前業務請求對應的防抖標記，確定針對所述當前業務請求的遠端業務調用是否異常；在針對所述當前業務請求的遠端業務調用被確定為異常時，產生兜底處理結果，所述兜底處理結果至少包括與所述唯一階段標識所標識的支付階段對應的模擬正常結果；以及將所述兜底處理結果發送給所述客戶端。
可選地，在上述態樣的一個示例中，基於與所述當前業務請求對應的防抖標記，確定針對當前業務請求的遠端業務調用是否異常包括：在所述防抖標記的標記值指示遠端業務調用異常時，確定針對當前業務請求的遠端業務調用異常。
可選地，在上述態樣的一個示例中，基於與所述當前業務請求對應的防抖標記，確定針對所述當前業務請求的遠端業務調用是否異常包括：在所述防抖標記的標記值指示遠端業務調用正常時，根據所述當前業務請求執行遠端業務調用；以及基於所述遠端業務調用的返回結果是否異常，確定針對所述當前業務請求的遠端業務調用是否異常。
可選地，在上述態樣的一個示例中，所述支付防抖方法還包括：在所述遠端業務調用的返回結果異常時，為所述防抖標記賦予用於指示遠端業務調用異常的標記值並包括在所述兜底處理結果中。
可選地，在上述態樣的一個示例中，在所述遠端業務調用的返回結果異常時，為所述防抖標記賦予用於指示遠端業務調用異常的標記值包括：在確定針對所述當前業務請求的遠端業務調用異常時，識別所述遠端業務調用異常是否為能夠進行兜底處理的異常；以及在識別出所述遠端業務調用異常是能夠進行兜底處理的異常時，為所述防抖標記賦予用於指示遠端業務調用異常的標記值並包括在所述兜底處理結果中。
可選地，在上述態樣的一個示例中，在所述當前業務請求是首次業務請求時，所述防抖標記是在攔截到所述當前業務請求後創建的，或者在所述當前業務請求是非首次業務請求時，所述防抖標記是上一業務請求處理過程所返回的防抖標記。
可選地，在上述態樣的一個示例中，在所述當前業務請求是首次業務請求時，透過下述過程來為所述當前業務請求創建防抖標記：在攔截到所述當前業務請求後，解析所攔截的當前業務請求，以確定所述當前業務請求所屬的業務類型；在所確定的業務類型屬於需要防抖處理的業務類型時，為所述當前業務請求創建所述防抖標記。
可選地，在上述態樣的一個示例中，所述需要防抖處理的業務類型包括線下收錢碼支付業務。
可選地，在上述態樣的一個示例中，在所述當前業務請求是所述支付過程的最後業務請求時，所述方法還包括：在將所述兜底處理結果發送給所述客戶端後，根據與所述支付過程對應的支付資訊，從墊支帳戶中支付相應數目的支付款給賣家。
可選地，在上述態樣的一個示例中，所述支付防抖方法還包括：回應於從墊支帳戶中支付相應數目的支付款給賣家，通知所述賣家相應數目的支付款已到帳。
根據本公開的另一態樣，提供一種支付防抖裝置，包括：攔截單元，被配置為攔截客戶端在支付過程中發送到服務端的當前業務請求，所述當前業務請求至少包括唯一階段標識，其中，所述支付過程包括多個支付階段，以及所述唯一階段標識用於唯一標識所述當前業務請求所對應的支付階段；異常確定單元，被配置為基於與所述當前業務請求對應的防抖標記，確定針對所述當前業務請求的遠端業務調用是否異常；兜底處理單元，被配置為在針對所述當前業務請求的遠端業務調用被確定為異常時，產生兜底處理結果，所述兜底處理結果至少包括與所述唯一階段標識所標識的支付階段對應的模擬正常結果；以及發送單元，被配置為將所述兜底處理結果發送給所述客戶端。
可選地，在上述態樣的一個示例中，所述異常確定單元進一步被配置為：在所述防抖標記的標記值指示遠端業務調用異常時，確定針對當前業務請求的遠端業務調用異常。
可選地，在上述態樣的一個示例中，所述支付防抖裝置還包括：業務調用單元，被配置為在所述防抖標記的標記值指示遠端業務調用正常時，根據所述當前業務請求執行遠端業務調用，其中，所述異常確定單元還被配置為：基於所述遠端業務調用的返回結果是否異常，確定針對所述當前業務請求的遠端業務調用是否異常。
可選地，在上述態樣的一個示例中，所述支付防抖裝置還包括：標記值調整單元，被配置為在所述遠端業務調用的返回結果異常時，為所述防抖標記賦予用於指示遠端業務調用異常的標記值並包括在所述兜底處理結果中。
可選地，在上述態樣的一個示例中，所述支付防抖裝置還包括：異常識別單元，被配置為在所述遠端業務調用的返回結果異常時，識別所述遠端業務調用異常是否為能夠進行兜底處理的異常，其中，所述標記值調整單元還被配置為在識別出所述遠端業務調用異常是能夠進行兜底處理的異常時，為所述防抖標記賦予用於指示遠端業務調用異常的標記值並包括在所述兜底處理結果中。
可選地，在上述態樣的一個示例中，所述支付防抖裝置還包括：防抖標記創建單元，被配置為在所述當前業務請求是首次業務請求時，在攔截到所述當前業務請求後為所述當前業務請求創建所述防抖標記。
可選地，在上述態樣的一個示例中，所述支付防抖裝置還包括：業務類型確定單元，被配置為在所述當前業務請求是首次業務請求時，在攔截到所述當前業務請求後，解析所攔截的當前業務請求，以確定所述當前業務請求所屬的業務類型，其中，所述防抖標記創建單元還被配置為在所確定的業務類型屬於需要防抖處理的業務類型時，為所述當前業務請求創建所述防抖標記。
根據本公開的又一態樣，提供一種計算設備，包括：一個或多個處理器，以及與所述一個或多個處理器耦合的記憶體，所述記憶體儲存指令，當所述指令被所述一個或多個處理器執行時，使得所述一個或多個處理器執行如上所述的支付防抖方法。
根據本公開的再一態樣，提供一種非暫時性機器可讀儲存媒體，其儲存有可執行指令，所述指令當被執行時使得所述機器執行如上所述的支付防抖方法。
利用本公開的方法和裝置，在目前網際網路規模以及複雜的企業級分散式架構體系下，為未來核心業務場景達到99.999%甚至更高的可用率目標提供高可用架構層面的保障，保障金融級別的穩定性，降低系統故障造成的公眾影響，減少商戶收款損失。
利用本公開的方法和裝置，從通用高可用架構層面減少系統抖動、故障對核心業務帶來的影響以及業務損失，提升整體業務鏈路的成功率，同時提升使用者體驗。
利用本公開的方法和裝置，從端的視角重新審視業務鏈路，透過解耦、異構、非同步化等思路可以反哺優化日常的業務鏈路，甚至可以對於一些業務場景升級為常態整體非同步化的能力。In view of the above problems, the present disclosure provides a method and device for anti-shake payment. Using the method and device, for this payment, the normal result of the simulation is returned from the service request from the time when the system is found to be jittered to the last service request. It has the multi-stage anti-shake capability of the payment link and reduces the impact of system jitter on the business. Impact and business loss.
According to one aspect of the present disclosure, a method for anti-shake payment is provided, including: intercepting a current business request sent by a client to a server during a payment process, the current business request at least including a unique stage identifier, wherein the payment process It includes multiple payment stages, and the unique stage identifier is used to uniquely identify the payment stage corresponding to the current service request; based on the anti-shake flag corresponding to the current service request, determine the remote end of the current service request Whether the service call is abnormal; when the remote service call for the current service request is determined to be abnormal, a bottom processing result is generated, and the bottom processing result includes at least the simulated normal corresponding to the payment phase identified by the unique phase identifier Result; and sending the bottom processing result to the client.
Optionally, in an example of the above aspect, based on the anti-shake flag corresponding to the current service request, determining whether the remote service call for the current service request is abnormal includes: indicating the flag value of the anti-shake flag When the remote service call is abnormal, the remote service call for the current service request is determined to be abnormal.
Optionally, in an example of the foregoing aspect, determining whether the remote service call for the current service request is abnormal based on the anti-shake flag corresponding to the current service request includes: The value indicates that when the remote service call is normal, execute the remote service call according to the current service request; and determine whether the remote service call for the current service request is abnormal based on whether the return result of the remote service call is abnormal.
Optionally, in an example of the above aspect, the payment anti-shake method further includes: when the return result of the remote service call is abnormal, assigning the anti-shake flag to indicate that the remote service call is abnormal The tag value of is included in the bottom processing result.
Optionally, in an example of the foregoing aspect, when the return result of the remote service call is abnormal, assigning the anti-shake flag with a flag value indicating the abnormality of the remote service call includes: When the remote service invocation of the current service request is abnormal, identifying whether the remote service invocation abnormality is an abnormality that can be handled under the hood; and when it is recognized that the remote service invocation exception is an anomaly that can be handled under the circumstance, The anti-shake flag is assigned a flag value for indicating abnormal remote service invocation and is included in the bottom processing result.
Optionally, in an example of the above aspect, when the current service request is the first service request, the anti-shake flag is created after intercepting the current service request, or when the current service request is When it is a non-first service request, the anti-shake mark is the anti-shake mark returned in the previous service request processing process.
Optionally, in an example of the above aspect, when the current service request is the first service request, an anti-shake flag is created for the current service request through the following process: after intercepting the current service request Analyze the intercepted current service request to determine the service type to which the current service request belongs; when the determined service type belongs to the service type requiring anti-shake processing, create the anti-shake flag for the current service request.
Optionally, in an example of the above aspect, the service type that requires anti-shake processing includes an offline payment code payment service.
Optionally, in an example of the above aspect, when the current service request is the last service request of the payment process, the method further includes: after sending the bottom processing result to the client , According to the payment information corresponding to the payment process, pay a corresponding amount of payment to the seller from the advance account.
Optionally, in an example of the above aspect, the payment anti-shake method further includes: in response to paying a corresponding amount of payment from the advance account to the seller, notifying the seller that the corresponding amount of payment has arrived.
According to another aspect of the present disclosure, a payment anti-shake device is provided, including: an interception unit configured to intercept a current service request sent by a client to a server during a payment process, the current service request at least including a unique stage identifier, Wherein, the payment process includes multiple payment stages, and the unique stage identifier is used to uniquely identify the payment stage corresponding to the current service request; the abnormality determination unit is configured to be based on the protection corresponding to the current service request. The jitter flag determines whether the remote service call for the current service request is abnormal; the bottom processing unit is configured to generate a bottom processing result when the remote service call for the current service request is determined to be abnormal. The bottom line processing result includes at least a simulated normal result corresponding to the payment phase identified by the unique stage identifier; and a sending unit configured to send the bottom line process result to the client.
Optionally, in an example of the above aspect, the abnormality determining unit is further configured to determine the remote service call for the current service request when the flag value of the anti-shake flag indicates that the remote service call is abnormal abnormal.
Optionally, in an example of the above aspect, the payment anti-shake device further includes: a service invocation unit configured to, when the flag value of the anti-shake flag indicates that the remote service invocation is normal, according to the current The service request executes a remote service call, wherein the abnormality determining unit is further configured to determine whether the remote service call for the current service request is abnormal based on whether the returned result of the remote service call is abnormal.
Optionally, in an example of the above aspect, the payment anti-shake device further includes: a mark value adjustment unit configured to give the anti-shake mark when the return result of the remote service call is abnormal The tag value used to indicate the abnormality of the remote service call is included in the bottom processing result.
Optionally, in an example of the above aspect, the payment anti-shake device further includes: an abnormality recognition unit configured to recognize that the remote service call is abnormal when the return result of the remote service call is abnormal Whether it is an abnormality that can be processed under the bag, wherein the mark value adjustment unit is further configured to, when it is recognized that the remote service invocation abnormality is an abnormality that can be processed under the bag, give the anti-shake mark to indicate The remote service calls the abnormal tag value and includes it in the bottom processing result.
Optionally, in an example of the above aspect, the payment anti-shake device further includes: an anti-shake mark creation unit configured to intercept the current service when the current service request is the first service request Create the anti-shake flag for the current service request after the request.
Optionally, in an example of the above aspect, the payment anti-shake device further includes: a service type determining unit configured to intercept the current service request when the current service request is the first service request Then, the intercepted current service request is parsed to determine the service type to which the current service request belongs, wherein the anti-shake mark creation unit is further configured to when the determined service type belongs to the service type that requires anti-shake processing To create the anti-shake mark for the current service request.
According to another aspect of the present disclosure, there is provided a computing device, including: one or more processors, and a memory coupled with the one or more processors, the memory storing instructions, when the instructions are When the one or more processors are executed, the one or more processors are caused to execute the payment anti-shake method described above.
According to another aspect of the present disclosure, a non-transitory machine-readable storage medium is provided, which stores executable instructions that, when executed, cause the machine to execute the above-mentioned payment anti-shake method.
Using the method and device of the present disclosure, under the current Internet scale and complex enterprise-level distributed architecture system, it can provide high-availability architecture guarantee for future core business scenarios to reach the availability target of 99.999% or even higher, and guarantee financial The level of stability reduces the public impact caused by system failures and reduces the loss of merchants' collection.
Using the method and device of the present disclosure, the impact of system jitter and failure on core services and business losses from the general high-availability architecture level are reduced, the success rate of the overall business link is improved, and the user experience is improved.
Using the method and device of the present disclosure, the business link can be re-examined from the perspective of the end, and the daily business link can be optimized through decoupling, heterogeneous, asynchronous and other ideas, and even some business scenarios can be upgraded to normal and overall asynchronous Capacity.
現在將參考示例實施方式討論本文描述的主題。應該理解，討論這些實施方式只是為了使得本領域技術人員能夠更好地理解從而實現本文描述的主題，並非是對申請專利範圍中所闡述的保護範圍、適用性或者示例的限制。可以在不脫離本公開內容的保護範圍的情況下，對所討論的元素的功能和排列進行改變。各個示例可以根據需要，省略、替代或者添加各種過程或組件。例如，所描述的方法可以按照與所描述的順序不同的順序來執行，以及各個步驟可以被添加、省略或者組合。另外，相對一些示例所描述的特徵在其它例子中也可以進行組合。
如本文中使用的，術語“包括”及其變型表示開放的術語，含義是“包括但不限於”。術語“基於”表示“至少部分地基於”。術語“一個實施例”和“一實施例”表示“至少一個實施例”。術語“另一個實施例”表示“至少一個其他實施例”。術語“第一”、“第二”等可以指代不同的或相同的物件。下面可以包括其他的定義，無論是明確的還是隱含的。除非上下文中明確地指明，否則一個術語的定義在整個說明書中是一致的。
一次支付過程包括一個支付階段或多個支付階段，本公開主要針對包括多階段的支付業務。可以將客戶端發起一次業務請求至下一次業務請求看作一個階段或者將客戶端發起一次業務請求至客戶端顯示支付完成看作一個階段。例如，對於線下收錢碼支付業務，如圖1所示，客戶端掃賣家的收錢碼為第一次業務請求，從客戶端發起第一次業務請求至客戶端顯示服務端返回的付款金額輸入框為創建交易號的階段110；使用者向客戶端顯示的付款金額輸入框輸入支付的錢數後確認提交為第二次業務請求，從客戶端發起第二次業務請求到客戶端顯示服務端返回的支付方式選項和支付密碼輸入框為拉起收銀台的階段120；使用者透過客戶端選擇支付方式並輸入支付密碼後確認提交則為第三次業務請求，從客戶端發起第三次業務請求至客戶端顯示服務端返回的“正在支付”的通知為提交支付的階段130；發起的第四次業務請求調用輪詢，查詢訂單的交易狀態，如果交易成功，則客戶端收到“付款成功”的通知，因此第四階段為輪詢支付結果的階段140。可見，線下收錢碼支付業務包括上述四個階段。
因為服務端的分散式系統業務鏈路較長，比較容易發生抖動，所以為了避免支付過程因抖動而中斷或出現錯誤，對於某次業務請求一旦服務端進行遠端調用發生異常則對這次業務請求及其後各次業務請求均進行兜底處理。根據遠端調用返回結果的錯誤碼、異常和/或業務參數等識別業務抖動，對業務抖動進行兜底處理，返回模擬結果，記錄兜底流水。可以根據兜底的流水觸發非同步恢復流程，從墊支帳戶打款給賣家。
圖2示出了本公開實施例1提供的支付防抖方法的流程圖，該過程可以由支付防抖裝置執行。實施例1主要考慮支付過程中一次業務請求的處理。
如圖2所示，在區塊210中，攔截客戶端在支付過程中發送到服務端的當前業務請求，當前業務請求至少包括唯一階段標識，其中，支付過程包括多個支付階段，以及唯一階段標識用於唯一標識當前業務請求所對應的支付階段。
可以透過AOP攔截客戶端發送到服務端的當前業務請求，其中，AOP為Aspect Oriented Programming的縮寫，意為面向導向編程，是透過預編譯方式和運行期動態代理實現程式功能的統一維護的一種技術。AOP可以理解為一個攔截器框架，但是這個攔截器會非常武斷，如果它攔截一個類，那麼它就會攔截這個類中的所有方法。
在區塊220中，基於與當前業務請求對應的防抖標記，確定針對當前業務請求的遠端業務調用是否異常。作為該實施例的一態樣，對於非首次業務請求所帶的防抖標記的標記值為異常的情況，確定針對當前業務請求的遠端業務調用為異常。對於在首次業務請求處理期間創建的防抖標記並且防抖標記的標記值為空的情況，以及非首次業務請求所帶的防抖標記的標記值為正常的情況，都確定針對當前業務請求的遠端業務調用為正常。
在區塊230中，當針對當前業務請求的遠端業務調用被確定為異常時，產生兜底處理結果，兜底處理結果至少包括與唯一階段標識所標識的支付階段對應的模擬正常結果。
在區塊240中，將兜底處理結果發送給客戶端。因此，從客戶端看到的返回結果都是模擬的正常結果。
圖3為在當前業務請求為支付過程的首次業務請求時的支付防抖方法的示例。
在區塊310中，支付防抖裝置攔截客戶端在支付過程中發送到服務端的首次業務請求，首次業務請求至少包括唯一階段標識。
在區塊320中，解析所攔截的首次業務請求，以確定首次業務請求所屬的業務類型。
在區塊330中，在所確定的業務類型屬於需要防抖處理的業務類型時，為首次業務請求創建防抖標記，防抖標記用於指示本次支付業務是需要防抖處理的業務。在本公開的一個示例中，需要防抖處理的業務類型可以包括線下收錢碼支付業務。防抖標記例如為appfuse_type。因為服務端為分散式系統，所以對業務請求進行處理需要進行遠端業務調用。防抖標記的標記值用於指示遠端業務調用是正常還是異常，異常指遠端業務調用的鏈路發生抖動。防抖標記的標記值例如為normal或shake，其中shake代表抖動，normal表示正常，即沒發生抖動。
在區塊340中，根據首次業務請求進行遠端業務調用。這裡可以由支付防抖裝置作為上游系統向服務端的下游系統進行遠端業務調用，作為替換方式，也可以由支付防抖裝置指示服務端的上游系統向下游系統進行遠端業務調用。
在區塊350中，基於遠端業務調用返回的調用結果，確定針對首次業務請求的遠端業務調用是否異常。如果遠端業務調用返回的調用結果異常，則確定針對首次業務請求的遠端業務調用異常，流程進行到區塊360。如果遠端業務調用返回的調用結果正常，則確定針對首次業務請求的遠端業務調用正常，流程進行到區塊380。
在區塊360中，為防抖標記賦予用於指示遠端業務調用異常的標記值，比如shake，基於與唯一階段標識所標識的支付階段對應的模擬正常結果和防抖標記產生兜底處理結果。與唯一階段標識所標識的支付階段對應的模擬正常結果保存在支付防抖裝置的記憶體中，支付防抖裝置解析所攔截的業務請求，根據解析出來的唯一階段標識在其記憶體中找到對應的模擬正常結果，從而產生兜底處理結果。流程進行到區塊370。
在區塊370中，將兜底處理結果發送給客戶端。因此，從客戶端看到的返回結果都是模擬的正常結果。
在區塊380中，為防抖標記賦予用於指示遠端業務調用正常的標記值，比如normal，基於遠端業務調用返回的調用結果和防抖標記產生正常處理結果。因此，正常處理結果包括遠端業務調用返回的調用結果中的資訊和防抖標記。流程進行到區塊390。
在區塊390中，將正常處理結果發送給客戶端。
圖4為當前業務請求為支付過程的非首次業務請求時的支付防抖方法的示例。
在區塊400中，支付防抖裝置攔截客戶端在支付過程中發送到服務端的非首次業務請求，非首次業務請求至少包括唯一階段標識和防抖標記。其中，防抖標記是上一業務請求處理過程所返回的防抖標記。
在區塊410中，判斷非首次業務請求所包括的防抖標記的標記值指示遠端業務調用是否異常。如果防抖標記的標記值指示遠端業務調用異常，則確定針對非首次業務請求的遠端業務調用異常，流程進行到區塊420。如果防抖標記的標記值指示遠端業務調用正常，則流程進行到區塊440。
在區塊420中，產生兜底處理結果，兜底處理結果包括與唯一階段標識所標識的支付階段對應的模擬正常結果和防抖標記，防抖標記具有用於指示遠端業務調用異常的標記值，比如shake。流程進行到區塊430。
在區塊430中，將兜底處理結果發送給客戶端。因此，從客戶端看到的返回結果都是模擬的正常結果。圖5為一個示例提供的從客戶端看到的支付的中間階段返回的模擬正常結果的示意圖。圖6為圖5所示的支付示例的最後階段返回的模擬正常結果的示意圖。
在區塊440中，根據非首次業務請求進行遠端業務調用。流程進行到區塊450。
在區塊450中，基於遠端業務調用返回的調用結果是否異常，確定針對非首次業務請求的遠端業務調用是否異常。如果調用結果異常比如SYSTEM_ERROR時，則確定遠端業務調用異常，流程進行到區塊460。如果調用結果正常，則確定遠端業務調用正常，流程進行到區塊480。
在區塊460中，為防抖標記賦予用於指示遠端業務調用異常的標記值，比如shake，基於與唯一階段標識所標識的支付階段對應的模擬正常結果和防抖標記產生兜底處理結果。流程進行到區塊470。
在區塊470中，將兜底處理結果發送給客戶端。
在區塊480中，產生正常處理結果，正常處理結果包括遠端業務調用返回的調用結果中的資訊和防抖標記，防抖標記具有用於指示遠端業務調用正常的標記值，比如normal。流程進行到區塊490。
在區塊490中，將正常處理結果發送給客戶端。
作為一個可選實施例，在圖3的區塊360和/或圖4的區塊460中為防抖標記賦予用於指示遠端業務調用異常的標記值之前，該實施例的支付防抖方法還可以包括抖動識別步驟。抖動識別步驟可以包括：識別遠端業務調用異常是否為能夠進行兜底處理的異常，在識別出遠端業務調用異常是能夠進行兜底處理的異常時，為防抖標記賦予用於指示遠端業務調用異常的標記值並包括在兜底處理結果中。
如果當前的業務請求包括支付資訊，支付防抖裝置可以記錄業務請求中的支付資訊和多階段上下文的狀態快取。支付資訊可以包括訂單金額、付款帳戶、以及收款帳戶等資訊，根據支付資訊產生訂單，訂單可以包括流水號。此外，與支付過程對應的支付資訊還可以來自服務端。記錄支付資訊以便於在同步兜底處理之後進行防抖非同步恢復。多階段上下文的狀態快取是多階段狀態中防抖需要用到的資訊。作為一個可選實施例，在當前業務請求是支付過程的最後業務請求時，該實施例的支付防抖方法還可以包括：在將兜底處理結果發送給客戶端後，根據與支付過程對應的支付資訊，從墊支帳戶中支付相應數目的支付款給賣家。從墊支帳戶中支付相應數目的支付款給賣家的過程可以稱為非同步恢復流程，因為這個過程是以非同步恢復方式完成的。在從墊支帳戶中支付相應數目的支付款給賣家之前，該實施例的支付防抖方法還可以包括：回應於從墊支帳戶中支付相應數目的支付款給賣家，通知賣家相應數目的支付款已到帳。通知賣家可以採用語音播報、簡訊通知、或者其他任何現有的方式。
在同步兜底處理之後，非同步恢復流程可以透過即時、定時、或者手動等方式觸發。其中，非同步恢復的過程與前述業務請求的處理過程在分散式系統中經由的鏈路大概率是不同的鏈路，也有可能是相同的鏈路。通常非同步恢復流程是以即時方式觸發，大約從通知賣家支付款已到帳時起的例如1～2秒鐘後從墊支帳戶打相應數目的支付款到賣家的帳戶。在極少數情況下，如果以即時方式觸發非同步恢復流程時系統仍然有故障，則可以定時方式從通知賣家支付款已到帳時起經過預設時長後從墊支帳戶打支付款到賣家的帳戶。在極特殊情況下，如果以定時方式觸發非同步恢復流程時系統仍然有故障，則可以人工介入以手動方式從墊支帳戶打支付款到賣家的帳戶。
整個支付過程對使用者而言是有體感的，看到的是免單優惠，如圖5和圖6所示，對賣家而言是無感知的，使用者支付完成後，同步地使賣家收到語音播報或簡訊通知等，而在資金處理方面需要在防抖非同步恢復的時候從支付墊資帳戶打款給賣家，而買家帳戶沒有資金變動而且可以事後從買家帳戶追款或者不從買家帳戶追款。
圖7為本公開實施例2提供的支付防抖方法的整個支付過程的流程圖，實施例2以本次支付過程包括3個階段為例。其中，支付防抖裝置為承擔防抖能力的基礎功能模組，支付防抖裝置可以是接入服務端中的組件，也可以是客戶端和服務端之間的獨立裝置。
如圖7所示，在700，支付防抖裝置攔截客戶端在支付過程中發送到服務端的第一次業務請求，第一次業務請求包括唯一階段標識，其中，唯一階段標識用於唯一標識當前業務請求所對應的第一支付階段。
在705，為第一次業務請求創建防抖標記，比如appfuse_type，以標識本次支付為需要防抖的業務。
在710，根據第一次業務請求進行遠端業務調用。
在715，基於遠端業務調用返回的調用結果是否異常，確定針對第一次業務請求的遠端業務調用是否異常。在確定遠端業務調用正常時，為防抖標記賦予用於指示遠端業務調用正常的標記值，比如normal，基於遠端業務調用返回的調用結果和防抖標記產生正常處理結果。
在720，將正常處理結果發送給客戶端。
在725，支付防抖裝置攔截客戶端在支付過程中發送到服務端的第二次業務請求，第二次業務請求包括唯一階段標識和防抖標記，其中，唯一階段標識用於唯一標識當前業務請求所對應的第二支付階段，防抖標記具有用於指示遠端業務調用正常的標記值，比如normal。
在730，根據第二次業務請求進行遠端業務調用。
在735，基於遠端業務調用返回的調用結果異常，確定針對第二次業務請求的遠端業務調用異常。
在740，在確定遠端業務調用異常時，識別遠端業務調用異常是否為能夠進行兜底處理的異常，即識別返回的調用結果的錯誤碼是否在兜底的範圍內，如果在兜底範圍內則進行兜底處理。
在745，在識別出異常為能夠進行兜底處理的異常時，為防抖標記賦予用於指示遠端業務調用異常的標記值，比如shake，基於與唯一階段標識所標識的第二支付階段對應的模擬正常結果和防抖標記產生兜底處理結果。
在750，將兜底處理結果發送給客戶端。
在755，支付防抖裝置攔截客戶端在支付過程中發送到服務端的最後業務請求，最後業務請求包括唯一階段標識和防抖標記，其中，唯一階段標識用於唯一標識當前業務請求所對應的最後支付階段，該防抖標記具有用於指示遠端業務調用異常的標記值，比如shake。
在760，基於防抖標記的標記值指示遠端業務調用異常，確定針對最後業務請求的遠端業務調用異常。
在765，產生兜底處理結果，兜底處理結果包括與唯一階段標識所標識的最後支付階段對應的模擬正常結果和防抖標記，防抖標記具有用於指示遠端業務調用異常的標記值，比如shake。
在770，將兜底處理結果發送給客戶端。
在775，客戶端顯示完成本次支付，使用者看到的都是模擬正常結果。
在780，啟動非同步恢復過程，以實現業務的最終一致。
在785，根據與該支付過程對應的支付資訊，從墊支帳戶中支付相應數目的支付款給賣家。
該實施例的支付防抖方法還可以包括：回應於從墊支帳戶中支付相應數目的支付款給賣家，通知賣家相應數目的支付款已到帳。通知賣家可以採用語音播報、簡訊通知、或者其他任何現有的方式。
由實施例2可見，對於防抖處理的業務，除了本次支付的最後一次業務請求，對於之前的每一次業務請求，支付防抖裝置均在發送返回結果給客戶端的同時，發送具有標記值的防抖標記給客戶端。客戶端發送下一次業務請求的時候會帶上該防抖標記，再次進入到支付防抖裝置內，如果防抖標記的防抖值指示遠端業務調用異常，則會被識別為這個支付過程上一階段已經被兜底處理，當次階段繼續走兜底流程，直到使用者完成這次支付。當然，對於本次支付的最後一次業務請求，支付防抖裝置發送返回結果給客戶端，也可以同時發送具有標記值的防抖標記給客戶端，只是這一階段是支付過程的最後階段，後面不會再有客戶端發送的業務請求了，因此發送防抖標記給客戶端的話資訊不夠簡潔。另外，如果對於當前業務請求進行遠端業務調用異常，支付防抖裝置在發送返回結果的同時發送具有用於指示遠端業務調用異常的標記值的防抖標記給客戶端，對於客戶端後續發起的業務請求，支付防抖裝置都不再發送防抖標記給客戶端，則雖然發送給客戶端的資訊簡潔，但是需要修改客戶端的程式。
本公開的支付防抖方法不限於上述各實施例所公開的技術方案，上面公開的對於支付過程一次業務請求處理的各個實施例可以在不偏離發明實質的情況下做出各種組合、變形和修改，此外，整個支付過程的各個階段的各個實施例也可以在不偏離發明實質的情況下做出各種組合、變形和修改。
利用本公開的方案，從通用高可用架構層面減少服務端的鏈路抖動、故障對業務帶來的影響以及業務損失，提升整體業務鏈路的成功率，同時提升使用者體驗。
利用本公開的方案，在目前網際網路規模以及複雜的企業級分散式架構體系下，為未來核心業務場景達到99.999%甚至更高的可用率目標提供高可用架構層面的保障，保障金融級別的穩定性，降低系統抖動造成的公眾影響，減少商戶收款損失。
圖8為本公開一個實施例提供的支付防抖裝置800的結構示意圖。其中，支付防抖裝置既可以為一個獨立的裝置，也可以為接入服務端的組件。如圖8所示，該實施例的支付防抖裝置800可以包括：攔截單元810、異常確定單元820、兜底處理單元830、以及發送單元840。
攔截單元810被配置為攔截客戶端在支付過程中發送到服務端的當前業務請求，當前業務請求至少包括唯一階段標識，其中，支付過程包括多個支付階段，以及唯一階段標識用於唯一標識當前業務請求所對應的支付階段。攔截單元810的操作可以參照上面參考圖2描述的區塊210的操作。
異常確定單元820被配置為基於與當前業務請求對應的防抖標記，確定針對當前業務請求的遠端業務調用是否異常。異常確定單元820的操作可以參照上面參考圖2描述的區塊220的操作。
兜底處理單元830被配置為在針對當前業務請求的遠端業務調用被確定為異常時，產生兜底處理結果，兜底處理結果至少包括與唯一階段標識所標識的支付階段對應的模擬正常結果。兜底處理單元830的操作可以參照上面參考圖2描述的區塊230的操作。
發送單元840被配置為將兜底處理結果發送給客戶端。發送單元840的操作可以參照上面參考圖2描述的區塊240的操作。
圖9為本公開另一個實施例提供的支付防抖裝置900的結構示意圖。如圖9所示，該實施例的支付防抖裝置900可以包括：攔截單元910、防抖標記創建單元920、異常確定單元930、業務調用單元940、兜底處理單元950、標記值調整單元960、以及發送單元970。
攔截單元910被配置為攔截客戶端在支付過程中發送到服務端的當前業務請求，當前業務請求至少包括唯一階段標識，其中，支付過程包括多個支付階段，以及唯一階段標識用於唯一標識當前業務請求所對應的支付階段。攔截單元910的操作可以參照上面參考圖7描述的700、725和755的操作。
防抖標記創建單元920，被配置為在當前業務請求是首次業務請求時，在攔截到當前業務請求後為當前業務請求創建防抖標記。防抖標記創建單元920的操作可以參照上面參考圖7描述的705的操作。
異常確定單元930被配置為基於與當前業務請求對應的防抖標記，確定針對當前業務請求的遠端業務調用是否異常。異常確定單元930還可以被配置為在防抖標記的標記值指示遠端業務調用異常時，確定針對當前業務請求的遠端業務調用異常。異常確定單元930的操作可以參照上面參考圖7描述的735和760的操作。
業務調用單元940被配置為在防抖標記的標記值指示遠端業務調用正常時，根據當前業務請求執行遠端業務調用。作為該實施例的一態樣，對於在首次業務請求處理期間創建防抖標記並且防抖標記的標記值為空的情況，以及非首次業務請求所帶的防抖標記的標記值為正常的情況，都認為防抖標記的標記值指示遠端業務調用正常。業務調用單元940的操作可以參照上面參考圖7描述的710和730的操作。異常確定單元930還可以被配置為基於遠端業務調用的返回結果是否異常，確定針對當前業務請求的遠端業務調用是否異常。異常確定單元930的操作可以參照上面參考圖7描述的735的操作。
兜底處理單元950被配置為在針對當前業務請求的遠端業務調用被確定為異常時，產生兜底處理結果，兜底處理結果至少包括與唯一階段標識所標識的支付階段對應的模擬正常結果。兜底處理單元950的操作可以參照上面參考圖7描述的745和765的操作。
標記值調整單元960被配置為在遠端業務調用的返回結果異常時，為防抖標記賦予用於指示遠端業務調用異常的標記值並包括在兜底處理結果中。標記值調整單元960的操作可以參照上面參考圖7描述的745的操作。
發送單元970被配置為將兜底處理結果發送給客戶端。發送單元970的操作可以參照上面參考圖7描述的750和770的操作。
作為該實施例的一態樣，該實施例的支付防抖裝置還可以包括正常處理單元。正常處理單元被配置為在針對當前業務請求的遠端業務調用被確定為正常時，產生正常處理結果，正常處理結果至少包括遠端業務調用返回的調用結果中的資訊。正常處理單元的操作可以參照上面參考圖7描述的715的操作。標記值調整單元960還可以被配置為在遠端業務調用的返回結果正常時，確定針對當前業務請求的遠端業務調用正常，為防抖標記賦予用於指示遠端業務調用正常的標記值並包括在正常處理結果中。標記值調整單元960的操作可以參照上面參考圖7描述的715的操作。發送單元970還可以被配置為將正常處理結果發送給客戶端。發送單元970的操作可以參照上面參考圖7描述的720的操作。
作為該實施例的另一態樣，該實施例的支付防抖裝置還可以包括業務類型確定單元。業務類型確定單元被配置為在當前業務請求是首次業務請求時，在攔截到當前業務請求後，解析所攔截的當前業務請求，以確定當前業務請求所屬的業務類型。業務類型確定單元的操作可以參照上面參考圖3描述的區塊320的操作。防抖標記創建單元920還可以被配置為在所確定的業務類型屬於需要防抖處理的業務類型時，為當前業務請求創建防抖標記。標記創建單元920的操作可以參照上面參考圖3描述的區塊330的操作。
作為該實施例的又一態樣，該實施例的支付防抖裝置還可以包括異常識別單元。異常識別單元被配置為在遠端業務調用的返回結果異常時，識別遠端業務調用異常是否為能夠進行兜底處理的異常。異常識別單元的操作可以參照上面參考圖7描述的740的操作。標記值調整單元960還可以被配置為在識別出遠端業務調用異常是能夠進行兜底處理的異常時，為防抖標記賦予用於指示遠端業務調用異常的標記值並包括在兜底處理結果中。標記值調整單元960的操作可以參照上面參考圖7描述的745的操作。
作為該實施例的在一態樣，該實施例的支付防抖裝置還可以包括支付處理單元。在當前業務請求是所述支付過程的最後業務請求時，在將兜底處理結果發送給客戶端後，根據與支付過程對應的支付資訊，從墊支帳戶中支付相應數目的支付款給賣家。支付處理單元的操作可以參照上面參考圖7描述的780-785的操作。
本公開的支付防抖裝置不限於上述各實施例所公開的技術方案，上面公開的各個實施例可以在不偏離發明實質的情況下做出各種組合、變形和修改。
如上參照圖2-9，對本公開的支付防抖方法及裝置的實施例進行了描述。應當理解的是，以上對於方法實施例的細節描述同樣適用於裝置實施例。以上的支付防抖裝置可以採用硬體實現，也可以採用軟體或者硬體和軟體的組合來實現。
圖10是本公開的一個實施例提供的實現支付防抖的計算設備的結構方塊圖。
如圖10所示，計算設備1000可以包括至少一個處理器1010、記憶體1020、記憶體1030、通信介面1040以及內部匯流排1050，該至少一個處理器1010執行在電腦可讀儲存媒體(即，記憶體1020)中儲存或編碼的至少一個電腦可讀指令(即，上述以軟體形式實現的元素)。
在一個實施例中，在記憶體1020中儲存有電腦可執行指令，其當執行時使得至少一個處理器1010：攔截客戶端在支付過程中發送到服務端的當前業務請求，當前業務請求至少包括唯一階段標識，其中，支付過程包括多個支付階段，以及唯一階段標識用於唯一標識當前業務請求所對應的支付階段；基於與當前業務請求對應的防抖標記，確定針對當前業務請求的遠端業務調用是否異常；在針對當前業務請求的遠端業務調用被確定為異常時，產生兜底處理結果，兜底處理結果至少包括與唯一階段標識所標識的支付階段對應的模擬正常結果；以及將兜底處理結果發送給客戶端。
應該理解的是，在記憶體1020中儲存的電腦可執行指令當執行時使得至少一個處理器1010進行本公開的各個實施例中以上結合圖2-9描述的各種操作和功能。
在本公開中，計算設備1000可以包括但不限於：個人電腦、伺服器電腦、工作站、桌上型電腦、膝上型電腦、筆記型電腦、行動計算裝置、智慧型電話、平板電腦、行動電話、個人數位助理(PDA)、手持裝置、訊息收發設備、可佩戴計算設備、消費電子設備等等。
根據一個實施例，提供了一種例如非暫時性機器可讀媒體的程式產品。非暫時性機器可讀媒體可以具有指令(即，上述以軟體形式實現的元素)，該指令當被機器執行時，使得機器執行本公開的各個實施例中以上結合圖2-9描述的各種操作和功能。
具體地，可以提供配有可讀儲存媒體的系統或者裝置，在該可讀儲存媒體上儲存著實現上述實施例中任一實施例的功能的軟體程式碼，且使該系統或者裝置的電腦或處理器讀出並執行儲存在該可讀儲存媒體中的指令。
在這種情況下，從可讀媒體讀取的程式碼本身可實現上述實施例中任何一項實施例的功能，因此機器可讀代碼和儲存機器可讀代碼的可讀儲存媒體構成了本發明的一部分。
可讀儲存媒體的實施例包括軟碟、硬碟、磁光碟、光碟(如CD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RAM、DVD-RW、DVD-RW)、磁帶、非易失性儲存卡和ROM。可選擇地，可以由通信網路從伺服器電腦上或雲端上下載程式碼。
本領域技術人員應當理解，上面公開的各個實施例可以在不偏離發明實質的情況下做出各種變形和修改。因此，本發明的保護範圍應當由所附的申請專利範圍來限定。
需要說明的是，上述各流程和各系統結構圖中不是所有的步驟和單元都是必須的，可以根據實際的需要忽略某些步驟或單元。各步驟的執行順序不是固定的，可以根據需要進行確定。上述各實施例中描述的裝置結構可以是物理結構，也可以是邏輯結構，即，有些單元可能由同一物理實體實現，或者，有些單元可能分由多個物理實體實現，或者，可以由多個獨立設備中的某些部件共同實現。
以上各實施例中，硬體單元或模組可以透過機械方式或電氣方式實現。例如，一個硬體單元、模組或處理器可以包括永久性專用的電路或邏輯(如專門的處理器，FPGA或ASIC)來完成相應操作。硬體單元或處理器還可以包括可編程邏輯或電路(如通用處理器或其它可編程處理器)，可以由軟體進行臨時的設置以完成相應操作。具體的實現方式(機械方式、或專用的永久性電路、或者臨時設置的電路)可以基於成本和時間上的考慮來確定。
上面結合圖式闡述的具體實施方式描述了示例性實施例，但並不表示可以實現的或者落入申請專利範圍的保護範圍的所有實施例。在整個本說明書中使用的術語“示例性”意味著“用作示例、實例或例示”，並不意味著比其它實施例“優選”或“具有優勢”。出於提供對所描述技術的理解的目的，具體實施方式包括具體細節。然而，可以在沒有這些具體細節的情況下實施這些技術。在一些實例中，為了避免對所描述的實施例的概念造成難以理解，習知的結構和裝置以方塊圖形式示出。
本公開內容的上述描述被提供來使得本領域任何普通技術人員能夠實現或者使用本公開內容。對於本領域普通技術人員來說，對本公開內容進行的各種修改是顯而易見的，並且，也可以在不脫離本公開內容的保護範圍的情況下，將本文所定義的一般性原理應用於其它變型。因此，本公開內容並不限於本文所描述的示例和設計，而是與符合本文公開的原理和新穎性特徵的最廣範圍相一致。The subject matter described herein will now be discussed with reference to example embodiments. It should be understood that the discussion of these embodiments is only to enable those skilled in the art to better understand and implement the subject matter described herein, and is not to limit the scope of protection, applicability or examples set forth in the scope of the patent application. The function and arrangement of the discussed elements can be changed without departing from the scope of protection of the present disclosure. Various examples can omit, replace or add various processes or components as needed. For example, the described method may be executed in a different order from the described order, and various steps may be added, omitted, or combined. In addition, features described with respect to some examples can also be combined in other examples.
As used herein, the term "including" and its variants means open terms, meaning "including but not limited to." The term "based on" means "based at least in part on." The terms "one embodiment" and "an embodiment" mean "at least one embodiment." The term "another embodiment" means "at least one other embodiment." The terms "first", "second", etc. may refer to different or the same items. Other definitions can be included below, either explicit or implicit. Unless clearly indicated in the context, the definition of a term is consistent throughout the specification.
The one-time payment process includes one payment stage or multiple payment stages, and the present disclosure mainly focuses on payment services including multiple stages. The client initiates a service request to the next service request as a stage, or the client initiates a service request until the client displays the payment completion as a stage. For example, for the offline payment code payment service, as shown in Figure 1, the client scans the seller’s payment code as the first service request. The client initiates the first service request until the client displays the payment returned by the server. The amount input box is the stage 110 of creating the transaction number; the user enters the amount of money paid into the payment amount input box displayed on the client and confirms the submission as the second business request. The second business request is initiated from the client to the client display The payment method option and payment password input box returned by the server is the stage 120 when the cashier is pulled up; the user selects the payment method through the client and enters the payment password and confirms the submission is the third business request. The third is initiated from the client. The second service request to the client shows that the “paying” notification returned by the server is the stage of payment submission 130; the fourth service request initiated calls polling to query the transaction status of the order. If the transaction is successful, the client receives The notification of "payment successful", therefore the fourth stage is the stage 140 of polling the payment result. It can be seen that the offline payment code payment business includes the above four stages.
Because the service link of the distributed system on the server side is long and jitter is prone to occur, in order to avoid interruption or errors in the payment process due to jitter, for a certain service request, once the remote call of the server is abnormal, the service request and After that, all business requests were dealt with. Identify the business jitter according to the error code, anomaly and/or business parameters of the result returned by the remote call, deal with the business jitter, return the simulation result, and record the running water. You can trigger the asynchronous recovery process based on the bottom line of the flow, and send money from the advance account to the seller.
Fig. 2 shows a flow chart of a payment anti-shake method provided in Embodiment 1 of the present disclosure, and the process can be executed by a payment anti-shake device. Embodiment 1 mainly considers the processing of a business request in the payment process.
As shown in FIG. 2, in block 210, the current business request sent by the client to the server during the payment process is intercepted. The current business request includes at least a unique stage identifier. The payment process includes multiple payment stages and a unique stage identifier. Used to uniquely identify the payment phase corresponding to the current business request.
The current business request sent by the client to the server can be intercepted through AOP. Among them, AOP is the abbreviation of Aspect Oriented Programming, which means oriented programming. It is a technology that achieves unified maintenance of program functions through precompilation and runtime dynamic agents. AOP can be understood as an interceptor framework, but this interceptor will be very arbitrary. If it intercepts a class, then it will intercept all methods in this class.
In block 220, based on the anti-shake flag corresponding to the current service request, it is determined whether the remote service call for the current service request is abnormal. As an aspect of this embodiment, for the case where the value of the anti-shake flag carried by the non-first service request is abnormal, it is determined that the remote service call for the current service request is abnormal. For the case where the anti-shake flag created during the processing of the first service request and the value of the anti-shake flag is empty, and the case where the value of the anti-shake flag carried by the non-first service request is normal, the current service request is determined The remote service call is normal.
In block 230, when the remote service call for the current service request is determined to be abnormal, a bottom processing result is generated, and the bottom processing result includes at least a simulated normal result corresponding to the payment phase identified by the unique phase identifier.
In block 240, the bottom processing result is sent to the client. Therefore, the returned result from the client is the normal result of the simulation.
Fig. 3 is an example of a payment anti-shake method when the current service request is the first service request of the payment process.
In block 310, the payment anti-shake device intercepts the first service request sent by the client to the server during the payment process, and the first service request includes at least a unique stage identifier.
In block 320, the intercepted first service request is parsed to determine the service type to which the first service request belongs.
In block 330, when the determined service type belongs to the service type that requires anti-shake processing, an anti-shake flag is created for the first service request, and the anti-shake flag is used to indicate that the current payment service is a service that requires anti-shake processing. In an example of the present disclosure, the types of services that require anti-shake processing may include offline payment code payment services. The anti-shake flag is, for example, appfuse_type. Because the server is a distributed system, processing business requests requires remote business calls. The value of the anti-shake flag is used to indicate whether the remote service call is normal or abnormal, and the abnormality refers to the jitter of the link for the remote service call. The mark value of the anti-shake flag is, for example, normal or shake, where shake represents jitter, and normal represents normal, that is, no jitter occurs.
In block 340, a remote service call is made according to the first service request. Here, the payment anti-shake device can be used as the upstream system to make remote service calls to the downstream system of the server. As an alternative, the payment anti-shake device can also instruct the upstream system of the server to make remote business calls to the downstream system.
In block 350, based on the call result returned by the remote service call, it is determined whether the remote service call for the first service request is abnormal. If the call result returned by the remote service call is abnormal, it is determined that the remote service call for the first service request is abnormal, and the process proceeds to block 360. If the call result returned by the remote service call is normal, it is determined that the remote service call for the first service request is normal, and the process proceeds to block 380.
In block 360, the anti-shake flag is assigned a flag value indicating the abnormality of the remote service call, such as shake, and the bottom processing result is generated based on the simulated normal result and the anti-shake flag corresponding to the payment stage identified by the unique stage identifier. The simulation normal result corresponding to the payment stage identified by the unique stage identifier is stored in the memory of the payment anti-shake device. The payment anti-shake device analyzes the intercepted business request, and finds the corresponding in its memory according to the unique stage identifier parsed The simulation results of normal, resulting in the bottom processing results. The process proceeds to block 370.
In block 370, the bottom processing result is sent to the client. Therefore, the returned result from the client is the normal result of the simulation.
In block 380, the anti-shake flag is assigned a flag value indicating that the remote service call is normal, such as normal, and a normal processing result is generated based on the call result returned by the remote service call and the anti-shake flag. Therefore, the normal processing result includes the information and the anti-shake flag in the call result returned by the remote service call. The process proceeds to block 390.
In block 390, the normal processing result is sent to the client.
Fig. 4 is an example of a payment anti-shake method when the current service request is a non-first service request in the payment process.
In block 400, the payment anti-shake device intercepts the non-first service request sent by the client to the server during the payment process, and the non-first service request includes at least a unique stage identification and anti-shake mark. Among them, the anti-shake mark is the anti-shake mark returned in the previous service request processing process.
In block 410, it is determined whether the flag value of the anti-shake flag included in the non-first service request indicates whether the remote service call is abnormal. If the value of the anti-shake flag indicates that the remote service call is abnormal, it is determined that the remote service call for the non-first service request is abnormal, and the flow proceeds to block 420. If the value of the anti-shake flag indicates that the remote service call is normal, the flow proceeds to block 440.
In block 420, a bottom processing result is generated. The bottom processing result includes a simulation normal result corresponding to the payment phase identified by the unique phase identifier and an anti-shake flag. The anti-shake flag has a flag value for indicating abnormal remote service invocation. Such as shake. The process proceeds to block 430.
In block 430, the bottom processing result is sent to the client. Therefore, the returned result from the client is the normal result of the simulation. Fig. 5 is a schematic diagram of a simulated normal result returned from the intermediate stage of payment seen by the client as an example. Fig. 6 is a schematic diagram of the simulated normal result returned in the final stage of the payment example shown in Fig. 5.
In block 440, a remote service call is made according to a non-first service request. The process proceeds to block 450.
In block 450, based on whether the call result returned by the remote service call is abnormal, it is determined whether the remote service call for the non-first service request is abnormal. If the call result is abnormal, such as SYSTEM_ERROR, it is determined that the remote service call is abnormal, and the process proceeds to block 460. If the call result is normal, it is determined that the remote service call is normal, and the flow proceeds to block 480.
In block 460, the anti-shake flag is assigned a flag value indicating the abnormality of the remote service call, such as shake, and the bottom processing result is generated based on the simulated normal result corresponding to the payment stage identified by the unique stage identifier and the anti-shake flag. The process proceeds to block 470.
In block 470, the bottom processing result is sent to the client.
In block 480, a normal processing result is generated. The normal processing result includes the information in the call result returned by the remote service call and the anti-shake flag. The anti-shake flag has a flag value indicating that the remote service call is normal, such as normal. The process proceeds to block 490.
In block 490, the normal processing result is sent to the client.
As an optional embodiment, before the anti-shake flag is assigned a flag value indicating abnormal remote service invocation in block 360 of FIG. 3 and/or block 460 of FIG. 4, the payment anti-shake method of this embodiment It can also include a jitter recognition step. The jitter identification step may include: identifying whether the remote service call abnormality is an abnormality that can be processed under the hood, and when it is recognized that the remote service call abnormality is an abnormality that can be processed under the circumstance, an anti-shake mark is assigned to indicate the remote service call The abnormal tag value is also included in the bottom processing result.
If the current service request includes payment information, the payment anti-shake device can record the payment information in the service request and the multi-stage context state cache. The payment information can include information such as the order amount, payment account, and collection account. The order is generated based on the payment information, and the order can include a serial number. In addition, the payment information corresponding to the payment process can also come from the server. Record payment information to facilitate the anti-shake asynchronous recovery after the synchronization process. The multi-stage context state cache is the information needed for anti-shake in the multi-stage state. As an optional embodiment, when the current service request is the last service request of the payment process, the payment anti-shake method of this embodiment may further include: after sending the bottom processing result to the client, according to the payment process corresponding to the payment process Information, pay the corresponding amount of payment to the seller from the advance account. The process of paying a corresponding amount of payment to the seller from the advance account can be called an asynchronous recovery process, because this process is completed in an asynchronous recovery method. Before paying a corresponding amount of payment from the advance account to the seller, the payment anti-shake method of this embodiment may further include: in response to paying a corresponding amount of payment from the advance account to the seller, notifying the seller that the corresponding amount of payment has been made Arrived. The seller can be notified by voice broadcast, short message notification, or any other existing methods.
After the synchronization process, the asynchronous recovery process can be triggered in real time, timed, or manually. Among them, the link through which the asynchronous recovery process and the foregoing service request processing process pass in the distributed system are likely to be different links, or they may be the same link. Normally, the asynchronous recovery process is triggered in an instant manner. About 1 to 2 seconds after the seller is notified that the payment has arrived, a corresponding amount of payment is transferred from the advance account to the seller's account. In rare cases, if the system is still malfunctioning when the asynchronous recovery process is triggered in an instant, you can send the payment from the advance account to the seller’s account after a preset period of time from the time the seller is notified that the payment has arrived. . In very special circumstances, if the system still fails when the asynchronous recovery process is triggered in a regular manner, you can manually intervene to manually transfer the payment from the advance account to the seller's account.
The entire payment process is physically sensitive to the user, and what you see is a free bill discount, as shown in Figure 5 and Figure 6, which is imperceptible to the seller. After the user completes the payment, the seller will be synchronized Receive a voice broadcast or text message notification, etc., and in terms of fund processing, you need to send money from the payment advance account to the seller when the anti-shake asynchronous recovery is performed, and the buyer's account has no fund changes and can be recovered from the buyer's account afterwards or Do not collect payment from buyer's account.
FIG. 7 is a flowchart of the entire payment process of the payment anti-shake method provided in Embodiment 2 of the disclosure. Embodiment 2 takes the current payment process including three stages as an example. Among them, the payment anti-shake device is a basic functional module that undertakes the anti-shake capability, and the payment anti-shake device may be a component connected to the server, or an independent device between the client and the server.
As shown in Figure 7, at 700, the payment anti-shake device intercepts the first service request sent by the client to the server during the payment process. The first service request includes a unique stage identifier, where the unique stage identifier is used to uniquely identify the current The first payment phase corresponding to the business request.
At 705, create an anti-shake mark for the first service request, such as appfuse_type, to identify that this payment is a service that requires anti-shake.
At 710, a remote service call is made according to the first service request.
At 715, based on whether the call result returned by the remote service call is abnormal, it is determined whether the remote service call for the first service request is abnormal. When it is determined that the remote service call is normal, the anti-shake flag is assigned a flag value indicating that the remote service call is normal, such as normal, and a normal processing result is generated based on the call result returned by the remote service call and the anti-shake flag.
At 720, the normal processing result is sent to the client.
At 725, the payment anti-shake device intercepts the second service request sent by the client to the server during the payment process. The second service request includes a unique stage identifier and an anti-shake mark. The unique stage identifier is used to uniquely identify the current service request In the corresponding second payment stage, the anti-shake flag has a flag value used to indicate that the remote service call is normal, such as normal.
At 730, a remote service call is made according to the second service request.
At 735, based on the abnormality of the call result returned by the remote service call, it is determined that the remote service call for the second service request is abnormal.
At 740, when determining the remote service call abnormality, identify whether the remote service call exception is an exception that can be handled, that is, identify whether the error code of the returned call result is within the range of the call, and if it is within the range of the call, proceed Bottom treatment.
At 745, when it is recognized that the abnormality is an abnormality that can be handled under the hood, the anti-shake flag is assigned a tag value indicating the abnormality of the remote service call, such as shake, based on the second payment phase identified by the unique phase identifier. Simulate the normal result and the anti-shake mark to produce the bottom processing result.
At 750, the bottom processing result is sent to the client.
At 755, the payment anti-shake device intercepts the last service request sent by the client to the server during the payment process. The last service request includes a unique stage identifier and an anti-shake mark. The unique stage identifier is used to uniquely identify the last service request corresponding to the current service request. In the payment phase, the anti-shake flag has a flag value that is used to indicate abnormal remote service calls, such as shake.
At 760, the remote service call is abnormal based on the mark value of the anti-shake flag, and the remote service call for the last service request is determined to be abnormal.
In 765, the bottom processing result is generated. The bottom processing result includes the simulated normal result corresponding to the last payment stage identified by the unique stage identifier and an anti-shake flag. The anti-shake flag has a flag value used to indicate abnormal remote service calls, such as shake .
At 770, the bottom processing result is sent to the client.
At 775, the client shows that the payment is completed, and the user sees the simulated normal results.
At 780, the asynchronous recovery process is initiated to achieve the final consistency of the business.
At 785, according to the payment information corresponding to the payment process, a corresponding amount of payment is paid from the advance account to the seller.
The payment anti-shake method of this embodiment may further include: in response to paying a corresponding amount of payment from the advance account to the seller, notifying the seller that the corresponding amount of payment has arrived. The seller can be notified by voice broadcast, short message notification, or any other existing methods.
It can be seen from Example 2 that for the anti-shake processing service, except for the last service request of this payment, for each previous service request, the payment anti-shake device sends the returned result to the client at the same time as the marked value Anti-shake mark to the client. When the client sends the next service request, it will take the anti-shake mark and enter the payment anti-shake device again. If the anti-shake value of the anti-shake mark indicates that the remote service call is abnormal, it will be identified as the payment process. The first stage has been processed, and the current stage continues to go through the process until the user completes the payment. Of course, for the last service request of this payment, the payment anti-shake device sends the return result to the client, and it can also send the anti-shake mark with the marked value to the client at the same time, but this stage is the last stage of the payment process. There will be no more business requests sent by the client, so the information is not concise enough to send the anti-shake mark to the client. In addition, if the remote service call is abnormal for the current service request, the payment anti-shake device sends the anti-shake flag with the flag value used to indicate the abnormal remote service call to the client while sending the return result, and the client initiates subsequent calls. For business requests, the payment anti-shake device no longer sends the anti-shake mark to the client. Although the information sent to the client is concise, the client’s program needs to be modified.
The payment anti-shake method of the present disclosure is not limited to the technical solutions disclosed in the above-mentioned embodiments. The above-disclosed embodiments of one-time service request processing in the payment process can be combined, modified and modified without departing from the essence of the invention. In addition, the various embodiments at various stages of the entire payment process can also be combined, modified, and modified without departing from the essence of the invention.
Using the solution of the present disclosure, the link jitter of the server, the impact of the fault on the business and the business loss from the general high-availability architecture are reduced, the success rate of the overall business link is improved, and the user experience is improved.
Using the solution of the present disclosure, under the current Internet scale and complex enterprise-level distributed architecture system, it can provide high-availability architecture guarantee for future core business scenarios to reach 99.999% or even higher availability targets, and guarantee financial-level Stability, reduce the public impact caused by system jitter, and reduce merchants' collection losses.
FIG. 8 is a schematic structural diagram of a payment anti-shake device 800 provided by an embodiment of the disclosure. Among them, the payment anti-shake device can be an independent device or a component connected to the server. As shown in FIG. 8, the payment anti-shake device 800 of this embodiment may include: an interception unit 810, an abnormality determination unit 820, a pocket processing unit 830, and a sending unit 840.
The intercepting unit 810 is configured to intercept the current business request sent by the client to the server during the payment process. The current business request includes at least a unique stage identifier. The payment process includes multiple payment stages, and the unique stage identifier is used to uniquely identify the current business. The payment phase corresponding to the request. The operation of the interception unit 810 may refer to the operation of the block 210 described above with reference to FIG. 2.
The abnormality determining unit 820 is configured to determine whether the remote service call for the current service request is abnormal based on the anti-shake flag corresponding to the current service request. The operation of the abnormality determination unit 820 may refer to the operation of the block 220 described above with reference to FIG. 2.
The bottom processing unit 830 is configured to generate a bottom processing result when the remote service call for the current service request is determined to be abnormal, and the bottom processing result includes at least a simulated normal result corresponding to the payment phase identified by the unique phase identifier. The operation of the bottom processing unit 830 may refer to the operation of the block 230 described above with reference to FIG. 2.
The sending unit 840 is configured to send the bottom processing result to the client. The operation of the sending unit 840 may refer to the operation of the block 240 described above with reference to FIG. 2.
FIG. 9 is a schematic structural diagram of a payment anti-shake device 900 provided by another embodiment of the present disclosure. As shown in FIG. 9, the payment anti-shake device 900 of this embodiment may include: an interception unit 910, an anti-shake mark creation unit 920, an abnormality determination unit 930, a service invocation unit 940, a pocket processing unit 950, a mark value adjustment unit 960, And the sending unit 970.
The intercepting unit 910 is configured to intercept the current business request sent by the client to the server during the payment process. The current business request includes at least a unique stage identifier. The payment process includes multiple payment stages, and the unique stage identifier is used to uniquely identify the current business. The payment phase corresponding to the request. The operations of the interception unit 910 may refer to the operations of 700, 725, and 755 described above with reference to FIG. 7.
The anti-shake mark creation unit 920 is configured to create an anti-shake mark for the current service request after intercepting the current service request when the current service request is the first service request. The operation of the anti-shake mark creation unit 920 may refer to the operation of 705 described above with reference to FIG. 7.
The abnormality determining unit 930 is configured to determine whether the remote service call for the current service request is abnormal based on the anti-shake flag corresponding to the current service request. The abnormality determining unit 930 may also be configured to determine that the remote service invocation for the current service request is abnormal when the flag value of the anti-shake flag indicates that the remote service invocation is abnormal. The operation of the abnormality determination unit 930 may refer to the operations of 735 and 760 described above with reference to FIG. 7.
The service invocation unit 940 is configured to execute the remote service invocation according to the current service request when the mark value of the anti-shake flag indicates that the remote service invocation is normal. As an aspect of this embodiment, for the case where the anti-shake flag is created during the processing of the first service request and the value of the anti-shake flag is empty, and the case where the value of the anti-shake flag carried by the non-first service request is normal , It is considered that the value of the anti-shake flag indicates that the remote service call is normal. The operation of the service invoking unit 940 may refer to the operations of 710 and 730 described above with reference to FIG. 7. The abnormality determining unit 930 may also be configured to determine whether the remote service call for the current service request is abnormal based on whether the return result of the remote service call is abnormal. The operation of the abnormality determination unit 930 may refer to the operation of 735 described above with reference to FIG. 7.
The bottom processing unit 950 is configured to generate a bottom processing result when the remote service call for the current service request is determined to be abnormal. The bottom processing result includes at least a simulated normal result corresponding to the payment phase identified by the unique phase identifier. The operation of the pocket bottom processing unit 950 can refer to the operations of 745 and 765 described above with reference to FIG. 7.
The mark value adjustment unit 960 is configured to, when the return result of the remote service call is abnormal, give the anti-shake mark a mark value indicating the abnormality of the remote service call and include it in the bottom processing result. The operation of the flag value adjustment unit 960 may refer to the operation of 745 described above with reference to FIG. 7.
The sending unit 970 is configured to send the bottom processing result to the client. The operation of the sending unit 970 may refer to the operations of 750 and 770 described above with reference to FIG. 7.
As an aspect of this embodiment, the payment anti-shake device of this embodiment may further include a normal processing unit. The normal processing unit is configured to generate a normal processing result when the remote service call for the current service request is determined to be normal, and the normal processing result includes at least information in the call result returned by the remote service call. The operation of the normal processing unit may refer to the operation of 715 described above with reference to FIG. 7. The mark value adjustment unit 960 may also be configured to determine that the remote service call for the current service request is normal when the return result of the remote service call is normal, and assign the anti-shake mark a mark value indicating that the remote service call is normal. Included in the normal processing results. The operation of the flag value adjustment unit 960 may refer to the operation of 715 described above with reference to FIG. 7. The sending unit 970 may also be configured to send the normal processing result to the client. The operation of the sending unit 970 may refer to the operation of 720 described above with reference to FIG. 7.
As another aspect of this embodiment, the payment anti-shake device of this embodiment may further include a service type determining unit. The service type determining unit is configured to, when the current service request is the first service request, after intercepting the current service request, analyze the intercepted current service request to determine the service type to which the current service request belongs. The operation of the service type determining unit may refer to the operation of the block 320 described above with reference to FIG. 3. The anti-shake mark creation unit 920 may also be configured to create an anti-shake mark for the current service request when the determined service type belongs to a service type that requires anti-shake processing. The operation of the mark creation unit 920 may refer to the operation of the block 330 described above with reference to FIG. 3.
As another aspect of this embodiment, the payment anti-shake device of this embodiment may further include an abnormality recognition unit. The abnormality recognition unit is configured to recognize whether the abnormality of the remote service call is an abnormality that can be handled when the return result of the remote service call is abnormal. The operation of the abnormality recognition unit may refer to the operation of 740 described above with reference to FIG. 7. The mark value adjustment unit 960 may also be configured to, when it is recognized that the remote service call abnormality is an abnormality that can be processed under the circumstance, give the anti-shake mark a mark value indicating the abnormality of the remote service call and include it in the undercover processing result . The operation of the flag value adjustment unit 960 may refer to the operation of 745 described above with reference to FIG. 7.
As an aspect of this embodiment, the payment anti-shake device of this embodiment may further include a payment processing unit. When the current service request is the final service request of the payment process, after sending the bottom processing result to the client, according to the payment information corresponding to the payment process, a corresponding amount of payment is paid from the advance account to the seller. The operation of the payment processing unit may refer to the operations of 780-785 described above with reference to FIG. 7.
The payment anti-shake device of the present disclosure is not limited to the technical solutions disclosed in the above embodiments, and the various embodiments disclosed above can be combined, modified, and modified without departing from the essence of the invention.
2-9, the embodiments of the payment anti-shake method and device of the present disclosure have been described. It should be understood that the above detailed description of the method embodiment is also applicable to the device embodiment. The above payment anti-shake device can be implemented by hardware, software or a combination of hardware and software.
FIG. 10 is a structural block diagram of a computing device for realizing payment anti-shake provided by an embodiment of the present disclosure.
As shown in FIG. 10, the computing device 1000 may include at least one processor 1010, a memory 1020, a memory 1030, a communication interface 1040, and an internal bus 1050. The at least one processor 1010 executes on a computer-readable storage medium (ie, At least one computer-readable instruction (ie, the above-mentioned element implemented in the form of software) stored or encoded in the memory 1020).
In one embodiment, a computer executable instruction is stored in the memory 1020, which when executed causes at least one processor 1010 to intercept the current business request sent by the client to the server during the payment process, and the current business request includes at least unique Phase identification, where the payment process includes multiple payment phases, and the unique phase identification is used to uniquely identify the payment phase corresponding to the current service request; based on the anti-shake flag corresponding to the current service request, determine the remote service for the current service request Whether the call is abnormal; when the remote service call for the current service request is determined to be abnormal, a bottom processing result is generated, and the bottom processing result includes at least the simulated normal result corresponding to the payment stage identified by the unique stage identifier; and the bottom processing result Sent to the client.
It should be understood that the computer-executable instructions stored in the memory 1020, when executed, cause at least one processor 1010 to perform various operations and functions described above with reference to FIGS. 2-9 in the various embodiments of the present disclosure.
In the present disclosure, the computing device 1000 may include, but is not limited to: personal computers, server computers, workstations, desktop computers, laptop computers, notebook computers, mobile computing devices, smart phones, tablet computers, mobile phones , Personal Digital Assistants (PDA), handheld devices, messaging equipment, wearable computing equipment, consumer electronics equipment, etc.
According to one embodiment, a program product such as a non-transitory machine-readable medium is provided. The non-transitory machine-readable medium may have instructions (ie, the above-mentioned elements implemented in the form of software), which when executed by a machine, cause the machine to perform various operations described above in conjunction with FIGS. and function.
Specifically, a system or device equipped with a readable storage medium may be provided, on which a software program code for realizing the function of any one of the above embodiments is stored, and the computer or device of the system or device The processor reads and executes the instructions stored in the readable storage medium.
In this case, the program code read from the readable medium itself can realize the function of any one of the above embodiments, so the machine readable code and the readable storage medium storing the machine readable code constitute the present invention a part of.
Examples of readable storage media include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD-RW), tape , Non-volatile memory card and ROM. Alternatively, the program code can be downloaded from the server computer or the cloud via the communication network.
Those skilled in the art should understand that the various embodiments disclosed above can be modified and modified without departing from the essence of the invention. Therefore, the scope of protection of the present invention should be limited by the scope of the attached patent application.
It should be noted that not all steps and units in the above-mentioned processes and system structure diagrams are necessary, and some steps or units can be omitted according to actual needs. The order of execution of each step is not fixed, and can be determined as needed. The device structure described in the foregoing embodiments may be a physical structure or a logical structure. That is, some units may be implemented by the same physical entity, or some units may be implemented by multiple physical entities, or may be implemented by multiple physical entities. Some components in independent devices are implemented together.
In the above embodiments, the hardware unit or module can be implemented mechanically or electrically. For example, a hardware unit, module, or processor may include a permanent dedicated circuit or logic (such as a dedicated processor, FPGA or ASIC) to complete the corresponding operation. The hardware unit or processor may also include programmable logic or circuits (such as general-purpose processors or other programmable processors), which may be temporarily set by software to complete corresponding operations. The specific implementation mode (mechanical method, or dedicated permanent circuit, or temporarily set circuit) can be determined based on cost and time considerations.
The specific implementations set forth above in conjunction with the drawings describe exemplary embodiments, but do not represent all embodiments that can be implemented or fall within the protection scope of the patent application. The term "exemplary" used throughout this specification means "serving as an example, instance, or illustration", and does not mean "preferred" or "advantageous" over other embodiments. The detailed description includes specific details for the purpose of providing an understanding of the described technology. However, these techniques can be implemented without these specific details. In some instances, in order to avoid incomprehensibility to the concepts of the described embodiments, conventional structures and devices are shown in block diagram form.
The foregoing description of the present disclosure is provided to enable any person of ordinary skill in the art to implement or use the present disclosure. For those of ordinary skill in the art, various modifications to the present disclosure are obvious, and the general principles defined herein can also be applied to other modifications without departing from the protection scope of the present disclosure. Therefore, the present disclosure is not limited to the examples and designs described herein, but is consistent with the broadest scope that conforms to the principles and novel features disclosed herein.
