1. 前言
互联网产品有一个特点,就是不停的升级,升级,再升级。一般采用敏捷开发的团队,基本上保持每周一次的发布频率,系统升级总是伴随着风险,新旧版本兼容的风险,用户使用习惯突然改变而造成用户流失的风险,系统down机的风险.....为了避免这些风险,很多产品都采用了灰度发布的策略,其主要思想就是把影响集中到一个点,然后再发散到一个面,出现意外情况后很容易就回退。
很长时间,我们都一直在改进搜索引擎的排序算法,尽量让最好的商品出现在 搜索结果的第一屏。我们尝试了很多种算法,不断调整各个排序因子所占的比重。但是我们无法确信我们的排序结果能满足所有用户的需求。所以我们采用了灰度发 布,选取几个一级商品类目,在其中应用不同的排序算法,比如在女装类目中,我们把卖家信用所占的比率调整到60%,在珠宝类目中,我们把销售量所占的比率 调整到60%.. 然后发布出去,收集用户反馈,最终选择一种大部分人认为好的算法。
在传统软件产品发布过程中(例如微软的Windows 7的发布过程中),一般都会经历Pre-Alpha、Alpha、Beta、Release candidate(RC)、RTM、General availability or General Acceptance (GA)等几个阶段(参考Software release life cycle)。可以看出传统软件的发布阶段是从公司内部->外部小范围测试>外部大范围测试->正式发布,涉及的用户数也是逐步放量的过程。
在互联网产品的发布过程中也较多采用此种发布方式:产品的发布过程不是一蹴而就,而是逐步扩大使用用户的范围,从公司内部用户->忠诚度较高的种子 用户->更大范围的活跃用户->所有用户。在此过程中,产品团队根据用户的反馈及时完善产品相关功能。此种发布方式,按照中国特色的叫法被冠 以”灰度发布“、”灰度放量“、”分流发布“。
关于“灰度发布”叫法的来源无从考察。只不过按照中国传统哲学的说法来看,很符合中国人中庸的思维模式:自然界所有的事物总是以对称、互补、和谐的形式存 在,例如黑与白、阴与阳、正与负、福与祸。在二元对立的元素间存在相互过渡的阶段,所谓”祸兮福所倚,福兮祸所伏“。具体到黑与白,在非黑即白中间还有中 间色——灰色。于是出现了很多关于灰色的说法:灰盒测试,灰色管理(极力推荐 任正非:管理的灰度),灰色收入,灰色地带等等。因此对于灰度发布实际上就是从不发布,然后逐渐过渡到正式发布的一个过程。
2. 灰度发布定义
灰度发布是指在黑与白之间,能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式,让一部分用户继续用A,一部分用户开始用B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面 来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。
3. 灰度发布作用
a.及早获得用户的意见反馈,完善产品功能,提升产品质量
b.让用户参与产品测试,加强与用户互动
c.降低产品升级所影响的用户范围
d.规避一定的发布风险
e.避免停服发布给用户带来不便
f.具有容灾能力
4. 灰度发布步骤
1)、定义目标
2)、选定策略:包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等
3)、筛选用户:包括用户特征、用户数量、用户常用功能、用户范围等
4)、部署系统:部署新系统、部署用户行为分析系统(web analytics)、设定分流规则、运营数据分析、分流规则微调
5)、发布总结:用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表
6)、产品完善
7)、新一轮灰度发布或完整发布
5. 灰度发布测试方法
灰度发布于互联网公司常用A/B测试似乎比较类似,老外似乎并没有所谓的灰度发布的概念。按照wikipedia中对A/B测试的定义,A/B测试又叫:A/B/N Testing、Multivariate Testing,因此本质上灰度测试可以算作A/B测试的一种特例。只不过为了术语上不至于等同搞混淆,谈谈自己理解的两者的差异。
灰度发布是对某一产品的发布逐步扩大使用群体范围,也叫灰度放量
A/B测试重点是在几种方案中选择最优方案
关于A/B测试可以参考这篇文章:A/B测试终极指南
6. 灰度发布引擎
对于一般的小系统并不需要单独的灰度发布引擎,可以参考A/B测试中做法,在页面JavaScript或服务器端实现分流的规则即可。但对于大型的互联网应用而言,单独的用于管理用户分流的发布引擎就很有必要了。“钱掌柜”分流发布模式 提到了原来阿里软件所使用的灰度发布引擎,设计思路具有普遍性,可以供参考
下面是一个灰度发布的架构示意图:
7. 灰度发布常见问题
7.1. 以偏概全
7.1.1. 问题特征:
a选择的样本不具有代表性;
b样本具有代表性,但选择样本用户使用习惯并没有涵盖所有核心功能
7.1.2. 解决方案:
样本选择要多样化,样本的组合涵盖大部分核心功能
7.2. 知识的诅咒
“知识的诅咒”的说法来自《粘住》中实验,具体可以自己搜索一下。我们自己对于自己开发的产品极为熟悉,于是乎想当然认为用户也应当能够理解产品的设计思路、产品的功能使用。
7.2.1. 问题特征:
a结果没有量化手段;
b只依赖于用户问卷调查;
c没有web analytics系统;
d运营数据不全面,只有核心业务指标(例如交易量),没有用户体验指标
e对结果分析,只选择对发布有利的信息,对其他视而不见
7.2.2. 解决方案:
a产品设计考虑产品量化指标
b结果分析依据量化指标而不是感觉
7.3. 发布没有回头路可走
7.3.1. 问题特征:
a新旧系统用户使用习惯差异太大,没有兼容原有功能
b新旧系统由于功能差异太大,无法并行运行,只能强制升级
c新系统只是实现了旧系统部分功能,用户要完整使用所有功能,要在 在新旧系统切换
7.3.2. 解决方案:
前期产品策划重点考虑这些问题,包括:回滚方案、 新旧系统兼容方案、用户体验的一致性、用户使用习惯的延续性、新旧系统数据模型兼容性
7.4. 用户参与度不够
7.4.1. 问题特征:
a指望用户自己去挖掘所有功能。对于一个产品,大部分用户经常只使用部分功能,用户大部分也很懒惰,不会主动去挖掘产品功能
b互动渠道单一
c陷入“知识的诅咒”,不尊重参与用户意见
7.4.2. 解决方案:
a善待吃螃蟹的样本用户,包括给予参与测试的用户小奖励(例如MS给参与Win7测试用户正版License)、给用户冠以title
b通过邮件、论坛、社区、Blog、Twitter等新媒体与用户形成互动
c提供产品功能向导。在hotmail最近的升级后的功能tip,gmail的tip都有类似的产品功能导向。在产品中会提示类似于:你知道吗,xx还提供xx功能,通过它你可以xx 。
8. 让产品具备灰度发布能力
8.1. 灰度机制的七个维度
8.1.1. 需求度
用户需求是产品核心,产品对需求的体现程度,就是企业被生态所需要的程度;
8.1.2. 速度
快速实现单点突破,角度、锐度尤其是速度,是产品在生态中存在发展的根本;
8.1.3. 灵活度
敏捷企业、快速迭代产品的关键是主动变化,主动变化比应变能力更重要;
8.1.4. 冗余度
容忍失败,允许适度浪费,鼓励内部竞争内部试错,不尝试失败就没有成功;
8.1.5. 开放协作度
最大程度地扩展协作,互联网很多恶性竞争都可以转向协作型创新;
8.1.6. 进化度
构建生物型组织,让企业组织本身在无控过程中拥有自进化、自组织能力;
8.1.7. 创新度
创新并非刻意为之,而是充满可能性、多样性的生物型组织的必然产物。
8.2. 灰度发布的策略要素
8.2.1. 易于发布到云平台
一般采用灰度发布都是具有自主产品的平台模式发布,而不是在客户服务器端进行发布,具备自主研发产品和有一定硬件部署能力的企业可以考虑灰度发布。
灰度发布一般是基于云的需要,如负载均衡,用户隔离等机制。如大型的电商网站等都是采用的分布式部署方式,利用负载均衡实现服务器分发,将用户访问分配到不同的地区服务器访问,确保用户访问效率,提升用户体验。
之所以强调易于发布,就是公司要具备自己可操作的服务器设备(云服务设备),这样可以实现在用户不知情的情况下实现灰度发布。即,在用户无感知的情况下实现最优配置的测试部署,提升产品质量,实现产品快速迭代——频繁发布,实现具有意义的‘实时发布’策略。
注:需要开通云服务模式(有一定硬件和经济实力的公司可以考虑)。
8.2.2. 设置用户标识策略
用于区分用户,辅助数据统计,保证灰度发布过程中用户体验的连贯性(避免用户在新旧版本中跳变,匿名Web应用比较容易有这个问题)。匿名Web应用可采用IP、Cookie等,需登录的应用可直接采用应用的帐号体系。
8.2.3. 目标用户选取策略
即选取哪些用户先行体验新版本,是强制升级还是让用户自主选择等。可考虑的因素很多,包括但不限于地理位置、用户终端特性(如分辨率、性能)、用户自身特点(性别、年龄、忠诚度等)。对于细微修改(如文案、少量控件位置调整)可直接强制升级,对于类似新浪微博改版这样的大型升级,应让用户自主选择,最好能够提供让用户自主回滚至旧版本的渠道。
对于客户端应用,可以考虑类似Chrome的多channel升级策略,让用户自主选择采用stable、beta、unstable channel的版本。在用户有明确预期的情况下自行承担试用风险。
8.2.4. 提供数据反馈入口
用户数据反馈:在得到用户允许的前提下,收集用户的使用新版本应用的情况。如客户端性能、客户端稳定性、使用次数、使用频率等。用于与旧版本进行对比,决策后续是继续扩大新版本投放范围还是回滚。
服务端数据反馈:新版本服务端性能、服务端稳定性等,作用与用户数据反馈类似。
8.2.5. 新版本回滚策略
当新版本灰度发布表现不佳时,应回滚至旧版本。对于纯粹的Web应用而言,回滚相对简单。主要难点在于用户数据的无缝切换。对于客户端应用,如果期待用户自行卸载新版本另行安装旧版本,成本和流失率都太高。可以考虑通过快速另行发布新版本,利用升级来“回滚”,覆盖上次灰度发布的修改。
对于移动客户端,新版本发布成本较高,需要Appstore、Market审核。本人没有移动客户端产品的经验,不太确定移动客户端产品如何处理灰度发布及回滚。但尽量将客户端打造成Web App,会更有利于升级和回滚。(不过苹果对纯Web App类的App有较强的限制,好像已经不允许在Appstore上发布这类应用了?)
8.2.6. 新版本公关运营支持
对于改版级别的大型升级,需要配合公关运营支持,用于及时处理用户在微博、博客等渠道给出的“显式反馈”。对比通过隐式数据反馈得到的结论后,综合考虑应对策略。
8.3. 灰度发布的方案
灰度发布一般有三种方式 nginx+lua,nginx根据cookie分流,nginx 根据权重来分配:
nginx+lua根据来访者ip地址区分,由于公司出口是一个ip地址,会出现访问网站要么都是老版,要么都是新版,采用这种方式并不适合nginx 根据权重来分配,实现很简单,也可以尝试nginx根据cookie分流,灰度发布基于用户才更合理。
Nginx+lua配置可以参考如下文章进行实践:
8.3.1. 方案一:代码逻辑控制
实现:
在代码中埋开关,做if-else判断,对于需要灰度的机器,设置开关为on,否则为off。每次版本发布都是有两个版本。
优点
· 快速回滚,不需要重新发布和重启系统。
缺点
· 对代码有倾入性。
· 分支逻辑,带来复杂性。
这种方式笔者曾经应用过,就是在阿里的时候把商品的数据库从Oracle切换到MySQL,使用了一个状态变量进行控制。从而打到平滑迁移的效果。
8.3.2. 方案二:Alibaba预发机制
其实这个不是真正意义上的灰度。因为这个预先发布机器是内部IP,没有对外服务的。需要绑定域名进行验证。但是数据是完全的线上。所以本质上是灰度 某些特定用户(可以访问灰度机器的用户,内部测试用户)的一种简单做法。其实API这边也有类似的做法,就是我们的Gamma环境,而且我们还提供了 Gamma机器的域名,方便外部合作用户配合测试。
优点
· 简单
缺点
· 浪费一台机器(这个可以预先发布完成之后投入正式环境,预发布的时候从nginx摘除,不过需要运维支持。)
· 不够灵活
· 只能针对接入层机器,IDL服务灰度需要另外考虑。
8.3.3. 方案三:SET部署
8.3.3.1. 按照业务隔离部署
比如现在API Container的做法,部署的粒度可以到API级别,前端根据nginx进行转发。比如:
· 微购物 API Container: api.weigou.qq.com
· 拍拍 API Container:api.paipai.com
· 易迅 API Container: api.yixun.com
· 网购 API Container:api.buy.qq.com
上面是大业务级别的隔离部署。还可以进一步细化到模块级别,比如虚拟服务电商的API,是挂在拍拍下面的一个子业务模块,但是由于他们接入微信之 后,访问量大增,为了避免影响拍拍其他业务,也为了避免受其他业务影响,API这里是给他们单独部署了两台机器,nginx配置一下就可以将针对虚拟的 API访问引流过来了:
虚拟API Container:http://api.paipai.com/v2/virbiz
这样,我们在发布一个版本的时候,可以先选择业务量最小的易迅进行发布,观察没有问题再全量其他平台。
8.3.3.2. 按照用户隔离部署
这个对于开放平台来说不是很适合,不过对于SNS这种应用场景就很合适了。比如QQ系统,按照用户号码段分为若干个set,每个set包含连续1亿 个号码的用户。假设现在最新的QQ号码接近10亿,则总共有10个set(Set 1到Set 10)。这样每次可以选择其中一个SET进行发布,而且高位QQ往往是不是很重要的用户,所以会先发布SET10。
优点
· 隔离部署,各个业务线影响最小。自动支持灰度发布。
缺点
· 灰度的粒度取决于隔离部署的粒度,一般会偏大。
· 相对于集中部署比较浪费机器。
· 各个业务线版本可能不一致,不利于统一管理。
· 有一定的实现和部署成本
8.3.4. 方案四:动态路由
采用一个可以灵活配置的灰度策略,影响Load Balance的行为,让其根据灰度策略,返回灰度服务的IP和端口。
适合与后台IDL的服务灰度。
优点
· 灵活,可控。
缺点
· 现在的配置中心和L5本身没有考虑指定路由策略,且不具有扩展性,需要在其外边开发。
· API的元数据来源比较分散,目前 API和IDL元数据,API等级和频率限制 分布在不同的数据源,现在需要增加一个 灰度路由 数据源。
9. 采用灰度发布的案例
9.1. 谷歌Gmail Labs
Gmail Labs是一个新特性橱窗,用户可以自己选择一些未正式发布的新特性进行体验,不喜欢可以关闭,在这个过程中,吃了螃蟹,也当了Google的小白鼠。
这个做法比传统的灰度要高明很多,更加尊重用户:
1、它没有强加用户,用户是否愿意当小白鼠完全自愿
2、新特性不是打包在一起的一个大版本,可以选择某几个喜欢的螃蟹尝尝
3、螃蟹不好吃可以扔掉,不用硬吃进肚子里引发肠胃炎
当然这些好处也是有代价的:
1、要开发一个labs平台实现新特性上架、独立尝试的功能,这可能要改动Gmail的前后台架构
2、新特性要按照一定规范来写,才能发布到这个平台上,可能会增加一些工作量
3、小白鼠用户增多之后,对系统的压力可能会有一定提升,因为每一位用户调用的界面都不一样了
既然Gmail Labs能够顺利发布,那么说明对Google来说,以上这些问题都不算问题。另外,现在展示的新特性,都注明了开发者的名字,那么,Gmail Labs可能会开放这个平台让外部开发者也能提交特性?这倒是很open的一种开发模式,非常适合Google的web app产品线。
9.2. 腾讯QZone
QZone是另外一个采用灰度发布的例子。大家都知道,QZone的改进是巨大的,从以前慢悠悠的老爷爷变成了一个充满青春活力的小伙子。其中经历了大小无数次的发布,他们的发布也都是采用了灰度发布的策略,用户数据的升级并不是大 面积的一次性升级,而是通过一个用户升级标志服务器,如果用户数据没有升级,后台会把此用户的数据逐步迁移到新版本上,然后将升级标志位置1,升级过程 中,用户仍然可以访问旧的数据,升级完成后的访问都将转发给新的版本。
QQ的很多产品发布都采用灰度发布,有些是抽取部分QQ号段升级成新系统,然后根据用户反馈再大范围升级。
9.3. 微信wechat
灰度、灰度、再灰度
在变更后的部署方式上,微信在一些规则会限定不能一次把所有的逻辑变更上去,每一次变更一小点观察到每一个环节没有问题的时候,才能布局到全网上去。微信后台每一天可以支撑超过20个后台变更,在业界来说,通常做到5个已经是比较快了,但是微信可以做到快4倍。
腾讯内部的上线系统
而所谓灰度发布,是指在黑与白之间,能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式,让一部用户继续用A,一部分用户开始用B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面 来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。(在腾讯,灰度发布是最常采用的发布方式之一)
孙子兵法:古之所谓善战者,胜于易胜者也
常识上,解决一个复杂问题的时候,会用高明的技巧解决复杂的问题,这个不是微信团队的目标,他们追求的要做到让所有问题很自然和简单的方式解决掉。在周颢看来,微信架构的技术复杂点在四个要点:协议、容灾、轻重、监控。
微信架构
· 协议。手机终端跟后台服务器之间的交互协议,这个协议的设计是整个系统的骨架,在这一点做好设计可以使得系统的复杂度大大降低。
· 容灾。当系统出现了若干服务器或若干支架(宕机的时候),仍然需要让系统尽可能的提供正常的服务。
· 轻重。如何在系统架构中分布功能,在哪一个点实现哪一个功能,代表系统中间的功能配置。
· 监控。为系统提供一个智能仪表盘。
在协议设计上,移动互联网和常规互联网有很大的区别。首先有CMWAP和CMNET的不同,在中国现在有相当多的手机用户使用WMWAP连接,还有 就是在线和离线的概念,当QQ下线的时候叫离线,当你登录的时候叫在线。但是在移动互联网这两个概念比较模糊。从微信的设计中,不管在线还是离线系统表现 都应该是一致的。还有一个是连接不稳定的问题,由于手机信号强弱的变化,当时信号很好,5秒钟走到信号不好的地区,连接就必须断掉。这个中间带来不稳定的 因素为协议设计带来较大困难。此外就是资费敏感的问题,因为移动互联网是按照流量计费的,这个计费会使得在协议设计中如何最小化传输的问题。最后就是高延 迟的问题。
对此,业界标准的解决方案:Messaging And Presence Protocol:1)XMPP;2)SIP/SIMPLE。它的优点是简单,大量开源实现。而缺点同样明显:1)流量大:状态初始化;2)消息不可靠。
微信在系统中做了特殊设计,叫SYNC协议,是参考Activesyec来实现的。特点首先是基于状态同步的协 议,假定说收发消息本身是状态同步的过程,假定终端和服务器状态已经被迟了,在服务器端收到最新的消息,当客户端、终端向服务器对接的时候,收取消息的过 程实际上可以简单的归纳为状态同步的过程,收消息以及收取你好友状态更新都是相同的。在这样的模式之下,我们会也许会把交互的模式统一化,只需要推送一个 消息到达的通知就可以了,终端收到这个通知就来做消息的同步。在这样的简化模式之下,安卓和塞班都可以得到统一。这样的系统本身的实现是更为复杂的,但是 获得很多额外的好处。
让剩下系统实现的部分更加简单,简化了交互模式,状态同步可以通过状态同步的差值获得最小的数据变更,通过增量的传输得到最小的数据传输量。通过这 样的协议设计,微信可以确保消息是稳定到达的,而且是按序到达。引用一句俗话:比它炫的没它简单,比它简单的没它快,没谁比他更快,哪怕在GPRS下,微 信也能把进度条轻易推到底。
9.4. Ucloud高可用架构实践
DevOps成都站|架构与运维峰会活动总结地址:
此处主要截取账户计费系统架构演进过程的六个阶段进行整理。
服务架构的演进过程
UCloud服务架构的演进主要经历了以下六个阶段:
a.单体模式;
b.具有灰度发布能力;
c.前后端分离;
d.服务化改造;
e.按SET部署;
f.分机房按SET部署,按SET进行跨机房热备容灾。
1. 单体模式架构上线业务系统
UCloud服务初期上线时的架构主要分三部分:
·
PHP Web Conosle,负责所有前端展现交互、后台服务间逻辑组装;
·
·
平台类服务,账户、计费、监控、名字服务等公共服务;
·
·
各业务系统分数据中心后台服务的接入层。
·
PHP Web Console、业务系统分数据中心的服务、平台类服务组合上线,Web Console 通过Protobuf与所有后端服务进行通信。
2. 具备灰度发布能力
要解决前面面临的问题,我们首先需要支持Web层灰度发布包含以下的灰度方式:
·
无用户态特性按照 单IP -> IP段(地区) -> 到IP取模逐步灰度控制影响范围;
·
·
有用户态特性按照 单内部用户(开发账号) -> 内部测试账号 -> 用户分级逐步灰度发布控制影响范围。
·
3. 前后端分离
·
开发API Gateway 层用来管理后端 API 注册和管理、权限验证管理、流量控制;
·
·
开发API层,解决前台交互层,需要整合跨系统逻辑调用问题,前端只专注产品交互和用户体验;
·
·
开发统一的单点登陆Token,系统方便前端实现跨域API调用让前端代码可以完全静态化。
·
在此阶段,完成前端展现可以独立控制发布,彻底实现了前后端解耦,API协议保证向前兼容,Web端可以随意重构交互优化前端架构,实现了跨域独立部署,独立的灰度策略互相之间不受影响,极大的提高了前端团队开发效率和稳定性。
4. 服务化改造
对业务端API开发效率优化:
·
按照业务模块化,所有业务API由后台产品研发部门独立部署发布上线;
·
·
抽象通用平台类特性例如:子账号特性,权限体系,计费等特性抽象公共能力让业务端在API中组装。
·
总体目标:让业务API开发效率提升并单独部署维护,提高产品特性的研发迭代效率并提高稳定性。
5. 按SET部署
基础架构优化完毕,各个业务系统单独部署发布,开始对系统进行容量和容灾方面的考虑,从部分平台类系统开始考虑按SET部署架构测底解决容量和容灾问题,每个SET只服务一部分用户,保证遇到物理服务器宕机等故障情况下只影响部分用户或业务。
例如图上所示, SET 1 服务1 ~ 服务50000000 用户,SET 2 服务50000001 ~ 100000000 的用户,一个SET 出现问题只影响一个部分用户,不同的业务根据自身情况进行SET切分,规模大小也视情况而定,按SET部署后合理的划分方式下不同SET之间数据还可以互相迁移,来平衡搞负载或高容量的SET,极大的提高了可运维性。
6. 分机房部署SET
按SET部署架构改造完毕后还没有达到最理想的状态,如果所有服务部署在单机房还是可能会出现问题,机房整体出现断电、断网等故障还是会出现大面积影响。
·
对SET架构进行分机房部署,让不同的用户运行在不同的机房中,这依赖一些基础设施比如跨机房光线专线。
·
·
跨地域SET在相邻节点部署热备,以便出现机房故障时能具备异地快速恢复服务的能力。
·
总体介绍了UCloud在不同的阶段架构演进的一些过程和经验,架构没有最好的,只有最合适当前业务发展的架构。
10. 参考资料