黃 晨,柏路平

(中移信息技術(shù)有限公司,深圳 518048)

1 引言

Spring Boot 框架[1,2]因其簡潔的配置、內(nèi)嵌的容器、自動(dòng)的依賴管理、組件化的功能配置,能夠讓開發(fā)者快速地搭建項(xiàng)目、編碼與新增功能,加快整個(gè)系統(tǒng)開發(fā)流程.以統(tǒng)一支付系統(tǒng)應(yīng)用為背景,系統(tǒng)開發(fā)使用了Spring Boot 框架,快速支撐了支付業(yè)務(wù)上線.然而隨著業(yè)務(wù)的發(fā)展,接入統(tǒng)一支付系統(tǒng)的外部商戶數(shù)量不斷增加、業(yè)務(wù)種類、業(yè)務(wù)吞吐量、需求功能都在不斷的增長,現(xiàn)有的開發(fā)部署架構(gòu)在應(yīng)用頻繁迭代上線、故障定位方面支持度較低,也比較難以適應(yīng)業(yè)務(wù)量月初、節(jié)假日等波動(dòng)性增長.

微服務(wù)[3,4]是將一個(gè)系統(tǒng)拆分成許多較小的、松散耦合的組件和服務(wù)的架構(gòu),具有組件共享、故障可控、彈性擴(kuò)展、易于部署等優(yōu)點(diǎn),近年來,隨著云平臺(tái)技術(shù)與容器管理技術(shù)的成熟,基于微服務(wù)框架來構(gòu)建大型應(yīng)用系統(tǒng)成為互聯(lián)網(wǎng)行業(yè)的趨勢.為解決支付系統(tǒng)Spring Boot 架構(gòu)現(xiàn)存的問題,開發(fā)人員同步開發(fā)了Spring Cloud 微服務(wù)版本并準(zhǔn)備上線.變更如此大的版本上線前必然要經(jīng)過充分的調(diào)試,并且之前的Spring Boot 架構(gòu)的支付系統(tǒng)也還要存留一段時(shí)間以備出現(xiàn)意外情況時(shí)可以回退,因此聯(lián)調(diào)環(huán)境需同時(shí)使用這兩種架構(gòu)的系統(tǒng)應(yīng)用供對外商戶調(diào)用并進(jìn)行聯(lián)調(diào)驗(yàn)證.

2 基于Nginx-F5的雙架構(gòu)應(yīng)用并行方案

2.1 Spring Boot 系統(tǒng)聯(lián)調(diào)部署

圖1是統(tǒng)一支付系統(tǒng)聯(lián)調(diào)環(huán)境部署示意圖.在DMZ 域[5,6]部署一臺(tái)Nginx,同時(shí)開通443和8080 兩個(gè)端口的公網(wǎng)接入口,與統(tǒng)一支付聯(lián)調(diào)系統(tǒng)提供的兩大類業(yè)務(wù)相對應(yīng),通過后端的http 請求接入API 業(yè)務(wù)(對外8080 端口),通過前臺(tái)的https 請求接入的H5 業(yè)務(wù)(對外443 端口),也有部分商戶通過https 對接API 業(yè)務(wù),由于H5與API 接口處理支付請求的流程不同,將它們開發(fā)成不同的應(yīng)用組件,并以不同的請求path 加以區(qū)分.

圖1 Spring Boot 版本的統(tǒng)一支付系統(tǒng)聯(lián)調(diào)部署

