浅谈系统架构中的状态

背景

最近在规划一个系统的无感升级，发现了之前设计中很多的不合理的地方，

其中最为代表性的就是各种有意无意的状态，所以在这里整理一下最近的一些思考还有收获，

如果能帮到其他人就太好了。

什么是状态?

对于软件领域中系统状态是什么有没有严格的定义，我这边并没有进行彻底的调研。但本文所说的状态特指对外部有影响的状态。

比如：

• 系统在内存中保存了目前系统时间，但这个只用来打印日志，那么我们可以说这个服务是无状态的。

• 但如果这个时间在本系统中进行业务有没完成的依据，那么我们就可以说这个服务是有状态的。

当然计算是第二种情况，也可以通过专门的授时服务器来讲这个时间状态消除。

为什么有状态不好？

理论上，有状态的服务

1. 无法轻易的水平扩展
2. 无法轻易实现故障恢复

具体来说：

• 当一个服务有了状态后，你不能简单的启动多个服务，实现性能的提升，因为这样的多个服务会导致系统内存在多个不一致的状态，从而导致系统业务逻辑的混乱。

• 由于存储的中间件状态在故障发生时丢失，修复或在其他节点重启后无法在中断时继续服务

服务状态的常见表现形式

内部保存了业务的进度或相似信息

比如：

• 内部开启了一个线程进行多步业务流程
• 保存了业务的调度信息，保存了访问者的信息，根据这些信息进行判断输出

内部驱动的定时修改外部数据或外部接口

比如：

• 定时1点备份数据库

• 每隔10s更新一次数据库中的信息

内部驱动的定时调用外部非幂等接口

• 每隔10s计算一次最新价格，发布消息

• 比如早上5点发送打开某个设备的闸门的指令

对外接口包含与内部强相关的信息

比如：

• 用本机的公钥-私钥进行加解密
• 返回下次请求中需要访问的地址
• 返回的结果或进行的动作跟内部的某个变量的状态有关

如何应对系统中的状态

包容

这个方向最为简单，什么都不做，其实这个是大多数场景的最佳方案，虽然从技术上来讲状态是尽量避免，但有的时候无状态话的设计成本是有状态的N倍，且无状态为该系统带来的价值无法支撑起该设计，这时候包容或是容忍系统状态化是最佳方案。

去状态

想要去除系统内的状态实在不是一件轻松的事，大体的思路都是外部化。即通过外部方式记录中间的状态，好让系统不必保存这些状态。

典型的方式：

• 使用redis保存原来在内存中数据
• 使用数据库来保存原来的中间业务状态
• 使用xxl-job来替换原来在Quartz的调度或定时框架
• 使用消息中间件来实现流程在系统中流转

选主

如果一个系统中的状态确实去不掉，就需要采用退一步的思路，这个可以参考经典的数据集群方案，一般都离不开多实例选主。

典型方式：

• 通过Raft协议来实现动态选主的复杂方案
• 通过zk的curator实现选主的简单方案

总结

本文探讨了系统的状态，还列出了常见的系统状态的形式，最后给出了一些改造思路或建议。

系统架构都是有生命的，需要随着业务的发展进行演进，有时间的话看看你的系统架构有没有坏味道吧。