关于灰度发布的感想

最近在研究springcloud，其中重要的就是服务的治理，各种接口与应用漫天飞，开发人员与运维实施人员不断的扯皮。曾几何时内部开发的RPC远程访问接口，在实施部署过程中费时劳力。

微服务接口的版本控制，代码的版本管理，最后到运维实施部署阶段就是灰度发布的管理，应该都是软件工程不同阶段的管理范畴。

• 选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等
• 筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等
• 部署系统：部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调
• 发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表

灰度发布按端分类

1. web页面灰度：按照IP或者用户ID切流啊。具有随机性，可以控制比例
2. 服务端灰度：考验主系分能力了，可以做逻辑切换开关，按照义务相关属性逐渐切流
3. 客户端灰度：一般按照用户逐渐推送包，主要是PC端(WIN，MAC)、移动端（安卓，OS）内部大规模内测

4. 数据库的灰度升级：首先数据全量复制，双写，最后去掉老数据库

发布策略

• 单策略：基于IP地址、用户ID、版本tag，用户自主升级。
• 基于上下文灰度发布策略：不限于地理位置、用户终端特性（如分辨率、性能）、用户自身特点（性别、年龄、忠诚度等）

新版本回滚策略

• 当新版本灰度发布表现不佳时，应回滚至旧版本。对于纯粹的Web应用而言，回滚相对简单。主要难点在于用户数据的无缝切换。对于客户端应用，如果期待用户自行卸载新版本另行安装旧版本，成本和流失率都太高。可以考虑通过快速另行发布新版本，利用升级来“回滚”，覆盖上次灰度发布的修改。
• 对于移动客户端，iOS TestFlight 实现灰度发布，安卓APP直接发布新版本覆盖有问题版本。

灰度发布工具

1. Nginx灰度发布： Nginx+LUA方式、根据Cookie实现灰度发布、根据来路IP实现灰度发布

2. 使用optimizely做A/B测试

 

 

 

 

参考：

https://www.jianshu.com/p/93a542855251

https://www.cnblogs.com/todsong/p/3918406.html