top of page

Microservices - 架構考慮事項

已更新:6月14日



數字化推動銀行通過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事件的執行鏈和時間順序。



感謝您閱讀這篇文章。有關詳細的 Microservices 架構考量事項,請聯繫我們 如果您想獲得更多關於金融科技的信息,請關註我們的 LinkedIn 或訂閱金融科技透视”。



緯泓是香港、新加坡和中國的頂級金融科技企業。自1998年以來,我們一直在幫助金融機構實施全球銀行解決方案


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


26 次查看

Comments


bottom of page