在京东我们是如何做服务降级的

在京东我们是如何做服务降级的

当我们依赖的中间件资源或者是上游服务性能出现严重问题时，为了防止用户看到错误页面或者加载页面时间过长，我们需要将服务降级静态页面。或者将不影响主流程的旁路服务关闭掉，以让出资源给主要流程。这类操作称为降级。服务降级方案有三种方式，降低一致性、减少非必要功能、简化功能，后面我会分别举例说明。

想要做好降级的前提是，提前压测得出指标上限，还有提前梳理好系统的性能制约点，比如依赖的服务响应超时时间和基础负载性能（比如CPU使用率），并纳入监控范围。当前提就绪后，我们就开始编写异常降级操作手册，包括托底预案，描述好当发生什么样的场景时，每一步做什么，它的预期结果是什么，还有是否演练过，只有经过真枪实弹考验的士兵才是好士兵。最后一点，我们会特别注意的，降级方案是手动生效还是自动生效的，它和止损息息相关。

先来看看手动生效。手动生效意味需要当有人反馈或者监控发现有异常后，手动修改配置中心的值，使得提前准备的降级预案生效。比如正常情况下我们会先读缓存，如果缓存中没有就尝试从数据库读取，服务降级后，当缓存无法命中时，直接返回默认值，简化功能。不过需要注意，有些情况操作生效时间不是实时的，客户端会缓存第一次加载的配置，然后每隔一段时间就同步一次，甚至需要重启APP才能生效，必要性只能让客服引导用户重启APP。

再来看看自动生效。一般做法是，在接口定义时，定义标明好失败或者超时返回的响应码和数据。有时我们会返回托底跳转链接给前端，让前端重定向加载托底页面。或者平时让前端一次性分别请求正常的链接和托底的链接，当正常的请求响应异常时就展示托底的数据，这种方案虽然每次都是经常两次，但是托底方案一般是轻量级的，所以也不失为一种策略。

那服务降级或者托底方案应该怎么做呢？

如果是核心流程，比如下单或者支付类不可或缺的流程，降级预案一般是在负载均衡Nginx中使用Lua脚本检测CPU使用率，当达到阀值时开启限流，让用户排队。如果是非核心流程，比如领卷中心交互型的，可以设置用户点击必弹“已抢完”提示，总比功能缺陷直接暴露给用户好。非核心流程中的不那么重要的服务，我们会直接关闭掉，比如红点提醒、猜你喜欢。还有一种比较特殊，它和用户日常操作强关联的，比如该服务平时展示的列表都是用户主动关注的，比如关注的达人最近发布的好文。那我们就每天同步存储一份有界的无状态的列表，当出现异常时就展示昨天的，这是在降低数据的一致性。这里我强调的是无状态的，因为我们需要避免展示过期的数据，不然显得很唐突和怪异。比如发现的京品推荐官，降级时会显示回放列表。

最后再来看看几个注意事项。

第一：周知。一个主入口里面会有很多的Tab，当默认Tab的服务短时间无法恢复时，往往会改变全部用户的或者部分用户的默认Tab，此时会和业务方提前沟通好，确保能承载相应的流量，防止雪崩效应。另外一个就是当发生异常时，及时和领导报备，不要一个人埋头苦干，其他人或许会有更佳的止损方案。

第二：事务补偿。当然每个业务的预案千差万别，有些还得准备好补偿机制。比如京东优惠小程序中组团领京豆，当成团而没有给用户京豆余额增加时，需要能及时手动补发。

第三：入口隐藏。有些情况，我们会隐藏入口或者入口明确提示用户该功能升级维护中，避免出现用户点击了以为生效了，但是实际上是不会生效的情况，造成用户损失。比如之前京东的东东农场中定时领取水滴，业务调整了但是入口没有做调整，导致了大量的客户投诉。

第四：降级来源和正常数据来源分开。

第五：紧急扩容。当服务负载过高，我们可能临时申请容器抗压。在京东，在大促高流量节点期间，上线变更需要多级审批。突发情况下我们为了减少上线流程时间，会在预发布分组发布线上配置的服务，因为预发布分组是无须领导审批的。

好，我今天分享了在京东是如何做服务级级的。如果有帮助到你，欢迎分享给你朋友们或者点个在看。