為了能夠保證新開發(fā)的Spring Cloud 架構(gòu)應(yīng)用的質(zhì)量,有必要將其部署在聯(lián)調(diào)環(huán)境,經(jīng)過外部商戶的測試報(bào)文來驗(yàn)證其所有功能.Spring Cloud 架構(gòu)的系統(tǒng)如何與原來的Boot 架構(gòu)的系統(tǒng)在聯(lián)調(diào)環(huán)境并存需要考慮如下問題:首先,Spring Cloud 版本是統(tǒng)一支付系統(tǒng)內(nèi)部的優(yōu)化版本,整個(gè)對外聯(lián)調(diào)過程應(yīng)該對外部商戶透明,即不應(yīng)讓外部商戶感知到統(tǒng)一支付系統(tǒng)是調(diào)測的哪個(gè)架構(gòu)的應(yīng)用;其次為保證內(nèi)部系統(tǒng)安全,應(yīng)盡量減少公網(wǎng)暴露面,還有DMZ 域的機(jī)器資源使用已經(jīng)飽和,新部署的Cloud 支付系統(tǒng)只能跟其他系統(tǒng)的應(yīng)用共用機(jī)器.

2.2 基于Nginx-F5的雙架構(gòu)應(yīng)用聯(lián)調(diào)并行方案

在Nginx 作為公網(wǎng)接入口,并充分考慮上述限制問題的基礎(chǔ)上,本文提出一種基于Nginx-F5[7-9]的雙架構(gòu)(大版本)應(yīng)用的并行方案,既不增加對外聯(lián)調(diào)的端口又可以使兩種Boot和Cloud 架構(gòu)的應(yīng)用得到高效的調(diào)測,如圖2所示.

圖2 基于Nginx-F5的雙架構(gòu)應(yīng)用系統(tǒng)并行方案

與之前的部署架構(gòu)圖相比,除了增加Cloud 架構(gòu)的應(yīng)用外,還新增了一套F5 負(fù)載均衡器.該F5是一個(gè)操作系統(tǒng)模擬器,需要單獨(dú)一臺(tái)虛擬機(jī)來安裝F5的操作系統(tǒng),由于DMZ 域機(jī)器資源有限,原來的Nginx 宿主機(jī)還安裝有很多其他的應(yīng)用,不能將其鏟除,F5 模擬器可以安裝在機(jī)器資源充足的內(nèi)網(wǎng)核心域.將F5 模擬器部署于原來的Nginx 之后,支付聯(lián)調(diào)應(yīng)用之前.主要使用F5的7 層轉(zhuǎn)發(fā)功能,細(xì)粒度地控制外部商戶的模擬報(bào)文在Boot 系統(tǒng)與Cloud 系統(tǒng)之間切換,在不影響線上Boot 架構(gòu)系統(tǒng)不停迭代新需求的同時(shí),可以隨時(shí)驗(yàn)證新的Cloud 架構(gòu)系統(tǒng)的基本功能.

2.3 與純Nginx的雙架構(gòu)應(yīng)用聯(lián)調(diào)并行方案比較

如不使用F5 模擬器,直接使用原來的Nginx的添加Lua 腳本模塊或者使用OpenResty 版本的Nginx,也能實(shí)現(xiàn)根據(jù)報(bào)文體中的某個(gè)屬性標(biāo)識(shí)轉(zhuǎn)發(fā)請求,但由于Nginx 流量轉(zhuǎn)發(fā)方式的變更需要修改配置文件或者加載的Lua 腳本并且重載才能生效,這個(gè)重載機(jī)制并不是每次配置變更都會(huì)生效,并且沒生效也沒有提示.這時(shí)只能強(qiáng)制殺掉Nginx的主進(jìn)程后,重新啟動(dòng)使變更的配置生效.而且Nginx的健康檢查機(jī)制是通過將后端服務(wù)器成員狀態(tài)的檢查結(jié)果打印到日志文件反映,當(dāng)有后端成員掛掉也不能及時(shí)發(fā)現(xiàn).而F5 模擬器具有可視化的Web 操作界面,后端服務(wù)器成員的啟停狀態(tài)能夠很直觀地看到,也很方便將后端成員的狀態(tài)設(shè)置開啟與關(guān)閉,其提供的負(fù)載規(guī)則irule[10],可以自定義各種基于報(bào)文頭和報(bào)文體的流量轉(zhuǎn)發(fā)策略,并且各種變更都是實(shí)時(shí)生效,且不會(huì)使正在活動(dòng)的連接斷開.

