面對的問題：隨著業(yè)務(wù)規(guī)模增長和系統(tǒng)運(yùn)行時間的增長，傳統(tǒng)集中式架構(gòu)應(yīng)用體現(xiàn)出越來越多的問題，例如單位成本高、并發(fā)數(shù)受限、無法彈性部署、業(yè)務(wù)模塊間可用性耦合等，而且無論是應(yīng)用程序變更還是數(shù)據(jù)庫臨時故障，該時間窗口內(nèi)整套系統(tǒng)均無法對外提供有效服務(wù)，系統(tǒng)可用性已受到較大影響。

　　解決措施：對大規(guī)模集中式應(yīng)用系統(tǒng)進(jìn)行輕量化改造，將其轉(zhuǎn)變?yōu)樾詢r比和吞吐量高、跨平臺性好、可自動化彈性伸縮且便于快速響應(yīng)的分布式系統(tǒng)，提高負(fù)載能力和可用性勢在必行。

必須解決的問題

　　分布式應(yīng)用系統(tǒng)的基本要素是在子應(yīng)用充分解耦的基礎(chǔ)上，使各應(yīng)用能高效地自動發(fā)現(xiàn)其他應(yīng)用及其提供的所有交易與服務(wù)，并根據(jù)配置、權(quán)限許可和目標(biāo)子應(yīng)用的負(fù)載情況進(jìn)行最合適的請求分發(fā)。同時要有相應(yīng)的保障體系用于分析和監(jiān)控系統(tǒng)運(yùn)行情況。業(yè)界成熟的復(fù)雜分布式系統(tǒng)通常還會考慮服務(wù)降級、熔斷等一些高級特性，但由于這些特性對一般集中式系統(tǒng)來說不是必須的，在此方案中不涉及這些內(nèi)容。

　　從上文可以看出，要將集中式系統(tǒng)拆解為分布式系統(tǒng)，需解決的問題主要有：必須實(shí)現(xiàn)拆分后各應(yīng)用可用交易、服務(wù)的自動注冊與發(fā)現(xiàn)；必須實(shí)現(xiàn)軟負(fù)載均衡以獲得最優(yōu)集中式應(yīng)用系統(tǒng)分布式改造方案研究的交易、服務(wù)流轉(zhuǎn)路徑；必須有易于操作的配置管理中心用于配置項(xiàng)管理和自動發(fā)送；必須有權(quán)限控制用以保證系統(tǒng)安全性；必須有統(tǒng)一日志收集和保障組件，用于分析和監(jiān)控系統(tǒng)運(yùn)行情況。由此得出的分布式應(yīng)用系統(tǒng)基本架構(gòu)如圖1所示。

圖1 分布式應(yīng)用系統(tǒng)基本架構(gòu)

　　由于原有技術(shù)限制，絕大部分現(xiàn)有集中式系統(tǒng)無法使用現(xiàn)有的成熟分布式應(yīng)用系統(tǒng)框架：要么改造量太大，要么組件限制不能改造。因此自主開發(fā)一套適用于現(xiàn)有集中式系統(tǒng)的分布式處理框架成為唯一的出路。經(jīng)筆者調(diào)研，最終選用ZooKeeper（以下簡稱zk）作為管理中心，ELK作為統(tǒng)一日志收集處理平臺來實(shí)現(xiàn)改造方案。此方案的物理架構(gòu)及內(nèi)部交互情況如圖2所示，其中單向箭頭表示單向訪問，雙向箭頭表示雙向訪問。

圖2 物理架構(gòu)及內(nèi)部交互情況

統(tǒng)一日志收集

　　各子應(yīng)用分布部署帶來的必然問題之一就是日志文件分散，給故障分析與排查帶來困難。為解決此問題且保證系統(tǒng)可用性，本改造方案采用ELK作為日志統(tǒng)一收集處理平臺。按照侵入性不同，以下兩種處理方案可供選擇。

　　（1）基于logbackAppender的實(shí)時日志發(fā)送。此方案使用定制化的logbackAppender實(shí)現(xiàn)日志實(shí)時發(fā)送。缺點(diǎn)是如果kafka集群運(yùn)行不夠穩(wěn)定會對自身應(yīng)用有影響，而且要實(shí)現(xiàn)日志的多種格式輸出需修改代碼。

　�。�2）基于logstash的外掛式準(zhǔn)實(shí)時日志收集。此方案是在日志輸出方部署logstash客戶端，自動掃描日志路徑下的日志變化，讀取日志并通過正則匹配格式化后發(fā)送到kafka集群。實(shí)時性較前一種方案略差，但是對應(yīng)用本身幾乎沒有影響，而且靈活性較前一種高。需要注意的是由于正則匹配比較消耗CPU資源，日志輸出較多較快或計(jì)算密集型的應(yīng)用不推薦使用這種接入方式。

