京东应用架构设计与治理

1 . 京东应用架构设计 吴博 2014/7/18 机要文档 请勿外传 1 

2 .目录 CONTENTS 架构愿景 业务架构 应用架构 数据架构 技术架构 618经验 

3 . 1 架构愿景 架构目标 4. 多快好省 构建超大型电商交易平台，兼 顾效率和性能，达到高人效、 3. 低成本 高时效和低成本的目标 增加服务的重用性，提高开发效率， 降低人力成本；利用成熟开源技术， 2. 高可扩展性 降低软硬件成本；利用虚拟化技术， 减少服务器成本 系统架构简单清晰，应用系统间耦合 低，容易水平扩展，业务功能增改方 1. 高可用性 便快捷 自动化运维。整体系统可用性99.99%，单个 系统可用性99.999%。全年故障时间整个系统 不超过50分钟，单个系统故障不超过5分钟 

4 .1 架构愿景 质量要求 可用性 互操作性 可管理性 性能 可靠性 可扩展性 安全性 概念 完整性 可维护性 质量 易用性 要求 可重用性 可支持性 可测试性 

5 .3 架构愿景 总体架构原则 可用性 • N+1原则 • 版本可以回退 • 功能可开关 • 容错设计 • 使用成熟的技术 • 可监控 • 多维度拆分 • 不过度设计 • 松耦合 • 抽象化 • 服务可重用 • 可水平扩展 • 单一责任原则 • 采用同质化硬件 • DID原则 可扩展性 成本 

6 .2 JD架构 架构组成和关键点 业务架构 应用架构 数据架构 技术架构 解耦 拆分 抽象 集成 复用 治理 

7 .目录 CONTENTS 架构愿景 业务架构 应用架构 数据架构 技术架构 618经验 

8 .2 业务架构 业务架构设计原则 1. 业务平台化 2. 核心业务、非核心业务分离 • 业务平台化，相互独立。 如交易平 • 电商核心业务与非核心业务分离， 台、仓储平台、物流平台、支付平 核心业务精简（利于稳定），非核 台、广告平台等 心业务多样化。如，主交易服务、 • 基础业务下沉，可复用。如用户、 通用交易服务 商品、类目、促销、时效等 4. 区分主流程、辅流程 3. 隔离不同类型的业务 • 分清哪些是电商的主流程。运行时， • 交易业务是签订买家和卖家之间的 优先保证主流程的顺利完成，辅流 交易合同，需要优先保证高可用性， 程可以采用后台异步的方式。避免 让用户能快速下单 辅流程的失败导致主流程的回滚。 • 履约业务对可用性没有太高要求， 如，下单时，同步调用快照，异步 可以优先保证一致性 通知台账、发票 • 闪购业务对高并发要求很高，应该 跟普通业务隔离 

9 .2 架构架构 业务架构图 

10 .2 业务架构 业务架构实例：基础业务下沉 

11 .目录 CONTENTS 架构愿景 业务架构 应用架构 数据架构 技术架构 618经验 

12 . 3 应用架构 应用架构设计原则 2 解耦/拆分 • 稳定部分与易变部分分离 • 核心业务与非核心业务分离 • 电商主流程与辅流程分离 • 应用与数据分离 1 稳定性原则 • 服务与实现细节分离 3 抽象化 • 一切以稳定为中心 • 应用抽象化：应用只依赖服务抽象， • 架构尽可能简单、清晰 不依赖服务实现细节、位置 • 不过度设计 • 数据库抽象化：应用只依赖逻辑数据 库，不需要关心物理库的位置和分片 • 服务器抽象化：应用虚拟化部署，不 需要关心实体机配置，动态调配资源 架构原则 5 容错设计 34 松耦合 • 服务自治：服务能彼此独立修改、 • 跨域调用异步化：不同业务域之间 部署、发布和管理。避免引发连 尽量异步解耦。 锁反应 • 非核心业务尽量异步化：核心、非 • 集群容错：应用系统集群，避免 核心业务之间，尽量异步解耦 单点 • 必须同步调用时，需要设置超时时 • 多机房容灾：多机房部署，多活 间和任务队列长度 

13 .3 应用架构 京东应用架构 

14 .3 应用架构 架构分析 应用架构 数据架构 基础架构 

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

16 .3 应用架构 依赖原则 2. 跨域弱依赖 • 跨业务域调用时，尽可能异步 弱依赖 1. 依赖稳定部分 3. 基本服务依赖 • 稳定部分不依赖易变部分 • 基本服务不能向上依赖流程服务 • 易变部分可以依赖稳定部分 • 组合服务、流程服务可以向下依赖 • 要求：避免循环依赖 基本服务 • 条件：基本服务稳定 6. 核心服务依赖 4. 非功能性服务依赖 • 核心服务不依赖非核心服务 • 非功能性服务不依赖功能性服务 • 非核心服务可依赖核心服务 • 功能性服务可依赖非功能性服务 • 条件：核心服务稳定 • 条件：非功能性服务稳定 5. 平台服务依赖 • 平台服务不依赖上层应用 • 上层应用可依赖平台服务 • 条件：平台服务稳定 

17 .5 技术架构 服务设计原则 无状态 可复用 松耦合 可治理 • 尽量不要把状态数据 • 复用粒度是有业务逻 • 跨业务域调用，尽可 • 制订服务契约 保存在本机 辑的抽象服务，不是 能异步解耦 • 服务可降级 • 接口调用幂等性 服务实现细节 • 必须同步调用时，设 • 服务可限流 • 服务引用只依赖于服 置超时和队列大小 • 服务可开关 务抽象 • 相对稳定的基本服务 • 服务可监控 与易变流程服务分层 • 白名单机制 • 基础服务下沉、可复用。如时效、库存、价格计算等 • 基础服务自治，相互独立 基本服务 • 基础服务的实现，要求精简、可水平扩展 • 基础服务实现物理隔离，包括基础服务相关的数据 

18 .3 应用架构 应用架构实例：交易订单 

19 .目录 CONTENTS 架构愿景 业务架构 应用架构 数据架构 技术架构 618经验 

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

21 .4 数据架构 数据架构 

22 .4 数据架构 数据架构实例：分布式索引系统 

23 .4 数据架构 数据架构实例：数据平台 

24 .目录 CONTENTS 架构愿景 业务架构 应用架构 数据架构 技术架构 618经验 

25 .5 技术架构 基础架构 

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

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

28 .目录 CONTENTS 架构愿景 业务架构 应用架构 数据架构 技术架构 618经验 

29 .6 618经验 618经验 618实战 前期准备 分流 机房带宽/交换机扩容 应用系统扩容 降级 流量控制 扩容 限流 数据库扩容 硬件监控 应用系统监控 0级系统预案评审 业务监控 监控 预案 线上演练 安全监控 应用系统 交易订单憋单泄洪 数据库 故障转移 线上压测 履约系统憋单 软负载 页面系统压测 DNS