為什麼說金融科技公司應該遷移到微服務架構？

最新 06-26

在這篇文章中，我將介紹我對於一些微服務相關問題的看法。第一個問題是為什麼金融科技公司應當把遺留的傳統架構應用遷移到現代的架構風格上；其次，如何在這一範式遷移過程中重用現有的應用資產；最後是這種遷移將以何種方式解決這一領域中包括代碼質量和重用性在內的一系列令人望而生畏的問題。

一個典型的金融科技公司往往都處於盡早走向市場的壓力中，這種壓力來源於股東和其他利益相關者。因而類似的公司在早期並不會給予應用架構足夠的重視。他們往往採用單體架構建立應用程序。這一架構易於實現，但在增加功能時會形成緊密的依賴關係。這一領域法規、稅收結構、許可證和資本要求的頻繁變動也加劇了這種混亂狀況。為了滿足新的相關要求，已經有大量的時間和努力消耗在了重新修改已有應用上。而這經常會引入新的錯誤並打斷現有的功能。在這一應對挑戰的過程中，這些公司最終會創建出亂麻一般的代碼，並由此導致代碼質量的惡化，以及維護噩夢。對於難以適應變化的單體架構而言這種問題會更加嚴重。

單體應用的架構是單層結構，用戶介面和數據訪問代碼都集成在一個平台中。

這種架構的簡單性使得最初構建和部署至生產環境的時間消耗非常少。相較於現代的web應用架構，這種架構會提供更高的性能（響應時間），因為在資料庫和應用介面之間的層次很少。但即使這樣，單體架構仍然缺少一些關鍵的特性，例如：

敏捷性和可維護性- 程序單元和代碼行數會隨著功能的增加而增長。一切都集中在一個程序中。這同樣會為業務功能的實現帶來巨大的挑戰，因為每次修改都必須對應用進行完整的測試。

可用性- 單體應用程序有更高的風險。因為即使應用程序的一部分發生中斷，它也可能會影響整個應用程序並可能導致應用程序崩潰。

可重用性- 可重用性僅局限於同一層內和同一程序單元中的方法和函數重用。儘管原則上可以在單體應用程序中創建獨立模塊，但鮮有實現。

可擴展性- 大多數金融科技公司都從一個細分產品起步，而這隻會影響金融業務流程中的一個小環節。即使用戶起初並不能快速適應，然而他們一旦開始從這種細分產品中獲益，用戶數就會逐漸增加。人們非常期望應用程序具有高度的可擴展性以及能夠支持高並發使用，同時又不需與最初的用戶吞吐量相妥協。

可測試性- 由於不同程序單元之間存在著複雜的相互依賴性，即使一個微小的功能變化測試，在這種單體應用中都會是一個挑戰。

微服務是一種以業務功能為中心的架構風格，而非基於UI，中間件和資料庫等技術因素。一個微服務就是一個獨立的單元，代表一個模塊端到端的功能。一個應用程序包含一個或多個模塊。因此，一組微服務就代表了一個應用程序。該體系結構推薦為每個服務設置獨立的資料庫（基於業務邏輯）。

這種架構的一些主要優點是：

它帶來了團隊組織範式的轉變。每一個模塊都有一組中間件和資料庫開發者以及質量保證（QA）測試員負責端到端的功能開發、測試和服務交付。又因為團隊成員會利用不同的技術為同一個模塊工作，這種組織方式增強了團隊凝聚力、主人翁意識和責任感。

微服務架構能夠為構建和管理銀行業和金融業應用提供更強的敏捷性。這些應用在本質上具有複雜的設計，需要持續的進化和擴容，能與多種外部和內部系統相集成以及達到多種層次的高安全要求。

相較於維護一個包含了所有功能的大型單一應用，維護獨立的微服務要容易得多。每個微服務在源代碼庫中都是獨立開發和維護的。這種分離的架構允許以更快，更高效的方式實現對應用程序的功能更改。這是因為開發一個全新的微服務並不需要很長時間。單元測試和代碼審閱也變得非常簡單。這種方法最終有助於提高應用程序的質量並減少缺陷。

