褚英雙 郭晶云

隨著港口信息化建設步入智慧港口建設的新階段，天津港智慧工作平臺逐漸融合多項港口運營相關業(yè)務，在滿足基礎辦公應用需求的同時，接入多個自建應用和第三方應用，從而對平臺運營升級的穩(wěn)定性提出較高要求。此外，移動端應用軟件使用頻次的增加也使天津港智慧工作平臺在運營升級方面面臨新的挑戰(zhàn)。為了降低天津港智慧工作平臺運營升級風險，滿足港口全天候連續(xù)作業(yè)對平臺服務連續(xù)性和穩(wěn)定性的要求，本文設計天津港智慧工作平臺灰度發(fā)布系統(tǒng)和流程，在原有的計算機端和移動端負載均衡架構的基礎上增加灰度服務器，為不同的升級類型和場景提供相應的發(fā)布策略，并配合服務器監(jiān)控、日志分析和回滾策略，完成面向指定用戶群體的灰度發(fā)布過程。

1 港口企業(yè)信息系統(tǒng)灰度發(fā)布的必要性

灰度發(fā)布指面向一定范圍內(nèi)的用戶群體發(fā)布系統(tǒng)新功能或修復系統(tǒng)問題，以確保系統(tǒng)升級發(fā)布過程的平滑性和穩(wěn)定性，避免其對用戶體驗造成大范圍的負面影響?；叶劝l(fā)布適用于用戶規(guī)模大、影響范圍廣的場景，是互聯(lián)網(wǎng)企業(yè)普遍采用的系統(tǒng)升級發(fā)布方式。例如，今日頭條、滴滴出行等移動端應用軟件經(jīng)常彈出的內(nèi)測通知就是常見的灰度發(fā)布方式之一。

隨著應用軟件更新迭代的節(jié)奏加快以及用戶對系統(tǒng)時效性的要求提高，港口企業(yè)信息系統(tǒng)面臨的運營升級壓力逐步顯現(xiàn)。目前，港口企業(yè)信息系統(tǒng)大多沿用傳統(tǒng)的升級發(fā)布方式：首先，對發(fā)布前的新系統(tǒng)開展功能測試和回歸測試;然后，選擇用戶使用率最低的時段完成系統(tǒng)升級發(fā)布;最后，對發(fā)布后的新系統(tǒng)再次開展功能測試和回歸測試。上述系統(tǒng)升級發(fā)布方式存在以下問題：（1）在用戶規(guī)模較大的情況下，很難控制系統(tǒng)升級發(fā)布過程對用戶體驗造成的負面影響;（2）發(fā)布前的系統(tǒng)測試難以實現(xiàn)真正的用戶全覆蓋;（3）在發(fā)布前的系統(tǒng)測試過程中，為了擴大系統(tǒng)測試的用戶覆蓋面，需要投入更多的資源和時間，從而導致系統(tǒng)升級發(fā)布效率大大降低;（4）由于港口生產(chǎn)具有連續(xù)性，港口企業(yè)信息系統(tǒng)需要連續(xù)運行，即使在低用戶使用率的時段升級發(fā)布系統(tǒng)，也難免對港口生產(chǎn)造成一定影響，而且這種影響是不可控制的。鑒于傳統(tǒng)的系統(tǒng)升級發(fā)布方式難以適應港口生產(chǎn)特點，有必要對原有的天津港智慧工作平臺發(fā)布系統(tǒng)和流程實施改造，設計合理有效的企業(yè)級灰度發(fā)布系統(tǒng)和流程。

2 天津港智慧工作平臺灰度發(fā)布系統(tǒng)設計

2.1 計算機端負載均衡方案

2.1.1 硬件架構

在原有的計算機端負載均衡架構的基礎上增加灰度服務器，并在灰度服務器上部署與其他負載均衡服務器相同的應用服務。根據(jù)實際業(yè)務需求和灰度用戶數(shù)量，設置單臺或多臺灰度服務器，并根據(jù)灰度發(fā)布的實際影響范圍，選擇是否將灰度服務器掛載于負載均衡架構下。為了避免發(fā)生用戶跳轉(zhuǎn)的情況，在非灰度發(fā)布期間，不掛載灰度服務器。由于用戶在灰度服務器上的任何操作均為正式業(yè)務操作，需要將灰度服務器連接至數(shù)據(jù)庫服務器。

2.1.2 軟件方案

為了將灰度發(fā)布面向的用戶群體控制在指定范圍內(nèi)，在天津港智慧工作平臺的用戶體系內(nèi)創(chuàng)建灰度發(fā)布群組?；叶劝l(fā)布群組內(nèi)的用戶通過正式登錄地址登錄系統(tǒng)，系統(tǒng)通過登錄接口判斷用戶為灰度用戶后，自動跳轉(zhuǎn)至灰度服務器所在的地址，從而在用戶無感知的情況下實現(xiàn)灰度發(fā)布。

