京东应用架构设计

《京东应用架构设计》由会员分享，可在线阅读，更多相关《京东应用架构设计（35页珍藏版）》请在金锄头文库上搜索。

1、2014/7/18 1 机要文档 请勿外传 京东应用架构设计 吴博 目 录 CONTENTS 架构愿景 业务架构 应用架构 数据架构 技术架构 618经验 架构目标 架构愿景 1 1. 高可用性 自动化运维。整体系统可用性99.99%，单个 系统可用性99.999%。全年故障时间整个系统 不超过50分钟，单个系统故障不超过5分钟 2. 高可扩展性 系统架构简单清晰，应用系统间耦合 低，容易水平扩展，业务功能增改方 便快捷 3. 低成本 增加服务的重用性，提高开发效率， 降低人力成本；利用成熟开源技术， 降低软硬件成本；利用虚拟化技术， 减少服务器成本 4. 多快好省 构建超大型电商交易平台，兼

2、 顾效率和性能，达到高人效、 高时效和低成本的目标 质量要求 1 架构愿景 质量 要求 概念 完整性 可测试性 可支持性 可维护性 可重用性 可用性 互操作性 可管理性 性能 可靠性 可扩展性 安全性 易用性 总体架构原则 3 架构愿景 可用性 可扩展性 成本 N+1原则 版本可以回退 功能可开关 不过度设计 松耦合 抽象化 服务可重用 可水平扩展 容错设计 可监控 多维度拆分 采用同质化硬件 单一责任原则 使用成熟的技术 DID原则 架构组成和关键点 JD架构 2 业务架构 应用架构 数据架构 技术架构 解耦 拆分 抽象 集成 复用 治理 目 录 CONTENTS 架构愿景 业务架构 应用架

3、构 数据架构 技术架构 618经验 业务架构设计原则 业务架构 2 1. 业务平台化 业务平台化，相互独立。 如交易平 台、仓储平台、物流平台、支付平 台、广告平台等 基础业务下沉，可复用。如用户、 商品、类目、促销、时效等 2. 核心业务、非核心业务分离 电商核心业务与非核心业务分离， 核心业务精简（利于稳定），非核 心业务多样化。如，主交易服务、 通用交易服务 3. 隔离不同类型的业务 交易业务是签订买家和卖家之间的 交易合同，需要优先保证高可用性， 让用户能快速下单 履约业务对可用性没有太高要求， 可以优先保证一致性 闪购业务对高并发要求很高，应该 跟普通业务隔离 4. 区分主流程、辅流

4、程 分清哪些是电商的主流程。运行时， 优先保证主流程的顺利完成，辅流 程可以采用后台异步的方式。避免 辅流程的失败导致主流程的回滚。 如，下单时，同步调用快照，异步 通知台账、发票 业务架构图 架构架构 2 业务架构实例：基础业务下沉 业务架构 2 目 录 CONTENTS 架构愿景 业务架构 应用架构 数据架构 技术架构 618经验 应用架构设计原则 应用架构 3 一切以稳定为中心 架构尽可能简单、清晰 不过度设计 服务自治：服务能彼此独立修改、 部署、发布和管理。避免引发连 锁反应 集群容错：应用系统集群，避免 单点 多机房容灾：多机房部署，多活 架构原则 3 稳定性原则 跨域调用异步化：

5、不同业务域之间 尽量异步解耦。 非核心业务尽量异步化：核心、非 核心业务之间，尽量异步解耦 必须同步调用时，需要设置超时时 间和任务队列长度 应用抽象化：应用只依赖服务抽象， 不依赖服务实现细节、位置 数据库抽象化：应用只依赖逻辑数据 库，不需要关心物理库的位置和分片 服务器抽象化：应用虚拟化部署，不 需要关心实体机配置，动态调配资源 稳定部分与易变部分分离 核心业务与非核心业务分离 电商主流程与辅流程分离 应用与数据分离 服务与实现细节分离 解耦/拆分 抽象化 松耦合 容错设计 1 2 3 4 5 京东应用架构 应用架构 3 架构分析 应用架构 3 应用架构 基础架构 数据架构 架构分解原则

