1、2014/6/29 1 机要文档 请勿外传 京东架构 设计 目 录 CONTENTS 架构愿景 JD架构 架构原则 618经验 架构 目标 架构愿景 1 1. 高 可用性 自动化运维。整体 系统可用性 99.99%，单个系统可用性 99.999%。全年故障时间整个系统不 超过 50分钟， 单个 系统故障不 超过 5分钟 2. 高可扩展性 系统架构简单清晰，应用系统间耦合低，容易水平扩展，增加和修改业务功能方便快捷 3. 低成本 服务 的重用 性高，提高开发效率， 降低人员成本； 使用成熟开源技术，降低系统成本；利用虚拟化技术，减少服务器成本 4. 多快好省 构建超大型 电商交易 平台 ，兼顾效
2、率和 性能， 达到 高人效、高时效和低成本的目的 架构愿景维 恩图 2 架构愿景 可用性 可扩展性 成本 省 高人效 高时效 低成本 好 快 多 高可用性 高可扩展性 低成本 品类丰富 功能多 交易量大 网站 速度快 订单 生产快 需求响应 快 质量要求 1 架构愿景 质量 要求 概念 完整性 可测试性 可支持性 可维护性 可重用性 可用性 互 操作性 可管理 性 性能 可靠性 可 伸缩性 安全 性 易用性 总体架构原则 3 架构愿景 可用性 可扩展性 成本 N+1原则 版本可以回退 功能可开关 不过度设计 服务可重用 可水平扩展 异步解耦 无状态 虚拟化 容错设计，故障控制 可监控 多维度拆
3、分 减少预先设计，不过度设计 采用同质化硬件 DID原则 单一责任原则 采用成熟的技术 目 录 CONTENTS 架构愿景 JD架构 架构原则 618经验 业务架构 JD架构 2 京东 IT架构 JD架构 2 架构分解 JD架构 2 应用 架构 基础 架构 数据 架构 应用架构图 JD架构 3 交易中心 JD架构 2 数据架构 JD架构 2 数据架构 JD架构 2 基础架构 JD架构 2 目 录 CONTENTS 架构愿景 JD架构 架构原则 618经验 总体原则 架构 原则 3 业务平台化 1. 基础业务下沉 2. 可复用 容错设计 1. 核心 服务 自治 ，服务 能够被彼此独立的修改、部署
4、、发布新版本和 管理 2. 应用系统集群，可水平扩展 3. 多 机房部署，多活 总体原则 4 3 1 异步化 1. 不同业务域之间尽量异步化，如交易与支付之间，履约与仓储之间 2. 非核心 业务尽量异步化 3. 应用 系统尝试 SEDA方式异步化 3 抽象 化 1. 服务抽象化，引用不需要关心服务实现 2. 应用集群抽象化，集群位置 透明 3. 数据库抽象化 ， 应用程序用 逻辑 SQL操作数据库 4. 服务器抽象化 ，应用系统不需要关心实体机的位置或数量，只关心资源 2 服务设计原则 架构原则 3 2. 重 用原则 1. 基本原则 3. 松耦合原则 服务引用时，只依赖于服务抽象 ， 不依赖于
5、服务实现 复用 粒度 是 有业务逻辑的 抽象服务，不是 服务 实现细节 每个基本服务相对独立，服务间通信尽可能少 基本服务构件，要求精简、自治、可水平扩展，其他服务可多样化 基本服务不依赖其它业务域服务，组合 服务、流程 服务可跨域调用 基本服务和 数据 在不同业务域做泳道隔离，不跨域调用 跨 业务域的 服务调用， 尽可能用异步解耦 核心业务不依赖非核心业务，非核心 业务 可降级 降低紧耦合：同步调用时，设置超时时间和最大并发数 不同特点的服务解耦：需要快速 响应的服务（如订单交易）与 其它 的 解耦 ； 相对稳定的服务（如基本服务）与变化频繁的（如流程服务）分层 4. 服务治理 原则 容量规
6、划，为每个服务制定 SLA，保证可 计量的性能 达到所定义的品质 对于 超容量规划的调用，要有限 流 设计 服务 需要设计成可回滚、可禁用、可监控、多活动 点 超负荷时，对于非核心服务调用应有降级机制 运行 时 原则 架构 原则 3 2、应用可回滚，功能可降级 当 应用出现问题时，要求能回滚到上一个的版本，也可以做功能开关或降级 6、故障转移 多机房部署，发生故障时，能即时切换 3、应用可水平扩展 当访问 量大时，应用系统需要能在线扩容 4、可监控 重要 服务需要埋点监控，帮助即时发现和解决问题 1、 SLA（服务品质协议） 服务方根据各引用方的需求，给出能正常提供服务的 TPS和 RT，并有
7、分流、限流和降级 机制 5、可容错 核心应用要求多活，避免单点设计，并且自身有容错 和修复 能力。故障时间 TTR小 系统部署原则 架构原则 3 系统部署 N+1原则 确保为故障多搭建一套系统，避免单点问题。例如，多机房部署、应用系统集群、数据库主备等 系统新上线，要求支持“灰度”发布，分步切流量，故障回滚 对于基本服务和数据库，相同业务域的服务器部署在一起；不同业务域的服务器物理隔离 按业务 域部署 D-I-D原则 设计（ Design） 20倍的 容量；实现 （ Implement） 3倍的 容量；部署 （ Deploy） 1.5倍的容量 支持灰度发布 1 3 4 2 数据架构原则 架构原
8、则 3 1 2 3 4 数据 原则 数据与应用分离 1. 数 据库位置透明，应用系统只依赖逻辑数据库； 2. 不直接访问其它宿主的数据库，只能通过服务访问 数据库主备从 1. 重要数据配置备库； 2. 流量大的数据库配置从库，做读写分离； 3. 数据量大的数据库做分库分表 ;4. 不同业务域数据库做分区隔离 用 Mysql数据库 除成本因素外， Mysql系列的数据库扩展性和支持高并发的能力较强，公司研发和运维在这方面积累了大量经验 不过度依赖缓存 数据库有较大容量时，尽量不要引入缓存。合理使用内存，可以提高系统的扩展性；但过度依赖，会降低系统的可用性 目 录 CONTENTS 架构愿景 JD
9、架构 架构原则 618经验 架构愿景 618经验 4 流量控制 监控 故障转移 机房带宽 /交换机扩容 应用系统扩容 数据库扩容 分流 降级 限流 扩容 预案 线 上压测 前期准备 618实战 硬件监控 应用 系统监控 业务监控 安全监控 应用系统 数据库 软负载 DNS 预案评审 线 上演练 交易订单憋坝泄洪 履约系统憋坝 页面 系统压测 流 控措施 618经验 4 1. 分流 应用：集群，无状态，提高访问量 数据 ：读写 分离，提高性能 水平扩展 应用 ：按业务域划分成不同子系统 数据 ：数据 分区 业务分区 应用：不同业务类型分片 数据 ：分库分表，提高数据容量 分片 应用：分层，功能
10、与非功能分开 数据 ：冷热数据 分离 动静分离 商品读库，商品写库 商品库、交易库 将交易系统中的秒杀以及非重要系统剥离出去 业务流程层、应用层 2. 降级 页面降级 无法缓解大流量 无法缓解 大流量 业务功能降级 3. 限流 Nginx前端限流 京东研发的业务路由，规则包括账户 ， IP，系统调用 逻辑等 应用系统限流 客户端限流 服务端限流 应用系统降级 1. 动态页面降级到静态 2. 整体 降级到其他页面 3. 页面 部分内容 1. 舍弃一些非 关键 业务，如购物车库存状态 1. 降级一些下游系统，如一次拆分暂停 1. 远程 服务降机到本地缓存，如运费 数据 降级 数据库 限 流 红线区
11、，力保数据库 监控分析 618经验 4 带运行状态的架构： 显示应用之间的依赖关系 分析应用和服务的血缘和影响 根据依赖关系，分析应用的入出流量分配。超预期流量时，方便定位问题 根据应用系统运行情况，计算应用风险值 根据服务 sla、 tps、 rt和依赖关系，评估服务风险值 全局风险评估，并动态更新，即时发现可能的问题 谢谢 ！ Thank you! 北京市朝阳区北辰西路 8号北辰世纪中心 A座 6层 6F Building A, North-Star Century Center, 8 Beichen West Street, Chaoyang District, Beijing 100101 T. 010-5895 1234 F. 010-5895 1234 E. 谢谢 ！北京市朝阳区北辰西路 号北辰世纪中心 座 层