因?yàn)樯a(chǎn)環(huán)境的Boot 架構(gòu)的應(yīng)用還在不斷的迭代新需求,而新的Cloud 架構(gòu)的應(yīng)用也需要調(diào)測基本的功能,并且在某個(gè)時(shí)刻追加Boot 架構(gòu)新迭代的全部需求,本文基于Nginx-F5的并行聯(lián)調(diào)架構(gòu)在下面的F5 加載irule 規(guī)則的流量切換方法下,能夠在不改變原有的業(yè)務(wù)入口的條件下,提高兩種架構(gòu)應(yīng)用的聯(lián)調(diào)效率,更好地支撐生產(chǎn)系統(tǒng)的不斷升級(jí)優(yōu)化.

3 基于F5 irule 規(guī)則的雙架構(gòu)應(yīng)用切換方法

圖2的雙架構(gòu)應(yīng)用系統(tǒng)并行方案中,F5 模擬器開啟443和8080 兩個(gè)端口的虛擬服務(wù),分別作為原接入Nginx的443和8080 服務(wù)的各自的后端服務(wù)器.因?yàn)镹ginx 在443 端口已經(jīng)卸載了https 證書,發(fā)送到F5的443 端口的已經(jīng)是http 協(xié)議的報(bào)文,所以在F5的443 端口的虛擬服務(wù)不需要再安裝證書.設(shè)置Nginx的443 端口的以https 服務(wù)進(jìn)來的API 請求固定地轉(zhuǎn)發(fā)到F5的8080 端口,這樣經(jīng)過F5的443 端口的業(yè)務(wù)就只有H5 類型,在F5的443 端口做7 層負(fù)載分發(fā)時(shí)就不用考慮API 類型的業(yè)務(wù),簡化了F5的流量控制過程.

統(tǒng)一支付系統(tǒng)的外部商戶各自的業(yè)務(wù)特點(diǎn)不盡相同,因此有必要將某個(gè)或者某些商戶的業(yè)務(wù)請求分離出來,并單獨(dú)發(fā)送至不同后端應(yīng)用系統(tǒng).

3.1 F5 基于報(bào)文屬性值的流量分發(fā)規(guī)則

因?yàn)橥獠可虘舻陌l(fā)送的請求都是結(jié)構(gòu)化的報(bào)文,即以XML和JSON 格式存在,XML 中是屬性及屬性值的集合,而JSON是鍵/值的集合,可以用屬性值或者鍵值的具體取值來代表一類商戶請求.因此可以通過F5的負(fù)載規(guī)則irule 編寫處理邏輯來改變請求分發(fā)方式.

irule是F5 功能強(qiáng)大的擴(kuò)展組件,通過TCL (tool command language)語言,可以編寫基于事件觸發(fā)的代碼段,對接收報(bào)文的關(guān)鍵字或分發(fā)需求進(jìn)行分析,以改變進(jìn)入F5的網(wǎng)絡(luò)請求的默認(rèn)分發(fā)方式,達(dá)到流量按需切換的目的.

結(jié)合外部商戶報(bào)文的特點(diǎn),編寫了高效的基于報(bào)文屬性值的irule 分發(fā)規(guī)則,如規(guī)則1.

