周智　吳世進　徐建鋒

摘要：本文對移動互聯(lián)網(wǎng)程序在電信行業(yè)支撐領(lǐng)域的灰度發(fā)布方案進行闡述，由原傳統(tǒng)方式進行一次性發(fā)布、不允許試錯的升級模式逐漸轉(zhuǎn)為為互聯(lián)網(wǎng)灰度發(fā)布。針對不同忠誠度的用戶提供不同的版本，通過接受用戶的反饋確定迭代發(fā)布版本，提供用戶更好的使用體驗。

關(guān)鍵詞：移動互聯(lián)網(wǎng)；灰度發(fā)布；電信行業(yè)；微信公眾號；業(yè)務(wù)支撐系統(tǒng)

1.概述

1.1系統(tǒng)現(xiàn)狀

目前湖北聯(lián)通互聯(lián)網(wǎng)程序發(fā)布方式采用傳統(tǒng)的發(fā)布方式。在每次發(fā)布新功能時，需要停止服務(wù)才能夠發(fā)布新的版本。發(fā)布成功后再次收集新版本的反饋信息，在下一次發(fā)布中進行優(yōu)化。此流程不光用戶體驗差，并且對于用戶的反饋響應(yīng)較慢，不適合快速更替的互聯(lián)網(wǎng)程序發(fā)展需求。

1.2建設(shè)背景

隨著互聯(lián)網(wǎng)經(jīng)濟進入全面發(fā)展期；移動終端設(shè)備同生活結(jié)合越來越緊密，因此迫切需要一個互聯(lián)網(wǎng)系統(tǒng)支撐業(yè)務(wù)發(fā)展。但是互聯(lián)網(wǎng)程序必須7*24無間斷服務(wù)。傳統(tǒng)支撐系統(tǒng)可以在無業(yè)務(wù)服務(wù)的過程中進行停系統(tǒng)更新。此種方案不能滿足互聯(lián)網(wǎng)程序的服務(wù)要求，并且互聯(lián)網(wǎng)程序的更新頻率較高，基于此種要求，就迫切需要一種能夠全新的發(fā)布方式。能夠提供用戶更好的體驗，無縫銜接。

2.建設(shè)目標和總體說明

2.1建設(shè)目標

將湖北聯(lián)通對外服務(wù)的互聯(lián)網(wǎng)程序?qū)嵭谢叶劝l(fā)布，能做到7*24小時不中斷，無縫升級。全面提升用戶使用感知。并且通過灰度發(fā)布，可以嘗試新的功能點，并且及時獲取用戶使用的反饋信息。

2.1.1提高產(chǎn)品發(fā)布的效率

在傳統(tǒng)發(fā)布的方式中，每發(fā)布一個版本，要經(jīng)過大量的審核，流程。一個版本時在上一個版本發(fā)布成功后再進行下個版本的設(shè)計研發(fā)發(fā)布。通過灰度發(fā)布，可以迭代開發(fā)。快速更替版本。

2.2總體說明

2.2.1傳統(tǒng)軟件發(fā)布

傳統(tǒng)軟件開發(fā)流程通過需求分析后，交由研發(fā)人員進行開發(fā)。此階段開發(fā)完成后由測試人員進行內(nèi)部測試.當測試通過后交由合并主版本好。進行Beta版發(fā)布，由測試組、相關(guān)人員，按照需求要求進行前面測試。如果測試無誤則在正式環(huán)境發(fā)布Release版本。發(fā)布過程中需要停止服務(wù)。造成用戶感知下降。如果用戶發(fā)布過程中存在測試階段未能發(fā)現(xiàn)的問題，并且不能在短期進行問題修復(fù)。則需要進行版本回退。

傳統(tǒng)發(fā)布模式優(yōu)點：

a）由于傳統(tǒng)發(fā)布模式是屬于全量發(fā)布，所以在代碼維護上只會存在一個版本，避免多個版本代碼維護。

n）由于后端只是適用一套數(shù)據(jù)源，在數(shù)據(jù)的避免數(shù)據(jù)轉(zhuǎn)模型轉(zhuǎn)換。

c）系統(tǒng)架構(gòu)簡單，維護工作量較少。

傳統(tǒng)發(fā)布模式缺點：

a）發(fā)布模式?jīng)Q定只能全量發(fā)布，所有的測試都在發(fā)布前完成；但是由于內(nèi)部測試人員較少的問題，故會存在測試不全面導致的BUG。

b）發(fā)布版本由于前期設(shè)計的問題，在用戶體驗或者流程上的不足只能在下一個版本中修正。造成版本發(fā)布周期延長。

c）用戶對新老版本的兼容性，使用習慣有段適應(yīng)的時間，有用戶流失的風險。

2.2.2互聯(lián)網(wǎng)程序發(fā)布

由于電信營業(yè)軟件都是為運營提供服務(wù)，要求在工作時段提供無縫服務(wù)；并且使用者都是內(nèi)部員工，故在非工作時段可以通過停止服務(wù)的方式進行全量升級。避免帶來分段升級的造成的系統(tǒng)不同步問題。

