作者:肖飞,于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:业务复杂度变更;系统重要级别提升
简洁原则;经济原则;动态原则
========== 相关阅读==========
聊聊高并发系统之降级特技
聊聊高并发系统之限流特技-1
聊聊高并发系统之限流特技-2
聊聊高并发之隔离术
聊聊高并发系统之队列术
聊聊高并发系统之HTTP缓存
==========公众号推荐==========
京东商品组公众号,负责京东商品系统的存储、服务、结构的规划。