京东商城企业架构

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