數字化推動銀行通過Microservices架構中設計的銀行API在各種開放平臺上提供服務。本文分享了Microservices的關鍵架構考慮事項。
Microservices是一種在容器化環境 (containerized environments) 中用於設計分布式和可擴展 API 的架構風格。常見的用例是下訂單、信息查詢和數據流。
這些用例的 API 是自發的、松散耦合(loosely-coupled)的並以協作方式處理事件。
以下是Microservices API架構設計的五個考慮事項:
1. 動態配置
2. 服務發現
3. 負載平衡
4. 斷路器
5. 分布式跟蹤
1. 動態配置
Microservices API支持不同環境下的多個實例。每個環境可能有不同的配置，例如IP地址、CPU或內存。
因此，設計應該考慮一個集中的配置服務，為不同的API實例提供不同的配置。
此外，設計還應考慮無需重啟API實例即可自動刷新配置。其中一種方法是定期從服務刷新配置。
或者，我們可以利用消息代理實時刷新API配置。當配置發生變化時，配置服務可以將新配置發送到消息代理，然後通過消息隊列將其推送到API。
2. 服務發現
除了從外部調用Microservices API外，Microservices API還可以協作以滿足要求。
因此，設計時應考慮API發現服務，該服務發布所有當前在線API及其調用詳細信息的在線實時目錄。
在容器環境下，API調用是可以動態改變的，比如容器每次啟動時可能會為API實例分配不同的IP。
為了維護發現服務的實時信息，每個API可以在服務啟動時向服務發送註冊消息。然後定期向發現服務發送心跳信號。一段時間內沒有心跳信號的API應視為離線並從列表中刪除。
3. 負載平衡
由於Microservices API具有高度可擴展性，因此可以同時運行多個API實例。設計應考慮在運行的API實例之間分配傳入請求的負載平衡。
有兩種負載平衡方法：服務器端和客戶端。
服務器端方法將硬件或軟件服務器置於API與其使用者之間。所有傳入請求都將傳輸到負載平衡器，負載平衡器將根據其負載平衡策略將請求重新定向到API。
服務器端方法的優點是獨立於API和使用者的實現。缺點是網絡延遲高。
客戶端方法在API客戶端中嵌入了負載平衡模塊。所有API實例信息都包含在API客戶端的內存空間中，因此可以直接調用API實例。
客戶端負載均衡的優點是網絡延遲低。缺點是依賴於API實現。
常見的用例是外部API使用者使用服務器端方法，並使用客戶端方法進行API間協作。
4. 斷路器
由於Microservices API會對客戶端請求進行協作，因此一個API的故障將導致級聯故障並使客戶端請求無響應。
Microservices設計應考慮使用斷路器來保護API免受級聯故障的影響。
斷路器是一種軟件設備，可根據預定義的條件和臨界值檢測API故障。在API失敗的情況下，它將應用恢復或回退的方法，例如調用替代API或返回緩存值。
斷路器有三種狀態：
關閉 - 此狀態表示所有API都正常，斷路器不會幹預API調用過程。
開啟 - 這種狀態意味著存在API故障，斷路器將應用恢復或回退方法。
半開 - 在開啟狀態一段時間後，斷路器將自動變為半開狀態。在這種狀態下，斷路器將再次調用失敗的API。如果調用成功，則將其狀態更改為關閉，否則將其狀態更改為開啟。
5. 分布式跟蹤
Microservices API的分布式特性讓執行跟蹤和調試非常困難。因此，Microservices API的設計應該考慮分布式跟蹤機製。
我們可以應用審計跟蹤服務，為AP使用者的每個調用提供唯一標識符。唯一標識符將傳遞給每個API之間調用並寫入日誌條目。
審計跟蹤分析工具會從不同的API實例中檢索日誌條目，然後根據唯一標識符和時間標識對日誌進行整合、分析和重組，以確定API事件的執行鏈和時間順序。
緯泓是香港、新加坡和中國的頂級金融科技企業。自1998年以來，我們一直在幫助金融機構實施全球銀行解決方案
Copyright © 2021 緯泓 版權所有，不得轉載
Comments