京东应用架构设计

2014/7/181机要文档请勿外传京东应用架构设计吴博目录CONTENTS架构愿景业务架构应用架构数据架构技术架构618经验架构目标架构愿景11.高可用性自动化运维。整体系统可用性99.99%，单个系统可用性99.999%。全年故障时间整个系统不超过50分钟，单个系统故障不超过5分钟2.高可扩展性系统架构简单清晰，应用系统间耦合低，容易水平扩展，业务功能增改方便快捷3.低成本增加服务的重用性，提高开发效率，降低人力成本；利用成熟开源技术，降低软硬件成本；利用虚拟化技术，减少服务器成本4.多快好省构建超大型电商交易平台，兼顾效率和性能，达到高人效、高时效和低成本的目标质量要求1架构愿景质量要求概念完整性可测试性可支持性可维护性可重用性可用性互操作性可管理性性能可靠性可扩展性安全性易用性总体架构原则3架构愿景可用性可扩展性成本•N+1原则•版本可以回退•功能可开关•不过度设计•松耦合•抽象化•服务可重用•可水平扩展•容错设计•可监控•多维度拆分•采用同质化硬件•单一责任原则•使用成熟的技术•DID原则架构组成和关键点JD架构2业务架构应用架构数据架构技术架构解耦拆分抽象集成复用治理目录CONTENTS架构愿景业务架构应用架构数据架构技术架构618经验业务架构设计原则业务架构21.业务平台化•业务平台化，相互独立。如交易平台、仓储平台、物流平台、支付平台、广告平台等•基础业务下沉，可复用。如用户、商品、类目、促销、时效等2.核心业务、非核心业务分离•电商核心业务与非核心业务分离，核心业务精简（利于稳定），非核心业务多样化。如，主交易服务、通用交易服务3.隔离不同类型的业务•交易业务是签订买家和卖家之间的交易合同，需要优先保证高可用性，让用户能快速下单•履约业务对可用性没有太高要求，可以优先保证一致性•闪购业务对高并发要求很高，应该跟普通业务隔离4.区分主流程、辅流程•分清哪些是电商的主流程。运行时，优先保证主流程的顺利完成，辅流程可以采用后台异步的方式。避免辅流程的失败导致主流程的回滚。如，下单时，同步调用快照，异步通知台账、发票业务架构图架构架构2业务架构实例：基础业务下沉业务架构2目录CONTENTS架构愿景业务架构应用架构数据架构技术架构618经验应用架构设计原则应用架构3•一切以稳定为中心•架构尽可能简单、清晰•不过度设计•服务自治：服务能彼此独立修改、部署、发布和管理。避免引发连锁反应•集群容错：应用系统集群，避免单点•多机房容灾：多机房部署，多活架构原则3稳定性原则•跨域调用异步化：不同业务域之间尽量异步解耦。•非核心业务尽量异步化：核心、非核心业务之间，尽量异步解耦•必须同步调用时，需要设置超时时间和任务队列长度•应用抽象化：应用只依赖服务抽象，不依赖服务实现细节、位置•数据库抽象化：应用只依赖逻辑数据库，不需要关心物理库的位置和分片•服务器抽象化：应用虚拟化部署，不需要关心实体机配置，动态调配资源•稳定部分与易变部分分离•核心业务与非核心业务分离•电商主流程与辅流程分离•应用与数据分离•服务与实现细节分离解耦/拆分抽象化松耦合容错设计12345京东应用架构应用架构3架构分析应用架构3应用架构基础架构数据架构架构分解原则应用架构32.垂直拆分（不同业务拆分）按业务域划分系统如，商品系统交易系统3.业务分片（同业务分片）按功能特点分开部署如，秒杀系统4.水平拆分（稳定与易变分离）服务分层功能与非功能分开1.水平扩展（复制）多机集群，提高并发能力按业务分库如，商品库，订单库分库分表，提高数据容量如，订单库按ID分库分表冷热数据分离，历史数据分离读写分离如，商品读库，商品写库应用系统高并发大数据稳定性数据库依赖原则应用架构32.跨域弱依赖•跨业务域调用时，尽可能异步弱依赖6.核心服务依赖•核心服务不依赖非核心服务•非核心服务可依赖核心服务•条件：核心服务稳定3.基本服务依赖•基本服务不能向上依赖流程服务•组合服务、流程服务可以向下依赖基本服务•条件：基本服务稳定4.非功能性服务依赖•非功能性服务不依赖功能性服务•功能性服务可依赖非功能性服务•条件：非功能性服务稳定1.依赖稳定部分•稳定部分不依赖易变部分•易变部分可以依赖稳定部分•要求：避免循环依赖5.平台服务依赖•平台服务不依赖上层应用•上层应用可依赖平台服务•条件：平台服务稳定服务设计原则技术架构5无状态•尽量不要把状态数据保存在本机•接口调用幂等性可复用松耦合可治理•复用粒度是有业务逻辑的抽象服务，不是服务实现细节•服务引用只依赖于服务抽象•跨业务域调用，尽可能异步解耦•必须同步调用时，设置超时和队列大小•相对稳定的基本服务与易变流程服务分层•制订服务契约•服务可降级•服务可限流•服务可开关•服务可监控•白名单机制基本服务•基础服务下沉、可复用。如时效、库存、价格计算等•基础服务自治，相互独立•基础服务的实现，要求精简、可水平扩展•基础服务实现物理隔离，包括基础服务相关的数据应用架构实例：交易订单应用架构3目录CONTENTS架构愿景业务架构应用架构数据架构技术架构618经验数据架构设计原则数据架构42456数据架构数据、应用分离•应用系统只依赖逻辑数据库•应用系统不直接访问其它宿主的数据库，只能通过服务访问数据读写分离•访问量大的数据库做读写分离•数据量大的数据库做分库分表•不同业务域数据库做分区隔离•重要数据配置备库；用Mysql数据库•除成本因素外，Mysql的数据库扩展性和支持高并发的能力较强，公司研发和运维在这方面积累了大量经验合理使用缓存•数据库有能力支撑时，尽量不要引入缓存•合理利用缓存做容灾1统一数据视图•保证数据的及时性、一致性、准确性、完整性3数据异构•源数据和目标数据内容相同时，做索引异构。如商品库不同维度•内容不同时，做数据库异构。如订单买家库和卖家库。数据架构数据架构4数据架构实例：分布式索引系统数据架构4数据架构实例：数据平台数据架构4目录CONTENTS架构愿景业务架构应用架构数据架构技术架构618经验基础架构技术架构5系统运行时原则技术架构5运行时1、可监控•服务的TPS和RT是否符合SLA•是否出现超预期流量2、应用可回滚，功能可降级•应用出现问题时，要求能回滚到上一版本，或做功能开关或降级3、在线扩容•超预期流量时，应用系统可选择在线水平扩展4、安全保证•确保系统的保密性和完整性•具有足够的防攻击能力5、可容错•核心应用要求多活，避免单点设计，并且自身有容错和修复能力。故障时间TTR小6、可故障转移•多机房部署，发生故障时，能即时切换系统部署原则技术架构5系统部署N+1原则•确保为故障多搭建一套系统，避免单点问题。例如，多机房部署、应用系统集群、数据库主备等•功能开发与运维分开。系统开发完成后，交给专业的运维团队管理和运营。•系统新上线，要求支持“灰度”发布，分步切流量，故障回滚•机房部署以业务域划分：基本服务和数据库，相同业务域的服务器部署在一起；不同业务域的服务器物理隔离业务子网虚拟化部署•虚机部署：二级系统、三级系统采用虚拟机部署，节省资源和管理成本•虚拟化部署：一级系统应用服务器，采用虚拟化部署支持灰度发布1453D-I-D原则•设计20倍的容量（Design）•实现3倍的容量（Implement）•部署1.5倍的容量（Deploy）2目录CONTENTS架构愿景业务架构应用架构数据架构技术架构618经验618经验618经验6流量控制监控故障转移机房带宽/交换机扩容应用系统扩容数据库扩容分流降级限流扩容预案线上压测前期准备618实战硬件监控应用系统监控业务监控安全监控应用系统数据库软负载DNS0级系统预案评审线上演练交易订单憋单泄洪履约系统憋单页面系统压测流量控制618经验61.分流应用：集群，无状态，提高访问量数据：读写分离，提高性能水平扩展应用：按业务域划分成不同子系统数据：数据分区业务分区应用：不同业务类型分片数据：分库分表，提高数据容量分片应用：分层，功能与非功能分开数据：冷热数据分离动静分离商品读库，商品写库商品库、交易库秒杀系统从交易系统中分离；非核心业务分离业务流程层、应用层2.降级页面降级无法缓解大流量无法缓解大流量业务功能降级3.限流Nginx前端限流京东研发的业务路由，规则包括账户，IP，系统调用逻辑等应用系统限流客户端限流服务端限流应用系统降级1.动态页面降级到静态2.整体降级到其他页面3.页面部分内容1.舍弃一些非关键业务，如购物车库存状态1.降级一些下游系统，如一次拆分暂停1.远程服务降机到本地缓存，如运费数据降级数据库限流红线区，力保数据库架构运行状态分析618经验6目的：故障预测，故障隔离功能：•显示应用之间的依赖关系•分析应用和服务的血缘和影响•根据依赖关系，分析应用的入出流量分配。超预期流量时，方便定位问题•根据应用系统运行情况，计算应用风险值•根据服务sla、tps、rt和依赖关系，评估服务风险值•全局风险评估，并动态更新，即时发现可能的问题风险评估618经验6一、风险指数：R=Rp*Rs*Ra其中，Rp发生故障可能性，Rs故障影响严重程度，Ra发现和解决故障的能力，初始值为3。1、Rp计算：Rp=p0+p(血缘关系)其中，p0=x0*10p(血缘关系)=x1*w1+x2*w2+...+xn*wnx=f（mem，cpu，tps，rt）2、Rs计算：Rs=s0+s(影响关系)其中，s0=s0*10s(影响关系)=y1*b1+y2*b2+...+ym*bmy=f（系统分级）二、修正后的风险指数：C=Cp*Rs*CaCp:修正后发生故障可能性。根据618预案评估Ca:修正后发现和解决故障能力。根据618预案评估三、根据修正值，迭代计算风险指数风险评估：利用应用之间的关系，评估每个应用可能的风险大小。计算方法：容量规划618经验6•容量指标选择•压测•服务关系分析•SLA制定•依赖治理•监测容量指标数据•为扩容、降级、降级提供依据•下单调用链分析：每笔交易对应tps•单量预测：根据历史数据，预测618单量•根据调用链模型，估算各节点业务峰值下单调用链下单调用链模型架构总结总结7复用抽象集成治理解耦/拆分应用技术数据业务1.电商业务域2.核心、非核心业务3.主流程、辅流程4.业务规则分离1.读写分离2.按业务域分库3.分库分表4.冷热数据分离1.应用集群水平扩展2.按业务域分离应用3.按功能分离应用4.按稳定性分离应用1.服务抽象，服务调用不依赖实现细节2.应用集群抽象，应用位置透明1.服务器资源抽象。应用只依赖虚拟化资源1.数据库抽象。应用只依赖逻辑数据库1.易变依赖稳定2.流程服务依赖基础服务3.非核心应用依赖核心应用1.功能开发与运维分离2.业务子网3.分离功能、非功能型需求1.同步调用时，设置超时和任务队列长度2.利用回调异步化3.利用MQ、缓存、中间件异步化1.跨业务域调用异步2.非核心业务异步1.数据库只能通过服务访问2.统一的元数据管理3.统一的主数据管理1.N+1设计2.灰度部署3.版本可回滚4.可监控5.可容灾1.服务自治2.SLA3.可水平扩展4.可限流5.服务可降级6.容错设计7.服务白名单1.重要数据做主备2.合理利用缓存容灾3.双写要做补偿1.代码提共通，可复用2.非功能性服务，可复用3.基础配置、基础软件复用1.基础业务下沉，可复用1.复用粒度是有业务逻辑的抽象服务1.厘清业务边界、作用域谢谢！Thankyou!北京市朝阳区北辰西路8号北辰世纪中心A座6层6FBuildingA,North-StarCenturyCenter,8BeichenWestStreet,ChaoyangDistrict,[e-mail]谢谢！Thankyou!北京市朝阳区北辰西路8号北辰世纪中心A座6层6FBuildingA,North-StarCenturyCenter,8BeichenWestStreet,ChaoyangDistrict,Beijing1