在大多數情況下，應用程序對於終端用戶都是可用的。因為在單個微服務出現問題的情況下，可以卸載單獨的服務，並且可以安裝新版本，同時不會導致整個應用程序在維護時段內停機。

可重用性有兩個方面：

服務可重用性 -這是可能的，因為每個微服務設計目的是體現應用程序的一個功能。這為重用不同的功能模塊提供了更高的靈活性。例如：證券的定價可以被開發為一個Web服務（模塊A，我們稱之為PriceService）。它將支持插入或更新證券最新價格的操作。價格可以feed的形式每日從諸如Bloomberg等市場信息來源獲取。交易流程處理可以被開發為另一個Web服務（模塊B，我們稱它為TradeProcessingService）。為了處理已經投資於證券的基金的交易，它需要最新的價格數據。因此，TradeProcessingService服務將在交易處理期間使用PriceService。

代碼可重用性 -服務體系結構本質上消除了代碼冗餘。現有的遺留技術可以進行邏輯分割，並且每個邏輯單元都能轉換為可重用的服務。這樣，我們不僅可以提高代碼質量，還可以重用我們現有的核心資產，並節省用現代語言重新編寫它們所付出的巨大努力。因為基於同一種語言構建所有服務並非必要，所以微服務架構中的單個服務可以用適合他們的語言編寫。這種架構的關鍵優勢之一是互操作性，因為微服務是技術無關的。

與傳統架構不同，微服務架構天然支持橫向擴展，以滿足並發用戶和交易量的增加。現代微服務平台 - 例如基於Spring引導，Zuul和Eureka組合的平台 - 支持以簡單高效的方式水平擴展服務。

可測試性會在更大程度上得到改善。行業標準指出，在有良好工程設計的應用程序中，測試佔據了成本的40％。如果軟體架構師可以降低這個成本，那麼回報就會很大。要使應用程序得以適當地測試，必須能夠控制每個服務的內部狀態和輸入，然後觀察其輸出。基於微服務的體系結構支持這種方法。每個微服務都可以獨立於其他部分進行完整的測試。這大大減少了全功能單體應用程序達到可測試狀態的等待時間。在上面的例子中，TradeProcessingService和PriceService服務都可以獨立開發和測試。

基於以上所有觀點，我們能否假設微服務架構是未來的方向？事實上，兩種架構各有所長。在決定採用這條道路之前，有幾個因素需要考慮。其中一些是：

分析現有的複雜混亂的代碼，從中分離出業務邏輯，並將他們構建成可重用的，有清晰、嚴格邊界的微服務，完成這些任務的成本非常高昂。你需要一批對當前代碼非常了解，並且具有不同技能專長的的開發者協助完成這一轉換過程。

從某種意義上說，基於微服務的體系結構的維護比較簡單，但它帶來了額外的挑戰，例如監視單個服務的正常運行時間，管理每個微服務的不同版本（包括運行時和源代碼庫）。

與基於微服務的體系結構相比，單體應用程序的故障排除相當容易，因為技術層的數量非常有限。現在，在新的架構體系中，服務集群遍佈於不同的

因而我們需要構建一個集中的日誌記錄和審計平台來識別有問題的服務，然後對其進行故障排除。這為今天單體應用支持團隊的工作方式帶來了變化。

我們應該制定交付政策，定期提供不同版本的微服務。

我們需要應對個別服務故障導致整體微服務組所提供的功能失效的情況

與單體應用相比，微服務需要更多的硬體和計算資源。

事實上，遷移到微服務牽涉到風險，努力和成本。但是，如果我們能制定正確的策略，那麼從長遠來看，應用程序的整體質量將會增加。這是無可否認的。如果沒有架構的範式轉變，無論我們投入多少資金改進單體應用的質量，投資回報率和收益率將非常小。為了消除這種遷移風險，公司可以考慮先用微服務架構完成新需求的開發，並逐漸將傳統模塊轉變為基於微服務的體系結構。