隨著互聯(lián)網(wǎng)金融業(yè)務(wù)和相關(guān)技術(shù)的不斷發(fā)展，傳統(tǒng)金融行業(yè)為滿足業(yè)務(wù)快速發(fā)展需求，正在積極引入各類開源技術(shù)，以快速搶占市場。那么，以金融和科技作為雙驅(qū)動的平安銀行在開源技術(shù)的引入方面是如何評估，運(yùn)用到哪些業(yè)務(wù)場景，以及面對復(fù)雜的網(wǎng)絡(luò)環(huán)境，是如何去部署的呢？

本文將以 Apache RocketMQ 為例，和您一起了解平安銀行在開源技術(shù)選型方面的思考和實踐。

?? RocketMQ 在平安銀行的應(yīng)用場景；

?? 復(fù)雜網(wǎng)絡(luò)環(huán)境下的部署實踐；

?? 多隔離區(qū)場景下的部署情況；

?? 多 IDC 場景下的部署情況；

?? 改造實踐和遇到的小插曲；

RocketMQ 在平安銀行的應(yīng)用場景

目前，平安銀行通過 RocketMQ 解決了數(shù)據(jù)預(yù)加、信息通知和狀態(tài)變化方面的業(yè)務(wù)需求，接下來，我們通過 App 登錄、資產(chǎn)總覽和工資理財 3 個應(yīng)用場景來展開講下。

App 登錄：

當(dāng)用戶打開平安銀行 App 的時候，系統(tǒng)會根據(jù)用戶的登錄 ID 去加載相應(yīng)的用戶數(shù)據(jù)，比如銀行卡、信用卡和理財產(chǎn)品等，以及一些系統(tǒng)通知。這個場景下，我們用到了 RocketMQ 的異步處理能力，即預(yù)加載需要使用的數(shù)據(jù)，提升用戶體驗。

資產(chǎn)總覽：

進(jìn)入平安銀行 App 資產(chǎn)總覽的頁面，頁面顯示賬戶余額、各類理財產(chǎn)品（黃金、基金和股票等），以及貸款等方面的信息。平安銀行對接了各類基金、黃金和股票等來自不同金融主體、不同系統(tǒng)的數(shù)據(jù)，具有種類多、異構(gòu)系統(tǒng)多和變化快的特點。我們的目標(biāo)就是讓資產(chǎn)總覽數(shù)據(jù)盡可能準(zhǔn)確，不同種類的資產(chǎn)變動的時候發(fā)出通知，資產(chǎn)系統(tǒng)收到通知后，根據(jù)變化的數(shù)據(jù)來計算出用戶當(dāng)前的資產(chǎn)總覽。

工資理財：

工資理財是指每月工資下發(fā)到銀行卡后，系統(tǒng)可以實現(xiàn)自動買入用戶設(shè)置好的理財產(chǎn)品，例如買一些定投類的理財產(chǎn)品。這里信息的傳遞流程是：

• 銀行卡里的余額出現(xiàn)變動，系統(tǒng)把變動信息發(fā)送到消息引擎；

• Consumer 端進(jìn)行消費(fèi)，通知用戶賬戶已經(jīng)出現(xiàn)變化；

• 系統(tǒng)判斷變動是否來源于代發(fā)工資；

• 如果是，系統(tǒng)會再發(fā)送一條消息；

• 理財?shù)?nbsp;Consumer 進(jìn)行消費(fèi)；

• 判斷現(xiàn)在是不是應(yīng)該買入工資理財類的產(chǎn)品；

• 如果是，自動買入用戶設(shè)定好的理財產(chǎn)品；

• 自動買入之后，余額再次變動，系統(tǒng)會再一次通知，這一次通知，判斷的就是一些其他的邏輯了。

那么，在這些場景中，我們對消息引擎會有哪些要求呢？

A、高可用、高可靠和高性能，這是金融行業(yè)引入開源技術(shù)的基本要求；

B、堆積能力，代發(fā)工資的用戶很多，一個公司的員工會在某個時間點集中發(fā)放；

