这是一个创建于 2332 天前的主题，其中的信息可能已经有所发展或是发生改变。
作为一名前端，受累于每次月版升级熬夜之苦，想了解一下灰度发布的前后逻辑，前端目前确定通过基于 cookie 的 nginx 转发能够实现基于账号的灰度，但涉及到后端的灰度，感觉最大的问题就是数据一致性的问题。
后端目前使用统一的业务数据库，因为业务复杂的原因字段繁多，如果后端采用灰度发布，那么对应的后端服务应该单独部署一套灰度机器，但是数据存取还是业务数据库中进行，这里就得考虑到如果新功能新增或删减字段，修改业务字段等情况的问题，如果灰度顺利不需要回滚，那么对数据库影响不大，如果灰度失败需要线上回滚，那么被修改过后的数据库要如何处理呢？必须要通过数据库脚本进行过滤清洗然后重新写入才行吗？
 |
1
whileFalse 2018-08-05 10:32:29 +08:00
只有新增字段没有删。
你不灰度发布，把 db 搞乱也得洗啊。 |
 |
2
fe619742721 OP @whileFalse 我们现在上线都是凌晨上线测试做全量回归，如果出现了问题会直接回滚，这样的话，用户的业务数据不会受到影响，但是如果灰度的话，必然会有部分用户使用灰度版本产生业务数据差异，所以从目前灰度的方案来看，使用统一数据库的前提下似乎也没有好的处理办法了是吗？只能从功能代码，数据库字段设计上考虑，避免灰度失败带来的数据差异影响了
|
|
3
whileFalse 2018-08-05 15:45:33 +08:00
@fe619742721 你们代码正式上线之前测几轮？
先在 dev、qa 测过之后，上了正式先给内部账户灰度用，内部账户数据脏了也没问题，而且过了两道之后出问题概率也很小。 不过还是要看业务形态，你们什么业务？ |
|
4
fe619742721 OP @whileFalse 开发自测，提测后测试全量，大概就这两轮吧，主要是做 toB 的企业服务，客户量大线上不敢出问题，真要推进做灰度的话紧急措施预案还是得有，之前就有提过要做灰度减少升级成本，也是因为数据问题搁置了
|
Select Language