很多程序员，都希望提升自己系统的撸棒性，什么是撸棒性呢?这个其实是从英文直译过来的，就是程序员的健壮性。相信不少程序员同学都听过服务雪崩，或者曾经使用过某款软件雪崩过。当服务发生雪崩的时候，几乎整个系统会处于不可用的状态，为什么会发生服务雪崩呢?我们举一个常见的例子。
因为新冠病毒的影响，口罩成为了稀缺物品，很多电商平台纷纷开启了口罩秒杀活动。一次口罩秒杀的正常流程可能是这样的，用户在前端发起请求，经过了复杂的网络环境，到了后台系统，后台是分很多个系统的，可能需要去商品系统去校验商品的合法性，然后去用户系统校验用户的合法性，再去库存系统校验还有没有库存，最后可能还要去积分系统、优惠系统、地址系统等等等。一次简单的秒杀，后台竟然如此复杂。而这么多系统，只要有一个系统出现瓶颈，就可能出现雪崩。例如库存系统，每秒本来可以处理1万个请求，突然来了10万个请求，他们只能够排队处理，可能只处理了5万个，后面的就超时了。超时了，用户的页面就有可能转菊花，用户很难受，就有可能不停的刷新，又涌进来更多的请求。本来用户系统可能可以处理10万个请求，因为用户不停的刷新，也崩溃了。而用户系统可不只影响了秒杀，一些使用其他功能的用户也被迫重试，最后，整个系统都趋于崩溃。
为了避免服务雪崩，我们需要做点什么，通常我们会使用限流或者熔断机制。限流，顾名思义，就是限制流量的大小。这个在日常生活中，我们也并不陌生。例如北上广深的地铁站，高峰时期就经常限流。本来10分钟只能搭乘500名乘客，这个时候我们让2000名乘客到站台等也是毫无意义，徒增风险，限流系统就是这种理念。预估好每个系统的容量，例如库存系统，一秒钟只能处理1万个请求，那么我们就让只有1万个请求能够请求到库存系统。其他的请求直接拒绝，告诉他们，库存已经售光了，下次再来。这就可以很好地保护到我们的系统。
另一种常见的手段，便是熔断。熔断就跟我们的保险丝一样，一旦电流达到某个值，就会烧断保险丝，从而保护到用电安全。熔断在分布式系统中其实也比较常见，一般有着下面三种状态。全开，表示服务运行正常，关闭，表示触发熔断，无法正常调用，半开，部分请求会被拦截。
那么熔断系统有什么用呢?我们举一个简单的例子，假如我们的服务是部署在多个机房的，突然有一天，某个机房的光纤被挖断了。这个时候，使用这个机房的服务基本都会失败了，这个时候，如果没有熔断系统，就会有持续不断的请求进入这个机房，结果必然是超时或者失败。最后引发上游业务的不断重试，引起雪崩。如果这个时候有熔断的存在，很快请求就会被路由到其他机房，从而达到对系统的保护。
那么，如何设计一个熔断系统呢?只要掌握了以下几点，相信并不困难。
- 位置 在一个分布式服务中，那些服务是瓶颈就是最有可能需要熔断的地方。
- 错误类型 在一个服务中，通常有各种类型的错误，有些是系统失败，像服务超时，运行时异常，有些则是逻辑失败，像订单重复取消，要正确的区分不同的错误，有些错误要触发熔断，有些则是可以跳过。
- 性能 一个好的熔断服务，对性能的影响应该是较小的。不难因噎废食，为了计数的准确而加了大力度的锁，从而造成性能大幅下跌。
- 服务恢复 一般，熔断的服务恢复有两种模式，一是自动恢复，熔断系统隔断时间进行服务探测，如果探测成功会进行服务恢复。另一种则是提供手动重置，例如我们误处理了一个错误码，造成系统熔断，那么我们需要手工重置。
- 日志 日志是必须的，特别是错误日志。所有的架构设计，都需要日志系统，不然就变成了薛定谔的熔断系统了。
好了，今天我们就介绍道这里，欢迎大家关注我，整理后会和大家继续分享。大家的支持是我继续唠嗑的动力。