規(guī)則1.基于報(bào)文屬性值的流量分發(fā)規(guī)則1) 設(shè)置屬性標(biāo)識(shí)列表iKeyList.2) 當(dāng)接收到請求并解析到報(bào)文體時(shí),屬性標(biāo)識(shí)列表中的元素按先后順序分別遍歷報(bào)文體,當(dāng)搜索到屬性標(biāo)識(shí)元素iKey 時(shí)就結(jié)束遍歷.3) 按照屬性值的位數(shù)從請求報(bào)文中截取iKey 對應(yīng)的屬性值iValue.4) 設(shè)置流量切換商戶標(biāo)識(shí)列表sList.5) 在sList 搜索報(bào)文的屬性取值iValue,如果搜索到則說明該請求報(bào)文是由該商戶發(fā)出,就將該筆報(bào)文發(fā)送到Cloud 應(yīng)用系統(tǒng).以驗(yàn)證某個(gè)商戶的微服務(wù)版本業(yè)務(wù)是否正常,如果沒有搜索到則發(fā)往默認(rèn)的Boot 系統(tǒng).

當(dāng)規(guī)則1的報(bào)文屬性取某個(gè)具有業(yè)務(wù)意義的值時(shí),就可以把報(bào)文分成兩類,分別發(fā)送到不同的系統(tǒng),下面以報(bào)文屬性取sysNo的值為例,描述如何根據(jù)外部商戶的商戶編碼將支付請求報(bào)文在Boot 系統(tǒng)和Cloud系統(tǒng)之間切換.圖3為irule 按照報(bào)文屬性值的流量分發(fā)的處理流程圖.

圖3 基于報(bào)文屬性值的流量分發(fā)處理流程

設(shè)置屬性標(biāo)識(shí)列表的原因是除了要兼容XML與JSON 格式的請求報(bào)文外,還要考慮特殊字符是否經(jīng)過url 編碼,統(tǒng)一支付系統(tǒng)的外部商戶數(shù)量接近100 個(gè),為了管理方便,每個(gè)商戶都分配有一個(gè)四位數(shù)值的編碼,作為一個(gè)匯集系統(tǒng)應(yīng)當(dāng)兼容不同的報(bào)文格式.對于商戶編碼sysNo 這一個(gè)屬性來說,屬性標(biāo)識(shí)的列表有4 個(gè)元素,分別是sysNo＞、sysNo%22、sysNo"、sysNo%3E 四個(gè)字符串,只有搜索到具體是列表中的哪一個(gè)元素后,才能在報(bào)文中按屬性值位數(shù)截取屬性的值.根據(jù)不同測試需求,修改商戶標(biāo)識(shí)列表sList的元素取值,可以實(shí)現(xiàn)只把一個(gè)商戶或者多個(gè)商戶的流量同時(shí)切換到微服務(wù)系統(tǒng),如sList={0069,0075,0089}表示把sysNo 取為0069、0075與0089 對應(yīng)3 個(gè)商戶的流量全部切換到微服務(wù)系統(tǒng).當(dāng)把該irule與F5的443 或者8080 端口綁定時(shí),對應(yīng)的虛擬服務(wù)就按照irule 定義的轉(zhuǎn)發(fā)邏輯分發(fā)流量,解除綁定則直接轉(zhuǎn)發(fā)到虛擬服務(wù)配置的默認(rèn)default 服務(wù)組.

3.2 F5 基于報(bào)文屬性值的比例分發(fā)方法

使用F5的irule 規(guī)則除了按照外部商戶編碼來分發(fā)流量之外,還可以按照流量的比例來進(jìn)行分發(fā).很多情況下Nginx和F5與后端服務(wù)器之間是一對多的關(guān)系,即負(fù)載均衡器將接收到的請求分發(fā)到多個(gè)后端服務(wù)器,通常一個(gè)虛擬服務(wù)具有一個(gè)默認(rèn)服務(wù)組,服務(wù)組里面的各個(gè)成員默認(rèn)都是按照輪詢的方式分發(fā)流量,各成員接收到的請求數(shù)都大致相同.也可以設(shè)置服務(wù)組的負(fù)載均衡模式為加權(quán)輪詢,組內(nèi)的每個(gè)成員都自帶有權(quán)重值,每個(gè)成員接收到的流量比例為該成員的權(quán)重值在組內(nèi)所有成員權(quán)重和的比重.

