不断服升级的基本思路

一般来说，WEB应用升级的基本要求是不中断服务，或者中断服务的时长尽量缩短。应用升级重点是数据的处理，本文总结不停服升级的基本思路

数据不需要迁移的场景

应用节点本身的升级是很容易的，不需要多说。通常只需要避开业务高峰时段，将集群中的节点分批次升级就可以了。

当然前提是应用节点必须是无状态（stateless）的，不过现在基本上微服务都是这样的，所以也不需要特别强调。

升级过程中，正在升级的节点，外部的流量会被切断，所以没有影响。另外可能会有定时任务调度，消息处理，或者批处理执行等。前面两者也可以看做是流量，只是来自于中间件，而非WEB请求。也是需要断流的，通常中间件会自动处理流量切换。比如当节点下线，定时任务就不会调度到该节点，消息也会被集群中的其他节点处理。批处理执行，一般只要避开时段就可以了，或者涉及到优雅停机的问题，这是另外一个话题，本文不展开。

而数据库是比较麻烦的，所以要求db的升级，需要以兼容的方式设计。比如允许新增表、新增字段，不允许删除表、删除字段、变更字段类型等

要数据迁移的情况

如果升级涉及到数据结构的变更，那情况就会比较复杂。为了达到不停服，至少减少停服时间的目的，需要用到数据增量同步的能力。整体的流程如下图：

方案的核心关键是需要具备增量数据同步的能力，即老集群是不断服的，因此新的业务数据在持续写入老的db，同时又不能允许太长的断服时间，所以就需要有增量数据同步的能力，持续把老db中的数据，迁移到新db中。这个过程是持续的迭代过程，第一次会执行的时间很长，把老db中的数据都搬到新db；而在这个过程中，新的业务数据又产生了，于是又要追平这部分新数据；接下来追平更少的新数据……重复这一过程，直到新老db的数据一致，增量迁移的动作才算完成

通常会借助binlog的能力来实现增量同步的方案，阿里的”精卫”已经提供了基础能力，业务只需要提供迁移的逻辑就可以了。

另外，同样会涉及到切流时的小问题。同样也把来自中间件的流量，先停掉，然后整体切换到新集群上即可。跟上一个场景是类似的。

增量数据迁移的一个主要的好处是，由于一直没有断服，所以可以允许反复的试错，容错率很高。如果在迁移过程中发生任何异常，只需要把新集群的db数据清掉，修复BUG后再来一次就可以了。此过程可无限循环，用户无感知。

全量迁移的情况

在特殊场景下，用户对于断服时长没有严格的限制，而开发增量数据迁移的难度又太大，此时也可以考虑先停服，然后全量数据迁移，再切流量。这个方案整体的难度要小很多，但是代价是断服时间会相当的长。

总结要点

应用节点本身，需要保证是无状态的。

切流的时候，要注意不仅是来自web的流量，来自中间件的流量也要全面考虑。比如RPC、消息、任务调度等，相关的流量都要考虑进来。

要考虑应用节点的优雅停机方案，本机的任务要确保处理完成。

为了实现不断服，关键是需要具备增量数据迁移的能力。

如果允许断服，则可以考虑全量数据迁移的方案，实现难度和工作量会小很多。