C、順序能力，即賬戶變動在先，發(fā)出通知在后；

D、事務(wù)性能力，如果沒有事務(wù)性，有可能會出現(xiàn)賬戶變動了，但沒有觸發(fā)購買理財產(chǎn)品的情況；

E、重試和延遲消息功能，比如工資發(fā)放的時候，可能是在晚上，這時候系統(tǒng)會自動把購買理財?shù)膭幼鞣旁诘诙彀滋烊ゲ僮?，再發(fā)出通知；

F、消息回溯能力，就是出現(xiàn)問題的時候，我們可以把這個消息進(jìn)行回溯，重新進(jìn)行消息的處理，提供完整的消息軌跡；

在技術(shù)選型的過程中，RocketMQ 符合我們在這些典型使用場景中對消息產(chǎn)品的需求，在引入的過程中，平安銀行也對社區(qū)做了相應(yīng)的貢獻(xiàn)。

復(fù)雜網(wǎng)絡(luò)環(huán)境下的部署實踐

多測試子環(huán)境下的服務(wù)調(diào)用場景

平安銀行有多套測試子環(huán)境，用來對不同的feature進(jìn)行測試，即圖中的 FAT、FAT001?FAT002?FAT003等。傳統(tǒng)銀行系統(tǒng)由大型機(jī)時代向更面向互聯(lián)網(wǎng)用戶的零售時代轉(zhuǎn)型過程中，不可避免微服務(wù)化，傳統(tǒng)較集中式系統(tǒng)會被劃分為較多的微服務(wù)，正常的情況如下圖，服務(wù) A 調(diào)用服務(wù) B，服務(wù) B 調(diào)用服務(wù) C，服務(wù) C 調(diào)用服務(wù) D。

隨著業(yè)務(wù)的需求，新的 feature，我們需要對服務(wù) A 和 B 進(jìn)行改動。相比在FAT環(huán)境里去部署測試，更合適的方式是另起一套 FAT 環(huán)境，這里我們命名為 FAT001，把服務(wù)A和B部署上去，A 調(diào)用 B，B會調(diào)用原來 FAT 環(huán)境里的 C 和 D。

此時，另一個新的需求，需要對服務(wù) A 和 C 進(jìn)行改動。如果直接發(fā)布到FAT 或 FAT001 肯定是不對的，會影響正在進(jìn)行的測試，此時，我們會再起一套測試環(huán)境，命名為FAT002，發(fā)布服務(wù) A 和 C。由于 FAT002 里沒有服務(wù) B，所以服務(wù)A要調(diào)用服務(wù) B 就需要去 FAT 環(huán)境（FAT 定義為較穩(wěn)定的測試子環(huán)境）。服務(wù) B 調(diào)用服務(wù) C 的時候，就不應(yīng)該調(diào)用本環(huán)境的 C了，而是調(diào)動 FAT002 的 C 才能實現(xiàn)測試功能。

再假設(shè)，系統(tǒng)同時還會有另外一個 feature 在測試 C 和 D，此時的調(diào)用邏輯也是一樣的，系統(tǒng)調(diào)用服務(wù) A 和 B 的時候是在 FAT，調(diào)用服務(wù) C 和 D 的時候會到 FAT003 的環(huán)境。

以上的服務(wù)調(diào)用場景是可以通過微服務(wù)框架解決的，進(jìn)行全鏈路測試，但在生產(chǎn)環(huán)境中，用戶的真實請求比測試環(huán)境中會更復(fù)雜一些。

真實的用戶請求過程

我們看一下真實的用戶請求。

APP發(fā)起一個請求請求，進(jìn)入網(wǎng)關(guān)，需要知道請求哪一個測試環(huán)境。通常的做法是：測試人員需要在APP上選好子環(huán)境，例如選擇 FAT001，我們可以直接把請求 FAT001 的網(wǎng)關(guān)（每個環(huán)境網(wǎng)關(guān)單獨部署），或者在requestheader上添加標(biāo)識，讓網(wǎng)關(guān)去區(qū)分它來源于哪一個環(huán)境（網(wǎng)關(guān)統(tǒng)一部署）。假如網(wǎng)關(guān)判斷請求來源于 FAT002，那就會把分發(fā)給 FAT002環(huán)境進(jìn)行處理。

