如何对应用进行云化改造？你学会了吗

在云平台中如果应用所在的虚拟机出现故障或流量突然增加时，平台能够自动对应用进行迁移或水平扩展，保证应用的可用性，如果应用本身是无状态的，只要通过管理器将可用应用注册到网关，网关根据服务状态进行流量分流即可。

但如果应用是有状态的，迁移将会导致用户访问状态丢失，用户数据丢失等问题。因为服务状态可能保存在内存或者硬盘上，当进行自动迁移时，这些状态数据可能无法及时进行迁移，造成用户使用问题。那么对于有状态应用是否可以支持故障迁移和水平扩展呢？

如果能够将有状态应用转化为无状态应用，就可以解决应用迁移时的状态丢失问题。将有状态应用改造为无状态应用，可以采用将应用状态转移到其他专门负责状态的应用中。通过缓存、持久化存储、文件存储将应用中的状态抽离出来，使应用间能够共享。例如在用户登录这个业务点中：用户登录失败次数，将被存储在缓存中；而用户锁定状态会被存储在持久化存储中，用户头像信息会被存储在共享存储中。这样用户从任意一个应用进行登录，应用都可以取得正确的状态。目前大部分应用也都是采用这种方式。

对于普通应用可以将状态转移到有状态应用中，但对于本身负责状态存储的应用，则不能再向外转移了,必须实现自身的有状态高可用。无状态应用必须与有状态应用进行绑定使用，使应用架构变得沉重，且可用性有所下降。例如应用使用kafka消息队列时，kafka的状态是存放在zookeeper中，所以引入kafka则必须引入zookeeper。站在高可用性的角度，Kafka集群的可用性不仅取决于自身，还受到了外部组件的制约，从长久来看，显然都不是一个优雅的方案。如果zookeeper不能正确进行相应，即使kafka节点存活但依旧可能出现整个消息集群不可用的情况。

那么应用是否可以仅依靠自身节点，而不引入第三方状态管理呢？答案是肯定的，Kafka在2.8版本中正式废弃了Zookeeper，拥抱Raft。这是一种去中心化的架构，不依赖外部的组件，而是做为一个协议簇嵌入到kafka应用中的，即与应用自己是融合为一体的。改造后消息集群部署更简单，可靠性更好，并且也更容易扩展。

除Kfaka以外，MySQL 5.7.17版本引入MySQL Group Replication(MGR)服务器插件，可用于创建高可用、可扩展、容错的复制拓扑结构。MGR可创建完全对等的多主服务器，较主备方案的可用性有较大的提升。当用户在任意节点提交数据时，该数据会提交到所有mysql服务器，在半数以上服务器成功响应时，该事物提交成功。由于集群中存在多数据副本，之前主备方案丢失数据的情况，能够得以避免。

对于一些只具有简单状态的应用，也可以参考kafka和mysql的方式自行实现raft协议，保存和同步自身状态，减少外部依赖。当然raft协议也存在一定的限制，例如同步的数据不宜过大，状态变化时，执行时间不宜过长。本文不对raft的具体细节进行讨论，有兴趣的同学，可以自行查阅相关资料。

应用上云实际上就是增强应用状态一致性的过程，无论是将状态外置，还是通过协议自同步状态，只要能够保证集群的状态一致性，就可以在云上进行水平迁移和扩张。也就可以作为云组件嵌入到云平台中，实现应用的自动化管理。