結(jié)合F5的加權(quán)輪詢負(fù)載模式,以及自定義irule腳本篩選出的特定屬性報(bào)文,可以實(shí)現(xiàn)兩種不同粒度的比例分發(fā),如圖4所示.將Boot 應(yīng)用和Cloud 應(yīng)用添加到同一個(gè)服務(wù)組,稱作混合服務(wù)組,這個(gè)服務(wù)組的負(fù)載均衡類型按成員權(quán)重分發(fā),通過修改Boot與Cloud應(yīng)用的權(quán)重則可控制轉(zhuǎn)發(fā)到微服務(wù)應(yīng)用的流量比例在0-100%之間變化.一種方式是直接將混合服務(wù)組添加到F5 虛擬服務(wù)的默認(rèn)服務(wù)組,則經(jīng)過該虛擬服務(wù)的所有請求都將按照比例分發(fā),屬于較粗的比例控制.另一種是將混合服務(wù)組與請求報(bào)文中具體的屬性標(biāo)識(shí)相結(jié)合,在規(guī)則irule 中將外部商戶編碼屬于sList 集合的報(bào)文發(fā)往混合服務(wù)組(對應(yīng)圖3),即可將經(jīng)過該虛擬服務(wù)的某個(gè)商戶或某幾個(gè)商戶的流量按照一定的比例分發(fā)到微服務(wù)應(yīng)用,這種流量分發(fā)控制更為精細(xì).

圖4 兩種粒度的流量比例分發(fā)控制

4 實(shí)驗(yàn)結(jié)果驗(yàn)證

為驗(yàn)證在本文架構(gòu)下流量切換方法的正確性,采用的方法是模擬各外部商戶系統(tǒng)發(fā)送測試報(bào)文到聯(lián)調(diào)系統(tǒng)的Nginx 入口,查看報(bào)文經(jīng)過F5的7 層負(fù)載后,最終是分發(fā)到了Boot 系統(tǒng)還是Cloud 系統(tǒng),是否與F5 虛擬服務(wù)加載的irule 定義的分發(fā)規(guī)則一致.

實(shí)驗(yàn)1:驗(yàn)證規(guī)則1 基于報(bào)文屬性值流量分發(fā)對于單個(gè)屬性取值的應(yīng)用效果,將sList 設(shè)置為{0230},即只將0230 商戶的請求切換到Cloud 系統(tǒng),并將該irule 規(guī)則與F5的8080 虛擬服務(wù)綁定,然后模擬0230,0280,0069 三個(gè)商戶分別發(fā)送1 000 筆支付請求報(bào)文,通過F5 提供的日志以及查看應(yīng)用日志統(tǒng)計(jì)確認(rèn),0280,0069 發(fā)送的2 000 筆報(bào)文都發(fā)送到了F5的API 虛擬服務(wù)的默認(rèn)Boot 應(yīng)用系統(tǒng),而0230 商戶的這1 000 筆報(bào)文都Cloud 應(yīng)用系統(tǒng),說明該規(guī)則對單個(gè)商戶的切換有效,正確率達(dá)到了100%.

實(shí)驗(yàn)2:驗(yàn)證該分發(fā)規(guī)則對于多個(gè)屬性取值時(shí)的應(yīng)用效果,將sList的取值設(shè)置為{0230 0280 0069},模擬這3 個(gè)商戶各發(fā)送1 000 筆報(bào)文,經(jīng)確認(rèn)這3 000 筆報(bào)文都發(fā)送到了irule 指定的Cloud 服務(wù)組,并且無其他商戶的報(bào)文發(fā)送到該服務(wù)組,說明該規(guī)則對多個(gè)商戶的同時(shí)切換也同樣有效.