6、 应用架构 3 2. 垂直拆分 （不同业务拆分） 按业务域划分系统 如，商品系统 交易系统 3. 业务分片 （同业务分片） 按功能特点分开部署 如，秒杀系统 4. 水平拆分 （稳定与易变分离） 服务分层 功能与非功能分开 1. 水平扩展 （复制） 多机集群，提高并发能力 按业务分库 如，商品库，订单库 分库分表，提高数据容量 如，订单库按ID分库分表 冷热数据分离，历史数据 分离 读写分离 如，商品读库，商品写库 应用系统 高并发 大数据 稳定性 数据库 依赖原则 应用架构 3 2. 跨域弱依赖 跨业务域调用时，尽可能异步 弱依赖 6. 核心服务依赖 核心服务不依赖非核心服务 非核心服务可依赖

7、核心服务 条件：核心服务稳定 3. 基本服务依赖 基本服务不能向上依赖流程服务 组合服务、流程服务可以向下依赖 基本服务 条件：基本服务稳定 4. 非功能服务依赖 非功能服务不依赖功能服务 功能服务可依赖非功能服务 条件：非功能服务稳定 1. 依赖稳定部分 稳定部分不依赖易变部分 易变部分可以依赖稳定部分 要求：避免循环依赖 5. 平台服务依赖 平台服务不依赖上层应用 上层应用可依赖平台服务 条件：平台服务稳定 服务设计原则 技术架构 5 无状态 尽量不要把状态数据 保存在本机 接口调用幂等性 可复用 松耦合 可治理 复用粒度是有业务逻 辑的抽象服务，不是 服务实现细节 服务引用只依赖于服 务

8、抽象 跨业务域调用，尽可 能异步解耦 必须同步调用时，设 置超时和队列大小 相对稳定的基本服务 与易变流程服务分层 制订服务契约 服务可降级 服务可限流 服务可开关 服务可监控 白名单机制 基本服务 基础服务下沉、可复用。如时效、库存、价格计算等 基础服务自治，相互独立 基础服务的实现，要求精简、可水平扩展 基础服务实现物理隔离，包括基础服务相关的数据 应用架构实例：交易订单 应用架构 3 目 录 CONTENTS 架构愿景 业务架构 应用架构 数据架构 技术架构 618经验 数据架构设计原则 数据架构 4 2 4 5 6 数据架构 数据、应用分离 应用系统只依赖逻辑数据库 应用系统不直接访问

9、其它宿 主的数据库，只能通过服务 访问 数据读写分离 访问量大的数据库做读写分离 数据量大的数据库做分库分表 不同业务域数据库做分区隔离 重要数据配置备库； 用Mysql数据库 除成本因素外，Mysql的数据 库扩展性和支持高并发的能力 较强，公司研发和运维在这方 面积累了大量经验 合理使用缓存 数据库有能力支撑时，尽量不 要引入缓存 合理利用缓存做容灾 1 统一数据视图 保证数据的及时性、一致 性、准确性、完整性 3 数据异构 源数据和目标数据内容相同时， 做索引异构。如商品库不同维度 内容不同时，做数据库异构。如 订单买家库和卖家库。 数据架构 数据架构 4 数据架构实例：分布式索引系统

10、数据架构 4 数据架构实例：数据平台 数据架构 4 目 录 CONTENTS 架构愿景 业务架构 应用架构 数据架构 技术架构 618经验 基础架构 技术架构 5 系统运行时原则 技术架构 5 运行时 1、可监控 服务的TPS和RT是否符合SLA 是否出现超预期流量 2、应用可回滚，功能可降级 应用出现问题时，要求能回滚到 上一版本，或做功能开关或降级 3、在线扩容 超预期流量时，应用系统可选 择在线水平扩展 4、安全保证 确保系统的保密性和完整性 具有足够的防攻击能力 5、可容错 核心应用要求多活，避免单点 设计，并且自身有容错和修复 能力。故障时间TTR小 6、可故障转移 多机房部署，发生

