灰度的分类
物理灰度
新旧功能的代码，物理隔离成两套代码。
对于后端，可以通过不同集群、不同接口实现；
对于前端，可以通过不同页面路由等方式实现。
逻辑灰度
新旧功能的代码，还在同一套代码，通过if else实现逻辑上的灰度
物理灰度与逻辑灰度的选择建议
- 如果灰度时间预计会很长，建议选择逻辑灰度，否则灰度期间，迭代内容需要在2套代码上进行重复开发
- 如果代码改动的地方比较多，建议使用物理灰度，否则需要在很多地方加
if else，影响代码质量，并且后期灰度清理（删除灰度判断代码和旧逻辑）工作量比较大
灰度的实现
场景1 前端根据用户是否在灰度内，展示不同样式
后端提供一个灰度判断接口boolean is-gray()
场景2 后端使用不同集群实现灰度
第一次访问页面，前后端交互时序
第二次访问页面
灰度的维度
常见的灰度维度有单据、日期、品类、地区、人、机器等等，视实际项目情况决定。
-
按单据维度灰度，可以按照单据的数字规律进行灰度，比如：
第1次灰度范围: 单据尾号为1
第2次灰度范围: 单据尾号为1、2
第3次灰度范围: 单据尾号为1、2、3 ...
逐步放量，最终达到100%灰度。
除了尾号，还可以按取余结果、单复数等等
-
按日期维度灰度，比如：
第1次灰度范围: 上线当天之后新增单据
第2次灰度范围: 上线前1个月之后新增单据
第2次灰度范围: 上线前3个月之后新增单据 ...
最后一次灰度范围: 全量单据
-
涉及前端样式改造时，如果按照单据、日期、品类等维度灰度，如果同一个用户看到的不同单子样式不同，会造成用户体验不一致
-
涉及前端样式改造时，如果要对列表页灰度，除非能保证同一列表页上的元素，都在灰度内或者灰度外，否则就只能按人灰度，否则同一列表页，无法展示不同样式
-
需要考虑灰度规则是否有数据倾斜问题，可能理论上是均匀灰度，实际上数据倾斜严重。 比如按单据尾号维度，尾号为1放入第1次灰度，理论上占10%，实际上数据库统计结果可能占40%
-
按机器维度灰度，可以先把新代码发布到1台小流量机器（占10%入流量），停留观察一段时间，再逐步发布其他机器
-
假设是对某个旧功能进行升级，按人的维度灰度时，可以先捞出一些使用这个旧功能概率比较大的人群进行灰度，避免灰度期间，没有流量进入改造过的代码
-
假如数据模型发生了变更，那么灰度期间，新旧数据模型共存，除了对数据读写功能进行灰度判断，每次放量前，还需要进行刷数，把旧数据模型升级成新数据模型
-
接口转发场景（http接口协议不变，旧接口转发到新接口实现旧接口下线），通过网关配置接口转发，可以利用网关的灰度能力逐渐放量，比如一灰10%的流量转发到新接口，二灰30%流量转发到新接口...直到100%放量
