RocketMQ 在平安銀行的實(shí)踐應(yīng)用!
隨著互聯(lián)網(wǎng)金融業(yè)務(wù)和相關(guān)技術(shù)的不斷發(fā)展，傳統(tǒng)金融行業(yè)為滿足業(yè)務(wù)快速發(fā)展需求，正在積極引入各類開源技術(shù)，以快速搶占市場。那么，以金融和科技作為雙驅(qū)動(dòng)的平安銀行在開源技術(shù)的引入方面是如何評估，運(yùn)用到哪些業(yè)務(wù)場景，以及面對復(fù)雜的網(wǎng)絡(luò)環(huán)境，是如何去部署的呢？...
隨著互聯(lián)網(wǎng)金融業(yè)務(wù)和相關(guān)技術(shù)的不斷發(fā)展，傳統(tǒng)金融行業(yè)為滿足業(yè)務(wù)快速發(fā)展需求，正在積極引入各類開源技術(shù)，以快速搶占市場。那么，以金融和科技作為雙驅(qū)動(dòng)的平安銀行在開源技術(shù)的引入方面是如何評估，運(yùn)用到哪些業(yè)務(wù)場景，以及面對復(fù)雜的網(wǎng)絡(luò)環(huán)境，是如何去部署的呢？
本文將以 Apache RocketMQ 為例，和您一起了解平安銀行在開源技術(shù)選型方面的思考和實(shí)踐。
RocketMQ 在平安銀行的應(yīng)用場景；
復(fù)雜網(wǎng)絡(luò)環(huán)境下的部署實(shí)踐；
多隔離區(qū)場景下的部署情況；
多 IDC 場景下的部署情況；
改造實(shí)踐和遇到的小插曲；
RocketMQ 在平安銀行的應(yīng)用場景
目前，平安銀行通過 RocketMQ 解決了數(shù)據(jù)預(yù)加、信息通知和狀態(tài)變化方面的業(yè)務(wù)需求，接下來，我們通過 App 登錄、資產(chǎn)總覽和工資理財(cái) 3 個(gè)應(yīng)用場景來展開講下。
App 登錄：
當(dāng)用戶打開平安銀行 App 的時(shí)候，系統(tǒng)會(huì)根據(jù)用戶的登錄 ID 去加載相應(yīng)的用戶數(shù)據(jù)，比如銀行卡、信用卡和理財(cái)產(chǎn)品等，以及一些系統(tǒng)通知。這個(gè)場景下，我們用到了 RocketMQ 的異步處理能力，即預(yù)加載需要使用的數(shù)據(jù)，提升用戶體驗(yàn)。
資產(chǎn)總覽：
進(jìn)入平安銀行 App 資產(chǎn)總覽的頁面，頁面顯示賬戶余額、各類理財(cái)產(chǎn)品（黃金、基金和股票等），以及貸款等方面的信息。平安銀行對接了各類基金、黃金和股票等來自不同金融主體、不同系統(tǒng)的數(shù)據(jù)，具有種類多、異構(gòu)系統(tǒng)多和變化快的特點(diǎn)。我們的目標(biāo)就是讓資產(chǎn)總覽數(shù)據(jù)盡可能準(zhǔn)確，不同種類的資產(chǎn)變動(dòng)的時(shí)候發(fā)出通知，資產(chǎn)系統(tǒng)收到通知后，根據(jù)變化的數(shù)據(jù)來計(jì)算出用戶當(dāng)前的資產(chǎn)總覽。
工資理財(cái)：
工資理財(cái)是指每月工資下發(fā)到銀行卡后，系統(tǒng)可以實(shí)現(xiàn)自動(dòng)買入用戶設(shè)置好的理財(cái)產(chǎn)品，例如買一些定投類的理財(cái)產(chǎn)品。這里信息的傳遞流程是：
銀行卡里的余額出現(xiàn)變動(dòng)，系統(tǒng)把變動(dòng)信息發(fā)送到消息引擎
Consumer 端進(jìn)行消費(fèi)，通知用戶賬戶已經(jīng)出現(xiàn)變化；
系統(tǒng)判斷變動(dòng)是否來源于代發(fā)工資；
如果是，系統(tǒng)會(huì)再發(fā)送一條消息；
理財(cái)?shù)?Consumer 進(jìn)行消費(fèi)；
判斷現(xiàn)在是不是應(yīng)該買入工資理財(cái)類的產(chǎn)品；
如果是，自動(dòng)買入用戶設(shè)定好的理財(cái)產(chǎn)品；
自動(dòng)買入之后，余額再次變動(dòng)，系統(tǒng)會(huì)再一次通知，這一次通知，判斷的就是一些其他的邏輯了。
那么，在這些場景中，我們對消息引擎會(huì)有哪些要求呢？
A、高可用、高可靠和高性能，這是金融行業(yè)引入開源技術(shù)的基本要求；
B、堆積能力，代發(fā)工資的用戶很多，一個(gè)公司的員工會(huì)在某個(gè)時(shí)間點(diǎn)集中發(fā)放；
C、順序能力，即賬戶變動(dòng)在先，發(fā)出通知在后；
D、事務(wù)性能力，如果沒有事務(wù)性，有可能會(huì)出現(xiàn)賬戶變動(dòng)了，但沒有觸發(fā)購買理財(cái)產(chǎn)品的情況；
E、重試和延遲消息功能，比如工資發(fā)放的時(shí)候，可能是在晚上，這時(shí)候系統(tǒng)會(huì)自動(dòng)把購買理財(cái)?shù)膭?dòng)作放在第二天白天去操作，再發(fā)出通知；
F、消息回溯能力，就是出現(xiàn)問題的時(shí)候，我們可以把這個(gè)消息進(jìn)行回溯，重新進(jìn)行消息的處理，提供完整的消息軌跡；
在技術(shù)選型的過程中，RocketMQ 符合我們在這些典型使用場景中對消息產(chǎn)品的需求，在引入的過程中，平安銀行也對社區(qū)做了相應(yīng)的貢獻(xiàn)。
復(fù)雜網(wǎng)絡(luò)環(huán)境下的部署實(shí)踐
多測試子環(huán)境下的服務(wù)調(diào)用場景
平安銀行有多套測試子環(huán)境，用來對不同的feature進(jìn)行測試，即圖中的 FAT、FAT001?FAT002?FAT003等。傳統(tǒng)銀行系統(tǒng)由大型機(jī)時(shí)代向更面向互聯(lián)網(wǎng)用戶的零售時(shí)代轉(zhuǎn)型過程中，不可避免微服務(wù)化，傳統(tǒng)較集中式系統(tǒng)會(huì)被劃分為較多的微服務(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)行改動(dòng)。相比在FAT環(huán)境里去部署測試，更合適的方式是另起一套 FAT 環(huán)境，這里我們命名為 FAT001，把服務(wù)A和B部署上去，A 調(diào)用 B，B會(huì)調(diào)用原來 FAT 環(huán)境里的 C 和 D。
此時(shí)，另一個(gè)新的需求，需要對服務(wù) A 和 C 進(jìn)行改動(dòng)。如果直接發(fā)布到FAT 或 FAT001 肯定是不對的，會(huì)影響正在進(jìn)行的測試，此時(shí)，我們會(huì)再起一套測試環(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 的時(shí)候，就不應(yīng)該調(diào)用本環(huán)境的 C了，而是調(diào)動(dòng) FAT002 的 C 才能實(shí)現(xiàn)測試功能。
再假設(shè)，系統(tǒng)同時(shí)還會(huì)有另外一個(gè) feature 在測試 C 和 D，此時(shí)的調(diào)用邏輯也是一樣的，系統(tǒng)調(diào)用服務(wù) A 和 B 的時(shí)候是在 FAT，調(diào)用服務(wù) C 和 D 的時(shí)候會(huì)到 FAT003 的環(huán)境。
以上的服務(wù)調(diào)用場景是可以通過微服務(wù)框架解決的，進(jìn)行全鏈路測試，但在生產(chǎn)環(huán)境中，用戶的真實(shí)請求比測試環(huán)境中會(huì)更復(fù)雜一些。
真實(shí)的用戶請求過程
我們看一下真實(shí)的用戶請求。
APP發(fā)起一個(gè)請求請求，進(jìn)入網(wǎng)關(guān)，需要知道請求哪一個(gè)測試環(huán)境。通常的做法是：測試人員需要在APP上選好子環(huán)境，例如選擇 FAT001，我們可以直接把請求 FAT001 的網(wǎng)關(guān)（每個(gè)環(huán)境網(wǎng)關(guān)單獨(dú)部署），或者在requestheader上添加標(biāo)識，讓網(wǎng)關(guān)去區(qū)分它來源于哪一個(gè)環(huán)境（網(wǎng)關(guān)統(tǒng)一部署）。假如網(wǎng)關(guān)判斷請求來源于 FAT002，那就會(huì)把分發(fā)給 FAT002環(huán)境進(jìn)行處理。
消息層面，如何處理這類用戶請求
以上是服務(wù)調(diào)用的請求路徑，比較好理解，但到了消息隊(duì)列上，問題會(huì)變得復(fù)雜些，假如一個(gè) feature 只是更改了消費(fèi)者，那如何把這條消息傳遞到改的消費(fèi)者應(yīng)用上去進(jìn)行測試，而不被其它環(huán)境的消費(fèi)者消費(fèi)掉，這是我們需要去考慮的問題。
來看下具體的情況，集群部署了 Broke A 和 Broke B，TopicA 分別部署在這兩個(gè)Broker上。 此時(shí)，Producer Group A 向 Topic A 中寫數(shù)據(jù)，Consumer Group A去消費(fèi)，這種情況下是不會(huì)有任何問題。
但如果新增一套 FAT001 的環(huán)境，要求 FAT001 發(fā)布的消息，只能由 FAT001 來消費(fèi)，F(xiàn)AT 不能消費(fèi)，這種情況下我們該怎么解決？
在消息上面加一些路由、或是加一些Tag、Filter、消息的Property？
這些都不能解決我們的問題。??
每個(gè)子環(huán)境部署一套 RocketMQ？
一方面成本太高，另一方面如果這個(gè)feture測試完成了，需要把相關(guān)的
應(yīng)用再切回 FAT 進(jìn)行處理，實(shí)現(xiàn)太過復(fù)雜。??
我們想一下，多個(gè) feature 同時(shí)進(jìn)行測試，DB 會(huì)部署一套還是多套？
首先一個(gè) feature 不會(huì)更改所在的應(yīng)用，一般來說 DB 是部署一套的，在數(shù)據(jù)庫里面添加字段，來識別數(shù)據(jù)是來源于哪一個(gè)子環(huán)境，如果多套部署，不更改的應(yīng)用取不到新部署的 DB 數(shù)據(jù)，無法進(jìn)行全鏈路測試，所以同樣的，我們也沒有在每個(gè)子環(huán)境都部署一套 RocketMQ，而是部署統(tǒng)一部署，通過 RPC 路由把請求路由到正確的生產(chǎn)者集，改造消息路由算法把消息路由到正確的消費(fèi)者進(jìn)行處理。
真實(shí)的用戶請求過程
生產(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)者同時(shí)變更
在上圖生產(chǎn)者和消費(fèi)者同時(shí)變更的場景下，如果消費(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 有部署，我們會(huì)把 Queue 的分組擴(kuò)大，在其默認(rèn)設(shè)置的情況下再翻一倍，新增的 Queue 就是給到 FAT001 進(jìn)行消費(fèi)的。
只有消費(fèi)者變更
再來看看只有消費(fèi)者變更的場景，如上圖。
假設(shè)有個(gè)feature只需要更改消費(fèi)者，部署在 FAT001。也是可以通過邏輯分組的方式，實(shí)現(xiàn)生產(chǎn)者根據(jù)請求來源來發(fā)送消息到隊(duì)列 FAT001 邏輯分組內(nèi)的 Queue，從而只讓部署在 FAT001 的消費(fèi)者消費(fèi)。
通過以上 3 個(gè)場景，我們了解到添加邏輯分組的必要性，實(shí)現(xiàn)過程并不復(fù)雜。主要做了以下調(diào)整：?
這個(gè)邏輯分組什么時(shí)候建立？
新建 Topic 的時(shí)候，全部建好？還是 Consumer 上線/下線的時(shí)候動(dòng)態(tài)的去進(jìn)行調(diào)整？
我們選擇了動(dòng)態(tài)創(chuàng)建的方式，這個(gè)過程中，我們添加了 Meta Server 進(jìn)行元數(shù)據(jù)管理，進(jìn)行動(dòng)態(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，上線時(shí)判斷應(yīng)用部署的分組（FAT、FAT001、FAT002...），如果Topic不存在對應(yīng)的分組，則新建；存在，則 rebalalce (新Consumer節(jié)點(diǎn)上線)，下線時(shí)，判斷該分組是否還存在 其它Consumer實(shí)例，若不存在，刪除分組，否則 rebalalce(Consumer某一節(jié)點(diǎn)下線)；
多隔離區(qū)場景下的部署實(shí)踐
由于對安全上的重視，金融行業(yè)的網(wǎng)絡(luò)環(huán)境相比其他行業(yè)會(huì)更復(fù)雜。整個(gè)隔離區(qū)分為以下幾個(gè)部分：
DMZ 區(qū)：
外網(wǎng)可以直接訪問，用于放置網(wǎng)關(guān)；
Web 區(qū)：
面向的是用戶手機(jī)，或者網(wǎng)頁上可以看到的功能應(yīng)用；
核心區(qū)：
包含核心的調(diào)用邏輯功能，和交易、訂單相關(guān)的核心應(yīng)用，例如 DB 和存儲(chǔ)；
外聯(lián)區(qū)：
用于訪問外網(wǎng)，有時(shí)候也會(huì)部署一些 Poxy 代理，因?yàn)閮?nèi)網(wǎng)不能直接訪問外網(wǎng)，需要通過代理去訪問外網(wǎng)；
專用區(qū)域：
對接基金、三方存管等外部系統(tǒng)。在金融行業(yè)，如果某個(gè)系統(tǒng)是閉環(huán)的，那必須要去做隔離；
管理區(qū)：
是指對整個(gè)區(qū)域的應(yīng)用要進(jìn)行集中管理，且數(shù)據(jù)流動(dòng)是單向的，只能取數(shù)據(jù)，不能通過管理區(qū)把某區(qū)域的數(shù)據(jù)推送到另一區(qū)域。
此外，從安全的角度出發(fā)，所有的區(qū)域在生產(chǎn)環(huán)境下都通過防火墻進(jìn)行隔離，這就給我們部署 RocketMQ 帶來了很大的實(shí)施難度。如果只部署一套，面對這么多的防火墻，生產(chǎn)者消費(fèi)者到集群的的流量跨墻，會(huì)給網(wǎng)絡(luò)帶來極大的不穩(wěn)定，遇到瓶頸，防火墻幾乎無法在線平滑擴(kuò)容；如果每個(gè)子環(huán)境都部署一套，又帶來運(yùn)維復(fù)雜度，而且還是存在數(shù)據(jù)同步和跨墻消費(fèi)的問題。
最終，我們采用的是折中的辦法，即統(tǒng)一部署加分隔離區(qū)部署，這樣做的益處是：
防火墻是開大策略，保證安全的前提下，符合監(jiān)管要求；
針對跨隔離區(qū)消費(fèi)的問題，我們采用復(fù)制的方式，模擬消費(fèi)者重新寫入目標(biāo)集群；
多IDC場景下的部署實(shí)踐
同城多IDC，可以認(rèn)為近似局域網(wǎng)，比較好處理，但異地多IDC多活場景，目前我們還沒有特別好的解方案，多活不可避免面臨數(shù)據(jù)分片、數(shù)據(jù)合并和數(shù)據(jù)沖突的解決等問題。
如果 Topic 下數(shù)據(jù)有多活需求，我們暫時(shí)通過復(fù)制方式來處理。但這類手工模擬消費(fèi)者消費(fèi)數(shù)據(jù)寫入新集群的復(fù)制方式，會(huì)存在一些問題，即復(fù)制到另一個(gè)集群之后 offset 會(huì)改變，處理邏輯就會(huì)有偏差。我們通過 pull 的方式自定義的去根據(jù) offset 去進(jìn)行消費(fèi)。當(dāng)故障轉(zhuǎn)移到新的集群需要去消費(fèi)的時(shí)候，需要獲取到新集群里面正確的offset 值。此時(shí)，這個(gè)值和之前集群里的已經(jīng)不一樣了，需要根據(jù)時(shí)間得到新集群里正確的offset 值，再去進(jìn)行消費(fèi)。在沒有更好的解決方案前，治理就顯得很關(guān)鍵了。
不過，我們注意到，在 RocketMQ 最新發(fā)布的版本里，提供了 DLedger 的特性，DLedger 定位的是一個(gè)工業(yè)級的 Java Library，可以友好地嵌入各類 Java 系統(tǒng)中，滿足其高可用、高可靠、強(qiáng)一致的需求。我們會(huì)盡快對這一特性進(jìn)行集成和測試。
改造實(shí)踐和遇到的小插曲
我們在對 RocketMQ 的使用過程中，添加了以下功能或特性：
A. 為生產(chǎn)者提供消息的堆積能力。
B. 將所有配置管理部署到配置中心，并做云端化處理，以滿足動(dòng)態(tài)修改的需求。
C. 在 4.3 版本還未提供事務(wù)處理能力前，我們在本地?cái)?shù)據(jù)庫里去建一張消息表，數(shù)據(jù)庫更改數(shù)據(jù)狀態(tài)的時(shí)候，會(huì)同步將數(shù)據(jù)寫入消息表。若發(fā)送失敗，則進(jìn)行補(bǔ)償。并在客戶端里進(jìn)行封裝。
D. 實(shí)現(xiàn)統(tǒng)一的消息者冪等處理。
E. 添加身份認(rèn)證和消息認(rèn)證（注：RocketMQ 4.3 版本中已經(jīng)實(shí)現(xiàn)身份認(rèn)證功能）
當(dāng)然，也遇到了一些小插曲，基本都是使用上的小問題，可能大家也會(huì)碰到：
A. 一個(gè)應(yīng)用使用多個(gè)RocketMQ集群時(shí)，未加載到正確的配置。在Client 端，如果沒有對 instancename 進(jìn)行配置，一個(gè)應(yīng)用連多個(gè)集群會(huì)失敗。
B. 在大數(shù)據(jù)的場景下，內(nèi)存溢出。訂閱的 Topic 越多，每個(gè) Queue 在本地緩存的 message 也會(huì)越多，默認(rèn)每個(gè) Queue 1000條，可能會(huì)把內(nèi)存打爆，可根據(jù)實(shí)際情況調(diào)整。
C. 刪除數(shù)據(jù)時(shí) IO 抖動(dòng)，默認(rèn)每天凌晨4點(diǎn)刪除數(shù)據(jù)，量上來后出現(xiàn) IO 抖動(dòng)，配置了消息刪除策略，默認(rèn)逗號分隔開，多配幾個(gè)時(shí)間刪除就可以了。
D. Broker上日志報(bào)延遲消息找不到數(shù)據(jù)文件。在主備切換的演練過程中，出現(xiàn)了延遲消息在 Broker 上處理異常的情況。當(dāng)主切換到備端時(shí)，延遲消息在 Broker 上保存的文件被自動(dòng)刪除，再切回主，由于延時(shí)消息的元數(shù)據(jù)感覺在，會(huì)查詢文件進(jìn)行處理，此時(shí)已找不到文件。
E. 掛 NAS 的時(shí)候，IP 獲取了 NAS 的私網(wǎng)地址，并被提交給了服務(wù)端。
以上就是我們在部署過程中遇到的一些小插曲，基本都是可以很快定位原因，解決的。
總的來看，RocketMQ 對平安銀行的消息系統(tǒng)建設(shè)的幫助是非常大的，尤其是滿足了數(shù)據(jù)持久化、順序消費(fèi)和回溯的需求，此外，在消息的查詢方面，也比我們之前使用的消息引擎好很多。最后再分享一點(diǎn)自己對中間件的一點(diǎn)感悟：中間件使用重在治理，規(guī)范不先行，開發(fā)兩行淚。