實(shí)驗(yàn)3:驗(yàn)證基于報(bào)文屬性值的比例分發(fā)方法,保持sList的取值設(shè)置為{0230 0280 0069}不變,修改irule 規(guī)則,將查找到切換商戶取值列表中的元素后轉(zhuǎn)發(fā)的服務(wù)組更換為混合服務(wù)組,該服務(wù)組里面既有Boot 應(yīng)用成員,又有Cloud 應(yīng)用的成員,將Boot 應(yīng)用成員的權(quán)重值設(shè)置為9,Cloud 應(yīng)用成員的權(quán)重值設(shè)置為1,這樣Cloud 應(yīng)用的占比為10%,模擬這3 個(gè)商戶各發(fā)送1 000 筆報(bào)文,發(fā)現(xiàn)Cloud 應(yīng)用接收到302 筆報(bào)文,并且全部來自0230,0280,0069 這3 個(gè)商戶,Boot 應(yīng)用收到2 698 筆來自這3 個(gè)商戶的報(bào)文,Cloud 應(yīng)用接收到的報(bào)文比例大約10%,說明該規(guī)則與加權(quán)輪詢的負(fù)載均衡算法結(jié)合使用能夠達(dá)到更細(xì)粒度的流量比例控制.

表1是以上3 個(gè)實(shí)驗(yàn)的流量分發(fā)數(shù)據(jù)表,實(shí)驗(yàn)結(jié)果說明本文提出的Nginx-F5 架構(gòu)下的流量切換方法,在規(guī)則屬性設(shè)置為單個(gè)和多個(gè)值的情況下,都能夠?qū)⒘髁空_地分發(fā)到報(bào)文屬性值對應(yīng)Boot 系統(tǒng)和Cloud系統(tǒng),能夠很好地支撐雙架構(gòu)應(yīng)用系統(tǒng)的并行聯(lián)調(diào).

表1 3 種實(shí)驗(yàn)的不同商戶報(bào)文接收情況

5 總結(jié)

為使統(tǒng)一支付系統(tǒng)能夠透明地對眾多外部商戶同時(shí)提供Spring Boot 架構(gòu)的應(yīng)用和Spring Cloud 架構(gòu)應(yīng)用的聯(lián)調(diào),本文提出了基于Nginx-F5的Spring Boot和Spring Cloud 兩種架構(gòu)應(yīng)用的并行方案,以及一種基于報(bào)文屬性值的流量分發(fā)規(guī)則,能夠?qū)⒔尤隖5 虛擬服務(wù)滿足某個(gè)屬性值的請求報(bào)文發(fā)送到Cloud 應(yīng)用系統(tǒng),而不是默認(rèn)的Boot 應(yīng)用系統(tǒng).將該流量分發(fā)規(guī)則與加權(quán)輪詢的服務(wù)組聯(lián)合使用,可實(shí)現(xiàn)更細(xì)粒度的百分比例分發(fā),如只將某一個(gè)或某幾個(gè)外部商戶的約5%的流量轉(zhuǎn)發(fā)到Cloud 系統(tǒng).采用這種雙架構(gòu)應(yīng)用的并行聯(lián)調(diào)方案,能夠做到既不影響生產(chǎn)Boot 系統(tǒng)的不斷需求迭代更新,又能使新的Cloud 系統(tǒng)得到充分完整的對外調(diào)測,有效地支撐生產(chǎn)系統(tǒng)不斷升級(jí)優(yōu)化.

本文中的Boot 及Cloud 兩種系統(tǒng)可理解為同一系統(tǒng)的不同版本,本文所提出的并行架構(gòu)及流量切換方法也可用于其他任何系統(tǒng)多版本并行及聯(lián)調(diào).流量分發(fā)規(guī)則中的報(bào)文屬性可變更為其他應(yīng)用系統(tǒng)有意義的分類標(biāo)識(shí),如用戶歸屬省、業(yè)務(wù)類型等,可推廣到其他系統(tǒng)的建設(shè)或者優(yōu)化演進(jìn).