有状态和无状态服务

有状态服务器和无状态服务器

• 对服务器程序来说，有两个基本假设十分重要，究竟服务器是基于状态请求还是无状态请求。状态化的判断是指两个来自相同发起者的请求在服务器端是否具备上下文关系。如果是状态化请求，那么服务器端一般都要保存请求的相关信息，每个请求可以默认地使用以前的请求信息。而无状态请求则不行，服务器端所能够处理的过程，他的处理信息必须全部来自于请求所携带的信息以及其他服务器端自身所保存的、并且可以被所有请求所使用的公共信息。

为什么要做无状态化

• 很多应用拆分成微服务，是为了承载高并发，往往一个进程扛不住这么大的量，因而需要拆分成多组进程，每组进程承载特定的工作，根据并发的压力用多个副本公共承担流量。
• 将一个进程变成多组进程，每组进程多个副本，需要程序的修改支撑这种分布式的架构，如果架构不支持，仅仅在资源层创建多个副本是解决不了问题的。
• 阻碍单体架构变为分布式架构的关键点就在于状态的处理。如果状态全部保存在本地，无论是本地的内存，还是本地的硬盘，都会给架构的横向扩展带来瓶颈。
• 状态分为分发、处理、存储几个过程，如果对于一个用户的所有的信息都保存在一个进程中，则从分发阶段，就必须将这个用户分发到这个进程，否则无法对这个用户进行处理，然而当一个进程压力很大的时候，根本无法扩容，新启动的进程根本无法处理那些保存在原来进程的用户的数据，不能分担压力。
• 所以要讲整个架构分成两个部分，无状态部分和有状态部分，而业务逻辑的部分往往作为无状态的部分，而将状态保存在有状态的中间件中，如缓存、数据库、对象存储、大数据平台、消息队列等。
• 这样无状态的部分可以很容易的横向扩展，在用户分发的时候，可以很容易分发到新的进程进行处理，而状态保存到后端。而后端的中间件是有状态的，这些中间件设计之初，就考虑了扩容的时候，状态的迁移，复制，同步等机制，不用业务层关心。
• 

容器和状态

• 容器和微服务是双胞胎，因为微服务会将单体应用拆分成很多小的应用，因而运维和持续集成会工作量变大，而容器技术能很好的解决这个问题。然而在微服务化之前，建议先进行容器化，在容器化之前，建议先无状态化，当整个流程容器化了，以后的微服务拆分才会水到渠成。

无状态化的几个要点

• 
• 对于数据的存储，主要包含几类数据：
  • 会话数据等，主要保存在内存中。
    • 对于保存在内存里的数据，例如Session，可以放在外部统一的缓存中。
  • 结构化数据，主要是业务逻辑相关
    • 对于业务相关的数据，则应该保存在统一的数据库中
  • 文件图片数据，比较大，往往通过CDN下发
    • 对于文件，照片之类的数据，应该存放在统一的对象存储里面，通过CDN进行预加载
  • 非结构化数据，例如文本、评论等
    • 对于非结构化数据，可以存在在统一的搜索引擎里面，例如ElasticSearch。
• 而所有的外部统一存储，无论是缓存、数据库、对象存储、搜索引擎、都有自身的分布式横向扩展机制。
•