11、故障时， 能即时切换 系统部署原则 技术架构 5 系统部署 N+1原则 确保为故障多搭建一套系统，避免 单点问题。例如，多机房部署、应 用系统集群、数据库主备等 功能开发与运维分开。系统开发完 成后，交给专业的运维团队管理和 运营。 系统新上线，要求支持“灰度” 发布，分步切流量，故障回滚 机房部署以业务域划分：基本服务 和数据库，相同业务域的服务器部 署在一起；不同业务域的服务器物 理隔离 业务子网 虚拟化部署 虚机部署：二级系统、三级系统 采用虚拟机部署，节省资源和管 理成本 虚拟化部署：一级系统应用服务 器，采用虚拟化部署 支持灰度发布 1 4 5 3 D-I-D原则 设计20倍的容量（

12、Design） 实现 3 倍的容量（Implement） 部署1.5倍的容量（Deploy） 2 目 录 CONTENTS 架构愿景 业务架构 应用架构 数据架构 技术架构 618经验 618经验 618经验 6 流量控制 监控 故障转移 机房带宽/交换机扩容 应用系统扩容 数据库扩容 分流 降级 限流 扩容 预案 线上压测 前期准备 618实战 硬件监控 应用系统监控 业务监控 安全监控 应用系统 数据库 软负载 DNS 0级系统预案评审 线上演练 交易订单憋单泄洪 履约系统憋单 页面系统压测 流量控制 618经验 6 1. 分流 应用：集群，无状态，提高访问量 数据：读写分离，提高性能 水

13、平扩展 应用：按业务域划分成不同子系统 数据：数据分区 业务分区 应用：不同业务类型分片 数据：分库分表，提高数据容量 分片 应用：分层，功能与非功能分开 数据：冷热数据分离 动静分离 商品读库，商品写库 商品库、交易库 秒杀系统从交易系统中分 离；非核心业务分离 业务流程层、应用层 2. 降级 页面降级 无法缓解大流量 无法缓解 大流量 业务功能降级 3. 限流 Nginx前端限流 京东研发的业务路由， 规则包括账户，IP，系统 调用逻辑等 应用系统限流 客户端限流 服务端限流 应用系统降级 1.动态页面降级到静态 2.整体降级到其他页面 3.页面部分内容 1.舍弃一些非关键业务， 如购物车

14、库存状态 1.降级一些下游系统，如 一次拆分暂停 1.远程服务降机到本地 缓存，如运费 数据降级 数据库限流 红线区，力保数据库 架构运行状态分析 618经验 6 目的：故障预测，故障隔离 功能： 显示应用之间的依赖关系 分析应用和服务的血缘和影响 根据依赖关系，分析应用的入出流量分配。 超预期流量时，方便定位问题 根据应用系统运行情况，计算应用风险值 根据服务sla、tps、rt和依赖关系，评估服 务风险值 全局风险评估，并动态更新，即时发现可 能的问题 风险评估 618经验 6 一、风险指数：R = Rp * Rs * Ra 其中，Rp发生故障可能性， Rs故障影响严重程度，Ra发现 和解决故障的能力，初始值为3。 1、Rp计算：Rp = p0 + p(血缘关系) 其中，p0 = x0 * 10 p(血缘关系) = x1*w1 + x2*w2 + . + xn*wn x = f（mem，cpu，tps，rt） 2、Rs计算：Rs = s0 + s(影响关系) 其中，s0 = s0 * 10 s(影响关系) = y1*b1 + y2*b2 + . + ym*bm y = f（系统分级） 二、修正后的风险指数：C = Cp * Rs * Ca Cp: 修正后发生故障可能性。