白海洋 臺運(yùn)紅

1.中國電信股份有限公司江蘇分公司；2.三江學(xué)院

0 引言

通信運(yùn)營商IT系統(tǒng)上云是踐行“數(shù)字中國”發(fā)展戰(zhàn)略的重要舉措。在去IOE（IBM小型機(jī)、Oracle數(shù)據(jù)庫、EMC高端存儲）的趨勢背景下，云資源池硬件穩(wěn)定性面臨挑戰(zhàn)。如何通過架構(gòu)優(yōu)化及云原生技術(shù)的應(yīng)用來提升系統(tǒng)整體可用性，是IT系統(tǒng)上云需要重點(diǎn)解決的問題。

容災(zāi)備份是提升IT系統(tǒng)可用性的重要手段，隨著鄭州暴雨等災(zāi)情的發(fā)生，異地容災(zāi)再次成為人們關(guān)注的熱點(diǎn)。IT系統(tǒng)上云為異地多中心的容災(zāi)環(huán)境建設(shè)創(chuàng)造了有利條件，如何在資源允許范圍內(nèi)建立起災(zāi)備系統(tǒng)，也成為云化改造需要關(guān)注的重點(diǎn)課題。

本文針對交易型系統(tǒng)上云改造提出“同城雙活”高可用架構(gòu)以及“兩地三中心”容災(zāi)部署方案，可以有效提升系統(tǒng)的高可用性。

1 相關(guān)概念

1.1 交易型系統(tǒng)

“交易型系統(tǒng)”是“交易密集型系統(tǒng)”的簡稱，與之對應(yīng)的是“計(jì)算密集型系統(tǒng)”。交易型系統(tǒng)是OLTP（Online Transaction Processing，聯(lián)機(jī)事務(wù)處理）系統(tǒng)的一類，具有并發(fā)請求高、事務(wù)一致性要求高、服務(wù)可用性要求高等特點(diǎn)。在通信運(yùn)營商領(lǐng)域，支付系統(tǒng)、充值系統(tǒng)、營業(yè)受理系統(tǒng)均可以歸為此類。

1.2 系統(tǒng)高可用

IT系統(tǒng)的可用性是衡量其穩(wěn)定服務(wù)能力的關(guān)鍵指標(biāo)，具體標(biāo)準(zhǔn)一般包括：持續(xù)穩(wěn)定服務(wù)時(shí)間、故障影響程度、故障恢復(fù)時(shí)間等。

高可用系統(tǒng)中需要考慮的設(shè)計(jì)原則一般包括：負(fù)載均衡、熔斷降級、限流、流量調(diào)度、故障隔離、超時(shí)與重試、事務(wù)一致性與回滾、冪等校驗(yàn)等?？紤]到高并發(fā)的場景，一般還需要考慮緩存、異步與并發(fā)、擴(kuò)縮容等因素。

1.3 容災(zāi)系統(tǒng)關(guān)鍵指標(biāo)

RTO（Recovery Time Objective）：系統(tǒng)發(fā)生災(zāi)難性故障后的恢復(fù)時(shí)間。

RPO（Recovery Point Object）：災(zāi)難發(fā)生后切換到災(zāi)備系統(tǒng)的數(shù)據(jù)損失量。

容災(zāi)半徑：生產(chǎn)系統(tǒng)和容災(zāi)系統(tǒng)之間的地理距離。

ROI（Return of Investment）：容災(zāi)系統(tǒng)的投入產(chǎn)出比。

2 “同城雙活”高可用系統(tǒng)架構(gòu)設(shè)計(jì)

2.1 系統(tǒng)架構(gòu)總體描述

“同城雙活”系統(tǒng)架構(gòu)是指在同城機(jī)房中部署兩套應(yīng)用環(huán)境，同時(shí)對外提供服務(wù)。該架構(gòu)設(shè)備資源利用率高、并發(fā)吞吐量大、數(shù)據(jù)一致性難度低，通過負(fù)載均衡、流量調(diào)度等策略可以起到一定的故障轉(zhuǎn)移效果，在運(yùn)營商系統(tǒng)上云改造中被廣泛應(yīng)用。

本文提出“同城雙活”高可用設(shè)計(jì)方案，部署架構(gòu)如圖1所示。

圖1 “同城雙活”高可用部署架構(gòu)圖

2.2 網(wǎng)關(guān)層流量調(diào)度算法及工具實(shí)現(xiàn)

2.1.1 多集群、多環(huán)境流量調(diào)度算法設(shè)計(jì)

（1）流量調(diào)度算法的形式化表述

