容器云之灰度發(fā)布設(shè)計(jì)

灰度發(fā)布是應(yīng)用服務(wù)從0到1完全發(fā)布的過程。在容器云平臺(tái)上，一個(gè)服務(wù)往往部署有很多個(gè)實(shí)例以根據(jù)業(yè)務(wù)流量實(shí)現(xiàn)彈性伸縮。為了驗(yàn)證某個(gè)服務(wù)或應(yīng)用的某一特性，或者驗(yàn)證某一服務(wù)的功能，在發(fā)布一個(gè)新的服務(wù)版本時(shí)，先發(fā)布1個(gè)或少量實(shí)例，通過對(duì)新特性的反饋分析或新功能的驗(yàn)證分析來決定是否繼續(xù)發(fā)布實(shí)例（或替換實(shí)例）或回滾?；叶劝l(fā)布和A/B測(cè)試、發(fā)布新版本和版本替換有相同點(diǎn)也有區(qū)別。軟件版本控制要說清楚灰度發(fā)布和A/B測(cè)試、發(fā)布新版本、版本替換等概念差別，先說下軟件版本控制問題。軟件產(chǎn)品對(duì)外發(fā)布版本號(hào)有Alpha、Beta、Released版本等。Alpha、Beta是對(duì)外發(fā)布的測(cè)試版本，Released指的是對(duì)外發(fā)布的正式版本。每個(gè)發(fā)布的版本號(hào)中通常包括為Major（主版本號(hào)）、Minor（小版本號(hào)）、Patch（補(bǔ)丁版本號(hào)）、Hotfix（熱修復(fù)版本號(hào)）、internal（內(nèi)部版本號(hào)）版本號(hào)等。，比如Released版本v1.2.3.4.10，其中1為主版本號(hào)，通常軟件架構(gòu)重構(gòu)或升級(jí)才會(huì)調(diào)整主版本號(hào)；2為小版本號(hào)，通常重要特性發(fā)布需要調(diào)整小版本號(hào)；3為補(bǔ)丁版本號(hào)，通常是為了修復(fù)已發(fā)布的版本中的系列漏洞而發(fā)的一個(gè)補(bǔ)丁版本或補(bǔ)丁包；4為熱修復(fù)版本號(hào)，通常用于緊急修復(fù)一些有重大影響的問題，多個(gè)的hotfixes可以打包成一個(gè)patch補(bǔ)丁包；10為內(nèi)部控制版本號(hào)，通常可用于內(nèi)部代碼或功能進(jìn)度控制等。我們暫借用軟件版本控制來說明下服務(wù)版本的灰度發(fā)布問題?；叶劝l(fā)布和A/B測(cè)試灰度發(fā)布的目的和A/B測(cè)試的目的類似，但并不等同。A/B測(cè)試的目的是為了選擇A或B而進(jìn)行的調(diào)研性測(cè)試；灰度發(fā)布的目的是驗(yàn)證某版本中某項(xiàng)功能能否滿足需求，比如某功能做了優(yōu)化，可能沒有時(shí)間進(jìn)行詳細(xì)深入的測(cè)試，需要部署到生產(chǎn)環(huán)境進(jìn)行實(shí)際生產(chǎn)驗(yàn)證，但又不能全部替換掉原來的版本（服務(wù)多實(shí)例部署，灰度發(fā)布是在服務(wù)實(shí)例級(jí)別，同一服務(wù)版本，不同實(shí)例版本），就可以發(fā)布一個(gè)灰度版本的實(shí)例，引部分流量進(jìn)行驗(yàn)證。如果沒有問題，則一步步替換掉原來全部實(shí)例（只有一個(gè)實(shí)例無法做灰度發(fā)布），如果有問題則回退。區(qū)分灰度發(fā)布和A/B測(cè)試，通常需要區(qū)分面向前端用戶的特性測(cè)試還是后端功能的驗(yàn)證。A/B測(cè)試通常是面向前端用戶的特性的調(diào)研選擇性測(cè)試，A/B測(cè)試通常有兩個(gè)入口（如下圖A/B測(cè)試）；后端功能的驗(yàn)證對(duì)用戶不可見，面向用戶的是一個(gè)入口（如下圖灰度發(fā)布），通過流量的分發(fā)策略來分發(fā)部分流量進(jìn)行驗(yàn)證。如果用戶的請(qǐng)求在使用灰度版本功能時(shí)出現(xiàn)異常或錯(cuò)誤就需要立刻回滾。如果沒有問題，則可以逐步擴(kuò)展實(shí)例數(shù)，直到全部替換。A/B測(cè)試的版本相當(dāng)于兩個(gè)Alpha或Beta版本，等調(diào)研測(cè)試之后選擇兩個(gè)中的一個(gè)正式發(fā)布為Released版本。灰度發(fā)布的版本相當(dāng)于發(fā)hotfix版本，或者也可以是patch版本，主要用于敏捷修復(fù)和驗(yàn)證功能。灰度發(fā)布和發(fā)布新版本發(fā)布新版本是全新發(fā)布一個(gè)新的服務(wù)版本或應(yīng)用版本或系統(tǒng)版本。它跟灰度沒有關(guān)系，是一個(gè)全新的發(fā)布。不管是否存在一個(gè)舊服務(wù)版本，也不管新版本和舊版本之間是否存在功能或（和）性能等之間的差別，所以可以看作是兩個(gè)獨(dú)立的版本。比如在部署了一個(gè)通用版本基礎(chǔ)上，為“大客戶甲”單獨(dú)發(fā)布部署了一個(gè)版本“v甲”?；蛘呷鏏PP可能同時(shí)有很多個(gè)版本并行運(yùn)行。舉個(gè)最容易理解的例子，比如微軟在維護(hù)Windows7操作系統(tǒng)版本時(shí)，又開發(fā)發(fā)布了Windows10。你用Windows10，我可能還在用Windows7，兩個(gè)版本同時(shí)都需要支持。發(fā)布新版本的目的并不是為了驗(yàn)證版本中功能或性能，也不是為了測(cè)試兩個(gè)版本的受歡迎或受認(rèn)可等的程度從而選擇一個(gè)更好的版本。所以發(fā)布新版本和灰度發(fā)布以及A/B測(cè)試都是不一樣的。發(fā)布新版本相當(dāng)于發(fā)布一個(gè)新的Relased版本。這通常是“應(yīng)用-服務(wù)-實(shí)例”分層中的“應(yīng)用”系統(tǒng)層，至少是“組件服務(wù)”層級(jí)，而不能是“實(shí)例”層次。灰度發(fā)布和版本替換灰度發(fā)布在灰度狀態(tài)下，是兩個(gè)版本的實(shí)例并存（多實(shí)例狀態(tài)）。版本替換功能的目的是用新的版本來替換舊的版本，并不需要存在灰度狀態(tài)的驗(yàn)證。雖然說灰度發(fā)布完成，也是實(shí)現(xiàn)了版本替換，最終結(jié)果版本一致（也存在回退可能），不過版本替換相對(duì)要簡(jiǎn)單一些，可以是單實(shí)例服務(wù)的替換，也可以是多實(shí)例服務(wù)的替換，其實(shí)就相當(dāng)于是服務(wù)版本的替換，屬于服務(wù)層的操作，它不關(guān)心服務(wù)有多少實(shí)例，一次性全部替換。有人說，應(yīng)用也可以做版本替換，沒錯(cuò)，不過需要考慮的是，是否影響到終端用戶。很多人對(duì)應(yīng)用和服務(wù)的定義是不一樣的，所以可以用是否影響終端用戶來判斷。如果影響到終端用戶，對(duì)用戶來說就是版本升級(jí)，如果對(duì)用戶透明，只是做后端服務(wù)的版本替換，比如服務(wù)的實(shí)現(xiàn)方法或連接配置等發(fā)生了改變，簡(jiǎn)單的如數(shù)據(jù)庫(kù)地址遷移了，服務(wù)配置需要更新，服務(wù)版本就發(fā)生了變化，就需要用新的服務(wù)版本替換舊的服務(wù)版本版本替換和灰度發(fā)布的區(qū)別在于是否有一個(gè)持續(xù)灰度的過程。如果沒有持續(xù)灰度的過程，就是版本替換；如果有則是灰度發(fā)布。最終目的都會(huì)實(shí)現(xiàn)版本的替換?；叶劝l(fā)布設(shè)計(jì)厘清楚了上面的幾個(gè)概念，我們討論下在以應(yīng)用管理為核心的容器云平臺(tái)或容器化PaaS平臺(tái)如何設(shè)計(jì)灰度發(fā)布功能?；叶劝l(fā)布是對(duì)服務(wù)的實(shí)例的替換過程，因此首先灰度發(fā)布是服務(wù)的一項(xiàng)功能，在應(yīng)用服務(wù)的列表或詳情頁面需要有灰度發(fā)布的入口。服務(wù)列表中灰度發(fā)布入口在應(yīng)用服務(wù)列表中，可以選擇列表中的一個(gè)服務(wù)進(jìn)行灰度發(fā)布操作。在灰度發(fā)布過程中的服務(wù)，其狀態(tài)應(yīng)該顯示“灰度”。非灰度的服務(wù)，正常的服務(wù)顯示“正常”，如果實(shí)例有異常，則顯示“異?！?。點(diǎn)服務(wù)名則進(jìn)入服務(wù)詳情頁面。在服務(wù)操作欄，則可以選擇：負(fù)載配置、灰度發(fā)布（灰度狀態(tài)則顯示“回滾”按鈕）、彈性配置、治理配置、標(biāo)簽、告警、搜索等操作。點(diǎn)“灰度發(fā)布”則打開服務(wù)灰度發(fā)布頁面，進(jìn)行灰度發(fā)布的策略配置。這里要說明的是，灰度發(fā)布的鏡像名是不變的，所以可以自動(dòng)獲??；版本號(hào)會(huì)變化，需要選擇一個(gè)新的版本號(hào)，默認(rèn)可以自動(dòng)填入最新的版本號(hào)。如果服務(wù)只有一個(gè)實(shí)例，則不可用灰度發(fā)布。固定IP方式也可以有多實(shí)例，也可以執(zhí)行灰度發(fā)布，只不過其前面往往需要加一層負(fù)載分發(fā)能力，比如說用Nginx或F5來實(shí)現(xiàn)分發(fā)?；叶炔呗耘渲没叶炔呗耘渲弥饕O(shè)置灰度發(fā)布的策略。發(fā)布的策略可以定義很多種，最常用可以使用灰度發(fā)布的服務(wù)個(gè)數(shù)或灰度發(fā)布百分比。如果用灰度發(fā)布百分比，這里可能有個(gè)問題，就是百分比分?jǐn)?shù)可能不合適，比如3個(gè)實(shí)例設(shè)置灰度替換策略50%，那灰度應(yīng)該是發(fā)布幾個(gè)實(shí)例呢？這種情況下建議下取整，3的50%是1.5，向下取整為1。在實(shí)例數(shù)較少的情況下，盡量用具體的實(shí)例個(gè)數(shù)來設(shè)置，實(shí)例數(shù)比較多時(shí)，用百分比比較合適。灰度策略可以很簡(jiǎn)單，也可以很復(fù)雜，比如再引入時(shí)間變量，等時(shí)區(qū)間或不等時(shí)區(qū)間灰度設(shè)置、定時(shí)策略和不定時(shí)策略等就可能又帶來很多灰度發(fā)布選項(xiàng)。比如前24小時(shí)發(fā)布5%，第2個(gè)24小時(shí)發(fā)布10%，第三個(gè)24小時(shí)發(fā)布40%等。還有異?；貪L策略等，會(huì)使灰度發(fā)布策略配置復(fù)雜化。在實(shí)際的服務(wù)灰度發(fā)布中，可能需要支持不同的策略選擇組合?；叶劝l(fā)布時(shí)，不改變服務(wù)實(shí)例數(shù)。調(diào)整服務(wù)實(shí)例數(shù)用彈性伸縮功能?；叶劝l(fā)布負(fù)載分發(fā)策略服務(wù)運(yùn)行在灰度狀態(tài)時(shí)，也需要考慮服務(wù)的請(qǐng)求分發(fā)策略。服務(wù)不同的分發(fā)策略會(huì)使灰度服務(wù)實(shí)例接收處理不同量的請(qǐng)求。服務(wù)分發(fā)策略可能是輪詢、權(quán)重、最小連接、響應(yīng)時(shí)間、Hash法等?；叶韧ǔ？梢允褂胔ash方法，選擇一些特定的請(qǐng)求來驗(yàn)證。在實(shí)現(xiàn)Ingress時(shí)候，就可以擴(kuò)展來支持不同的分發(fā)策略。這是平臺(tái)層的功能，就不屬于k8s調(diào)度管理層的能力了，所以需要額外的能力擴(kuò)展?；叶劝l(fā)布實(shí)例列表處于灰度狀態(tài)的服務(wù)，進(jìn)入服務(wù)詳情頁面，在服務(wù)實(shí)例列表中需要體現(xiàn)灰度實(shí)例和原實(shí)例之間的區(qū)別?？梢酝ㄟ^實(shí)例的版本號(hào)和背景色等來體現(xiàn)?；叶葼顟B(tài)的服務(wù)實(shí)例版本是不一樣的，鏡像版本也不一樣，但灰度結(jié)束后最終版本會(huì)統(tǒng)一（無論回滾或滾動(dòng)發(fā)布完成）。實(shí)例詳情頁面需要在表之上顯示服務(wù)的基本信息，包括服務(wù)名、應(yīng)用名、命名空間、創(chuàng)建人、創(chuàng)建時(shí)間、狀態(tài)、服務(wù)暴露方式、服務(wù)地址，資源分配和使用、負(fù)載策略、灰度策略、調(diào)度標(biāo)簽、備注等信息，這樣一目了然當(dāng)前服務(wù)的信息，也方便到服務(wù)、應(yīng)用等的跳轉(zhuǎn)，從而形成操作閉環(huán)。其實(shí)應(yīng)用、服務(wù)、實(shí)例、Pod、容器、集群、分區(qū)、節(jié)點(diǎn)、命名空間等各對(duì)象之間都需要通過其關(guān)系關(guān)聯(lián)起來，實(shí)現(xiàn)便利地跳轉(zhuǎn)和排序，方便查詢和統(tǒng)計(jì)。

