李從凡 梁燕飛 廣東利通科技投資有限公司智能交通研究院

ETC車道系統(tǒng)是高速公路深化收費公路制度改革、取消省界站后車輛通行高速公路費用收取的主要手段，而整個收費過程，是由ETC車道軟件自動完成。由于高速公路收費站在地理位置上分布較為分散，且ETC車道數(shù)量龐大，傳統(tǒng)的ETC車道軟件為單體程序，每當(dāng)版本升級時，往往需要運(yùn)維人員到達(dá)現(xiàn)場關(guān)閉車道后進(jìn)行部署，費時費力；而且為了減少對車輛通行的干擾，只能選擇車流量小時逐條更新，效率較低；遇到版本升級頻繁時，給運(yùn)維工作造成巨大的壓力。ETC車道軟件版本升級工作成本高且周期長，是日常運(yùn)維的一大痛點。

在理想的情況下，用戶希望ETC車道軟件時時刻刻都是可用的，為了滿足不斷變化的新業(yè)務(wù)，需要不斷升級更新應(yīng)用程序，有時可能需要頻繁的發(fā)布版本。為達(dá)到此目的，本文通過使用微服務(wù)技術(shù)對ETC車道軟件進(jìn)行重構(gòu)，并采用K8S特有的滾動更新技術(shù)，實現(xiàn)“零停機(jī)”、用戶“零感知”的可持續(xù)部署ETC車道軟件。

一、可持續(xù)部署技術(shù)概述

（一）K8S介紹

K8S是Kubernetes 的簡稱，它是用來管理容器集群的平臺。既然是管理集群，那么就存在被管理節(jié)點，針對每個 K8S集群都由一個 Master負(fù)責(zé)管理和控制集群節(jié)點。

我們通過 Master 對每個節(jié)點 Node 發(fā)送命令。簡單來說，Master 就是管理者，Node就是被管理者。Node 可以是一臺機(jī)器或者一臺虛擬機(jī)。在 Node 上面可以運(yùn)行多個Pod，Pod 是 K8S管理的最小單位，同時每個 Pod 可以包含多個容器（Docker）。

通過下面的 K8S架構(gòu)簡圖可以看到Master 和 Node 之間的關(guān)系：（見圖1）

圖1 K8S架構(gòu)簡圖

（二）滾動更新技術(shù)介紹

k8s通過部署（Deployment）來創(chuàng)建副本應(yīng)用程序，部署自動創(chuàng)建副本集（ReplicaSet），副本集可以精確地控制每次替換的Pod數(shù)量。具體來說，k8s每次使用一個新的副本控制器（replication controller）來替換已存在的副本控制器，從而始終使用一個新的Pod模板來替換舊的pod模板。在整個滾動過程期間，保證始終有可用的副本在運(yùn)行，從而平滑的發(fā)布新版本。

二、ETC車道軟件架構(gòu)設(shè)計

為了配合k8s實現(xiàn)滾動更新，ETC車道軟件采用微服務(wù)技術(shù)進(jìn)行設(shè)計，使其適應(yīng)具備容器化部署的能力，具體的架構(gòu)圖如圖2所示。

由圖2可以看出，ETC車道系統(tǒng)可分為4個部分，其中ETC業(yè)務(wù)模塊實現(xiàn)了收費業(yè)務(wù)，是整個系統(tǒng)里面的變化部分，也是每次版本升級的關(guān)鍵，它以Pod的形式存在于車道節(jié)點中，采用k8s的滾動更新機(jī)制進(jìn)行升級，其他模塊為輔助作用，設(shè)計理念如下：

圖2 ETC車道軟件架構(gòu)圖

（一）硬件隔離

由于ETC車道系統(tǒng)外設(shè)眾多，使用串口通信協(xié)議或者PCI卡進(jìn)行通信，而容器環(huán)境作為一臺虛擬主機(jī)，難以訪問宿主機(jī)的硬件資源，一般通過網(wǎng)絡(luò)協(xié)議與外部進(jìn)行通信，因此需要構(gòu)建一個“硬件控制模塊”的單體程序完成串口協(xié)議等到網(wǎng)絡(luò)協(xié)議的轉(zhuǎn)換，起到外設(shè)與ETC業(yè)務(wù)模塊的橋梁作用。

（二）狀態(tài)管理

要實現(xiàn)滾動更新機(jī)制，實現(xiàn)無縫升級，微服務(wù)必須是無狀態(tài)的。

ETC業(yè)務(wù)模塊負(fù)責(zé)ETC車輛的整個交易流程，在某通行車輛的交易過程中，必須臨時保存交易信息，這和微服務(wù)的無狀態(tài)要求是相矛盾的。

我們引入Redis內(nèi)存數(shù)據(jù)庫作為交易狀態(tài)的臨時存儲手段，因而ETC業(yè)務(wù)模塊可以滿足無狀態(tài)的要求，在新舊Pod的切換過程中，交易仍能持續(xù)進(jìn)行，而且Redis提供持久化機(jī)制，就算重啟計算機(jī)也不會丟失狀態(tài)，交易仍能繼續(xù)進(jìn)行。

