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