但是由于電信行業(yè)部分軟件開始對互聯(lián)網(wǎng)提供服務(wù)，為用戶自助服務(wù)，針對此類業(yè)務(wù)系統(tǒng)需要支持7*24小時無間斷服務(wù)，不允許長時間停業(yè)務(wù)進行升級維護，并且互聯(lián)網(wǎng)程序更新較為頻繁，也造成了現(xiàn)有發(fā)布方案不便。

為了解決以下三點問題，需要優(yōu)化發(fā)布流程

1）能夠不中斷服務(wù)，或者減少中斷服務(wù)的時間和頻率的情況下發(fā)布版本。

2）能夠在全面發(fā)布新版本的前，進行全方位的測試，針對不同的維度，對用戶提供相應(yīng)的功能。

3）對用戶進行分維度區(qū)分，按照忠誠度，年齡段等維度區(qū)分，向不同維度的用戶提供不同的功能，收集用戶的反饋，獲取真實用戶的體驗及建議。可以導向后續(xù)的功能。并且防止新舊版本兼容性的風險，防止用戶使用習慣改變而造成的用戶流失風險。

3.灰度發(fā)布的方案

在實際生產(chǎn)運營的過程中，根據(jù)用戶的維度進行定向發(fā)布；根據(jù)系統(tǒng)發(fā)布關(guān)注點的不同，設(shè)定不同的灰度發(fā)布策略。

我們可以根據(jù)用戶號碼，用戶歸屬地域，入網(wǎng)時間，終端特性，或者按照其他的策略來區(qū)分用戶，對用戶進行分塊。提供不同的軟件版本。

灰度發(fā)布管理員按照策略生成不同的用戶域，功能覆蓋點進行個性化發(fā)布。并且提供數(shù)據(jù)反饋入口。根據(jù)反饋結(jié)果進行產(chǎn)品完善，制定新一輪的灰度發(fā)布，到最后的完整發(fā)布。

3.1灰度發(fā)布規(guī)則制定

1）篩選用戶。

a）規(guī)則生成；按照用戶的地域歸屬，入網(wǎng)時間，終端特性，內(nèi)部用戶，種子用戶，活躍用戶等維度劃分用戶，可以按照不同的用戶特性，分發(fā)給不同的測試環(huán)境。比如對于內(nèi)部用戶，種子用戶這類流失率滴的用戶提供比較激進的功能，收集反饋信息。評估用戶的接納度。

b）手動導入；灰度管理人員可以導入指定用戶的維度，將其路由至指定的測試發(fā)布環(huán)境中。

2）通過以上兩類用戶群生成規(guī)則，可以靈活動態(tài)的制定發(fā)布策略。動態(tài)的分流。以此達到迭代開發(fā)，灰度發(fā)布的，快速更新的方式。

3）當灰度發(fā)布管理員通過管理系統(tǒng)制定了分發(fā)規(guī)則。按照規(guī)則將生成具體的分發(fā)的用戶明細。待測試環(huán)境部署完畢后，將此分發(fā)用戶的明細同步到負載均衡的路由cache中。完成灰度發(fā)布規(guī)則的制定以及執(zhí)行。

3.2湖北聯(lián)通微信公眾號灰度發(fā)布概述

針對湖北聯(lián)通微信公眾號灰度發(fā)布的模式介紹：

湖北聯(lián)通對外服務(wù)的APP，微信公眾號，WAP頁面等公眾系統(tǒng)通過前置中轉(zhuǎn)代理將用戶請求轉(zhuǎn)發(fā)到后端服務(wù)器，在轉(zhuǎn)發(fā)的過程中通過灰度管理員制定的分發(fā)規(guī)則將用戶分發(fā)到不同的服務(wù)器。應(yīng)用服務(wù)器根據(jù)配置查找后臺對應(yīng)的數(shù)據(jù)源。部分需要用到內(nèi)部系統(tǒng)的接口信息，則通過DMZ區(qū)的中轉(zhuǎn)服務(wù)器進行消息轉(zhuǎn)發(fā)。調(diào)用核心網(wǎng)絡(luò)數(shù)據(jù)服務(wù)。

3.2.1公網(wǎng)服務(wù)系統(tǒng)

此模塊主要是對公眾模塊，湖北聯(lián)通對公眾服務(wù)的信息都從此窗口提供能力。WAP程序，手機APP程序，以及微信公眾號等互聯(lián)網(wǎng)程序。此類應(yīng)用通過后端接口同業(yè)務(wù)數(shù)據(jù)進行交互。以此完成對公眾的服務(wù)請求。

3.2.2負載權(quán)衡路由分發(fā)

原始負載均衡主要是為了平衡各個應(yīng)用服務(wù)器的壓力，將訪問的用戶通過預(yù)先制定的規(guī)則進行分流。

為了滿足灰度發(fā)布，在原始負載均衡上必須新建一套規(guī)則。需要將用戶群再次進行區(qū)分。在原來負載均衡的策略上增加一層灰度發(fā)布的分流規(guī)則。

