摘要：基于的前端灰度發(fā)布方案灰度發(fā)布和測(cè)試簡(jiǎn)介灰度發(fā)布將某個(gè)功能灰度發(fā)布逐漸放量給特定線上人群，避免新功能全量上線帶來的風(fēng)險(xiǎn)。如果我們把這些版本信息管理起來，并且通過特定的手段對(duì)用戶請(qǐng)求應(yīng)用測(cè)試就可以完成前端不同版本的灰度發(fā)布。

將某個(gè)功能灰度發(fā)布（逐漸放量）給特定線上人群，避免新功能全量上線帶來的風(fēng)險(xiǎn)。

上面的圖可以通過兩個(gè)方面來理解：

藍(lán)色實(shí)線和藍(lán)色虛線訪問Nginx服務(wù)器，nginx通過負(fù)載均衡將流量分?jǐn)偟胶蠖朔?wù)器。

黃色的線是應(yīng)用了灰度的流量（配置Nginx規(guī)則）可以將特定流量分發(fā)到特定的機(jī)房，以達(dá)到對(duì)特定用戶應(yīng)用產(chǎn)品新功能；

舉個(gè)簡(jiǎn)單的例子：將http請(qǐng)求cookie中含有test=1字段的請(qǐng)求都轉(zhuǎn)發(fā)到灰度代碼的機(jī)房；

上面通過通過配置特定Nginx規(guī)則的方法來達(dá)到產(chǎn)品灰度的方法雖然可以滿足一定業(yè)務(wù)量的需求，但是他也有很多的缺點(diǎn)：

不靈活，每次上線新業(yè)務(wù)代碼需要做灰度都要重新更新nginx規(guī)則，造成開發(fā)和運(yùn)維負(fù)擔(dān)；

上線的代碼要做機(jī)房區(qū)分，不能夠?qū)⒋a全量。本地的Git代碼也要區(qū)分開發(fā)分支和測(cè)試分支，線上分支等若干分支，管理起開麻煩；

不能滿足業(yè)務(wù)量大或者業(yè)務(wù)需要頻繁迭代，需要頻繁做測(cè)試的業(yè)務(wù)；

那么有沒有更好的方法來做灰度發(fā)布呢？當(dāng)然是有的，A/B測(cè)試就能夠彌補(bǔ)上面通過Nginx規(guī)則來做灰度的缺點(diǎn)。

將線上一部分真實(shí)人群流量隨機(jī)拆分成多個(gè)組，對(duì)每個(gè)分組的人群應(yīng)用不同策略或功能，通過計(jì)算每組人群的業(yè)務(wù)指標(biāo)（轉(zhuǎn)化率、成交率等）來衡量策略或功能的實(shí)際效果。

我們通過下面的這張圖簡(jiǎn)單的了解下A/B測(cè)試的原理：

由上圖我們可以知道A/B和傳統(tǒng)的灰度方法的區(qū)別：

傳統(tǒng)的灰度是通過Nginx分發(fā)流量到服務(wù)器，A/B測(cè)試是通過業(yè)務(wù)代碼區(qū)分流量訪問不同的代碼塊。

那么A/B測(cè)試的優(yōu)缺點(diǎn)是什么呢？

優(yōu)點(diǎn)：

隨著業(yè)務(wù)的變化不用頻繁的變化Nginx規(guī)則，不用分機(jī)房上線業(yè)務(wù)代碼，本地git分支不用為了做灰度而建專門的分支；

流量區(qū)分是業(yè)務(wù)代碼做的。所以上線代碼的時(shí)候可以全量上線到所有機(jī)房；

缺點(diǎn)：

因?yàn)榱髁繀^(qū)分是業(yè)務(wù)代碼做的。所以在代碼中會(huì)存在很多的if...else分支語(yǔ)句。但是這樣還好，因?yàn)楦鶕?jù)SDK的規(guī)范來書寫代碼，還是很好管理的。

前端跟后端很大的區(qū)別就是直接面對(duì)用戶，就算很簡(jiǎn)單的修改一次按鈕的顏色就需要一次上線。這種操作對(duì)用戶是可感知的。

