企业上云，如何确保应用是否无状态？

在devops的八荣八耻中就提到，应用以无状态为荣，以有状态为耻。应用的状态是阻止应用弹性伸缩以及用户端高可用体验的拦路虎，这里所说的状态信息，更多的是指原先记录在会话session中的信息和定时任务执行的状态信息。如果要做无状态的改造，有两种思路，一种是通过在业务逻辑上的优化，真正的去掉原来记录在session的中的信息，这种方式改造的很完全，但是难度大，并且适用范围比较小；另外一种方式就是将原来由各个业务节点保存的session信息，集中地保存在session服务上，这样就变相的去掉了业务的状态信息，请求到达的时候，就可以从session服务中获取session信息，实现了业务逻辑与session保存的解耦，从而可以使业务模块能够快速的弹性扩容和缩容。同时session服务一般都是分布式部署，自身提供了良好的高可用机制以及分布式部署特性，在多机房或者多云环境下可以部署在多机房或者多云，从而保证session数据的安全可靠。同时认证模块如果使用token的方式，那么可以将用户的session id放在token里面，从而解决认证和session id安全两方面的问题。

容器应用的一个前提条件就是无状态应用，但是对于这个问题我觉得可以从两个层面去理解：

1. 是不是一定要把所有的应用状态进行改造。我觉得大可不必，我们不是为了容器而容器，容器解决的是互联网应用的弹性伸缩和高频度发版。对于传统应用，其用户群体和应用本身的特点不一定适合容器，容器也不一定能给这些应用带来多么大的收益。例如银行的核心、信贷、柜面等系统。
2. 对于状态的改造，我觉得大的改造方向可以从状态缓存改造思路入手，将所有应用的状态以一种可以保持的数据格式保存在缓存服务器集群上。目前可以实现类似功能的中间件及开源方案有一些，但是都需要根据自己的业务需求进行分析挖掘和改造。

分两个层面，应用入IAAS，不强制要求应用无状态，有状态的应用也可以入云，但不能享受到弹性伸缩的便利性。数据库节点是有状态的，也是可以入云的。应用入PaaS，天生是要求弹性伸缩的，则必须要无状态。
应用无状态化，我觉得主要要考虑三个方面：
1、配置。如应用节点要访问数据库节点，一般要将数据库的地址或域名存在本地配置中。无状态化就需要将类似这样的本地配置集中存放到配置中心之类的地方。
2、Session。用户的会话信息一般要集中存放到缓存服务中。
3、日志。系统日志或应用日志生成后要自动保存到日志中心或日志服务器上。