简介京东商城超大型电商系统架构设计方案是一份面向中大型电商平台技术决策者、架构师及高级开发者的架构参考文档系统梳理了构建高并发、高可用、可扩展交易平台的核心思路。内容涵盖架构目标、业务与应用设计原则、数据架构、技术架构总览及运维原则并针对自营、平台、三方等混合模式给出拆分与隔离策略适用于电商系统规划、微服务改造及性能优化场景。整份资源为一个PDF文档大小2.51MB内容完整可直接阅读、打印或作为团队培训材料。内容预览覆盖应用架构分层、服务依赖原则、水平扩展与垂直拆分等关键方法论配有清晰目录导航方便按需查阅。目前已有186位读者学习下载适合需要借鉴一线电商架构经验的读者快速获取体系化设计方案。1. 超大型电商系统架构设计先从京东的分层逻辑里抄判断标准很多电商团队做架构第一反应是搜微服务拆分方案、缓存集群、负载均衡配置真正动手时才发现难的不是这些技术选型而是不知道下一步该拆什么。京东这份超大型电商系统架构设计方案把架构目标、业务架构、应用架构、数据架构、技术架构总览和系统运维原则全部收进了一套设计原则里而且给出了“什么时候拆、拆到什么粒度、拆完怎么治理”的判断标准。京东系统本身融合自营、商城、三方平台等模式和国内中小型电商的业务形态更接近比纯平台型电商方案更有对照价值。适合正在做系统重构或微服务改造的后端团队、技术负责人拿来做架构设计参考也适合刚接触电商领域的人理解一套交易系统到底是怎么分层立起来的。2. 业务架构设计原则四组判断把电商域的边界划清楚业务架构是整份方案里最先落地的判断部分。京东商城系统融合了自营模式、商城模式、三方平台等模式和淘宝、天猫以商城模式为主的电商系统相比业务模式要丰富很多还包括了 WMS、TMS、OMS 的环节。所以中小型电商公司要学架构学京东这套业务架构更贴近自己因为业务模式相近拆起来才有参考价值。这一章的四组判断决定了后续应用架构和服务架构的拆分方向。2.1 业务平台化先把可复用的基础业务沉下去方案里明确写了“业务平台化相互独立”交易平台、仓储平台、物流平台、支付平台、广告平台各自独立同时把用户、商品、类目、促销、时效这类基础业务下沉为可复用的公共能力。言下之意是业务平台化不是简单地把系统拆成多个项目而是先识别哪些能力被多个业务场景共同使用把这些能力沉淀成基础服务再让交易、仓储、物流等业务平台各自演进。实际落地时我会按四步走先把所有业务流程列成一张域清单再对每个域标注“被多少个上层场景调用”然后标注变更频率最后根据“被复用程度高 变更频率低”这两个条件判断是否下沉为基础业务。下面这张表是我常用的判断矩阵业务域被上层场景复用数变更频率处理结论用户中心高多个业务平台使用低下沉为基础业务商品中心高交易/搜索/推荐都要用中下沉为基础业务促销中心中营销场景较多高视复用范围做成独立平台交易平台低交易主链路使用高保留在上层业务平台业务平台化最容易出的问题是下沉之后没定依赖规则导致基础服务和上层应用互相依赖。这个问题放在第 5 章专门展开。这里只需要记住一点下沉是手段单向依赖才是目标。2.2 核心业务与非核心业务分离精简链路才能保证稳定方案里指出“核心业务精简利于稳定非核心业务多样化”并举例区分了主交易服务和通用交易服务。核心链路指的是能让用户完成“浏览商品 — 下单 — 支付成功”的最小集合非核心业务是围绕这个闭环展开的扩展能力。核心链路保持精简意味着参与主链路的节点越少故障面就越小非核心业务追求多样化可以快速迭代即使出问题也不影响主交易。判断一个功能该不该进核心链路我常用一个非常直接的问题把这个功能关掉交易闭环还能不能成立能成立就不是核心闭环的一部分不能成立就必须放进核心链路。按这个标准把业务分完后核心业务走严格的上线评审和灰度流程非核心业务可以保持更短的发布周期。方案里的“主交易服务、通用交易服务”就是这么分工的主交易服务做最精简的下单链路通用交易服务承接扩展出来的多样化交易场景。2.3 区分主流程与辅流程下单时同步做快照异步通知台账方案原文是“运行时优先保证主流程的顺利完成辅流程可以采用后台异步的方式。避免辅流程的失败导致主流程的回滚。如下单时同步调用快照异步通知台账、发票。”这一段是整个方案里最实操的部分。主流程是用户在下单那一刻必须等待结果的动作比如校验库存、生成订单快照辅流程是围绕订单发生但不需要用户等待的动作比如写台账、开发票、发消息。同步调用快照的意义在于订单详情页的数据可能来自多个服务如果下单时不留一份快照后续商品改价、标题修改历史订单就失真了。而台账、发票这类动作晚几分钟处理并不影响用户体验放进消息队列异步消费失败还能重试不会让整个下单事务跟着回滚。我给团队落地时用这么一张判断矩阵判断维度主流程辅流程用户感知程度用户直接等待结果用户无感知数据一致性要求强一致最终一致失败影响订单异常阻断交易可补偿、可重试典型示例订单快照、库存扣减台账通知、发票、消息推送落地步骤是先画出下单时序图把每个调用标成同步或异步凡是用户必须等待结果才能进入下一步的留在同步主流程台账、发票、消息推送这类动作一律丢进 MQ消费失败进重试队列再给异步任务独立的队列和连接池避免任务积压后反过来拖数据库。2.4 隔离不同类型的业务交易、履约、闪购不能共用一套资源池方案里有一段容易被忽略的话“交易业务是签订买家和卖家之间的交易合同需要优先保证高可用性让用户能快速下单履约业务对可用性没有太高要求可以优先保证一致性闪购业务对高并发要求很高应该跟普通业务隔离。”这说明不同类型的业务稳定性诉求是不同的硬把它们挤在同一个集群里会互相拖垮。具体拆的时候我按三档处理交易类业务优先保证高可用独立部署核心服务独立集群履约类业务允许异步和排队优先保证数据一致闪购、秒杀这类瞬时流量巨大的业务单独拆系统、单独限流、单独监控。判断标准是看峰值流量和日常流量的倍数关系比如峰值达到日常流量的十倍以上就应当列入隔离对象。业务类型优先目标隔离级别交易业务高可用让用户快速下单独立部署核心服务独立集群履约业务数据一致性允许异步队列削峰闪购业务高并发独立集群独立限流策略这个原则落在应用架构上就是第 3 章要讲的“业务分片”。业务隔离是分片的前置判断分片是隔离的物理实现。3. 应用架构分层与拆分从表现层到服务层四个拆分动作的顺序不能乱业务边界划完之后下一层是应用架构。方案给出的应用分层是表现层、业务流程层、服务层同时把质量层、数据架构层、治理层放在服务治理的位置。拆分动作则有四个水平扩展、垂直拆分、业务分片、水平拆分。这一章把分层和四个拆分动作放在一起讲因为分层决定拆分的形态拆分动作决定系统长成什么样。3.1 应用架构分层表现层、业务流程层、服务层各管一段方案里的分层结构很明确。表现层包含首页、列表页、详情页业务流程层包含商品系统、交易系统、订单系统、财务系统、物流系统等服务层包含商品服务、交易服务、订单服务、财务服务、物流服务。表现层只负责展示和交互业务流程层负责编排业务系统服务层沉淀可复用的基础能力治理层负责服务质量、数据架构和治理规则。我习惯用一个下单场景来解释这条链路用户在首页看到商品表现层点进详情页表现层点击下单后进入交易系统业务流程层交易系统调用交易服务服务层完成订单创建订单服务返回结果监控系统记录这次调用的 RT 和成功率质量层。每一层都只和相邻层通信禁止表现层直接调用服务实现也禁止业务系统之间互相访问对方的数据库。落地的第一步是画一张“页面 — 系统 — 服务”三层归属表把当前代码里的模块全部归位第二步是梳理调用方向所有跨层调用必须从上往下第三步是禁止反向调用和横向调用数据库。分层定清楚后面做水平扩展和垂直拆分才有边界可言。3.2 四个拆分动作水平扩展、垂直拆分、业务分片、水平拆分方案对四个拆分动作的描述很精炼水平扩展也就是复制的能力应用系统实现多机集群、提升并发能力数据库进行读写分离如商品读库、商品写库。垂直拆分指不同业务系统的拆分如商品系统、交易系统数据库同样拆成商品库、订单库。业务分片同业务进行分片比如秒杀系统、常规下单系统分开数据库方面把订单表按 ID 取模运算后分库分表。水平拆分服务层面功能与非功能分开稳定业务与易变业务分开数据库方面冷热数据分离、历史数据分离。这里的关键是四个动作是有顺序的。我一般建议先做水平扩展解决容量瓶颈再做垂直拆分解决业务耦合然后对热点业务做分片解决同类流量冲突最后做水平拆分解决冷热数据和稳定性隔离。顺序反了就会陷入“还没复制就先分库”的尴尬。拆分动作应用层面操作数据层面操作典型场景水平扩展多机集群、提升并发读写分离商品读库、商品写库垂直拆分按业务域拆系统按业务域拆库商品系统、交易系统商品库、订单库业务分片同业务拆多套分库分表秒杀系统、常规下单系统订单表按 ID 取模水平拆分功能与非功能分离冷热数据分离稳定业务与易变业务历史订单归档这四个动作不是只做一次。业务发展到新的规模往往要再走一轮“扩展 → 垂直 → 分片 → 水平”的循环。3.3 以订单系统为例从读写分离到分库分表的落地路径拿订单系统走一遍比较容易理解四个拆分动作怎么配合。假设现在订单库是单库单表读写混合高峰期写库压力大。第一步做读写分离。订单写库保持主库订单读库承接查询请求。这里要注意还有读写延迟刚下单的订单在列表里可能查不到需要业务侧容忍秒级延迟或者关键位置强制走主库。第二步做垂直拆分。把订单库和支付流水库分开再到把订单库和库存库分开。这一步是为了让不同业务域的数据库故障不互相影响。第三步做业务分片。订单表按订单 ID 或用户 ID 取模分成 16 个库路由规则写进数据库中间件应用层无感知。第四步做水平拆分。半年内的订单留在热库超过半年的订单归档到历史订单库冷热数据彻底分离。这里有个血泪经验是分片键的选择。如果用户端高频查询是“我的订单”优先按用户 ID 分片如果运营端是按订单号查询订单号到分片号的映射就必须提前设计。两边都要强需求时按数据架构设计里的“索引异构”做一张映射表订单号关联用户 ID再定位分片。提示分片键一旦定下来后续跨分片查询会很难做。上线前先用真实查询模板把走查跑一遍确认所有高频查询都能命中分片键。3.4 拆分完成后的检查清单怎么确定拆对了拆分完成不等于架构就稳定了我一般用下面这张检查清单做验收检查项拆前现象拆后验证商品系统和交易系统耦合商品改版常导致下单模块变更依赖检查工具查不到反向调用秒杀流量冲击常规下单大促时常规订单 P99 明显升高秒杀分片独立后常规链路 P99 回到基线历史数据拖慢热查询订单列表分页越来越慢热库查询 P99 达标历史库独立读写分离后读到旧数据列表查不到刚下的单明确读写延迟阈值主流程按需走主库这张清单要保留下来作为后续每次上线和扩容的回归项。架构拆分不是一次性动作每一次发布都可能把边界重新搅浑。4. 服务设计与技术选型无状态、幂等、可治理组件按层配应用拆分完成之后剩下的关键是把服务设计和技术组件配起来。方案里的服务设计原则有四个无状态、可复用、松耦合、可治理。技术架构总览则把组件分成基本平台、集成层、质量层三个层次。这一章把服务原则和组件选型放在一起讲是因为服务怎么设计直接决定组件怎么配。4.1 服务设计四原则无状态、可复用、松耦合、可治理无状态是水平扩展的前提。方案原文是“尽量不要把状态数据保存在本机接口调用幂等性”。只有服务无状态请求落到哪个节点都能处理扩容才没有负担。状态数据要外置到 Redis、数据库这类外部存储接口要做成幂等重复提交和重试不产生重复订单。可复用指的是复用有业务逻辑的抽象服务而不是复用实现细节。服务引用只依赖服务抽象不依赖具体实现位置和方式。这样实现换了调用方不用改。松耦合要求跨业务调用尽量异步解耦。必须同步调用时设置超时和队列大小防止下游故障拖死上游。稳定服务和易变流程要分层基本服务下沉流程服务在上层编排。可治理是服务上线的底线。方案提到了服务契约、可降级、可限流、可开关、可监控、白名单机制。落地时每个服务都要有一份明确的契约定义和降级配置。拿一个下单服务的配置举例service: name: trade-order-service contract: POST /api/v1/orders circuit_breaker: enabled: true qps_threshold: 200 fallback_mode: degrade-to-checkout-fallback rate_limit: qps: 1000 queue_size: 256 monitor: sla_target_rt_ms: 200 alert_on_qps_spike: true这段配置的逻辑是trader-order-service 对外提供 POST /api/v1/orders 这个契约单机 QPS 超过 200 时熔断器打开请求落到降级接口 degrade-to-checkout-fallback限流上限是单机 1000 QPS同步等待队列 256监控以 200ms 为 SLA 目标QPS 出现尖峰时告警。这里的 yaml 格式只是示意不是某个中间件的官方配置但字段含义是通用的。实际接入配置中心后降级开关和限流阈值可以动态调整这就是“功能可降级”的落地形态。4.2 技术架构组件基本平台、集成层、质量层怎么拼方案里的技术架构总览把组件分成了三块基本平台、集成层、质量层。对应关系如下层次方案组件职责落地选型参考基本平台JFS/Jimstore、JSS、JDW、Search、DBS缓存、图片、即时服务、索引、数据库Redis、对象存储、搜索集群、数据库集群集成层PAF、SAF、JDMQ、JDAL、JDWorker、JDRules、JDCenter、JMP流程编排、服务中间件、消息、数据访问、调度、规则、配置、推送工作流引擎、RPC 框架、消息队列、分库分表中间件、分布式调度、规则引擎、配置中心、推送网关质量层UMP、Loghub、JDriskM、jdcenter监控、日志、风控、应用管理Prometheus 监控、ELK 日志、风控系统、应用管理平台规模没到一定量级不需要自研这些组件。用开源件把“基本平台 集成层 质量层”三层补齐即可。这里最值得重视的是 JDAL 这类数据库中间件业务分片之后路由规则和历史数据迁移能力都压在它身上选型时要重点考察分片规则扩展性和平滑迁移能力。4.3 “数据库能支撑时不要引入缓存”怎么理解数据架构设计原则里有句话容易被忽略“数据库有能力支撑时尽量不要引入缓存。合理利用缓存做容灾。”很多团队一谈性能优化就上缓存结果缓存成了新的故障源数据不一致、击穿、雪崩问题全来了。缓存的作用不是替代数据库而是给数据库减负。正确顺序是先用慢日志和索引优化解决数据库瓶颈确认数据库 QPS 和 RT 确实到了天花板再考虑缓存缓存只放真正热的数据比如商品详情、库存读缓存设置过期时间和降级策略缓存故障时回源数据库用监控盯缓存命中率和回源流量。缓存当容灾用指的是数据库被瞬时流量打穿时缓存还能扛住读请求给数据库恢复争取时间。注意缓存不能当数据库用。凡是写多读少、强一致要求高的数据先留在数据库里别往缓存里塞。4.4 运维原则要前置可回滚、可降级、在线扩容、可监控系统运维原则不是上线后才考虑的必须在架构设计阶段就定下来。方案的要求是应用可回滚功能可降级在线扩容可监控可容错可故障转移。落到工程上就四件事第一每个服务保留最近可用版本的镜像和部署脚本故障时能在几分钟内回到上一版本。第二功能开关覆盖常见降级点比如发票通知、台账写入这类辅流程可以直接关掉。第三在线扩容要提前演练新增节点经过压测确认能接流量再真正放量。第四监控围绕 TPS、RT 和 SLA 建设出现超预期流量自动告警配合限流和熔断自动动作。运维就绪项验收标准可回滚5 分钟内回到上一可用版本功能可降级开关可关闭非核心流程在线扩容30 分钟内增加集群节点可监控TPS、RT、失败率指标齐全多机房容灾核心应用多活故障可切换5. 避坑与常见问题落地这套电商架构方案时最容易翻车的 5 个地方前面这几章的原则单独看都对合在一起执行就常出玄学问题。架构设计文档落到真实系统翻车点往往不在技术选项而在原则之间的顺序和边界没把握好。下面 5 个坑是我反复见到、也踩过的按“现象 → 原因 → 解决”写出来。平台化拆分后出现循环依赖现象基础用户服务下沉后业务方开始往用户服务里加字段几次迭代后用户服务反向依赖交易服务查询订单数据改一个基础服务要连带发一串上层系统。原因只做了业务域划分没有执行依赖原则。方案里写得清楚稳定部分不依赖易变部分易变部分可以依赖稳定部分坚决避免循环依赖平台服务不依赖上层应用。解决对每个基础服务执行依赖检查只保留“上层 → 基础”的单向依赖发现循环依赖把反向查询改成事件通知或数据冗余交易数据按需同步到用户侧而不是让用户服务直接调交易服务接口。辅流程异步化做成了“假异步”现象下单后发票和台账的异步任务堆积了几十万条消费端把订单库连接池占满正常下单跟着超时。原因异步调用改了但消费逻辑里又同步调了主流程服务和数据库等于把压力从同步链路搬到了消息链路。解决辅流程消费端独立部署独立连接池独立资源配额消费逻辑不能反向依赖主流程接口消息失败进死信队列靠定时任务补偿不阻塞主流程。这个坑对应的就是方案里“避免辅流程的失败导致主流程的回滚”这句。秒杀、闪购没有独立隔离现象闪购开场后常规下单链路的 P99 从 200ms 涨到 2s支付成功率下跌。原因闪购和常规下单在同一个应用数据库也是同一套分片策略流量尖峰把所有资源打穿。解决按“业务分片”原则把闪购系统单独拆出来独立限流、独立监控数据库单独分片或至少独立连接池隔离前先算峰值流量和日常流量的倍数超过十倍就列入隔离对象不做侥幸设计。为了“高可用”提前引缓存缓存反而变成新故障源现象Redis 抖动商品详情页大面积报错数据库回源流量暴涨服务直接雪崩。原因没有遵守“数据库有能力支撑时尽量不要引入缓存”这条原则缓存引入后没有设计降级命中率下降时所有请求回源把数据库打垮。解决先做索引和 SQL 优化确认数据库确实扛不住再引缓存缓存统一设置过期时间和回源限流缓存故障时接口降级直接读库用限流保护数据库。容灾和性能是两个目标混在一起做最后两个都做不好。无状态设计被本地 session 打破水平扩容后随机出问题现象服务从 3 个节点扩展到 12 个用户登录态时好时坏部分请求路由到异常节点后直接失败。原因服务里用了本地 session 或本机内存保存用户状态无状态原则没有落地。节点一多流量被随机分发状态不在本机的节点就无法处理请求。解决把会话状态移到 Redis 等外部存储对外接口保持幂等用幂等键做去重重复提交和重试不产生重复订单扩容后先压测验证节点流量分配再逐步放量。6. 验证架构设计是否立得住故障预算与演练清单架构方案好不好不是看文档画了多少图而是看故障时系统能不能自己站稳。拿这份方案的可用性目标做验证抓手比较直接。6.1 把可用性目标换算成故障预算方案原文给出了两个数字整体系统可用性 99.99%单个系统可用性 99.999%全年故障时间整个系统不超过 50 分钟单个系统故障不超过 5 分钟。换算一下一年是 525600 分钟99.99% 可用性对应约 52.56 分钟的全年故障时间方案取整为不超过 50 分钟99.999% 对应约 5.26 分钟取整为不超过 5 分钟。可用性目标全年故障时间月均故障时间99.99%约 52.56 分钟约 4.38 分钟99.999%约 5.26 分钟约 0.44 分钟这个预算的意思是整个系统一年只有约 50 分钟的故障余量一次上线事故就可能花掉大半预算单个系统只允许约 5 分钟故障意味着任何单服务故障都必须靠自动恢复和快速回滚解决不能等着人工排查半天。6.2 交付前走完这张验证清单每次给团队交付架构方案前我强制要求走一遍下面的清单故障演练随机停掉一个节点确认集群还能给出正确响应服务不会被单点故障拖死。回滚演练上线新版本后模拟发现问题确认 5 分钟内能回到上一个可用版本。降级演练关闭非核心功能比如发票通知、台账写入确认主交易链路不受影响。压测按预估峰值流量压测看 TPS 和 RT 是否符合 SLA 目标观察是否出现超预期流量。依赖检查检查有没有循环依赖、非核心依赖核心、平台服务依赖上层应用。从那以后我每次交付架构方案都会先把这套验证清单走完再做故障演练看监控数据确认没问题才放量。架构设计文档写得好不好不是看图画得全不全而是看故障时系统能不能自己站起来。这份方案适合在系统重构前翻一遍拿它当判断清单比临时搜资料靠谱希望帮到你。本文还有配套的精品资源点击获取