01.03 Day 19 - 弹力设计篇之“降级设计”

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

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

关键词总结：降级的牺牲（降低一致性、停止次要功能、简化功能）、降低数据一致性（失效、命中、更新）、降级设计要点（梳理和分析业务、降级的关键条件、可简化业务流程设计、流水账记录法、降级开关、限流程度参数、降级标签、降级演练）。

 

所学总结：

 

降级的牺牲

降低一致性

降级之后，只能保证流程最终结果的一致性。

停止次要功能

降级之后，对次要服务所占用的资源进行裁剪，将大部分资源分配给重要的服务。

简化功能

降级之后，必要的时候，忽略非关键数据并只返回重要的数据。
 

降低数据一致性

通过缓存来降低数据库的访问量。

失效

当缓存中没有对应数据时才从数据库中读取并将其保存至缓存。

命中

当缓存中有对应数据时直接将其返回即可。

更新

将数据更新至数据库后让缓存失效。
 

降级设计要点

梳理和分析业务

我们需要对业务进行非常详尽的梳理和分析工作。

降级的关键条件

定义出关键的降级条件之后，做好相应的防护准备，可以通过代码来实现，做成能够全自动或半自动执行的方案。

可简化业务流程设计

需要对功能的重要程度作区分，在降级时，可以决定留住哪些服务，丢弃哪些服务。

流水账记录法

需要记录服务执行到达的每一步，当有遗漏或问题时，可以对照每一步的执行结果，或某个请求操作停留的步骤。

降级开关

可以做成推送或拉取的方式。

限流程度参数

当流量激增或是达到一定数值时，网关自动给所请求的服务传递一个限流程度的参数，当服务接收到限流程度参数后，其根据限流的程度来判断是否需要进行降级操作。

降级标签

前端可以根据后端返回的协议头里的降级标签，来判断部分数据不可用的问题，是否是降级所导致的。

降级演练

为了确保降级操作在进行的过程中不会有意想不到的问题或结果，我们需要定期进行降级演习操作。
 

末了

重新总结了一下文中提到的内容：降级设计本质、资源不足、访问量过大、降级的方法、降低一致性、停止次要功能、简化功能、降级设计要点。