本文主要是介绍01.03 Day 19 - 弹力设计篇之“降级设计”，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
大家好，我是 Snow Hide，作为《左耳听风》这个专栏的学员之一，这是我打卡的第 19 天，也是我第 19 次进行打卡这种操作。
今天我温习了该专栏里一篇叫《弹力设计篇之“降级设计”》的文章。
关键词总结：降级的牺牲（降低一致性、停止次要功能、简化功能）、降低数据一致性（失效、命中、更新）、降级设计要点（梳理和分析业务、降级的关键条件、可简化业务流程设计、流水账记录法、降级开关、限流程度参数、降级标签、降级演练）。
所学总结：
降级的牺牲
降低一致性
降级之后，只能保证流程最终结果的一致性。
停止次要功能
降级之后，对次要服务所占用的资源进行裁剪，将大部分资源分配给重要的服务。
简化功能
降级之后，必要的时候，忽略非关键数据并只返回重要的数据。
降低数据一致性
通过缓存来降低数据库的访问量。
失效
当缓存中没有对应数据时才从数据库中读取并将其保存至缓存。
命中
当缓存中有对应数据时直接将其返回即可。
更新
将数据更新至数据库后让缓存失效。
降级设计要点
梳理和分析业务
我们需要对业务进行非常详尽的梳理和分析工作。
降级的关键条件
定义出关键的降级条件之后，做好相应的防护准备，可以通过代码来实现，做成能够全自动或半自动执行的方案。
可简化业务流程设计
需要对功能的重要程度作区分，在降级时，可以决定留住哪些服务，丢弃哪些服务。
流水账记录法
需要记录服务执行到达的每一步，当有遗漏或问题时，可以对照每一步的执行结果，或某个请求操作停留的步骤。
降级开关
可以做成推送或拉取的方式。
限流程度参数
当流量激增或是达到一定数值时，网关自动给所请求的服务传递一个限流程度的参数，当服务接收到限流程度参数后，其根据限流的程度来判断是否需要进行降级操作。
降级标签
前端可以根据后端返回的协议头里的降级标签，来判断部分数据不可用的问题，是否是降级所导致的。
降级演练
为了确保降级操作在进行的过程中不会有意想不到的问题或结果，我们需要定期进行降级演习操作。
末了
重新总结了一下文中提到的内容：降级设计本质、资源不足、访问量过大、降级的方法、降低一致性、停止次要功能、简化功能、降级设计要点。
这篇关于01.03 Day 19 - 弹力设计篇之“降级设计”的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
