从程序员的角度看灰度发布，是不是真的很难实现和落地？

场景: 我理解灰度发布都是按百分比不断的升级！当升级到百分之 90 后，客服收到大量用户说新功能存在问题，第一时间应该是回滚！

Q1：那么就存在一个数据回滚问题，从数据库，再到 redis 缓存，再到消息中间件 Mq，再扯到大数据 Kafka，这一些列的回滚后的脏数据怎么解决？

想到解决思路：所有的中间件和存储都存 2 遍，首先复制所有的表和 redis 缓存和 Mq 队列，存一个 next_version 后缀存一个现在的表数据，当发布到 100%后把原来的数据所有都改成 pre_version 后缀，所有的中间和数据 next_version 后缀删除，这样就能顺利的解决回滚问题。

这样就衍生出一个新问题：业务同学一定不能在业务层写这样兼容的代码，那只能是技术支持团队解决，那么怎么保证业务同学写 2 遍数据，能顺利写入？

比如: 用户表新增了一个字段，新增了一个用户联系人表和联系人和用户的关联表

Q1-1 那么在新功能上线时，业务代码如何做到一次数据插入能兼容上一次版本和新版本？

我想到解决方法，自研中间件拦截层，并在业务代码少许的版本代码，比如在新增值字段要表注解 @newField，新增的表要注解 @newTable

从上面来看灰度发布自研的成本相对来说非常高。

望大佬能说一下自己的解决方法把！谢谢了

LxExExl

2021-07-31 11:39:12 +08:00

当升级到百分之 90 后，客服收到大量用户说新功能存在问题，第一时间应该是回滚！

这里假设有问题。
我一般先内测（员工+QA ），然后 5%开一段时间，看 metrics，收 feedback 。没问题才会继续 30%，50%，95%（留 5%作为对照组，岁末的时候来衡量团队一个 half 总体提升了多少）

哪能一下开 90 然后大量用户说存在问题啊。

另一个是开发之前就要想清楚，设计好，技术上和功能上都要考虑是否向前兼容。

pigbug

2021-07-31 11:45:02 +08:00

@LxExExl 我的意思是慢慢按百分比滚动升级，但是用户回馈可能没有那么及时，比如一部分用户没有用这个新新功能，一部分用户发现 bug 但是不知道怎么反馈，但是滚动升级到百分之 90 后部分用户反馈有存在 bug 。客服接受反馈到 QA，QA 测试的确存在问题，反馈到开发团队和运维团队。这个时候回滚。

lidlesseye11

2021-07-31 12:07:59 +08:00

首先，有灰度不代表所有上线功能都灰度。
其次，灰度的比较对象是没有灰度，而不是完美的灰度。现实中都是抉择和取舍，具体问题具体分析，没有说绝对的。
而且你说的数据问题，这不管有没有灰度都要解决的吧？
切换的时候就是读旧 db，双写新旧 db -> 旧 db 数据迁移到新 db ->读新 db 废除旧 db
双写一般会有自研中间件处理。然后上线前都会写好万一要回滚时的清理脏数据脚本。

mreasonyang

2021-07-31 13:59:03 +08:00

看重灰度准效率的业务一般都很难在数据层面通过两套逻辑的异步同步来实现灰度的，搞不好就会由于一致性问题导致真正的大事故。如果能做到蓝绿发布，并且底层数据实现了单元化存储，那应该还是能解决一部分问题的。

百分比灰度是很基础的思路，但楼主说的小比例时反馈滞后直到大比例才收到反馈这种情况在中小流量的业务中确实很容易遇到。

我理解这个问题难以彻底解决，但可以通过类似 AB 测试的方式圈定人群逐步放量，从而实现更精细的灰度控制。

例如对于面向 C 端的业务，在上线时以相关的研发和测试为基础灰度点，逐步向外扩大，从而做到影响范围尽量小且反馈效率更高。