12.27 Day 12 - 弹力设计篇之“服务的状态”

大家好，我是 Snow Hide，作为《左耳听风》这个专栏的学员之一，这是我打卡的第 12 天，也是我第 12 次进行打卡这种操作。

今天我温习了该专栏里一篇叫《弹力设计篇之“服务的状态”》的文章。

关键词总结：服务的状态、Stateless / 无状态服务（函数式编程、无状态服务的状态表现、无状态服务的状态存储（非关键数据、关键数据））、Stateful / 有状态服务（有状态服务的好处（数据本地化 Data Locality、高可用性/一致性）、Sticky Session / 粘滞会话/会话保持、分布式长连接、Gossip）、服务状态容错设计（运行时复制、全部/大部分一致、服务与文件系统分离）。

 

所学总结：

 

服务的状态

系统中的状态可以是用户登录之后的 Session 或者一些暂存在系统服务器的数据，早期用 Servlet 的 Application Scope 来统计网站访问量也是有一个典型的有状态例子。而将数据保存在客户端 Cookie 的做法则是属于无状态的范畴。只要应用服务器不持有数据，那么它就是无状态的服务。
 

Stateless / 无状态服务

分布式系统中最容易进行节点添加和删除的服务就是不持有状态数据的服务。

函数式编程

函数是没有状态的，也即函数是不可变的，函数的包含了处理数据的算法，但它不持有数据。一般情况下函数不会更改数据本身，它只是返回处理的结果。

无状态服务的状态表现

• 结果：程序/服务的调用结果；
• 上下文：程序/服务处理组合的总结果；
• 配置：程序/服务的配置信息。

无状态服务的状态存储

将状态数据存储到服务以外。

非关键数据

可以将例如不需要事务介入的非关键数据存储在 Redis、Memcached 或 MongoDB 中。

关键数据

可以将关键的数据存储在例如 MySQL、Zookeeper/Etcd 这种强一致的服务或者分布式文件系统（开源的有：Ceph 和 GlusterFS）中。
 

Stateful / 有状态服务

有状态服务的好处

数据本地化 Data Locality

服务在访问本地存储的数据时，一般情况下是不会出现延时的现象。

高可用性/一致性

CAP 理论中的 A 代表了可用性，C 代表了一致性。而有状态的服务本身就符合这两个条件。分布式服务中常见的两种是 AP（高可用） 和 CP（强一致），但鱼与熊掌不可兼得。

Sticky Session / 粘滞会话/会话保持

在有状态服务中，由于用户每次所访问的服务都会是同一个实例，所以用户所对应的 session 也是存在的。

分布式长连接

分布式系统中服务间共享状态的办法可以通过一致性哈希算法来实现，但这种方式会有出现服务端成为热点的问题，需要通过客户端进行断开操作。

分布式协议 Gossip

分布式系统中可以借助 Gossip 协议来在各个服务节点之间通过广播消息的方式做到元数据在服务之间的同步机制。集群服务的分配管理会比较直观。
 

服务状态容错设计

运行时复制

运行时复制数据需要考虑的问题是一致性。运行时复制的方案有：Zookeeper、Kafka、Redis 或者 Elasticsearch 等。

全部/大部分一致

CAP 理论里的 CA 代表的是全部节点的数据一致，而其中的 CP 代表的则是大部分节点的数据一致即可。

服务与文件系统分离

可以将服务与它所挂载的文件系统存放至不同的物理位置，当服务本身不可用时，我们可以将之前服务实例所使用的文件系统挂载至重新生成的服务实例中供其使用。
 

末了

重新总结了一下文中提到的内容：无状态服务、无状态服务和函数的类比、分布式数据库支持、有状态服务、Sticky Session、一致性哈希算法、分布式哈希表（DHT）、可在实例间随意进行切换的分布式文件系统。