消息層面，如何處理這類用戶請求

以上是服務(wù)調(diào)用的請求路徑，比較好理解，但到了消息隊列上，問題會變得復(fù)雜些，假如一個 feature 只是更改了消費(fèi)者，那如何把這條消息傳遞到改的消費(fèi)者應(yīng)用上去進(jìn)行測試，而不被其它環(huán)境的消費(fèi)者消費(fèi)掉，這是我們需要去考慮的問題。 

來看下具體的情況，集群部署了 Broke A 和 Broke B，TopicA 分別部署在這兩個Broker上。 此時，Producer Group A 向 Topic A 中寫數(shù)據(jù)，Consumer Group A去消費(fèi)，這種情況下是不會有任何問題。

但如果新增一套 FAT001 的環(huán)境，要求 FAT001 發(fā)布的消息，只能由 FAT001 來消費(fèi)，F(xiàn)AT 不能消費(fèi)，這種情況下我們該怎么解決？

• 在消息上面加一些路由、或是加一些Tag、Filter、消息的Property？

  這些都不能解決我們的問題。???♂?

• 每個子環(huán)境部署一套 RocketMQ？

  一方面成本太高，另一方面如果這個feture測試完成了，需要把相關(guān)的應(yīng)用再切回 FAT 進(jìn)行處理，實現(xiàn)太過復(fù)雜。???♂?

我們想一下，多個 feature 同時進(jìn)行測試，DB 會部署一套還是多套？

首先一個 feature 不會更改所在的應(yīng)用，一般來說 DB 是部署一套的，在數(shù)據(jù)庫里面添加字段，來識別數(shù)據(jù)是來源于哪一個子環(huán)境，如果多套部署，不更改的應(yīng)用取不到新部署的 DB 數(shù)據(jù)，無法進(jìn)行全鏈路測試，所以同樣的，我們也沒有在每個子環(huán)境都部署一套 RocketMQ，而是部署統(tǒng)一部署，通過 RPC 路由把請求路由到正確的生產(chǎn)者集，改造消息路由算法把消息路由到正確的消費(fèi)者進(jìn)行處理。

真實的用戶請求過程

生產(chǎn)者變更

在上圖中生產(chǎn)者變更的場景下，默認(rèn)的場景 FAT發(fā)送，F(xiàn)AT 消費(fèi) ，沒有問題的，假設(shè) FAT001 的生產(chǎn)者發(fā)布了，需要 FAT001 發(fā)送到MQ集群，F(xiàn)AT 是可以直接消費(fèi)。

生產(chǎn)者、消費(fèi)者同時變更

在上圖生產(chǎn)者和消費(fèi)者同時變更的場景下，如果消費(fèi)者在 FAT001也部署了應(yīng)用，需要FAT消費(fèi)者不能消費(fèi)由FAT001產(chǎn)生的消息，而是由 FAT001的消費(fèi)者去消費(fèi)。我們的處理方式是在邏輯上把Topic A下面的Queue進(jìn)行分組，相當(dāng)于加了邏輯分組，如果消費(fèi)者在 FAT001 有部署，我們會把 Queue 的分組擴(kuò)大，在其默認(rèn)設(shè)置的情況下再翻一倍，新增的 Queue 就是給到 FAT001 進(jìn)行消費(fèi)的。

只有消費(fèi)者變更

再來看看只有消費(fèi)者變更的場景，如上圖。

假設(shè)有個feature只需要更改消費(fèi)者，部署在 FAT001。也是可以通過邏輯分組的方式，實現(xiàn)生產(chǎn)者根據(jù)請求來源來發(fā)送消息到隊列 FAT001 邏輯分組內(nèi)的 Queue，從而只讓部署在 FAT001 的消費(fèi)者消費(fèi)。

通過以上 3 個場景，我們了解到添加邏輯分組的必要性，實現(xiàn)過程并不復(fù)雜。主要做了以下調(diào)整：???

