文章内容概述
本文内容较多，分为如下部分：无状态服务和有状态服务定义、无状态服务应用场景、有状态服务应用场景、有无状态俩种服务的架构质量对比、实现有状态服务的挑战、有状态服务重构成无状态服务。
警告提示
任何情况下都优先考虑使用无状态服务，即使阅读本文，包括以后写的有状态服务实现模式后。
高可用原则
高可用4大原则自认为分别是[端到端]，[有状态vs无状态]，可观测，万一，其他微服务框架，容器化认为是次要的。
服务状态定义
分布式系统里，节点服务包含了`业务处理`和`数据`俩部分。如果数据是从持久化系统加载，则认为此节点是有状态的；如果数据常驻于节点内，业务逻辑是从外部加载进来的，则认为是有状态节点。
无状态服务
绝大多数系统都是无状态服务，服务不需要在服务本地（JVM）记录同一个客户端（如用户，设备，或者其他作为客户端的服务等）请求的历史状态或者记录客户端的信息，服务需要的这些数据将从数据库或者Redis，MongDB加载。例如登录服务、搜索服务、电商中库存查询、物联网中查询家庭设备的状态等。
无状态服务的技术实现非常成熟，如果服务是无状态，仅仅需要增加节点既可实现系统高可用和高性能。但随着流量增加和服务节点增加，代理服务和数据库本身可能成为高可用高性能的瓶颈，因此代理服务和数据库节点也应该支持扩展节点。
无状态服务的主要优点有实现简单，像编写CURD代码那样简单；扩容简单，增加节点即可，代理服务可以使用轮询，随机等路由技术实现。
有状态服务
与无状态服务对应的是有状态服务，要求服务端记录同一个客户端的交互历史数据和状态数据，有状态服务通常从外部加载执逻辑而不是数据。比如用户前端流程表单在最终提交前保留在服务端的临时表单数据、用户登录后的会话信息放在Session，Session信息存放在JMV内存里等。
有状态需要客户端始终连接到同一个服务节点（持久化连接），需要客户端或者代理服务采取的路由策略保证同一个客户任何请求都在同一个节点执行，比如来自同一个IP的用户。
有状态服务的主要优点有高性能，主要避免了从数据库加载数据的延迟，也避免了从持久化系统反复加载数据；任意状态数据结构，不再需要持久化系统保存状态数据，其状态不限制于JSON，表数据结构；CAP，分布式常见的AP能得到满足外，由于数据在同一个节点，其C也能满足，但如果主节点宕机（或者客户端认为C宕机路由到从节点），从节点接管，则C不成立；避免使用性能不佳的数据库，无状态服务的扩容，也会导致其用的数据库节点扩容，无状态节点因为不需要数据库，则省去了数据库的使用成本，以及其导致的性能瓶颈。
有状态服务挑战
有状态服务不难实现，但要达成高可用目标，则难得多。有状态服务高可用的部署架构存在诸多技术挑战性，如持久连接、复制、读写一致、分区、分区再平衡、分布式共识、集群管理、业务逻辑加载等。
两种服务架构质量对比
基于无状态服务和有状态服务各自的优缺点，从高可用、故障恢复、故障容错、高性能、可修改、可伸缩性等方面对两种服务的架构质量进行了对比。
有状态服务转无状态服务方法
既然无状态服务有如此多的优点，除非有高性能要求，架构中应该优先使用无状态服务，如果是有状态的服务，需要改成无状态服务，有4个办法：有状态服务的状态数据存放在Redis等更为可靠的存储介质；服务端的状态每次都回传给客户端，客户端下次调用携带这些状态；有状态服务把有状态部分单独隔离出来，把其他部分放在无状态服务里；使用Zookeeper，数据库等强一致工具来实现投票，元数据管理，二阶段提交等，而无需自己实现。
再次警告
有状态服务高可用实现难度较大，类似正在实现一个Redis，Kafka这样的中间件，需要承担为了性能引入的复杂性。那么，如何更好地应对有状态服务高可用的挑战呢？
