无论是系统架构范畴，还是前几年性能测试和优化领域，大家都很喜欢讲三高(高并发高性能高可用)，其中经常会出现这几个专业术语：缓存、限流、熔断、降级。
这些听起来很高大上的技术术语，到底是什么，在什么场景使用，它的作用又是什么，很多同学感觉云里雾里不太理解。
一个故事理解技术要点第三篇，这篇文章我们来聊聊在稳定性保障领域中经常出现的那些技术术语。
故事案例
先看下面这个故事案例：
假设你去银行取钱，你是用户，银行是一个软件系统。
直接在柜台取钱，相当于应用直接访问银行金库(数据库)。柜台数量有限(连接池)，人稍微多一些，就会给柜台处理业务压力。所以很多银行对于小额存取款，都会引导用户去ATM机(缓存)。
但是柜台和ATM机数量有限，所以需要在大厅设置用户休息等待区(缓冲区)。用户进入银行后刷卡取号(队列)，进入休息等待区等候叫号，银行按叫号顺序处理业务。
假设周末来银行办理业务的人数过多，大堂经理(调度)会引导多余的用户去其他营业厅办理业务(限流)，或者通过网上银行自助办理(分流)，再或者改天来办理业务(熔断)，降低银行的业务处理压力。
银行除了存取款，还有贷款业务，但贷款业务需要的材料手续多，业务复杂，流程长。如果来办理业务的人数过多，则可以设定贷款业务只在周三办理(降级)，其他时间只办理存取款业务。
好了，故事讲完了，这就是关于缓存限流熔断降级的比喻形式，是不是很形象。
服务治理
在系统架构设计范畴，大家都希望系统具备“三高”的特性。因为只有系统具备高性能高可用高扩展性，才能应对复杂的业务流程，承载更多的用户访问。
“三高”只是架构设计实现的目标，要保障这个目标达成，自然少不了技术手段。一般将这些技术手段统称为服务治理，或者流量治理。而流量治理，则可以归结到服务稳定性保障领域。
在保障服务稳定性方面，流量治理的主要目的有如下几种：
- 性能优化：通过流量路由、负载均衡等技术手段，确保系统资源高效利用，降低时延，避免拥塞。
- 可用性保障：通过限流、降级、熔断等手段，确保核心业务和应用服务可以再高负载下也可以正常运行。
- 故障容错恢复：在系统出现异常或宕机时，通过流量重定向手段快速摘除异常流量，并将请求路由到正常服务或备份机房上面，实现业务止血、故障转移和自我恢复，保障系统业务的持续可用性。
- 降本增效：通过性能优化、服务调度和流量控制，降低软硬件成本，并通过线上应急响应机制和日常演练，提高处理问题的整体效率。
术语解析实践
1、限流
限流其实很好理解，毕竟系统的处理能力是有限的，限流则是对超过系统处理能力的流量进行控制。
一句户概括限流：控制访问应用的流量在系统承载范围内。
限流的主要目的是为了提升系统整体可用性，同时平衡用户体验和成本支出。
在实践中，执行限流有如下三点可参考的经验：
- 在业务请求入口（网关）限流，避免内部互相调用放大流量。
- 限流是个演进状态，从连接池、IP、指定SQL到更细的层级粒度做限流。
- 每个调用层都做限流，每个应用先保证自己可用，对其他依赖调用要做到“零信任”。
2、熔断
在微服务系统中，一个服务可能会依赖多个服务，同时被其他服务依赖。以电商业务的订单服务为例，它会依赖库存商品和支付服务，同时也会被个人中心等服务依赖。
如果订单服务出现异常或者故障，如果不进行针对性处理，则会影响整个业务系统的正常运转，最后造成雪崩效应。
简单理解，所谓熔断就是保障系统和服务在过载或异常场景下系统正常运行的技术手段。
以电商双十一大促为例，常见熔断案例有如下两种：
- 双十一零点的前半小时， 动态推送，把日志关掉。
- 流量高峰来临或者应用集群出问题时，留一台机器观察错误和异常的日志。
3、降级
所谓降级，简单理解就是在系统面临高负载时，人为将一些不重要或优先级不高的业务功能临时下线，降低系统压力，同时多出的这部分资源去支撑更核心的业务处理。
如果用一句话概括降级，则是强依赖通过熔断做紧急处理，弱依赖提前主动降级。
在实践中，执行降级有如下三点可参考的经验：
- 主动降级：提前进行风险识别，然后针对性的降级，可降低已知的风险。
- 紧急降级：假设出现重大问题，才需要决策是否启用的方案（风险较大）。
- 预案平台：平台化的目的是留痕，方便后续把限流降级熔断等配置恢复回来。
最后需要注意的是：无论限流还是降级以及熔断，本质上对业务都是有损的。即在尽可能保障服务可用的情况下提供业务可用，保障业务目标的达成。这是一个需要不断验证和评估投入产出比的过程。