• 這個邏輯分組什么時候建立？

  新建 Topic 的時候，全部建好？還是 Consumer 上線/下線的時候動態(tài)的去進(jìn)行調(diào)整？

我們選擇了動態(tài)創(chuàng)建的方式，這個過程中，我們添加了 Meta Server 進(jìn)行元數(shù)據(jù)管理，進(jìn)行動態(tài)創(chuàng)建：

• 添加 Meta Service，管理的元數(shù)據(jù)包括 Producer、Consumer、Topic、Queue 和 Subenv等信息：

• 調(diào)整 Producer，取Request Head 里面請求來源（FAT、FAT001、FAT002...），如果 Topic 對應(yīng)的存在分組，選擇分組的 Queue，否則發(fā)到默認(rèn)分組呢的Queue；

• 調(diào)整 Consumer，上線時判斷應(yīng)用部署的分組（FAT、FAT001、FAT002...），如果Topic不存在對應(yīng)的分組，則新建；存在，則 rebalalce (新Consumer節(jié)點上線)，下線時，判斷該分組是否還存在 其它Consumer實例，若不存在，刪除分組，否則 rebalalce(Consumer某一節(jié)點下線)；

多隔離區(qū)場景下的部署實踐

由于對安全上的重視，金融行業(yè)的網(wǎng)絡(luò)環(huán)境相比其他行業(yè)會更復(fù)雜。整個隔離區(qū)分為以下幾個部分：

• DMZ 區(qū)：

外網(wǎng)可以直接訪問，用于放置網(wǎng)關(guān)；

• Web 區(qū)：

面向的是用戶手機(jī)，或者網(wǎng)頁上可以看到的功能應(yīng)用；

• 核心區(qū)：

包含核心的調(diào)用邏輯功能，和交易、訂單相關(guān)的核心應(yīng)用，例如 DB 和存儲；

• 外聯(lián)區(qū)：

用于訪問外網(wǎng)，有時候也會部署一些 Poxy 代理，因為內(nèi)網(wǎng)不能直接訪問外網(wǎng)，需要通過代理去訪問外網(wǎng)；

• 專用區(qū)域：

對接基金、三方存管等外部系統(tǒng)。在金融行業(yè)，如果某個系統(tǒng)是閉環(huán)的，那必須要去做隔離；

• 管理區(qū)：

是指對整個區(qū)域的應(yīng)用要進(jìn)行集中管理，且數(shù)據(jù)流動是單向的，只能取數(shù)據(jù)，不能通過管理區(qū)把某區(qū)域的數(shù)據(jù)推送到另一區(qū)域。

此外，從安全的角度出發(fā)，所有的區(qū)域在生產(chǎn)環(huán)境下都通過防火墻進(jìn)行隔離，這就給我們部署 RocketMQ 帶來了很大的實施難度。如果只部署一套，面對這么多的防火墻，生產(chǎn)者消費(fèi)者到集群的的流量跨墻，會給網(wǎng)絡(luò)帶來極大的不穩(wěn)定，遇到瓶頸，防火墻幾乎無法在線平滑擴(kuò)容；如果每個子環(huán)境都部署一套，又帶來運(yùn)維復(fù)雜度，而且還是存在數(shù)據(jù)同步和跨墻消費(fèi)的問題。

最終，我們采用的是折中的辦法，即統(tǒng)一部署加分隔離區(qū)部署，這樣做的益處是：??

• 防火墻是開大策略，保證安全的前提下，符合監(jiān)管要求；

• 針對跨隔離區(qū)消費(fèi)的問題，我們采用復(fù)制的方式，模擬消費(fèi)者重新寫入目標(biāo)集群；

多IDC場景下的部署實踐

同城多IDC，可以認(rèn)為近似局域網(wǎng)，比較好處理，但異地多IDC多活場景，目前我們還沒有特別好的解方案，多活不可避免面臨數(shù)據(jù)分片、數(shù)據(jù)合并和數(shù)據(jù)沖突的解決等問題。

