聊聊业务高可用和应用高可用

上篇文章聊到了线上业务防资损的话题，业务防资损本身就是质量保障体系很重要的一环，甚至说第一要务。从另一种角度来说，业务防资损本身则要求线上业务可以为用户提供高可用的服务能力。

我们经常讲到线上服务的“三高”，即高并发、高性能、高可用，通常意义上指的是应用服务的高可用。而业务的高可用，则是从业务功能的正确性、友好性和用户体验的角度来看待。简单来说，应用服务高可用是技术实现角度（可以看作是企业内部的角度），业务服务高可用则是从业务价值的角度（可以看作是用户角度）。

这篇文章，我想聊聊我对于业务和应用高可用的理解以及看法。

思维导图

技术高可用

技术高可用，我们耳熟能详：“高并发、高性能、高可用”。

指的是软件系统在面对较高的并发用户请求时，可以快速的正确处理业务请求，并且服务的在线可用时长达到一个很高的指标。技术高可用有三个很重要的名词，即：

• SLA：服务等级协议，也可以理解为服务可用性协议，这是一个服务提供方和服务使用方双方约定的一个协议。我们常说的服务可用性达到 99.99%，一般就是服务提供方承诺自身的服务可用性目标可以达到这个数值。

• SLO：服务等级目标，指的是我们综合衡量服务可用性的目标。如可用率>99.99%、如数据库主从切换耗时<2min。

• SLI ：服务等级指标，即用哪些具体的指标度量服务可用目标。比如高性能的目标用 TPS/99RT 度量，这个时候可以将指标定义为单机平均 TPS>300，99RT<100ms 这两个指标。

以上三者的关系在 SRE 领域可以这样理解：SLO 是评估系统可用性/稳定性的目标，SLI 是表示该目标的具体数值，SLA 是服务提供方基于 SLO 的具体数值对服务使用方承诺的服务水平。

要实现技术的高可用，即应用服务的高可用，我们常见的做法有：请求限流、服务降级、请求熔断、请求排队、应用隔离以及异地多活等容灾机制。但技术的高可用，真的能保证业务的高可用吗？下面是一个我亲身经历的案例：

某年双 11 大促，为了保障电商核心交易业务，我们做了大量的性能优化和高可用方案。生产全链路压测的性能指标看上去也很好，足以扛过百万并发的入口请求。双 11 当天，流量超过我们预期，但由于高可用方案做的比较好，服务都可以在可接受的时间范围内处理请求并返回响应。但大量用户还是下不了单，导致了大量客诉。

原因是什么呢？我们当时商品详情页的逻辑是请求超时后可以实时在页面刷新，这就导致了短时间内请求商品详情接口的 QPS 激增。而我们的高可用方案是商品服务对下游服务做了熔断，这样保证了自己不会被下游强依赖的库存和优惠券等服务拖垮，保障了自己的服务可用性。

从技术角度来说，请求超时，熔断下游依赖，页面做个提醒，是个很正常的场景。但从业务角度来说，超时后用户可以实时刷新，越刷新 QPS 越高，越超时，导致无法下单。这就导致了业务的不可用，即无法为用户提供正确稳定的业务服务。

到这里，上面的问题答案不言而喻：技术的高可用并不等于业务的高可用。

上面的问题最后我们的解决方案是商品详情页超时后加一个遮罩的友好提醒，让用户无法实时刷新。同时，在网关层按照接口维度进行限流，而不是应用维度，避免人为的放大流量。最后，将商品详情页下游依赖的消息提醒等非强依赖的业务做了降级操作，降低整体的流量。

业务高可用

上面的案例说明了技术的高可用并不等于业务的高可用，那么业务的高可用是什么呢？

以 To C 互联网电商业务为例，我个人认为业务的高可用可以用四个词概括：

正常访问：无论请求量多大，必须保证用户的正常访问和操作通畅，至少核心高频业务没问题（比如保证最起码的商品导购、优惠券、商品浏览和下单支付业务可用）。

友好提醒：假设遇到上述的请求量过大需要排队，也需要有友好的处理机制和提醒，降低用户的不友好体验（比如超时排队，加一个友好的提醒遮罩）。

异常冗余：还是上述的案例，如果遇到请求量过大排队，就需要及时的切流和扩容，或者在网关层限流，而不是放任人为的流量过高导致业务不可用时长拉长。

防止资损：防资损相关的内容上篇文章聊过，业务的高可用还要注意预防资损。比如用户支付成功了，但是订单状态未更新导致下单失败。比如用户明明有优惠券，但是优惠券服务挂了导致无法使用优惠券，用户多付款。再比如发放优惠券没做规则限制，导致用户重复领取优惠券叠加使用甚至黄牛薅羊毛。

我个人认为，技术的高可用目标，一定是在保证业务的高可用的前提下才有意义，否则只会陷入技术的自嗨陷阱里。