“混合云管理平台”系列文章又上新啦!!上篇文章《资源管理篇》,介绍了资源管理部分,本篇《应用云化篇》将继续讨论如何对应用进行云化改造以及如何对在云平台中对应用进行部署与管理?
有状态应用与无状态应用
在云平台中如果应用所在的虚拟机出现故障或流量突然增加时,平台能够自动对应用进行迁移或水平扩展,保证应用的可用性,如果应用本身是无状态的,只要通过管理器将可用应用注册到网关,网关根据服务状态进行流量分流即可。
但如果应用是有状态的,迁移将会导致用户访问状态丢失,用户数据丢失等问题。因为服务状态可能保存在内存或者硬盘上,当进行自动迁移时,这些状态数据可能无法及时进行迁移,造成用户使用问题。那么对于有状态应用是否可以支持故障迁移和水平扩展呢?
有状态应用转无状态应用
如果能够将有状态应用转化为无状态应用,就可以解决应用迁移时的状态丢失问题。将有状态应用改造为无状态应用,可以采用将应用状态转移到其他专门负责状态的应用中。通过缓存、持久化存储、文件存储将应用中的状态抽离出来,使应用间能够共享。例如在用户登录这个业务点中:用户登录失败次数,将被存储在缓存中;而用户锁定状态会被存储在持久化存储中,用户头像信息会被存储在共享存储中。这样用户从任意一个应用进行登录,应用都可以取得正确的状态。目前大部分应用也都是采用这种方式。
有状态应用的云化实现
对于普通应用可以将状态转移到有状态应用中,但对于本身负责状态存储的应用,则不能再向外转移了,必须实现自身的有状态高可用。无状态应用必须与有状态应用进行绑定使用,使应用架构变得沉重,且可用性有所下降。例如应用使用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的具体细节进行讨论,有兴趣的同学,可以自行查阅相关资料。
应用云化总结
应用上云实际上就是增强应用状态一致性的过程,无论是将状态外置,还是通过协议自同步状态,只要能够保证集群的状态一致性,就可以在云上进行水平迁移和扩张。也就可以作为云组件嵌入到云平台中,实现应用的自动化管理。
本文转载自:[微信公众号]TC星球
作者:范明明
原文链接:https://mp.weixin.qq.com/s/R7bW0IFZZtXPEyBPUVYNJA
推荐阅读