服务降级背后的技术架构设计

作者：肖飞，于2011年8月份加入京东，曾亲身参与到京东的应用性能监控、统一日志、流式计算、内存缓存、四层防攻击等一些基础技术平台的研发和搭建工作，经历了京东的技术系统从简单粗放向复杂精细化的演变过程。目前主要工作为多中心交易项目中的数据复制中间件JingoBUS的研发。平时也会开发一些公共的平台和工具，关注分布式系统的实现、程序设计、性能优化、开发语言等。

本文是2016年11月肖飞在京东技术开放日分享的《服务降级背后的技术架构设计》PPT内容。

降级之术

数据

• 总共5000+预案

• 结算页，依赖62个服务接口，31个有故障切换预案，45个降级预案

• 移动大促高峰时点前主动降级

数据来源京东预案管理系统，有重合。涉及类型：故障切换、资源调配、限流、降级。

示例

牺牲部分用户体验

• 商详页不显示特色服务icon、促销信息等

• 结算页不显示自提/311/411预约日历

• 订单详情页不显示GIS订单轨迹、催单等

• 评价列表禁止10页之后的翻页

• 实时统计和报表禁用

• 强制必选查询条件中的路由或索引字段

• 领豆豆防刷降级为拼图验证

• H5变PC页面

• 使用通用内容代替个性化推荐内容

降低安全级别

• 发放京豆、提交订单、发表评论、登录不调用风控接口

• 结算页前端下单不启用验证码

• 集中式session不可用，cookie解密即可

• ip limit服务，注册、登录不限制次数

• 商品修改内容不做敏感词过滤

牺牲部分业务逻辑

• 拍卖出价时不校验京豆数量

• 发表评价，不再校验是否退货

延缓任务处理

• WMS任务处理引擎，暂停调拨、节能补贴等任务

• OFW优先处理高优先级、拆分逻辑较简单的订单

损失数据持久性

• 用户地址更新，写redis，不回写数据库

• 库存预占，写redis，异步回写数据库

• 用户新增普票，写redis，不持久

• 订单二次拆分任务机制，由JMQ降为redis队列

降低准确性/实时性

• 实时价格过期不回源

• 动态页变静态拖底页

• 用户昵称接口降级，显示用户pin

• 库存状态接口降级，显示有货

• 抽奖异常，所有用户均显示未中奖

降低性能

• 数据库代替缓存防重、查询

• 数据库任务队列轮询代替MQ

• CDN降为源站

• 本地缓存降为RPC

降低容灾能力

• 自动调度变为手工调度

• VIP降级为real ip

降级之架构设计

降级设计的基础：服务化架构

• 解决系统的扩展性

• 故障隔离

• 服务拆分和治理

根据单一职责和故障隔离原则，确认业务和功能边界

确认服务依赖关系

确认上下游SLA

案例：结算页核心服务；上游：PC端结算页Web、手机APP、微信入口等；下游：62个依赖服务接口。

上游依赖

上游依赖分析的目的：梳理上游系统等级；设计限流降级方案和开关。

针对上游的主要降级手段：限流降级；按照用户质量，将高风险用户、爬虫优先降级；按照上游系统等级，将低级别系统的资源调度到高级别系统。

下游依赖

下游依赖分析的目的：–梳理依赖的影响程度和范围；设计候选降级方案和开关。

结算页强依赖：服务：购物车、商品、库房属性、库存预占、四级地址、订单号、接单；存储：orderstore缓存；不可降级，要求下游拼死保护SLA。

结算页弱依赖

   

实施

降级实施：人工 or 自适应；主动 or 被动。

时机：根据上游确认的SLA，超出调用量阈值的，触发限流降级开关；根据下游确认的SLA，结合最近的可用率、资源使用率、耗时等统计、监控信息，切换到备选方案，或恢复到常规方案。

降级之道

降级：是利用有限资源，保障系统核心功能高可用、有损的架构方法。有限资源；核心高可用；有损；架构方法。

关键词解读：

有限资源（边际效用递减法则：单位资源投入对可用性的效用是不断递减的）。核心（功能/服务等级：核心高可用，级别越低，可用性要求越低）。有损（降级与故障切换的关系：降级是有损的故障切换）。架构方法（降级需要预先分析、设计，有实施方法论）。

降级预案设计原则

• 候选方案要简洁，不要把系统复杂化

• 考虑降级的收益和影响成本，设计收益率最高的方案

• 降级预案需要定期review：业务复杂度变更；系统重要级别提升

• 简洁原则；经济原则；动态原则