三、集群設(shè)計

如圖3所示，高速公路的收費站為局域網(wǎng)，可以訪問部中心和省中心服務(wù)器，為了保證集群的可靠性，K8S集群應(yīng)以收費站為單位建立，而在省中心用Harbor搭建鏡像倉庫，供全省所有收費站拉取鏡像使用。

圖3 集群設(shè)計圖

具體的升級過程為：

1）先將“ETC業(yè)務(wù)模塊”鏡像上傳到鏡像倉庫

2）然后在K8S Master節(jié)點執(zhí)行升級命令

3）最后K8S集群自動完成各個ETC Node節(jié)點的自動升級。

四、實現(xiàn)持續(xù)部署

K8s的目標(biāo)是在滾動更新的過程中最大程度地減少服務(wù)的中斷，其工作過程如下：

1）k8s創(chuàng)建新的Pod，讓其處于活動狀態(tài)并準(zhǔn)備就緒

2）k8s將會停止舊的 Pod，從而將 Pod的狀態(tài)更新為“Terminating”

3）k8s將舊的Pod從 Endpoints 對象中移除

4）k8s發(fā)送一個 SIGTERM 信號給舊Pod 的主進(jìn)程。

5）SIGTERM 信號就會讓舊Pod容器以正常的方式關(guān)閉，并且不接受任何新的連接。

6）舊Pod 從 Endpoints 對象中被移除后，負(fù)載均衡器就會將流量路由到其他（新的）Pod 中去。

但由于負(fù)載均衡器檢測Endpoints對象的變化，并更新其配置是個異步的過程，可能在這個間隔里舊的Pod已經(jīng)被關(guān)閉了，所以就可能導(dǎo)致很少的請求會被路由到終止的Pod 上去。

為了解決這個問題，實現(xiàn)“零停機(jī)”，我們在編寫Deployment腳本時可以加入：

preStop：

exec：

command：["/bin/bash"，"-c"，"sleep 20"]

這樣，舊的Pod從Endpoints 對象中被移除后，還能繼續(xù)提供20秒的服務(wù)，保證了無縫切換。

五、實施過程與效果

從2020年3月開始，我們先后在廣東省多個路段進(jìn)行現(xiàn)場試運(yùn)行和優(yōu)化，經(jīng)省中心校驗，系統(tǒng)流水正確，流水上傳和參數(shù)下發(fā)正常穩(wěn)定，路段后臺管理系統(tǒng)流水和圖片查詢統(tǒng)計正常，交易時間<300ms，已具備ETC標(biāo)準(zhǔn)車道（出入口）連續(xù)24小時不間斷過車交易能力。經(jīng)過總結(jié)，我們認(rèn)為具備以下實施效果：

（1）應(yīng)用部署效率提高

利用K8S集群的滾動更新技術(shù)，每當(dāng)ETC車道軟件進(jìn)行版本升級時，只需遠(yuǎn)程操作站級Master節(jié)點，即可完成更新，更新過程不影響ETC車道正常過車，在實際使用過程中，更新一個站的30條ETC車道，耗時不到1分鐘。

（2）車道故障率下降

當(dāng)K8S集群內(nèi)的Pod出現(xiàn)故障時，集群會將Pod自動重啟，而redis中仍保存著交易狀態(tài)，車道系統(tǒng)從故障中自動恢復(fù)，整體穩(wěn)定性得到顯著提升。

（3）系統(tǒng)監(jiān)控能力提升

得益于K8S集群的多級監(jiān)控機(jī)制，運(yùn)維人員可以實現(xiàn)對系統(tǒng)、平臺、應(yīng)用的全方位監(jiān)控，監(jiān)控可以細(xì)化至每一個節(jié)點和應(yīng)用實例。監(jiān)控指標(biāo)更加豐富，同時借助消息推送渠道，使軟硬件故障通知更為及時，響應(yīng)更加迅速。

（4）人員成本下降

運(yùn)維人員直接在K8S的Master節(jié)點發(fā)出更新指令，K8S自動完成整個更新過程，運(yùn)維人員在非硬件故障情況下無須到達(dá)現(xiàn)場，有效減少了運(yùn)維人員的工作量。

六、結(jié)語

基于Kubernetes 的可持續(xù)部署技術(shù)將研發(fā)與運(yùn)維人員從煩瑣的手工操作中解放出來，同時，系統(tǒng)后臺具備了高可靠性、失敗冗余和容災(zāi)恢復(fù)等特點，在高速公路ETC車道的改造實踐中具有較大的發(fā)展空間。由于當(dāng)前系統(tǒng)每個ETC Node部署在車道工控機(jī)內(nèi)，當(dāng)車道工控機(jī)出現(xiàn)硬件故障時，ETC車道交易也將中斷，如何能利用K8S集群的高可用技術(shù)，達(dá)到車道工控機(jī)出現(xiàn)硬件故障時，ETC車道系統(tǒng)仍能正常交易，是我們下一步的研究方向。