Stateless，stateful实现

最近比较关心如何构造所谓有状态的容器应用。我们提到有状态，无状态，其实纠缠不清，因为它隐含了两层含义。一层是逻辑需求，一层是实现。
逻辑需求层面，也许我们应该避免overload这个有状态，无状态的术语，改为session间有没有依赖性。对有依赖性的应用，有时也有人称为stateful application/stateful workloads. 在本文中我们避免这个称谓。

stateful和stateless，如今在业界更多的用于描述实现.

有状态无状态的实现，这里指的是跨session（aka 请求）之间，在service里面（aka 在server上）有没有保持跨session的内容。无状态，在service里面没有需要跨请求session的内容，每个请求session都可以重新开始，在任意一个节点上都可以。

有状态实现，就必须找到存有/知道处理上一个请求session的service节点（一个跨session information的Owner， aka affinity），找到它，然后取到存在service/server里的状态，才能处理。。这样，应用的scale out就变得比较困难。

session间没有依赖性

首先注意session间有无dependency和实现是stateless/stateful不是等同的关系。如果session间无dependency，那么天然是无状态的。如果session间有依赖性，则要看实现。

session间有依赖性

如果session之间是有依赖关系，要用到上次的结果，那么就只能先把上次的结果拿出来。这时候可以用有状态的实现，也可以用无状态的实现，只是状态记录在哪里的问题（客户端，server端，DB）。

有状态的实现，就需要寻找这个特殊的owner。

server无状态的实现，有时称为“Share nothing”， 就是：

1. 客户端每次请求带着所需状态。这种在web应用一般比较少见，因为对客户端的掌控力有限。
2. 在每次session结束后，把状态写入一个持久化DB，这样下次从DB中读取，
   这样虽然麻烦一点（对DB的存取多一些），但是能够scale out，所以总的处理能力和吞吐量上升了。

stateful的好处：

• client变的简单，在server端记录数据，不需要client通过cookie等记录

stateless的好处：

• 可以scaleout

Serverless就是把所有的stateful问题，通过存储来倒换，转化成stateless的。所以两个serverless之间的交互通过一个存储。这也有些[缺点]（https://blog.csdn.net/SpanningWings/article/details/87314099）。

概念上DB层是有状态的实现

因为从概念上DB层，数据必须保持在“DB server”（这一层是state owner），符合我们说的有状态实现的定义。虽然在数据库内部实现，也可以分出stateless层来， 但最终有一层必须是stateful层，因为信息只会存在那里。最终有一个Owner的概念。最低最低，存储介质比如硬盘，是state owner。

各层基本上是个OR的关系，只要各层之间就插入一个有状态层的实现，就能够实现对“逻辑上session间有依赖关系”的支持。