基于Nodejs的前端灰度宣布计划
1. 灰度宣布和A/B测试简介
灰度宣布
将某个功用灰度宣布（逐步放量）给特定线上人群，防备新功用全量上线带来的风险。
上面的图可以经由历程两个方面来明白：
- 蓝色实线和蓝色虚线接见Nginx效劳器，nginx经由历程负载平衡将流量分摊到后端效劳器。
- 黄色的线是运用了灰度的流量（设置Nginx划定规矩）可以将特定流量分发到特定的机房，以抵达对特定用户运用产物新功用；
举个简朴的例子：将http要求cookie中含有test=1字段的要求都转发到灰度代码的机房；
上面经由历程经由历程设置特定Nginx划定规矩的要领来抵达产物灰度的要领虽然可以满足一定营业量的需求，然则他也有许多的瑕玷：
- 不天真，每次上线新营业代码须要做灰度都要从新更新nginx划定规矩，形成开辟和运维累赘；
- 上线的代码要做机房辨别，不可以将代码全量。当地的Git代码也要辨别开辟分支和测试分支，线上分支等多少分支，治理起开贫苦；
- 不能满足营业量大或许营业须要频仍迭代，须要频仍做测试的营业；
那末有无更好的要领来做灰度宣布呢？固然是有的，A/B测试就可以填补上面经由历程Nginx划定规矩来做灰度的瑕玷。
A/B测试
将线上一部份实在人群流量随机拆分红多个组，对每一个分组的人群运用差别战略或功用，经由历程盘算每组人群的营业目标（转化率、成交率等）来权衡战略或功用的实际效果。
我们经由历程下面的这张图简朴的了解下A/B测试的道理：
由上图我们可以晓得A/B和传统的灰度要领的区分：
传统的灰度是经由历程Nginx分发流量到效劳器，A/B测试是经由历程营业代码辨别流量接见差别的代码块。
那末A/B测试的优瑕玷是什么呢？
长处：
- 跟着营业的变化不必频仍的变化Nginx划定规矩，不必分机房上线营业代码，当地git分支不必为了做灰度而建特地的分支；
- 流量辨别是营业代码做的。所以上线代码的时刻可以全量上线到一切机房；
瑕玷：
- 由于流量辨别是营业代码做的。所以在代码中会存在许多的
if...else分支语句。然则如许还好，由于依据SDK的范例来誊写代码，照样很好治理的。
2. 基于A/B测试的前端灰度怎样做
前端跟后端很大的区分就是直接面临用户，就算很简朴的修正一次按钮的色彩就须要一次上线。这类操纵对用户是可感知的。
当代前端有个特征就是脱离了后端模板引擎的衬着，大多数是运用React、Vue这类MVVM框架的前端（浏览器）衬着。这类情况下后端实在仅仅是给用户供应一个空的html文件（事情中常常称作为壳）。大多数营业代码开辟完今后都是作为静态文件上线到效劳器，经由用户接见后缓存到CDN节点上的。而且这个历程大多数是增量上线的。
实在我们每次上线完以后效劳器上缓存的html文件就包含差别的版本信息。假如我们把这些版本信息治理起来，而且经由历程特定的手腕（对用户要求运用A/B测试）就可以完成前端差别版本的灰度宣布。
运用Nodejs天真掌握前端宣布
我们可以视察下Webpack或许是别的打包东西打包后的html文件。每次外联的静态文件都包含差别的hash戳。这些外链的文件又都是增量缓存到效劳其上的。
index.html （我们页面的“壳”）
一些 xxx.js文件 （衬着页面+页面的营业逻辑）
xxx.css 文件 （掌握页面显现款式）
也许就是下面的这个模样
基于以上的特征，我们能不能只管削减对营业代码侵入，而可以掩盖营业修改较大的需求举行灰度或许是A/B测试呢？
看下下面的这个这个要求的图：
每次我们打包编译完以后，就将相干的css文件和js文件信息保存到当地的一个json文件中。这些信息的key可所以我们的git的tag信息（主要来形貌本次发版信息包含的功用等）。
基本上json文件包含的信息以下：
const version = {
// 可以形貌本次的上线内容/ 或许是git tag
'tag1': {
'css': 'xxxxxxx.css',
'app': 'app_xxx.js',
'ventor'： 'ver_xxx.js'
}
}这里仅仅是一个简朴的demo示例，可以运用Nodejs写文件的特征直接将文件版本号写入到index.html返回给前端浏览器
Nodejs效劳的特征是每次更新完代码须要重启以后才见效。每次上完线重启效劳就会先搜检当地代码根目次下的这个json文件。看下这个个中包含的tag是不是在DB中存储，假如有存储就不做操纵，假如没有就将它存储DB做耐久化。
上面图上面的Apollo就是用来设置那些用户接见新功用的平台。在Nodejs端，每次接收到用户要求的时刻都邑推断用户的信息是不是满足相干前提，然后从DB中读取相干静态文件信息衬着到index.html中去。
简朴总结下：将每次打包的静态文件信息先存储下来，以后要求抵达Nodejs的时刻推断用户是不是满足相干前提，假如满足就读取DB将相干的静态文件信息返回给Nodejs，Nodejs将静态页衬着好以后返回给用户，抵达灰度的目标。
3.别的细节题目
运用Nodejs之前我们的页面就是直接布置在效劳其上，此次运用了Nodejs后，会有许多别的的题目须要做，比如说Nodejs效劳的监控，多机房布置等。这些在大部份的公司应当都有相干的运维工程师来做。我这里简朴引见一些别的的内容
范例的一定
这里的范例包含当地开辟时工程目次的范例和线上用户接见url的范例。
- 开辟目次范例
在笔者写这篇文章的时刻最新的Nodejs版本已是 11.10版本了，最新的LTS版本是10.15.1版本。发起运用Nodejs的同砚都晋级本身的Node到8.0版本以上，由于8.0版本是一个官方原生支撑async...await语句的版本。
.
├── client // 安排客户端的代码
├── index.html
├── index.js
├── node_modules
├── output
├── package-lock.json
├── package.json
├── server // 安排效劳端Nodejs代码
├── test.sh
须要注重的就是在编写webpack打包东西的时刻将server目次下的给排撤除。安排不必要的编译和产出，增添打包速率。
- 线上url的商定
当运用了新的效劳的时刻为了防备跟旧营业的争执一定须要运用新的url。这个时刻就须要做一些商定。现在我们是这么商定的
// 域名/产物线/模块/
http://wwww.aaa.com/driver/bus/index.html
// 域名/产物线/模块/静态文件目次
http://wwww.aaa.com/driver/bus/static/js/index.js
http://wwww.aaa.com/driver/bus/static/css/index.html兼容老营业须要做的事情
前面提到此次营业晋级我们运用了新的url，然则为了保证营业的稳定性我们不是一次性将一切的流量都切到新效劳上去的。我们也是经由历程批量的切的，所以会存在线上用户有的区域接见新效劳有区域接见旧效劳。那末有一天会有悉数切换的一天，然则照样会有一些用户接见到旧链接，这个时刻可以经由历程设置Nginx 的`rewrite来讲旧链接都转成新的链接。
- 晋级后的营业怎样接见新的衔接
- 已要求相干的设置
防备不必要的要求
前端路由可以分为两种体式格局，hash和path切换。由于关于前端衬着页面来讲，当第一次要求完成后，实在一切的页面都已下载到了当地（页面异步加载除外）。在我们经由历程path切换页面的时刻，每次都邑向效劳端发送要求，实在这些要求是不须要抵达Nodejs效劳的。我们可以经由历程Nginx设置将这些无用的流量招架在Nginx这一层，削减效劳器的压力。
假如是运用hash的体式格局则不存在如许的题目，然则会有别的的题目就是对搜索引擎不友好。固然前端路由切换照样应当依据本身的营业做弃取。
4. 前端营业拓展
当我们运用了Nodejs效劳以后，可以拓展的手艺点有哪些，一下简朴枚举一些：
- 效劳端衬着：进步首屏衬着时候，提拔用户体验。
- 前端接口校验：增添前端接见后端接口，后端接口返回数据的安全性。
- 前后端星散，前端工程师的天真性越发的高。
5. 手艺晋级带来的收益
- 前端上线可以完成小流量、灰度、宣布，可以对线上流量做A/B测试，削减线上题目；
- 可以定制化对部份用户推进新功用；
- 加速首屏的衬着时候，提拔用户体验；
- 多机房布置前端代码，下降前端效劳不可用的风险；
- 团队成员手艺才能的提拔；
6. 末了
固然这类计划也不仅仅是可以运用Nodejs来做，也可以运用别的言语。由于我们公司已有基于A/B测试的Nodejs-SDK。我这我就不详细引见道理了。道理可以参考百度百科。假如有题目须要一同议论可以留言或许是邮箱联络我：hpuhouzhiqiang@gmail.com
