读发布！设计与部署稳定的分布式系统（第2版）笔记10_自动化和缓慢的响应

 

1. 工业机器人

1.1. 具有多层防护措施，防止对人员、机器和设施造成损害

1.2. 防护措施能限制机器人的动作和传感器的感知

1.3. 机械臂的旋转范围会远远小于它可以达到的全部运动范围

2. 自动化

2.1. 它更像是工业机器人

2.1.1. 掌握控制层感知系统的当前状态

2.1.2. 将其与期望的状态进行对比

2.1.3. 对系统施加影响，使当前状态进入到期望状态

2.2. 自动化系统并未简单地按照人类管理员的意愿行事

2.2.1. 自动化平台与管理员关于系统预期状态的不同“信念”的冲突，引发了2016年8月11日链接聚合网站Reddit遭遇停机事故

2.2.2. 刻意的手动更改与自动化平台之间的冲突

2.3. 自动化使得管理员能够花费较少的努力进行大量的操作，这就是一个力量倍增器

2.4. 自动化系统面对两套相互冲突的指令时，也会卡壳

2.5. 由自动化所引发的操作，需要花时间才能完成

2.5.1. 这段时间通常会比监控的时间间隔要长，因此请务必考虑到系统需要经过一些延迟后，才能对操作做出响应

3. 控制层

3.1. 控制层中的软件主要管理基础设施和应用程序，而不是直接交付用户功能

3.1.1. 日志记录

3.1.2. 监控

3.1.3. 调度程序

3.1.4. 扩展控制器

3.1.5. 负载均衡器

3.1.6. 配置管理

3.2. 基础设施管理工具可以迅速对系统产生巨大的影响，要在其内部构建限制器和防护措施，防止其快速毁掉整个系统

3.3. 控制层软件中实现类似工业机器人的防护措施

3.3.1. 如果软件观测器显示系统中80%以上的部分不可用，那么与系统出问题相比，软件观测器出问题的可能性更大

3.3.1.1. 被隔离的节点无法正确地感知当前状态

3.3.1.2. 控制系统会感知环境，但它们有可能被愚弄

3.3.2. 运用滞后原则

3.3.2.1. 快速启动机器

3.3.2.2. 要慢慢关机

3.3.2.3. 启动新机器要比关闭旧机器更安全

3.3.3. 当期望状态与观测状态之间的差距很大时，要发出确认信号，这相当于工业机器人上的大型黄色旋转警示灯在报警

3.3.4. 那些消耗资源的系统应该设计成有状态的，从而检测它们是否正在试图启动无限多个实例

3.3.5. 构建减速区域，缓解势能

3.3.5.1. 控制层虽然每秒都能感知到系统已经过载，但它启动一台虚拟机处理负载需要花费5分钟

3.3.5.2. 大量负载依然存在的情况下，要确保控制层不会在5分钟内启动300个虚拟机

4. 缓慢的响应

4.1. 通常由过度的需求引起

4.2. 争着使用已经供不应求的数据库连接，会使响应变慢，进而加剧这种争用，导致恶性循环

4.3. 内存泄漏经常表现为响应缓慢

4.3.1. 内存泄漏会导致垃圾收集器过度运行，从而引发响应缓慢

4.4. 低层级的低效协议会导致网络停顿，从而导致响应缓慢

4.5. 对网站来说，响应缓慢会招致更多的流量

4.5.1. 那些等待页面响应的用户，会频繁地单击重新加载按钮，为已经过载的系统施加更多的流量

4.6. 缓慢的响应会将调用系统和被调用系统中的资源拖得动弹不得

4.6.1. 生成响应较慢比拒绝连接或返回错误更糟

4.7. 缓慢的响应倾向于逐层向上传播，并逐渐导致层叠失效

4.7.1. 一旦陷入响应缓慢，上游系统本身的处理速度也会随之变慢，并且当响应时间超过其自身的超时时间时，会很容易引发稳定性问题

4.8. 快速返回系统失效信息，能使调用方的系统快速完成事务处理，最终成功或是系统失效，取决于应用程序的逻辑

4.9. 让系统具备监控自身性能的能力，就能辨别其何时违背SLA

4.9.1. 系统能跟踪自己的响应情况，那么就可以知道自己何时变慢

4.9.2. 系统平均响应时间超出系统所允许的时间时，可以考虑发送一个即时错误响应

4.9.3. 当平均响应时间超过调用方的超时时间时，应该发送这样的响应