通過灰度發(fā)布管理制定的規(guī)則，將用戶群按照規(guī)則路由到測試服務(wù)集群，和正式環(huán)境服務(wù)集群中。此路由規(guī)則表需要導人到cache中，并且支持動態(tài)加載，避免由于全量加載導致服務(wù)的中斷。

灰度發(fā)布的路由集群可以有多套，并不局限于一套測試環(huán)境，一套正式環(huán)境的配置。根據(jù)發(fā)布軟件的需要，可以設(shè)置多套發(fā)布環(huán)境。

3.2.3灰度發(fā)布服務(wù)器集群

服務(wù)集群根據(jù)業(yè)務(wù)要求分為測試服務(wù)集群，正式環(huán)境服務(wù)集群。但是測試服務(wù)集群并不局限只有一個，可以根據(jù)業(yè)務(wù)的要求。生成相應(yīng)的多套環(huán)境。

不同的服務(wù)集群可以針對不同分組的用戶，并且這些集群可以很方便地橫向擴展。在灰度發(fā)布的過程中，可以在測試環(huán)境中動態(tài)增加訪問的用戶數(shù)。以便達到更全面的測試。

通過多用戶的，多群體的用戶測試。收集測試用戶的反饋信息，進行及時的更新。加快版本的迭代更替。使用戶可以更新認可度較高的版本。

3.2.4灰度發(fā)布數(shù)據(jù)層

在傳統(tǒng)網(wǎng)絡(luò)發(fā)布過程中，對于數(shù)據(jù)庫數(shù)據(jù)存儲層面的變更一直是持相當謹慎的態(tài)度，因為數(shù)據(jù)庫的變更。一般都伴隨著業(yè)務(wù)的停止服務(wù)。這個情況是發(fā)布版本會盡量避免的，或者通過在前期數(shù)據(jù)庫設(shè)計中預(yù)留一部分字段，以備后續(xù)的不時之需。

在部分的灰度發(fā)布方案中也不能夠覆蓋到數(shù)據(jù)庫的修改的情況。在此方案中我們可以通過用戶的數(shù)據(jù)的實時轉(zhuǎn)換的方式來達到灰度發(fā)布的目的。在發(fā)布測試環(huán)境后，在數(shù)據(jù)庫層面建立需要轉(zhuǎn)換的用戶數(shù)據(jù)。建立兩套數(shù)據(jù)樣本，對于測試用戶采用測試樣本，對于正式用戶還是采用正式樣本。當測試用戶通過發(fā)布規(guī)則進入到測試環(huán)境中，系統(tǒng)檢測到當前用戶的數(shù)據(jù)存儲才用的正式版本中的存儲結(jié)構(gòu)。測試提醒用戶需要進行數(shù)據(jù)轉(zhuǎn)換，此時通過調(diào)用后臺的單用戶數(shù)據(jù)轉(zhuǎn)換腳本，將用戶有變化的數(shù)據(jù)轉(zhuǎn)移到新的存儲表中。這樣就實現(xiàn)了數(shù)據(jù)的無縫對接。在后續(xù)發(fā)布正式版本時，也可以通過批量轉(zhuǎn)換的方式實現(xiàn)數(shù)據(jù)的轉(zhuǎn)換。

3.2.5后端消息轉(zhuǎn)發(fā)

前端用戶通過發(fā)起業(yè)務(wù)請求，轉(zhuǎn)發(fā)到后端核心系統(tǒng)請求。由于后端服務(wù)接口變更升級較少，并且前端業(yè)務(wù)請求對后臺請求的高度依賴性。后端業(yè)務(wù)轉(zhuǎn)發(fā)無需做灰度發(fā)布的設(shè)置。

4.總結(jié)及展望

4.1全文總結(jié)

本文對移動互聯(lián)網(wǎng)灰度發(fā)布詳細的介紹，分析如何快速迭代更新發(fā)布程序，并且做到7*24小時不中斷服務(wù)，給用戶更完善的體驗。

4.2展望

本文介紹的移動互聯(lián)網(wǎng)程序的灰度發(fā)布，源于通信行業(yè)向互聯(lián)網(wǎng)企業(yè)轉(zhuǎn)型發(fā)展的迫切需要，結(jié)合湖北聯(lián)通市場的互聯(lián)網(wǎng)發(fā)展而設(shè)計和實現(xiàn)。系統(tǒng)的使用會提高聯(lián)通用戶感知，大大促進業(yè)務(wù)辦理的便捷性，并且通過灰度發(fā)布，能夠嘗試激進的功能，允許大膽創(chuàng)新，試錯。在灰度測試用戶基數(shù)的基礎(chǔ)下，能夠?qū)︻A(yù)上線的功能進行全面的測試，避免傳統(tǒng)發(fā)布模式中對于測試不全面而導致的BUG，以及功能，業(yè)務(wù)流程設(shè)計不合理的方面，對用戶的反饋及時響應(yīng)。在移動互聯(lián)網(wǎng)業(yè)務(wù)模式不斷創(chuàng)新的未來，如何進一步優(yōu)化和改善系統(tǒng)，適度超前的完善系統(tǒng)框架和主要功能，以快速響應(yīng)市場變化和需求，個人認為還有很多需要深入探索的方面。