注冊中心

　　注冊中心主要有三部分，第一部分是應(yīng)用注冊中心，第二部分是交易、服務(wù)注冊中心，第三部分是其他注冊中心。

　　基于應(yīng)用注冊中心收集到的實(shí)時負(fù)載信息（包括當(dāng)前請求總數(shù)、虛擬機(jī)空閑內(nèi)存大小等）和zk的Watcher機(jī)制，可以輕松實(shí)現(xiàn)應(yīng)用自動注冊發(fā)現(xiàn)；同時可以根據(jù)較復(fù)雜的均衡策略在網(wǎng)關(guān)應(yīng)用本地生成當(dāng)前最優(yōu)服務(wù)器列表。

　　各應(yīng)用在啟動時需要將自身交易、服務(wù)信息以臨時節(jié)點(diǎn)的方式寫入服務(wù)注冊中心，網(wǎng)關(guān)應(yīng)用利用交易、服務(wù)注冊中心收集到歸屬系統(tǒng)名稱和本地的當(dāng)前最優(yōu)服務(wù)器列表即可快速獲取指定交易、服務(wù)的實(shí)際URL。

　　在集中式系統(tǒng)中，某些公共交易、服務(wù)會采用“統(tǒng)一入口+策略分發(fā)”的方式來進(jìn)行請求分流（以下稱為待分發(fā)公共交易），而在分布式拆分時這種處理方式會導(dǎo)致網(wǎng)關(guān)應(yīng)用無法僅通過交易、服務(wù)名稱來確定其實(shí)際目標(biāo)應(yīng)用。為避免大規(guī)模的前后臺重構(gòu)，必須要有一個其他注冊中心來統(tǒng)一注冊各應(yīng)用中能夠作為路由參數(shù)的策略類型和策略值，以便網(wǎng)關(guān)收到待分發(fā)公共交易時進(jìn)行路由選擇。

配置管理中心

　　在集中式系統(tǒng)中通常存在一些可以動態(tài)調(diào)整的配置性信息，例如最大消息隊(duì)列深度，某些多線程操作的并發(fā)線程數(shù)量等。在應(yīng)用較少時以http方式逐臺調(diào)整所有應(yīng)用的配置是可以接受的，但在分布式場景下這種方式就不再可行，必須要有一個配置管理中心來負(fù)責(zé)下發(fā)這些動態(tài)參數(shù)的變更，減少運(yùn)維人員工作負(fù)擔(dān)。在特定場景下某些公共交易也可以利用該配置管理中心實(shí)現(xiàn)交易的異步廣播分發(fā)。

　　分布式改造過程中通常還涉及數(shù)據(jù)庫拆分。對筆者所在系統(tǒng)來說，子應(yīng)用數(shù)據(jù)庫是否獨(dú)立拆分會影響到一些公共交易的實(shí)際路由，而利用配置管理中心則可以實(shí)現(xiàn)交易路由的靈活動態(tài)調(diào)整。

權(quán)限管理

　　本方案需要進(jìn)行權(quán)限控制的主要有兩部分，一是注冊節(jié)點(diǎn)（例如枚舉節(jié)點(diǎn)、交易節(jié)點(diǎn)等）的訪問權(quán)限，二是子應(yīng)用的訪問權(quán)限。為簡化處理，一套系統(tǒng)的所有zk節(jié)點(diǎn)的加密授權(quán)信息是一致的，不同系統(tǒng)的授權(quán)信息不同。應(yīng)用程序?qū)ψ�冊�?jié)點(diǎn)的所有操作必須經(jīng)過鑒權(quán)以避免非法訪問。

　　本系統(tǒng)內(nèi)部所有應(yīng)用可以互相訪問（如圖2所示），同時各個子應(yīng)用允許所有經(jīng)過授權(quán)的外部系統(tǒng)應(yīng)用直接訪問其指定交易或服務(wù)。子應(yīng)用在進(jìn)行交易、服務(wù)注冊時會同步增加相應(yīng)授權(quán)節(jié)點(diǎn)及其監(jiān)聽器，然后基于監(jiān)聽器收到的通知信息形成允許訪問IP列表。收到請求時子應(yīng)用會進(jìn)行IP鑒權(quán)，外部IP只有在允許訪問列表中才允許訪問該子應(yīng)用。外部系統(tǒng)需要直接訪問子應(yīng)用時需在目標(biāo)交易、服務(wù)的授權(quán)節(jié)點(diǎn)下注冊其應(yīng)用IP信息。

請求處理流程

