top of page

銀行實施Microservices的三大挑戰

已更新:6月14日



在當前API的趨勢下,銀行開始將Microservices作為API框架來開發實施,有些銀行甚至將其視為許多問題的對策。

 

​例如性能,復原能力,可伸縮性等,甚至有人聲稱核心銀行的未來也將落在Microservices。


Microservices無疑具有解決許多問題的能力,但它有其局限性。這裏,我們列出了在銀行實施Microservices的三個主要挑戰。

1. 交易管理

2. 服務績效

3. 應用程序分區

 

交易管理


分布式計算中的交易完整性始終是一個問題。 

 

由於Microservices是分布式計算的技術,因此在不同的Microservices或不同的服務器中進行交易時,將很難管理這些交易的整體完整性。

 

舉例,您可以從一個帳戶中取款,但無法將資金存入另一個賬戶。

 

針對這個問題,有幾種解決方案,例如分布式交易處理協調器,但它的性能很慢。

 

另一種解決方案是采用交易訂閱體系結構,但它可能會有數據不一致的窗口。

 

我們的建議是避免分布式交易。因此,您可以將所有交易納入一項服務的方式對Microservices進行分區。

 

服務性能


盡管Microservices可以將負載分配到不同的服務器,但是它不能保證每個單獨調用的性能。

 

這是因為每個單獨的調用都可能觸發許多Microservices,所有Microservices都通過網絡進行傳達,並且網絡的效率性、延時性和可靠性永遠無法保證。

 

應用程序分區

​傳統應用程序的體系結構方法是Monolithic。軟件架構師需要采用一種嶄新的Microservices架構方法。

 

他們必須將單個應用程序分解為許多小型服務,每個服務都可以獨立運行和管理。

 

應用程序分區是對每個應用程序逐個案例進行練習。

 

除了技術知識,設計人員還需要相關行業領域的知識。我們認為行業領域知識比技術知識更為重要。

 

舉例,如果您要開發基於Microservices的訂單管理系統(OMS),您需要了解證券交易的生命周期。這樣您才可以更好地定義系統邊界。

 

我們看到銀行業正在大肆宣傳使用Microservices。但這不是靈丹妙藥,某些情況完全不適合使用Microservices。

 

我們曾經看到一個從以數據庫為中心的應用程序遷移到Microservices體系結構的案例 (存儲過程中有超過10萬行代碼)。毋庸置疑,該項目以失敗告終。

 

簡而言之,Monolithic方法具有許多優點。而Microservices方法是否適合您,將取決於您要處理什麽問題。


感謝您閱讀這篇文章。想了解更多關於 Microservices 在銀行中的運用,請聯系我们。 


如果您想獲得更多關於金融科技的信息,請關註我們的LinkedIn 或訂閱 “FinTech Insights”.


Copyright © 2021 緯泓  版權所有,不得轉載

22 次查看0 則留言

Comments


bottom of page