標識灰度服務器和所有負載均衡服務器，并使標識與服務器的互聯(lián)網(wǎng)協(xié)議地址一一對應。用戶通過負載地址登錄至指定服務器后，系統(tǒng)需要作出以下判斷：一是獲取用戶信息，判斷用戶是否為灰度用戶;二是獲取本機服務器標識，判斷是否跳轉(zhuǎn)至相應的服務器。此時存在以下兩種情況。

（1）系統(tǒng)判斷當前用戶為灰度用戶，繼續(xù)獲取當前用戶登錄的服務器標識，并根據(jù)服務器標識判斷是否跳轉(zhuǎn)至相應的服務器：若登錄的服務器標識為灰度服務器，則不作處理;若登錄的服務器標識為非灰度服務器，則通過單點登錄方式跳轉(zhuǎn)至標識為灰度服務器的服務器。

（2）系統(tǒng)判斷當前用戶為非灰度用戶，繼續(xù)獲取當前用戶登錄的服務器標識，并根據(jù)服務器標識判斷是否跳轉(zhuǎn)至相應的服務器：若登錄的服務器標識為非灰度服務器，則不作處理;若登錄的服務器標識為灰度服務器，則通過隨機算法生成標識，并與負載均衡架構下的非灰度服務器標識相匹配，然后通過單點登錄方式跳轉(zhuǎn)至匹配標識所對應的非灰度服務器，從而確保登錄至灰度服務器的非灰度用戶能夠隨機分配至正式服務器，避免因非灰度用戶集中跳轉(zhuǎn)至單臺正式服務器而導致服務器壓力激增的情況。

2.2 移動端負載均衡方案

移動端服務系統(tǒng)架構由移動端應用軟件和移動端HTML5組成，在系統(tǒng)升級或功能上線時需要考慮兩種情況;因此，與計算機端負載均衡方案相比，移動端負載均衡方案更為復雜。

2.2.1 硬件架構

在原有的移動端負載均衡架構的基礎上，根據(jù)實際業(yè)務需求和灰度用戶數(shù)量，增設單臺或多臺灰度服務器?；叶确掌魈峁﹩为毜腍TML5接口，并向外部提供移動端應用軟件服務和HTML5服務，其中HTML5服務也對移動端負載均衡服務器上部署的應用軟件開放。

2.2.2 軟件方案

（1）移動端應用軟件更新 在移動端應用軟件更新場景下，采用客戶端版本推送技術，當灰度用戶使用移動端應用軟件時，向灰度用戶推送版本更新提醒。根據(jù)應用軟件更新的具體情況，內(nèi)測推送可設定為強制更新或可選更新。移動端應用軟件更新涉及應用軟件后臺服務更新和應用軟件客戶端更新：在應用軟件后臺服務更新場景下，將新客戶端配置到移動端正式服務器;在應用軟件客戶端更新場景下，將新客戶端配置到移動端灰度服務器。由于客戶端更新可能涉及后臺服務器接口更新，在軟件設計上需要分兩步來滿足此類更新場景的灰度發(fā)布需求：第一步，將客戶端配置到移動端灰度服務器;第二步，將客戶端配置到移動端正式服務器。

（2）HTML5服務更新 為了滿足多應用軟件場景下的更新需求，采用HTML5多首頁技術，通過設置不同版本的HTML5首頁，分別為正式版本和灰度版本提供入口服務：正式版本首頁配置所有正式上線的應用軟件;灰度版本首頁僅配置更新或新上線的應用軟件，正式上線的應用軟件則配置正式版本入口?；叶扔脩舻卿浵到y(tǒng)后，系統(tǒng)自動加載灰度版本首頁;灰度測試完畢后，系統(tǒng)自動加載正式版本首頁。該方案能夠在用戶無感知的情況下完成灰度測試，從而降低灰度版本首頁對用戶體驗造成的負面影響。

3 天津港智慧工作平臺灰度發(fā)布流程設計

天津港智慧工作平臺升級更新涉及計算機端新功能上線、計算機端多功能優(yōu)化更新、移動端新功能上線、移動端多功能優(yōu)化更新等多種場景。為了滿足不同場景下的系統(tǒng)升級需求，提升系統(tǒng)及其功能迭代升級的平滑性和穩(wěn)定性，需要針對不同的升級類型和場景設計相應的灰度發(fā)布流程。

3.1 計算機端灰度發(fā)布流程

計算機端灰度發(fā)布通常涉及計算機端新功能上線以及與此相對應的移動端HTML5新功能上線。如果新功能影響的用戶數(shù)量較少，則將灰度發(fā)布范圍限定在指定用戶范圍內(nèi);如果新功能影響的用戶數(shù)量較多或?qū)θw用戶都會產(chǎn)生影響，則根據(jù)影響程度設計相應的灰度發(fā)布階段。計算機端灰度發(fā)布流程如圖1所示，具體分為以下兩種情況。