　　為最小化改動，內(nèi)部系統(tǒng)交互應(yīng)盡量以系統(tǒng)現(xiàn)有主要請求方式為準(zhǔn)，使用相同網(wǎng)絡(luò)協(xié)議及報文格式。如圖3所示，網(wǎng)關(guān)收取外部請求時，根據(jù)路由參數(shù)（例如url名稱或其他特定請求參數(shù)等）從相應(yīng)的本地注冊信息緩存中獲取目標(biāo)子應(yīng)用，若存在目標(biāo)子應(yīng)用則將請求轉(zhuǎn)發(fā)，否則按照常規(guī)流程處理請求。

圖3 請求處理流程

　　待分發(fā)公共交易等特殊交易由于必須進(jìn)行報文解析才能拿到相應(yīng)的路由參數(shù)，耗時增加較其他直接轉(zhuǎn)發(fā)交易更多。在不破壞原有請求參數(shù)結(jié)構(gòu)的前提下，將路由參數(shù)添加到無需解析即可獲取的地方（如http請求報文頭），使網(wǎng)關(guān)無需報文解析即可確定轉(zhuǎn)發(fā)目標(biāo)，提高處理效率。

壓力測試及分析

　　限于篇幅筆者選取若干典型交易進(jìn)行了壓力測試，各個交易代表的典型場景說明如下。

　　process1、2、3：網(wǎng)關(guān)根據(jù)zk配置決定分發(fā)策略，本測試中不分發(fā)；process41、42、51、52：網(wǎng)關(guān)應(yīng)用解析請求后根據(jù)策略類型A進(jìn)行子應(yīng)用分發(fā)，其中策略值為A1的請求由網(wǎng)關(guān)直接處理，策略值為A2分發(fā)到子應(yīng)用SUB1上；process6：網(wǎng)關(guān)直接轉(zhuǎn)發(fā)至SUB1子應(yīng)用的普通HTTP請求；process7：網(wǎng)關(guān)直接轉(zhuǎn)發(fā)至SUB1子應(yīng)用的文件生成下載請求（該交易并發(fā)數(shù)受限）；process8：網(wǎng)關(guān)收到MQ消息后直接轉(zhuǎn)發(fā)至SUB2子應(yīng)用的Webservice請求；process9：網(wǎng)關(guān)收到請求后直接轉(zhuǎn)發(fā)至SUB2子應(yīng)用，SUB2子應(yīng)用收到請求后在正常邏輯處理過程中請求SUB1子應(yīng)用；process10：網(wǎng)關(guān)應(yīng)用解析公共文件生成請求后根據(jù)策略類型B進(jìn)行子應(yīng)用分發(fā)，本測試中分發(fā)至子應(yīng)用SUB2（該交易并發(fā)數(shù)受限，與process11組合調(diào)用）；process11：網(wǎng)關(guān)應(yīng)用解析公共文件下載請求后根據(jù)策略類型B進(jìn)行子應(yīng)用分發(fā)，本測試中分發(fā)至子應(yīng)用SUB2（該交易并發(fā)數(shù)受限，與process10組合調(diào)用）。

　　從測試結(jié)果可以看出：對于不分發(fā)的交易，分布式處理效率較集中式略高，原因可能是分布式網(wǎng)關(guān)應(yīng)用的可用空閑內(nèi)存較集中式多。這種效率提升對于內(nèi)存占用較高的交易更加明顯。單一次轉(zhuǎn)發(fā)的時間損耗在絕大部分情況下在4~10ms之間浮動，偶爾會達(dá)到15ms。

　　綜合場景測試內(nèi)容如表1，結(jié)果如圖4�？梢钥闯觯壕C合場景測試情況下事務(wù)的平均耗時與該事務(wù)包含的轉(zhuǎn)發(fā)次數(shù)相關(guān)，同時會受單交易自身復(fù)雜程度和內(nèi)存占用情況等因素影響，特定場景下分布式平均耗時甚至?xí)�低于集中式。需要網(wǎng)關(guān)進(jìn)行報文解析后再轉(zhuǎn)發(fā)的交易其平均耗時增長較直接轉(zhuǎn)發(fā)交易略長，且報文越長耗時增加越多。

表1 綜合場景測試內(nèi)容

圖4 綜合場景測試結(jié)果

小結(jié)

　　經(jīng)實(shí)際測試，本改造方案基本滿足集中式系統(tǒng)分布式改造的一般性要求，但在配套的自動化部署方面并未進(jìn)行更加深入的研究。要充分發(fā)揮分布式系統(tǒng)的特點(diǎn)，基礎(chǔ)設(shè)施建設(shè)至關(guān)重要。在改造應(yīng)用系統(tǒng)的同時，如果能充分利用容器化技術(shù)和云平臺，實(shí)現(xiàn)應(yīng)用的自動化、智能化快速部署，才能真正發(fā)揮分布式系統(tǒng)的長處。

（文章來源：金融電子化雜志）

掃碼即可手機(jī)
閱讀轉(zhuǎn)發(fā)此文