灰度發(fā)布設(shè)計(jì)原則針對(duì)當(dāng)前容器云平臺(tái)灰度發(fā)布的一些不足，從筆者使用體驗(yàn)角度提出了一些想法。灰度發(fā)布設(shè)計(jì)首先不能把多個(gè)功能糅合在一起，否則搞不清楚要做什么，也使功能設(shè)計(jì)復(fù)雜化；另外也不能把一個(gè)操作流程分為幾個(gè)部分，否則操作體驗(yàn)會(huì)很差，做完一步不知道下一步在哪里。其實(shí)不只是灰度發(fā)布，容器云平臺(tái)設(shè)計(jì)是為了用戶使用的，而不是開發(fā)人員想當(dāng)然的自以為是。基于經(jīng)驗(yàn)和體會(huì)總結(jié)，建議灰度發(fā)布可以遵循以下原則：原則1：功能設(shè)計(jì)清晰灰度發(fā)布功能設(shè)計(jì)需要先厘清概念，不能把多種概念混在一起，單一功能不能又能發(fā)布新版本又能做版本替換等等。不同的概念往往意味著不同的功能，在設(shè)計(jì)時(shí)需要明確區(qū)分，理解單一功能邊界和區(qū)別。原則2：功能流程完整灰度發(fā)布功能需要有完整的流程，能夠形成閉環(huán)。從灰度發(fā)布入口，到策略配置，到自動(dòng)執(zhí)行灰度、異?；貪L、提醒等，然后返回服務(wù)列表，顯示服務(wù)狀態(tài)（是否灰度狀態(tài)）?；叶劝l(fā)布從服務(wù)列表回到服務(wù)列表，一個(gè)完成閉環(huán)流程結(jié)束。原則3：以用戶體驗(yàn)為最高原則灰度發(fā)布設(shè)計(jì)是為了方便用戶完成自己的工作。在設(shè)計(jì)時(shí)需要從用戶的角度來思考問題，不能僅僅從開發(fā)人員自身的角度為了完成開發(fā)功能而應(yīng)付。所以需要換位思考下，把自己當(dāng)作用戶去設(shè)計(jì)和實(shí)現(xiàn)，才能做好并贏得客戶。容器云平臺(tái)灰度發(fā)布在容器云平臺(tái)上并不是一個(gè)核心的功能，不過如果能夠