京东 周光 - 京东虚拟业务系统高可用性设计

尉礼骞

2017/12/18 发布于 技术 分类

ArchSummit全球架构师峰会是InfoQ中国团队推出的面向高端技术管理者、架构师的技术大会,参会者中超过50%拥有8年以上的工作经验。 ArchSummit秉承“实践第一、案例为主”的原则,展示新技术在行业应用中的最新实践,技术在企业转型中的加速作用,帮助企业技术管理者、CTO、架构师做好技术选型、技术团队组建与管理,并确立技术对于产品和业务的关键作用。

文字内容
1. 京东虚拟业务系统高可用性设计 周光 京东商城研发部架构师
5. Ø  虚拟业务系统 Ø  虚拟业务系统高可用性实践 Ø  大促如何确保高可用
6. 虚拟业务系统特点 Ø  非标品 Ø  多业务线(20+产品线) Ø  业务复杂程度不一 Ø  大量第三方供应商交互 Ø  新业务上线迅速 Ø  系统维护量大 տ઀ ଶ‫؃‬ ங᫫ᄶၚᎱ ֗᷇ሲ ๢ᐥ ṛ ਮ ‫ܔ‬ հ ‫ے‬ရ‫ ؀شܜ‬૧෢ ᄍ‫ڊ‬ᐥ ṛ᷇ሲ ᳪᐥ ᯌମ ᅉ᫣ᐥ ᥤ᷇ ኞၚᗈᩇ ኪ୽ᐥ ჋౭ᅩ‫ܜ‬ ֗ ਮ ‫ܔ‬ հ ၞᰁ‫ ؀ش‬ၞᰁ‫ے‬ရᒊ ᦾᩇ‫؀ش‬
7. 虚拟业务系统架构v1.0 Ø  系统抽象度不高 Ø  重复开发,效率低 Ø  系统稳定性难保证
8. 虚拟业务系统架构v2.0 Ø  基础公共能力下沉 Ø  商品、订单等模型抽象 Ø  业务组件提炼 Ø  业务流程平台化 Ø  编排 Ø  配置
9. 部署架构 Ø  多实例多机房部署 Ø  同机房不同机柜 Ø  ES集群 Ø  MySQL一主多从 Ø  缓存(JimDB)一主多从
10. Ø  虚拟业务系统 Ø  虚拟业务系统高可用性实践 Ø  大促如何确保高可用
11. 高可用性的度量 A = MTBF / (MTBF + MTTR) MTBF = 平均故障间隔时间(Mean Time Between Failures) MTTR = 平均恢复时间(Mean Time to Recovery) 提高系统的可用性的两个途径 •  提高MTBF:减少故障 •  降低MTTR:快速解决故障
12. 影响可用性的因素与应对方法 因素 单点故障 依赖故障 超出承载 定位、恢复慢 方法 结果 冗余 提高MTBF 降级、异步化 提高MTBF 限流 提高MTBF 监控报警、应急预案 降低MTTR
13. 冗余设计 – 消除单点 基础设施层 •  多IDC •  多DNS •  多CDN •  多路由器 •  双网卡 数据层 •  数据库master/ slave •  缓存一主多从 •  ES集群 应用层 •  多实例 •  跨机架 •  服务无状态
14. 数据冗余实现 – 复制 应用同步双写 可立刻读 性能差 应用异步双写 性能好 有延迟 JMQ 商品MQ 虚拟商品全量ES 虚拟商品中心 虚拟商品库 (分库分表)
15. 数据冗余实现 – 复制 利用底层数据存储复制机制 对应用无侵入 开发量少 延迟较严重 虚拟订单中心 binlog 虚拟订单库 Binlake 虚拟订单ES( jiesi1)
16. 数据本地化 应用场景 Ø  依赖外部数据 Ø  高频访问 Ø  数据变化频率低 实现方式 Ø  定时主动数据同步 Ø  第三方通知
17. 降级 场景 依赖的外部系统出现故障 原则 方法 例子 KISS 降级非关键依赖 开关(手动/自动) 方案审查、演练 性能降级:比如缓存降级到ES 功能降级:比如优惠劵服务故障降级支付方式
18. 降级 – 虚拟商品系统 1 Lua自动降级调用HTTP接口 2 开关控制是否实时写全量ES 虚拟商品shop端 3 开关控制是否写快照 4 开关控制是否读Jimdb 垂直搜索index 垂直搜索主服务 商品MQ 2 3 单品页 Nginx 虚拟商品中心 4 1 Jimdb POP商品 微信手Q 抢购系统 虚拟商家 图片服务 4 视频系统 搜索全量ES 商品全量ES 商品快照ES Jimdb 商品主库分库
19. 异步化-事件驱动(火车票) 典型场景 Ø  访问第三方系统不稳定(网络等) 实现方式 Ø  事件驱动业务流程 Ø  失败利用MQ重试机制 Ø  注意幂等
20. 限流 典型场景 Ø  机票防刷;抢火车票 接入层限流 Ø  Nginx+Lua+Redis Ø  IP、账户、地区等 应用限流 Ø  服务框架设置(方法级)
21. 限流
22. 监控与报警 Ø  系统监控(CPU,内存、负载等) Ø  网络监控(网络流入量,流出量等) Ø  磁盘监控(使用率、读写速度等) Ø  容器监控 (线程数、SWAP使用等) Ø  服务监控(TP99, 调用量等) Ø  业务监控(订单状态等) Ø  JVM监控
23. Ø  虚拟业务系统 Ø  虚拟业务系统高可用性实践 Ø  大促如何确保高可用
24. 大促备战 发现薄弱环节 梳理关键流程 容量估计 4 演练 故障模拟 应急方案 1 Keyword 3 优化 性能 可用性 2 压测 系统压测、稳定性测试 全链路压测 TP99, CPU, 内存…
25. 系统压测 Ø  测试环境/预发环境 Ø  关注吞吐量、性能和稳定性 Ø  常态化
26. 全链路压测 Ø  在公网模拟真实用户行为 Ø  从CDN节点压测 Ø  使用Forcebot执行压测 Ø  监控访问量、TP99、CPU等
27. 容量规划 规划 Ø  基于历史数据、促销计划预测 Ø  根据压测分配资源 扩容方法 ᶱፓ! XXXX! ๢಄1 ! ๢಄2! ๢಄…! 2016.1 2017. 2017.1 ਫֺහ! ๐‫ۓ‬ᚆ ਫֺහ! ๐‫ۓ‬ᚆ ਫֺහ! ๐‫ۓ‬ᚆ 1.11ၞ 6.18ၞ 1.11ᶼ ‫(ێ‬ӡ/ ‫(ێ‬ӡ/ ‫(ێ‬ӡ/ ᰁ(ӡ/ ᰁ(ӡ/ ᦇၞᰁ ᑁ҂! ᑁ҂! ᑁ҂! ᑁ҂! ᑁ҂! (ӡ/ᑁ҂! ҂! ! ! 24! 1.6! 24! 1.6! 12! 0.8! 1.6! 2! 3! Ø  应用水平扩容(增加docker) Ø  硬件垂直扩容(内存、升级SSD等) Ø  基础设施扩容(数据库分库分表、ES分片扩容、缓存分片扩容等)
28. 全场景故障模拟演练 Ø  开发人员自助服务 Ø  故障模拟种类 Ø  系统故障 Ø  网络故障 Ø  服务故障 Ø  可视化效果数据
29. 应急预案 Ø  数量:虚拟业务200+ Ø  类型:应用/依赖 Ø  演练:与故障模拟结合