本文是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：业务复杂度变更;系统重要级别提升
- 简洁原则;经济原则;动态原则
作者：肖飞，于2011年8月份加入京东，曾亲身参与到京东的应用性能监控、统一日志、流式计算、内存缓存、四层防攻击等一些基础技术平台的研发和搭建工作，经历了京东的技术系统从简单粗放向复杂精细化的演变过程。目前主要工作为多中心交易项目中的数据复制中间件JingoBUS的研发。平时也会开发一些公共的平台和工具，关注分布式系统的实现、程序设计、性能优化、开发语言等。
【本文来自51CTO专栏作者张开涛的微信公众号(开涛的博客)，公众号id: kaitao-1234567】