本方法實(shí)現(xiàn)的流量調(diào)度算法支持對多集群、多環(huán)境的選擇轉(zhuǎn)發(fā)，算法描述如下。定義一個(gè)四元組，在單條流量的作用下，從變量承載方式M中，獲取業(yè)務(wù)變量V，決定作用條件C，從而得到作用結(jié)果R，確定轉(zhuǎn)發(fā)到的集群及環(huán)境。具體解釋如下：

1）V是業(yè)務(wù)變量的集合，根據(jù)實(shí)際業(yè)務(wù)場景，通?？蛇x用V = {area_code， app_id， service_id， staff_code}的集合。其中area_code為地區(qū)編碼，app_id為接入應(yīng)用編碼，service_code為應(yīng)用服務(wù)編碼，staff_code為操作人員編碼。

2）M是變量承載方式集合，表示從報(bào)文中獲取到V的具體位置或方式。HTTP協(xié)議中，M={header，cookie，urlparam}，其中header方式適用于API接口請求，特點(diǎn)是效率高、方便解析；cookie方式適用于界面請求，例如js、jss等靜態(tài)資源請求；url_param是指鏈接中的參數(shù)，適用于鏈接跳轉(zhuǎn)類請求。

3） C是作用條件的集合，本方法中，即IP地址和端口號；

4）R是作用結(jié)果集合，決定最終的轉(zhuǎn)發(fā)方向，在本方法中，即集群和邏輯環(huán)境。

（2）基于Nginx的集群及環(huán)境切換原理

最終的轉(zhuǎn)發(fā)結(jié)果R是由作用條件C決定的。C集合的IP決定了R集合的Cluster，指向集群的路由配置策略原理如圖2。例如，當(dāng)期望路由目標(biāo)地址為集群1，可配置Nginx的IP轉(zhuǎn)發(fā)策略到IP1。

圖2 Nginx節(jié)點(diǎn)選擇集群及邏輯環(huán)境原理圖

C集合中的Port決定了R集合的Env。例如，當(dāng)期望目標(biāo)的應(yīng)用環(huán)境為A環(huán)境，可配置Nginx端口轉(zhuǎn)發(fā)策略到端口1。

基于以上集群、邏輯環(huán)境的配置原理，通過IP與端口的配置組合，可以控制流量轉(zhuǎn)發(fā)任一集群的邏輯環(huán)境，以實(shí)現(xiàn)雙中心的容災(zāi)切換及版本灰度發(fā)布。

（3）根據(jù)業(yè)務(wù)需求的流量切換原理

當(dāng)需要根據(jù)指定的業(yè)務(wù)邏輯進(jìn)行流量轉(zhuǎn)發(fā)時(shí)，可通過控制V集合的條件來實(shí)現(xiàn)。

例如，需要南京（區(qū)號025）、徐州（區(qū)號0516）的流量轉(zhuǎn)發(fā)到環(huán)境B做灰度驗(yàn)證，需要將流量配置轉(zhuǎn)發(fā)到端口2，其配置偽代碼如下：

2.1.2 網(wǎng)關(guān)策略配置管理及同步工具設(shè)計(jì)

網(wǎng)關(guān)的策略在分布式配置中心Apollo中管理和持久化。為了實(shí)現(xiàn)各個(gè)Nginx節(jié)點(diǎn)配置的同步下發(fā)、同步生效，本文設(shè)計(jì)了配置同步變更工具，其方法和流程如圖3所示，算法描述如下：

圖3 Nginx集群配置同步變更工具執(zhí)行流程圖

步驟1：更改Apollo配置中心數(shù)據(jù)后，啟動配置變更數(shù)據(jù)下發(fā)，由客戶端程序接收；

步驟2：Nginx集群各個(gè)節(jié)點(diǎn)檢查配置，執(zhí)行nginx -s reload；

步驟3：Nginx主進(jìn)程Master打開新的監(jiān)聽端口；

步驟4：Nginx主進(jìn)程Master通過新配置啟動新的worker子進(jìn)程；

步驟5：Nginx主進(jìn)程Master進(jìn)程向老的worker進(jìn)程發(fā)送QUIT信號；

步驟6：老worker進(jìn)程關(guān)閉監(jiān)聽句柄，待服務(wù)處理完后優(yōu)雅下線；

步驟7：配置檢查服務(wù)與配置中心比對，如果配置不一致，發(fā)送告警。

基于該流程，可以實(shí)現(xiàn)路由策略的不停機(jī)無縫切換，切換前歷史請求仍按原路返回，保證業(yè)務(wù)的持續(xù)性。

