读发布！设计与部署稳定的分布式系统（第2版）笔记17_中间件、背压和调速器

1. 完全的解耦

1.1. 各台服务器、层级和应用程序解耦得越彻底，集成点、层叠失效、响应缓慢和线程阻塞等问题就越少

1.2. 应用程序解耦后，系统可以单独更改其他应用程序的所有配件，因此也更具适应性

2. 中间件

2.1. 在极其杂乱无章的环境中，集成原本就不在一起工作的系统

2.2. 中间件既可以做到将其集成，又可以做到将其解耦

2.3. 由于集成点是导致系统不稳定的首要原因，因此“既可集成，又能解耦”是件好事

2.4. 松耦合的中间件允许调用系统和接收系统在不同的地点和时间处理消息

2.4.1. IBM MQSeries

2.4.2. 所有基于队列或发布-订阅机制的消息传递系统

2.4.3. 实现系统间消息传递的SMTP或SMS系统

2.4.3.1. SMTP和SMS系统通常由人（而不是服务器）充当消息代理，且系统延迟往往很高

2.5. 面向消息的中间件，在空间和时间上实现端点解耦

2.5.1. 发出请求的系统不会“坐等回复”

2.5.2. 不会导致层叠失效

2.6. 从同步的“请求-回复”到异步的通信方式的转变，需要完全不同的设计

2.6.1. 需要考虑转换成本

2.6.2. 中间件解耦是架构决策

2.6.2.1. 相关的实施会波及系统的每个部分

2.6.3. 应该在最后责任时刻到来时，尽早做出这种几乎不可逆转的决策

3. 背压机制

3.1. 每个性能问题都源于其背后的一个等待队列

3.1.1. 套接字的监听队列

3.1.2. 操作系统的运行队列

3.1.3. 数据库的I/O队列

3.2. 如果队列无限长，那么它就会耗尽所有可用的内存

3.3. 随着队列长度的增加，完成队列中某项工作的时间也会增加

3.3.1. 当队列长度达到无穷大时，响应时间也会趋向无穷大

3.4. 要想获得有限的响应时间，就需要构建有限长度的等待队列

3.5. 如果队列的长度是有限的，那么当队列已满且生产者仍试图再塞入一个新请求时，必须立刻采取应对措施

3.5.1. 假装接受新请求，但实际上将其抛弃

3.5.2. 确实接受新请求，但抛弃队列中的某一个请求

3.5.2.1. 随着时间的推移价值迅速降低的数据，抛弃队列中最先发出的请求可能是最佳选择

3.5.3. 拒绝新请求

3.5.4. 阻塞生产者，直至队列出现空的位置

3.5.4.1. 一种流量控制手段，允许队列向发送数据包的上游系统实施“背压”措施

3.5.4.2. 消费者必须当心，不要永久阻塞

3.6. TCP在每个数据包中都采用额外的字段构建背压机制

3.6.1. 来自TCP接收方窗口的背压，会让发送方填满其发送缓冲区，这时后续写入套接字的调用将被阻塞

3.7. 背压机制通过让消费者放慢工作来实现安全性

3.8. 背压机制会导致线程阻塞

3.9. 背压机制最适合异步调用和编程

3.9.1. Rx框架、actor或channel工具实现这个机制

3.10. 在系统边界内运用背压机制效果最好

3.10.1. 在系统边界之间，还是需要使用卸下负载模式和异步调用

4. 卸下负载

4.1. 服务、微服务、网站和开放式API都有一个共同特点：无法控制其需求量

4.1.1. 总能对某个系统施加超出其处理能力的负载

4.2. 服务应该模仿TCP的做法

4.2.1. 当负载过高时，就开始拒绝新的工作请求

4.2.2. 当请求花费的时间超过SLA规定的响应时长时，就可以卸下一些负载

4.2.2.1. 让系统的响应时间得到控制，而不是任其让调用方超时

4.3. 将负载均衡器用作减震器

4.4. 运用背压机制会更有效

5. 自动化机制

5.1. 自动化机制缺乏判断能力，一旦出错，就错得惊人

5.2. 自动化机制处理人类不擅长的事情

5.2.1. 重复的任务和快速的响应

5.3. 自动化机制不擅长的事情

5.3.1. 自动化机制不擅长的事情

6. 调速器

6.1. 使用调速器限制发动机的速度，即使动力源可以更快地驱动，调速器也可以防止它以不安全的转速运转

6.2. 调速器可以感知状态和时间，知道一段时间以来自身执行的操作

6.3. 调速器往往是不对称的

6.3.1. 在不安全的方向上施加阻力

6.3.2. 一旦超出范围，就可以运用调速器增加操作阻力

6.4. 使用调速器的意义在于放缓做事的速度，以便人工干预

6.4.1. 需要监控响应曲线的两端，当有情况发生时能够提醒人们，并给他们足够的可视化信息理解所发生的事情


来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！