現(xiàn)代前端有個(gè)特點(diǎn)就是脫離了后端模板引擎的渲染，大多數(shù)是使用React、Vue這種MVVM框架的前端（瀏覽器）渲染。這種情況下后端其實(shí)僅僅是給用戶提供一個(gè)空的html文件（工作中經(jīng)常稱作為殼）。大多數(shù)業(yè)務(wù)代碼開發(fā)完以后都是作為靜態(tài)文件上線到服務(wù)器，經(jīng)過用戶訪問后緩存到CDN節(jié)點(diǎn)上的。而且這個(gè)過程大多數(shù)是增量上線的。

其實(shí)我們每次上線完之后服務(wù)器上緩存的html文件就包含不同的版本信息。如果我們把這些版本信息管理起來，并且通過特定的手段（對(duì)用戶請(qǐng)求應(yīng)用A/B測(cè)試）就可以完成前端不同版本的灰度發(fā)布。

我們可以觀察下Webpack或者是其它打包工具打包后的html文件。每次外聯(lián)的靜態(tài)文件都包含不同的hash戳。這些外鏈的文件又都是增量緩存到服務(wù)其上的。

index.html （我們頁(yè)面的“殼”）
一些 xxx.js文件 （渲染頁(yè)面+頁(yè)面的業(yè)務(wù)邏輯）
xxx.css 文件 （控制頁(yè)面顯示樣式）

大概就是下面的這個(gè)樣子

基于以上的特點(diǎn)，我們能不能盡量減少對(duì)業(yè)務(wù)代碼侵入，而可以覆蓋業(yè)務(wù)改動(dòng)較大的需求進(jìn)行灰度或者是A/B測(cè)試呢？

看下下面的這個(gè)這個(gè)請(qǐng)求的圖：

每次我們打包編譯完之后，就將相關(guān)的css文件和js文件信息保存到本地的一個(gè)json文件中。這些信息的key可以是我們的git的tag信息（主要來描述本次發(fā)版信息包含的功能等）。

基本上json文件包含的信息如下：

const version = {
  // 可以描述本次的上線內(nèi)容/ 或者是git tag
  "tag1": {
    "css": "xxxxxxx.css",
    "app": "app_xxx.js",
    "ventor"： "ver_xxx.js"
  }
}

這里僅僅是一個(gè)簡(jiǎn)單的demo示例，可以使用Nodejs寫文件的特性直接將文件版本號(hào)寫入到index.html返回給前端瀏覽器

Nodejs服務(wù)的特點(diǎn)是每次更新完代碼需要重啟之后才能生效。每次上完線重啟服務(wù)就會(huì)先檢查本地代碼根目錄下的這個(gè)json文件。看下這個(gè)其中包含的tag是否在DB中存儲(chǔ)，如果有存儲(chǔ)就不做操作，如果沒有就將它存儲(chǔ)DB做持久化。

上面圖上面的Apollo就是用來配置那些用戶訪問新功能的平臺(tái)。在Nodejs端，每次接收到用戶請(qǐng)求的時(shí)候都會(huì)判斷用戶的信息是否滿足相關(guān)條件，然后從DB中讀取相關(guān)靜態(tài)文件信息渲染到index.html中去。

簡(jiǎn)單總結(jié)下：將每次打包的靜態(tài)文件信息先存儲(chǔ)下來，之后請(qǐng)求到達(dá)Nodejs的時(shí)候判斷用戶是否滿足相關(guān)條件，如果滿足就讀取DB將相關(guān)的靜態(tài)文件信息返回給Nodejs，Nodejs將靜態(tài)頁(yè)渲染好之后返回給用戶，達(dá)到灰度的目的。

使用Nodejs之前我們的頁(yè)面就是直接部署在服務(wù)其上，這次使用了Nodejs后，會(huì)有很多其它的問題需要做，比如說Nodejs服務(wù)的監(jiān)控，多機(jī)房部署等。這些在大部分的公司應(yīng)該都有相關(guān)的運(yùn)維工程師來做。我這里簡(jiǎn)單介紹一些其它的內(nèi)容

這里的規(guī)范包括本地開發(fā)時(shí)工程目錄的規(guī)范和線上用戶訪問url的規(guī)范。

開發(fā)目錄規(guī)范

