大家好，我是 Snow Hide，作为《左耳听风》这个专栏的学员之一，这是我打卡的第 44 天，也是我第 52 次进行这种操作。
今天我温习了该专栏里叫《弹力设计篇之“认识故障和弹力设计”》、《弹力设计篇之“隔离设计”》、《弹力设计篇之“异步通讯设计”》、《弹力设计篇之“幂等性设计”》、《弹力设计篇之“服务的状态”》的文章。
关键词总结：分布式系统中关键的设计模式（容错设计/弹力设计）、系统可用性评估、故障分类（无计划宕机、有计划宕机）、为故障而准备的设计（当系统无法自动修复故障时）、隔离设计概念（Bulkheads/隔板）、服务种类间隔离（多板块数据获取、大数据平台、跨板块业务逻辑/流程步骤、跨板块交互、多板块分布式事务）、用户请求间隔离（服务/数据独立、服务共享/数据独立、服务/数据共享）、隔离设计关键点（隔离粒度定义、取舍评估、设计模式选用、自动化管控工具、监控系统）、同步通讯、同步通讯问题（调用链依赖、调用链阻塞、串行通讯、骨牌效应）、异步通讯、异步通讯方式（请求响应、发送订阅、代理）、事件驱动设计优点（可重用性、高度隔离、无阻塞、适配器接入、访问量处理）、事件驱动设计缺点（流程管控、顺序问题、事务复杂度）、异步通讯设计关注点（解耦、隔离、并发）、异步通讯注意事项（顺序、丢失率、记录、幂等）、幂等性（作用）、幂等性方案（上游系统负责、下游系统负责）、全局 ID、幂等性处理流程、HTTP 幂等性（GET、HEAD、OPTIONS、DELETE、POST、PUT）、幂等性设计（PRG 模式）、服务的状态、Stateless / 无状态服务（函数式编程、无状态服务的状态表现、无状态服务的状态存储（非关键数据、关键数据））、Stateful / 有状态服务（有状态服务的好处（数据本地化 Data Locality、高可用性/一致性）、Sticky Session / 粘滞会话/会话保持、分布式长连接、Gossip）、服务状态容错设计（运行时复制、全部/大部分一致、服务与文件系统分离）。
所学总结：
弹力设计篇之“认识故障和弹力设计”
分布式系统中关键的设计模式
容错设计/弹力设计
容错能力、可伸缩性、数据一致性、高并发能力。
系统可用性评估
可用性、平均故障前运行时间、平均修复时间。
故障分类
无计划宕机
系统、数据/中介、其他。
有计划宕机
日常、维护、升级。
为故障而准备的设计
降低 MTTR，提高 MTTF。
当系统无法自动修复故障时
自我隔离。
弹力设计篇之“隔离设计”
隔离设计概念
Bulkheads/隔板
源自于船舱。
服务种类间隔离
服务对应自己的数据库。
多板块数据获取
一次性返回所有谁。
大数据平台
收集数据到一个数据仓库。
跨板块业务逻辑/流程步骤
需要保证板块间的业务按先后顺序执行。
跨板块交互
借助中间件发布/订阅消息。
多板块分布式事务
类似 2PC 的方案来确保数据一致性。
用户请求间隔离
将申请大额资源服务的用户分配至独立的一个或多个服务实例中，将申请小额资源服务的用户分配至共享的一个或多个服务实例中。
服务/数据独立
将处在完全独立的服务实例和数据分区中。
服务共享/数据独立
将处在共享的服务实例和独立的数据分区中。
服务/数据共享
将处在完全共享的服务实例和数据分区中。
隔离设计关键点
隔离粒度定义
确保能定义出恰当的业务隔离粒度。
取舍评估
考虑复杂度、成本、性能、资源分配等的问题。
设计模式选用
设计模式有：高可用、重试机制、异步机制、消息队列、流量管控、熔断。
自动化管控工具
借助自动化运维工具来提高运维人员对系统指标及资源利用率方面的管理效率。
监控系统
需要看到每一项系统指标和资源使用现状。
弹力设计篇之“异步通讯设计”
同步通讯
同一时间内只能处理一件事情。
同步通讯问题
调用链依赖
整个系统的响应速度将取决于响应速度最慢的那个服务。
调用链阻塞
会使发送方阻塞并等待接收方的响应返回。
串行通讯
一次只能发送一条消息给接收方。
骨牌效应
一旦有一个接收方出问题，那么发送方将被一直被阻塞。
异步通讯
避免通讯阻塞、骨牌效应等问题的出现。
异步通讯方式
请求响应
轮训、回调。
发送订阅
发送方会将消息发送至消息队列中。
代理
发送方将消息发送至 Broker，接收方则从 Broker 订阅消息。
高可用、高性能、持久化。
事件驱动设计优点
代理是最好的事件驱动架构。
可重用性
所有服务都是可以被重复使用的。
高度隔离
包括它们的开发、测试、运维以及故障。
无阻塞
通过代理来进行交互。
适配器接入
日志、认证、版本、限流、降级、熔断等等。
访问量处理
不会再产生一方拖慢另一方速度的情况。
事件驱动设计缺点
流程管控
业务流程将变得难以管控。
顺序问题
需要一个借助状态机机制来解决类似的问题。
事务复杂度
可能需要使用 2PC 或最终一致性来解决这种问题。
异步通讯设计关注点
解耦
服务之间通过代理进行通讯。
隔离
确保其他服务不会受出故障服务的影响。
并发
发送或接收代理的消息时不会被阻塞。
异步通讯注意事项
顺序
设计中需要考虑服务在处理乱序消息方面的能力。
丢失率
当出现问题时我们很难直到它们在哪里。
记录
以便我们在系统出现故障时能够方便的定位到消息最后一次到达的地方，好让我们能从那里开始继续。
幂等
接收消息的一方要确保相同的消息如论被重传多少次都能被处理一次。
弹力设计篇之“幂等性设计”
幂等性
作用
资源无论被访问多少次，其结果都是一样的。
幂等性方案
上游系统负责
通过下游系统所提供的验证接口来检查结果的正确性。
下游系统负责
下游系统不管接收到多少次相同的请求，它对特征一样的多个请求，只做一次处理。
全局 ID
可以借助由 Twitter 开源的基于全局唯一 ID 算法实现的分布式 ID 生成算法项目 Snowflake。
幂等性处理流程
我们需要一个分布式的存储系统，专门用来提供幂等性服务。这个系统可以是基于关系型数据库，或者 MongoDB 这样的高性能 NoSQL 数据库。
HTTP 幂等性
GET
幂等，无副作用，获取接口返回的 Header 和 Body 数据，每次调用的结果都相同。
HEAD
幂等，无副作用，获取接口返回的 Header 数据，每次调用的结果都相同。
OPTIONS
幂等，无副作用，获取接口所支持的 HTTP 方法，每次调用的结果都相同。
DELETE
幂等，有副作用，用于删除数据，每次调用的结果都相同。
POST
幂等，有副作用，用于创建数据，每次调用的 URI 不同。
PUT
幂等，有副作用，用于创建或更新数据，每次调用的结果相同。
幂等性设计
PRG 模式
在调用 post 请求处理完毕之后比较保险的做法是，做一个 302 重定向，到达跳转之后的页面显示出刚刚创建的数据。这种设计方式叫“创建/重定向/获取”，也即 Post/Redirect/Get（PRG 模式）。
弹力设计篇之“服务的状态”
服务的状态
只要应用服务器不持有数据，那么它就是无状态的服务。
Stateless / 无状态服务
最容易进行节点添加和删除的服务就是不持有状态数据的服务。
函数式编程
一般情况下函数不会更改数据本身，它只是返回处理的结果。
无状态服务的状态表现
程序/服务的调用结果；程序/服务处理组合的总结果；程序/服务的配置信息。
无状态服务的状态存储
将状态数据存储到服务以外。
非关键数据
不需要事务介入的非关键数据存储在 Redis、Memcached 或 MongoDB 中。
关键数据
关键的数据存储在例如 MySQL、Zookeeper/Etcd 这种强一致的服务或者分布式文件系统（开源的有：Ceph 和 GlusterFS）中。
Stateful / 有状态服务
有状态服务的好处
数据本地化 Data Locality
一般情况下是不会出现延时的现象。
高可用性/一致性
分布式服务中常见的两种是 AP（高可用） 和 CP（强一致），但鱼与熊掌不可兼得。
Sticky Session / 粘滞会话/会话保持
在有状态服务中，由于用户每次所访问的服务都会是同一个实例，所以用户所对应的 session 也是存在的。
分布式长连接
服务间共享状态的办法可以通过一致性哈希算法来实现，但这种方式会有出现服务端成为热点的问题，需要通过客户端进行断开操作。
Gossip
在各个服务节点之间通过广播消息的方式做到元数据在服务之间的同步机制。集群服务的分配管理会比较直观。
服务状态容错设计
运行时复制
方案有：Zookeeper、Kafka、Redis 或者 Elasticsearch 等。
全部/大部分一致
CA 代表的是全部节点的数据一致，而其中的 CP 代表的则是大部分节点的数据一致即可。
服务与文件系统分离
当服务本身不可用时，我们可以将之前服务实例所使用的文件系统挂载至重新生成的服务实例中供其使用。
末了
重新总结了一下文中提到的内容：弹力设计的目的、系统可用性衡量指标、故障的起因及分类、船体水密舱的设计、分布式系统的隔离设计、常见的隔离种类、同步通讯的问题、异步通讯的好处以及种类、事件驱动设计和异步通讯设计、幂等性含义、幂等性副作用（不取决于调用次数）、服务调用结果（成功、失败、超时）、可能产生不幂等的问题（超时）、幂等性方案（轮询处理结果、下游系统做幂等处理）、分布式系统幂等性（Snowflake 全局 ID）、幂等性接口处理流程、无状态服务、无状态服务和函数的类比、分布式数据库支持、有状态服务、Sticky Session、一致性哈希算法、分布式哈希表（DHT）、可在实例间随意进行切换的分布式文件系统。