在應(yīng)用過程中，應(yīng)用系統(tǒng)應(yīng)避免socket長連接的設(shè)計(jì)。長連接的引入將導(dǎo)致流量切換時(shí)難以快速生效，在Nginx reload過程中，由于老的worker進(jìn)程不能及時(shí)釋放，多次切換后還可能導(dǎo)致內(nèi)存溢出故障。

2.3 應(yīng)用框架層高可用設(shè)計(jì)

（1）服務(wù)健康檢查及故障恢復(fù)機(jī)制設(shè)計(jì)

利用kubernetes（簡稱K8S）的就緒探針（readinessProbe）和存活探針（livenessProbe）實(shí)現(xiàn)服務(wù)啟動和運(yùn)行階段的健康檢查。就緒探針健康檢查的工作原理如圖4所示。

圖4 K8S Service向Pod負(fù)載流量的健康檢查機(jī)制

K8S中通過Service向外暴露服務(wù)，提供向內(nèi)部各個(gè)Pod（K8S資源管理的最小單元）的負(fù)載均衡。Service通過Label Selector匹配當(dāng)前就緒的Pod，還未就緒的Pod不會出現(xiàn)在Service的endpoints（目標(biāo)節(jié)點(diǎn)），即流量不會向其轉(zhuǎn)發(fā)。就緒探針在Pod的啟動階段根據(jù)配置策略開始探測服務(wù)是否可用，如果探測成功則容器進(jìn)入ready狀態(tài)。當(dāng)一個(gè)Pod中的所有的容器進(jìn)入ready狀態(tài)后，該P(yáng)od的ready狀態(tài)為true，此時(shí)可被Service發(fā)現(xiàn)并納入流量轉(zhuǎn)發(fā)節(jié)點(diǎn)。如果就緒探針探測失敗，則流量不會向其轉(zhuǎn)發(fā)。配合spec.restartPolicy重啟策略的定義，可以自動實(shí)現(xiàn)啟動失敗pod的自動重啟，直至正常啟動進(jìn)入ready狀態(tài)后，才向外提供服務(wù)。

就緒探針的執(zhí)行原理與存活探針類似，通過健康檢查策略配合重啟策略，可對異常Pod及時(shí)清理，從而實(shí)現(xiàn)運(yùn)行期間的故障自動恢復(fù)。

需要注意的是，一旦容器發(fā)生不可恢復(fù)的異常，單純依賴K8S的健康檢查將無法徹底排除故障。例如，當(dāng)應(yīng)用連接的數(shù)據(jù)庫異常導(dǎo)致容器在啟動階段或運(yùn)行階段異常退出，Pod重啟后將始終不能進(jìn)入ready狀態(tài)。此時(shí)應(yīng)當(dāng)配合Pod重啟的告警及時(shí)人為干預(yù)排障。

（2）應(yīng)用網(wǎng)關(guān)的熔斷降級、限流和重試機(jī)制設(shè)計(jì)

當(dāng)遇到諸如秒殺購物、搶票等超高流量并發(fā)場景，系統(tǒng)承載能力已不能滿足實(shí)際的并發(fā)量時(shí)，為了避免流量洪峰沖垮整個(gè)系統(tǒng)，同時(shí)為客戶提供友好的報(bào)錯(cuò)信息，需要由應(yīng)用網(wǎng)關(guān)來做熔斷降級和限流。為避免由于網(wǎng)絡(luò)傳輸導(dǎo)致的偶發(fā)性異常，可通過重試機(jī)制來提高服務(wù)可用性。

本方法的熔斷降級機(jī)制采用令牌桶限流算法。該算法在限制調(diào)用平均速率的同時(shí)還允許一定程度的突發(fā)調(diào)用。

2.4 核心應(yīng)用組件一鍵應(yīng)急切換工具設(shè)計(jì)

為避免單機(jī)房組件整體故障的風(fēng)險(xiǎn)，核心應(yīng)用組件分布式緩存、分布式消息隊(duì)列在自身主備切換功能的基礎(chǔ)上，本方法設(shè)計(jì)了備用組件一鍵應(yīng)急切換的工具，原理如圖5所示。

圖5 備用組件一鍵應(yīng)急切換工具執(zhí)行流程圖

其算法執(zhí)行步驟：

步驟1：在配置中心中準(zhǔn)備好備用組件的配置集；

步驟2：切換控制器發(fā)出切換配置指令到K8S的ConfigMap中，修改其環(huán)境變量為備用配置集；

步驟3：切換控制器向相關(guān)容器發(fā)出重啟指令；

步驟4：容器重啟時(shí)，讀取ConfigMap中的環(huán)境變量，獲取備用配置集的信息；

步驟5：從配置中心讀取備用組件的配置集，完成重啟。

備用組件保持可用狀態(tài)的關(guān)鍵：

