这几天在考虑某客户端程序支持灰度升级的事。最开始其实有一股冲动想要实现出来早点发挥作用,但经过梳理后,逐步意识到其可能带来的实际效果并不如最初设想的那么大,同时还会带来一些新的问题要去面对和解决。
比如,实施人员的操作负担会增加——执行灰度升级需要更精细的操作,不仅步骤增多,还需要去了解和规划升级策略。然后管理难度也会增加——灰度升级过程中,会存在不同版本客户端共存的情况,增加了环境的复杂度。而这些问题,恰恰是我们现有升级模式的优势所在——对实施够简单。
回到最初为什么想要来支持灰度升级呢?其实初衷是想实现AIO的平滑升级,降低升级问题对用户造成的使用影响。但是,想要达到或接近这个目标并非只有灰度升级一条路。并且走这条路也未必就能达到好的预期效果。
回顾目前程序升级面临的主要风险,主要集中在运行环境上。而这类问题属于“一次性”的,一旦在当前环境上解决过就不再会发生。针对这类问题,我们其实可以采取更加直接和有效的解决方案。虽然灰度升级也是解决办法,并且看似能“一劳永逸”,但似乎并不划算(有点把“小菜盘成肉价钱”的意思)。但这个思路后续应该还是可以适时实践的。
整理下这个事情,有两个要点可以记录:
1、完美方案并不存在。正如涛哥例会上常提到的,事物都有其两面性,我们往往要在利弊之间做出权衡和选择。
2、做事情别忘记初衷,不是盲目追求某种方案。我们不是要去做“灰度升级”本身,而是要解决我们所面临的问题。并且灰度升级也只是解决问题的一个可能选择而已。
备注:这里说的“灰度升级”是指只对特定范围的客户端进行升级试运行,在功能稳定后再逐步扩大升级范围。属于实现产品的平滑发布的一种方式,可以降低升级风险并保证整体系统的稳定运行。