（1）僅計算機端上線新功能而不涉及移動端，并且計算機端新功能上線不影響移動端HTML5功能使用。在這種情況下，只須針對新功能設計相應的灰度發(fā)布策略，通過灰度測試后，即可正式上線新功能。

（2）計算機端新功能與移動端相關功能同步上線，或計算機端新功能上線影響移動端HTML5功能使用。在這種情況下，需要將計算機端待更新內(nèi)容和移動端待更新內(nèi)容分別發(fā)布至計算機端灰度服務器和移動端灰度服務器，并使移動端灰度服務器與計算機端灰度服務器對接，從而確保功能升級對非灰度用戶隔離，并實現(xiàn)計算機端與移動端灰度用戶范圍一致。此類型升級需要增加放量次數(shù)，以降低問題暴露在更多用戶面前的概率。

3.2 移動端灰度發(fā)布流程

移動端灰度發(fā)布流程如圖2所示，具體分為以下兩種情況。

（1）移動端應用軟件更新 移動端應用軟件更新采用向灰度用戶推送版本更新提醒的方式，根據(jù)應用軟件更新的必要性及其對用戶的影響，可設定為強制更新或非強制更新。在移動端應用軟件的灰度發(fā)布流程中，需要確定是否涉及后臺服務器接口更新：如果不涉及后臺服務器接口更新，則只要選定灰度測試范圍，并根據(jù)應用軟件更新的影響范圍，將版本更新提醒分階段放量推送至灰度用戶即可;如果涉及后臺服務器接口更新，則需要先將待更新的應用軟件配置到灰度服務器，并在完成灰度測試后再次封裝應用軟件，將客戶端指向正式服務。

（2）移動端HTML5服務更新 移動端HTML5服務更新采用HTML5多首頁技術，為不同的用戶群體提供不同版本的HTML5首頁：灰度版本首頁面向灰度用戶，配置待更新的應用軟件;正式版本首頁面向非灰度用戶，配置無須更新的應用軟件。這種灰度發(fā)布方式能夠應對港口生產(chǎn)中的大部分場景，并能降低對灰度用戶日常使用系統(tǒng)功能的負面影響。

3 天津港智慧工作平臺灰度發(fā)布范圍管理及過程管理

3.1 灰度發(fā)布范圍管理

灰度發(fā)布范圍通常指灰度用戶范圍，其選擇與上線功能涉及的用戶群體及上線功能對系統(tǒng)整體的影響等因素有關。

（1）對于面向全體用戶的通用功能，可采用分階段逐步擴大灰度發(fā)布范圍和隨機選擇灰度發(fā)布范圍兩種模式：前者的優(yōu)點是便于控制影響范圍和收集用戶反饋;后者的優(yōu)點是能夠從統(tǒng)計學的角度實現(xiàn)有效覆蓋，避免因灰度發(fā)布范圍選擇不當而導致結果偏差。

（2）對于面向部分用戶的特定功能，可采用在使用此功能的用戶范圍內(nèi)隨機選擇灰度發(fā)布范圍的模式。需要注意的是：在這種情況下，有必要將不使用此功能的用戶也列入灰度發(fā)布范圍，以便測試新功能上線對原有功能的影響。

3.2 灰度發(fā)布過程管理

（1）服務器監(jiān)控 在灰度測試過程中，需要加強對內(nèi)存使用率、硬盤占用率、線程數(shù)量等服務器關鍵運行參數(shù)的實時監(jiān)控，以便及時發(fā)現(xiàn)問題并解決問題。

（2）日志分析 日志分析有助于在用戶反饋問題時準確、高效地定位問題點。在灰度測試期間，可以調(diào)低灰度服務器的日志級別，以便獲取更多的運行期信息?；叶葴y試完畢后，需要對日志進行全面分析，形成灰度測試日志分析結論。

（3）回滾策略 科學有效的回滾策略有助于降低灰度發(fā)布過程中異常問題對用戶的影響。在灰度發(fā)布過程中，如果異常問題影響用戶正常使用系統(tǒng)功能并且無法立即修復，可以采取以下兩種處理方式：一種處理方式是根據(jù)實際發(fā)布內(nèi)容和異常問題的實際影響選擇性回滾;另一種處理方式是取消灰度用戶，將灰度用戶指向正式服務，適用于計算機端灰度測試和移動端HTML5灰度測試。

4 結束語

灰度發(fā)布的目的在于使用戶參與功能上線前的測試過程，并在功能上線前根據(jù)用戶反饋完成優(yōu)化和改進，從而避免功能上線后出現(xiàn)與用戶需求不匹配的情況，進而降低補丁升級頻率和系統(tǒng)運維壓力。實踐證明，天津港智慧工作平臺灰度發(fā)布系統(tǒng)和流程能夠有效降低信息系統(tǒng)迭代更新過程中可能出現(xiàn)的風險，提升功能上線的平滑性和穩(wěn)定性，為港口全天候連續(xù)生產(chǎn)作業(yè)提供有力支撐。

（編輯：張敏 收稿日期：2020-11-13）