在筆者寫這篇文章的時(shí)候最新的Nodejs版本已經(jīng)是 11.10版本了，最新的LTS版本是10.15.1版本。建議使用Nodejs的同學(xué)都升級(jí)自己的Node到8.0版本以上，因?yàn)?b>8.0版本是一個(gè)官方原生支持async...await語(yǔ)句的版本。

.
├── client // 放置客戶端的代碼
├── index.html
├── index.js
├── node_modules
├── output
├── package-lock.json
├── package.json
├── server // 放置服務(wù)端Nodejs代碼
├── test.sh

需要注意的就是在編寫webpack打包工具的時(shí)候?qū)erver目錄下的給排除掉。放置不必要的編譯和產(chǎn)出，增加打包速度。

線上url的約定

當(dāng)使用了新的服務(wù)的時(shí)候?yàn)榱朔乐垢f業(yè)務(wù)的沖突肯定需要使用新的url。這個(gè)時(shí)候就需要做一些約定。目前我們是這么約定的

// 域名/產(chǎn)品線/模塊/
http://wwww.aaa.com/driver/bus/index.html
// 域名/產(chǎn)品線/模塊/靜態(tài)文件目錄
http://wwww.aaa.com/driver/bus/static/js/index.js
http://wwww.aaa.com/driver/bus/static/css/index.html

前面提到這次業(yè)務(wù)升級(jí)我們使用了新的url，但是為了保證業(yè)務(wù)的穩(wěn)定性我們不是一次性將所有的流量都切到新服務(wù)上去的。我們也是通過批量的切的，所以會(huì)存在線上用戶有的地區(qū)訪問新服務(wù)有地區(qū)訪問舊服務(wù)。那么有一天會(huì)有全部切換的一天，但是還是會(huì)有一些用戶訪問到舊鏈接，這個(gè)時(shí)候可以通過配置Nginx 的`rewrite來講舊鏈接都轉(zhuǎn)成新的鏈接。

升級(jí)后的業(yè)務(wù)怎么訪問新的連接

已經(jīng)請(qǐng)求相關(guān)的配置

前端路由可以分為兩種方式，hash和path切換。因?yàn)閷?duì)于前端渲染頁(yè)面來說，當(dāng)?shù)谝淮握?qǐng)求完成后，其實(shí)所有的頁(yè)面都已經(jīng)下載到了本地（頁(yè)面異步加載除外）。在我們通過path切換頁(yè)面的時(shí)候，每次都會(huì)向服務(wù)端發(fā)送請(qǐng)求，其實(shí)這些請(qǐng)求是不需要到達(dá)Nodejs服務(wù)的。我們可以通過Nginx配置將這些無用的流量抵擋在Nginx這一層，減少服務(wù)器的壓力。

如果是使用hash的方式則不存在這樣的問題，但是會(huì)有另外的問題就是對(duì)搜索引擎不友好。當(dāng)然前端路由切換還是應(yīng)該根據(jù)自己的業(yè)務(wù)做取舍。

當(dāng)我們應(yīng)用了Nodejs服務(wù)之后，可以拓展的技術(shù)點(diǎn)有哪些，一下簡(jiǎn)單列舉一些：

服務(wù)端渲染：提高首屏渲染時(shí)間，提升用戶體驗(yàn)。

前端接口校驗(yàn)：增加前端訪問后端接口，后端接口返回?cái)?shù)據(jù)的安全性。

前后端分離，前端工程師的靈活性更加的高。

前端上線可以實(shí)現(xiàn)小流量、灰度、發(fā)布，可以對(duì)線上流量做A/B測(cè)試，減少線上問題；

可以定制化對(duì)部分用戶推動(dòng)新功能；

加快首屏的渲染時(shí)間，提升用戶體驗(yàn)；

多機(jī)房部署前端代碼，降低前端服務(wù)不可用的風(fēng)險(xiǎn)；

團(tuán)隊(duì)成員技術(shù)能力的提升；

當(dāng)然這種方案也不僅僅是可以使用Nodejs來做，也可以使用其它語(yǔ)言。因?yàn)槲覀児疽呀?jīng)有基于A/B測(cè)試的Nodejs-SDK。我這我就不具體介紹原理了。原理可以參考百度百科。如果有問題需要一起討論可以留言或者是郵箱聯(lián)系我：hpuhouzhiqiang@gmail.com