因素6，进程，讨论支持云原生应用的无状态特点
应用程序应作为单个无状态进程执行。正如本书前面提到的，我对管理和辅助进程的使用有很强的看法，现代的云原生应用程序应该由一个单一的无状态进程组成
这与原始的12个因素稍有矛盾，后者的要求更为宽松，允许应用程序由多个进程组成
我经常提出的一个问题是无状态的概念是什么？人们想知道如何构建一个没有任何状态的进程，毕竟，每个应用程序都需要某种状态，对吗？即使是最简单的应用程序也会留下一些浮动的数据，所以您怎么可能有一个真正的无状态进程呢？
无状态应用程序在处理请求之前不假设内存内容，也不在处理请求之后假设内存内容。应用程序可以在处理请求或处理事务的过程中创建和使用瞬态，但在客户机收到响应时，这些数据应该已经全部消失
简单地说，所有持久状态都必须在应用程序外部，由后端服务提供。因此，无状态不是说不存在状态，而是说状态不能在应用程序中维护
例如，一个提供用户管理功能的微服务是无状态的，因此所有用户的列表都在后端服务（例如Oracle或MongoDB数据库）中维护。显然，让数据库无状态的是没有意义的
进程通常通过共享公共资源来相互通信。即使不考虑向云端迁移，采用无共享模式也会带来很多好处
首先，进程之间共享的任何东西都是一种责任，这使得所有这些进程都变得更加脆弱。在许多高可用性模式中，进程将通过各种技术共享数据，以选举集群领导者，决定进程是主进程还是备份进程，等等
如果你的程序跑在云上面，你要规避上面这些做法。你的进程可以在没有任何警告的情况下在一瞬间消失，这是一件好事。进程来来去去，水平和垂直扩展，而且是高度可处置性的。这意味着进程之间共享的任何内容也可能消失，从而可能导致连锁失败
文件系统准确的说并不是一个后端服务，这意味着你不能通过文件来共享程序间的数据，云上面的磁盘是瞬时的，并且在某些场景下是只读的
如果进程间需要共享数据，比如web集群间的session状态，那么session状态应该外部化，同时通过一个后端服务存储和读取状态
一种常见的模式，尤其是在长时间运行、基于容器的web应用程序会在进程启动期间缓存频繁使用的数据，这一点本书已经提到，进程需要快速启动和停止，而花很长时间来预热内存缓存违反了这一原则
更糟糕的是，将应用程序必须用到的的数据缓存在内存可能会使应用程序膨胀，使每个实例（应具有弹性伸缩性）占用的RAM远远超过所需要的
有几十种第三方缓存产品，包括Gem‐fire和Redis，它们都被设计为应用程序的后端服务用来缓存状态数据。它们可以用于缓存会话状态，但也可以用于缓存进程在启动过程中可能需要的数据，并避免进程之间紧密耦合的数据共享