基于高可用性的分布式云化交易型系統(tǒng)設計方法研究

白海洋 臺運紅

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

0 引言

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

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

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

1 相關概念

1.1 交易型系統(tǒng)

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

1.2 系統(tǒng)高可用

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

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

1.3 容災系統(tǒng)關鍵指標

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

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

容災半徑：生產系統(tǒng)和容災系統(tǒng)之間的地理距離。

ROI（Return of Investment）：容災系統(tǒng)的投入產出比。

2 “同城雙活”高可用系統(tǒng)架構設計

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

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

本文提出“同城雙活”高可用設計方案，部署架構如圖1所示。

圖1 “同城雙活”高可用部署架構圖

2.2 網(wǎng)關層流量調度算法及工具實現(xiàn)

2.1.1 多集群、多環(huán)境流量調度算法設計

（1）流量調度算法的形式化表述

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

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

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

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

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

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

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

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

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

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

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

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

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

2.1.2 網(wǎng)關策略配置管理及同步工具設計

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

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

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

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

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

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

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

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

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

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

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

2.3 應用框架層高可用設計

（1）服務健康檢查及故障恢復機制設計

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

圖4 K8S Service向Pod負載流量的健康檢查機制

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

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

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

（2）應用網(wǎng)關的熔斷降級、限流和重試機制設計

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

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

2.4 核心應用組件一鍵應急切換工具設計

為避免單機房組件整體故障的風險，核心應用組件分布式緩存、分布式消息隊列在自身主備切換功能的基礎上，本方法設計了備用組件一鍵應急切換的工具，原理如圖5所示。

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

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

步驟1：在配置中心中準備好備用組件的配置集；

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

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

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

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

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

（1）緩存組件：在做緩存配置變更時，應同時向備用緩存中上載配置。

（2）消息隊列組件：在建立Topic、消費組時，應保持備用環(huán)境與生產環(huán)境的一致。

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

3 “兩地三中心”容災架構設計

在“同城雙活”部署的基礎上，擴展異地容災熱備部署，其架構設計如圖6所示。綜合考慮故障恢復時間RTO、故障期間數(shù)據(jù)損失率RPO、投出產出比ROI三個指標，其部署特點如下：

圖6 兩地三中心容災部署架構

（1）機房流量調度：通過智能DNS實現(xiàn)向容災環(huán)境的流量調度。

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

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

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

4 方法實現(xiàn)

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

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

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

5 結束語

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

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

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