（1）緩存組件：在做緩存配置變更時(shí)，應(yīng)同時(shí)向備用緩存中上載配置。

（2）消息隊(duì)列組件：在建立Topic、消費(fèi)組時(shí)，應(yīng)保持備用環(huán)境與生產(chǎn)環(huán)境的一致。

通過以上策略，組件應(yīng)急切換可以在生產(chǎn)環(huán)境默認(rèn)組件全阻的情況下，實(shí)現(xiàn)向備用應(yīng)急組件的快速切換，降低故障恢復(fù)時(shí)間。

3 “兩地三中心”容災(zāi)架構(gòu)設(shè)計(jì)

在“同城雙活”部署的基礎(chǔ)上，擴(kuò)展異地容災(zāi)熱備部署，其架構(gòu)設(shè)計(jì)如圖6所示。綜合考慮故障恢復(fù)時(shí)間RTO、故障期間數(shù)據(jù)損失率RPO、投出產(chǎn)出比ROI三個(gè)指標(biāo)，其部署特點(diǎn)如下：

圖6 兩地三中心容災(zāi)部署架構(gòu)

（1）機(jī)房流量調(diào)度：通過智能DNS實(shí)現(xiàn)向容災(zāi)環(huán)境的流量調(diào)度。

（2）備機(jī)房的部署：備機(jī)房采用單集群部署模式，保持當(dāng)前生產(chǎn)環(huán)境的軟件版本。

（3）公共組件分布式部署：對實(shí)時(shí)性要求不高、讀寫頻率較小的組件，可采用分布式部署方式，保持?jǐn)?shù)據(jù)一致，其中備機(jī)房的節(jié)點(diǎn)數(shù)可采用最小化設(shè)置。推薦公共部署的組件有：配置中心、日志中心、分布式文件系統(tǒng)、定時(shí)任務(wù)組件等。

（4）數(shù)據(jù)庫同步及一致性保證：從主機(jī)房交易庫通過otter工具向備機(jī)房交易庫同步數(shù)據(jù)。備機(jī)房根據(jù)資源條件及業(yè)務(wù)需要決定是否設(shè)置運(yùn)維庫。

4 方法實(shí)現(xiàn)

該高可用性系統(tǒng)設(shè)計(jì)方法已在“江蘇電信新一代支付中心”系統(tǒng)上應(yīng)用實(shí)現(xiàn)，支付中心的可用性和容災(zāi)性得到顯著提升。為了驗(yàn)證其高可用的設(shè)計(jì)效果，通過破壞性測試、壓力測試等手段，得到測試結(jié)論如表1所示。

表1 江蘇電信新一代支付中心高可用系統(tǒng)測試案例

為了驗(yàn)證系統(tǒng)持續(xù)服務(wù)能力，測試期間通過LoadRunner工具對服務(wù)進(jìn)行壓力測試，得到測試接口的吞吐量及報(bào)錯(cuò)情況?！叭萜鞴收匣謴?fù)”場景測試中，在第4分鐘模擬單個(gè)容器服務(wù)故障，正常觸發(fā)了容器健康檢查和故障恢復(fù)。由于故障恢復(fù)期間（10s左右）可用節(jié)點(diǎn)數(shù)降低，接口并發(fā)量稍有下降，待容器重啟完成重新加入服務(wù)列表后，并發(fā)量恢復(fù)正常。

5 結(jié)束語

為提升分布式云化交易型系統(tǒng)的可用性，降低系統(tǒng)故障概率，縮短故障恢復(fù)時(shí)間，提升系統(tǒng)容災(zāi)性，本文設(shè)計(jì)了“同城雙活”和“兩地三中心兩套高可用系統(tǒng)部署架構(gòu)，分架構(gòu)、分層級闡述了高可用系統(tǒng)設(shè)計(jì)方法。實(shí)際應(yīng)用中可根據(jù)業(yè)務(wù)容災(zāi)等級做架構(gòu)的選型。

本文創(chuàng)新提出基于Nginx的多集群、多環(huán)境流量調(diào)度原理，并提出網(wǎng)關(guān)配置同步變更工具的設(shè)計(jì)方法；創(chuàng)新提出備用組件一鍵應(yīng)急切換工具的設(shè)計(jì)方法；創(chuàng)新提出了異地容災(zāi)環(huán)境建設(shè)的總體方案。

該方法已在“江蘇電信新一代支付中心”系統(tǒng)上應(yīng)用實(shí)現(xiàn)，通過破壞性、壓力測試驗(yàn)證了設(shè)計(jì)方法的有效性，并在實(shí)際生產(chǎn)中驗(yàn)證了系統(tǒng)的高可用性。