如果 Topic 下數(shù)據(jù)有多活需求，我們暫時通過復(fù)制方式來處理。但這類手工模擬消費(fèi)者消費(fèi)數(shù)據(jù)寫入新集群的復(fù)制方式，會存在一些問題，即復(fù)制到另一個集群之后 offset 會改變，處理邏輯就會有偏差。我們通過 pull 的方式自定義的去根據(jù) offset 去進(jìn)行消費(fèi)。當(dāng)故障轉(zhuǎn)移到新的集群需要去消費(fèi)的時候，需要獲取到新集群里面正確的offset 值。此時，這個值和之前集群里的已經(jīng)不一樣了，需要根據(jù)時間得到新集群里正確的offset 值，再去進(jìn)行消費(fèi)。在沒有更好的解決方案前，治理就顯得很關(guān)鍵了。

不過，我們注意到，在 RocketMQ 最新發(fā)布的版本里，提供了 DLedger 的特性，DLedger 定位的是一個工業(yè)級的 Java Library，可以友好地嵌入各類 Java 系統(tǒng)中，滿足其高可用、高可靠、強(qiáng)一致的需求。我們會盡快對這一特性進(jìn)行集成和測試。

改造實踐和遇到的小插曲

我們在對 RocketMQ 的使用過程中，添加了以下功能或特性：??

A. 為生產(chǎn)者提供消息的堆積能力。

B. 將所有配置管理部署到配置中心，并做云端化處理，以滿足動態(tài)修改的需求。

C. 在 4.3 版本還未提供事務(wù)處理能力前，我們在本地數(shù)據(jù)庫里去建一張消息表，數(shù)據(jù)庫更改數(shù)據(jù)狀態(tài)的時候，會同步將數(shù)據(jù)寫入消息表。若發(fā)送失敗，則進(jìn)行補(bǔ)償。并在客戶端里進(jìn)行封裝。

D. 實現(xiàn)統(tǒng)一的消息者冪等處理。

E. 添加身份認(rèn)證和消息認(rèn)證（注：RocketMQ 4.3 版本中已經(jīng)實現(xiàn)身份認(rèn)證功能）

當(dāng)然，也遇到了一些小插曲，基本都是使用上的小問題，可能大家也會碰到：??

A. 一個應(yīng)用使用多個RocketMQ集群時，未加載到正確的配置。在Client 端，如果沒有對instancename 進(jìn)行配置，一個應(yīng)用連多個集群會失敗。

B. 在大數(shù)據(jù)的場景下，內(nèi)存溢出。訂閱的 Topic 越多，每個 Queue 在本地緩存的 message 也會越多，默認(rèn)每個 Queue 1000條，可能會把內(nèi)存打爆，可根據(jù)實際情況調(diào)整。

C. 刪除數(shù)據(jù)時 IO 抖動，默認(rèn)每天凌晨4點刪除數(shù)據(jù)，量上來后出現(xiàn) IO 抖動，配置了消息刪除策略，默認(rèn)逗號分隔開，多配幾個時間刪除就可以了。

D. Broker上日志報延遲消息找不到數(shù)據(jù)文件。在主備切換的演練過程中，出現(xiàn)了延遲消息在Broker 上處理異常的情況。當(dāng)主切換到備端時，延遲消息在 Broker 上保存的文件被自動刪除，再切回主，由于延時消息的元數(shù)據(jù)感覺在，會查詢文件進(jìn)行處理，此時已找不到文件。

E. 掛 NAS 的時候，IP 獲取了 NAS 的私網(wǎng)地址，并被提交給了服務(wù)端。

以上就是我們在部署過程中遇到的一些小插曲，基本都是可以很快定位原因，解決的。

總的來看，RocketMQ 對平安銀行的消息系統(tǒng)建設(shè)的幫助是非常大的，尤其是滿足了數(shù)據(jù)持久化、順序消費(fèi)和回溯的需求，此外，在消息的查詢方面，也比我們之前使用的消息引擎好很多。最后再分享一點自己對中間件的一點感悟：中間件使用重在治理，規(guī)范不先行，開發(fā)兩行淚。