企业官网建设流程全解析

这是「我干开发这些年」系列的第二篇，上周发了《电商全局篇》，阅读量冲到了4000+，转发170+次。对于我这个只有几十个粉丝的小破号来说，这简直是"人生巅峰"了😂

看到后台数据的时候，我内心OS：

• "原来真的有人爱看技术文章！"

• "原来大家不是都在刷短视频！"

• "原来我写的东西还有点用！"

尤其是看到170+次转发，我就在琢磨：你们是转给了同事学习，还是跟我一样，习惯性地"分享到文件助手"当网盘用😄

不管怎样，既然大家不嫌弃，那我就继续更新下去。

今天聊交易系统——这个电商的"心脏"，到底是怎么跳动的

交易的本质-一场跨越千年的交换游戏

交易，说白了就是买卖双方货物的交换。

买家掏钱，卖家给货——这是人类最古老的商业行为，从远古时代的"以物易物"，到现在的"扫码支付"，本质从未改变

想象一下，你去菜市场买菜：

老板问："这白菜多少钱一斤？"你说："2块！"然后你递上10块钱，老板称重、打包、找零——交易完成。

整个过程简单、直接、高效，为什么？

因为天然满足了两个关键因素：

第一，交易双方都在场。你拿着钱站在摊位前，老板守着菜摊，面对面交易。

第二，货物就在眼前。菜市场的摊位就是"场"，白菜堆在眼前，看得见摸得着。

一手交钱，一手交货，交易瞬间达成。

互联网交易：复杂在哪里？

但在互联网上，情况完全不同了，买家坐在北京的家里，卖家在杭州的公司，商品存在广州的库房——相隔千里，怎么交易？

虽然交易双方和商品还在，但出现了两个新的致命问题：

问题一：钱怎么付？

不能当面交现金，不能先转账后对方不发货，也不能先发货再付款——卖家不放心。这时候就需要一个"中间担保人"，也就是支付系统。

问题二：货怎么发？

买家看不到实物，不能当场拿走，也不知道货发到哪了。这就需要一个"物流追踪系统"，也就是交付系统

交易四大核心要素

为了解决这些问题，电商交易系统必须围绕四大要素构建：交易双方、货物挑选、付款、发货

交易双方：会员体系

解决的核心问题：在网上，谁是买家？谁是卖家？他们可信吗？

在菜市场，老板认识你，"老顾客了"，天然有信任。

但在互联网上，需要注册、登录、实名认证才能建立最基础的信任。

会员体系要管理的事情包括：

买家是谁？有什么偏好？信用如何？

卖家是谁？卖什么东西？资质是否合规？

他们的身份如何验证？权限如何管理？

比如买家需要注册登录、实名认证、积累信用分；

卖家需要商家入驻、资质审核、缴纳保证金。

平台还要有黑名单、限购规则、风控体系来保障交易安全。

货物挑选：交易流程

解决的核心问题：看不见摸不着的商品，怎么让用户相信并下单？

在菜市场，你可以拿起白菜看看、闻闻、捏捏，直观判断新不新鲜。

但在网上，只能通过图片、视频、详情页、买家评价来了解商品。

交易流程要解决三件事：

商品如何展示？

需要详情页、高清图片、视频、规格选择、用户评价来"还原"商品真实样貌。

购物车如何管理？

线下你可以拿个篮子边逛边放

线上需要一个虚拟购物车来暂存商品、预览价格、提供凑单推荐

订单如何生成？

线下是口头约定"我要5斤"

线上需要选择收货地址、支付方式、计算优惠，最后提交订单生成一个唯一的订单号来"锁定"这笔交易

付款：支付系统

解决的核心问题：如何保证买家付了钱、卖家能收到钱，同时不会"付了钱不发货"或"发了货不付钱"？

菜市场是一手交钱一手交货，当场完成，基本没有信任风险

但网上交易有时间差，所以需要担保交易机制。

流程是这样的：用户点击支付，钱先到平台账户托管，卖家看到"已付款"后发货，用户确认收货后，平台再把钱打给卖家

支付系统要做的事情包括：对接支付宝、微信支付等支付渠道；

记录每一笔资金流水生成支付单；

还要有风控机制识别盗刷、恶意退款、套现等行为。

发货：交付系统

解决的核心问题：货物如何从卖家仓库送到买家手里？过程中怎么追踪？

菜市场买完就拿走，网购要等3到7天，中间还得追踪"货到哪了"。

交付系统的职责是：订单付款后通知仓库拣货打包，对接顺丰、菜鸟等物流公司，实时追踪物流状态（已发货、运输中、派送中、已签收），还要处理退货退款、换货、补发等售后问题。

整个流程就是：用户支付成功→订单系统通知履约系统→履约系统通知仓库→仓库拣货打包出库→对接物流公司生成快递单号→快递揽件运输配送→用户签收订单完成

上面四大要素拼起来，就是一个最小化的电商交易系统。

用户在前台注册登录、浏览商品、加购物车、下单；

后台的会员体系管理买卖家信息和权限；

交易流程负责商品展示、购物车管理、下单和订单管理；

支付系统处理钱的流转；交付系统处理货的流转。

一句话总结

会员体系，解决"谁在交易"

交易流程，解决"交易什么"

支付系统，解决"钱怎么走"

交付系统，解决"货怎么发"

以上为一个最小化的电商交易系统的全貌，本篇内容核心聚焦于其中的交易流程的解析，其他部分可以参考全局篇进行对照理解

交易链路的核心流程

从用户点击"加购"到最终收到货，整个交易链路经历了四个关键阶段。

加购阶段，用户点击"加购物车"，购物车系统实时查询商品中心获取最新价格和库存状态，然后返回购物车列表；

下单阶段，用户点击"提交订单"后，下单系统会依次验证用户身份、获取商品信息、扣减库存，最后生成订单写入数据库并返回订单号；

支付阶段，用户点击"去支付"跳转到收银台选择支付方式，支付系统对接支付宝或微信完成扣款，生成支付单后回调通知订单系统更新状态为"待发货"；

履约阶段，订单管理调用交付系统下发发货通知，交付系统生成交付单并对接物流公司获取运单号，之后实时同步物流状态直到用户签收。

整个流程从前到后环环相扣，每个系统各司其职又紧密协作，共同完成一笔完整的交易。

除了这条正向流程，交易系统还要处理逆向流程，也就是售后退款、退货换货、投诉纠纷等场景，这部分同样需要多个系统的联动配合，确保用户权益得到保障。

交易核心系统与职责划分

现代电商交易系统采用分层架构和服务化设计，将复杂的交易流程拆解为多个职责清晰的独立系统。

下单系统是用户购买的入口，负责确认购买意向、核销优惠券、扣减库存，最终完成交易契约的订立并创建订单；

交易平台作为交易的履行系统，承担订单的持久化存储、状态流转管理以及与数据库的交互；

支付平台专门处理资金流转，对接支付宝、微信等支付渠道，实现支付结果的同步返回和异步回调通知；

购物车提供商品暂存、实时价格预览、凑单推荐等辅助决策能力，帮助用户在下单前做好准备；

优惠引擎统一管理交易中的各类促销活动，包括优惠券、满减、红包等的下发和核销；

逆向交易系统则处理售后场景，包括客诉处理、退货退款、换货补发等逆向流程。

这些系统各司其职又相互协作，通过接口调用和消息传递完成复杂的交易编排，既保证了系统的高可用性和可扩展性，也让团队能够独立维护各自的业务领域。

核心业务系统

支撑系统

关键技术设计要点-大型电商交易系统

第一秘诀之单据模型设计

交易系统要应对复杂的数据流和亿级访问量，同时保障高可用，核心策略之一就是采用合理的单据模型。

一笔完整的订单从下单到完成，涉及三个核心环节：

交易确认（买什么、多少钱、有什么优惠）

资金流转（怎么付款、付了多少、退款给谁）

物流履约（发到哪里、什么时候发、物流状态）

从用户下单行为到最终生成订单，需要记录买卖家信息、商品信息、品牌信息、营销优惠信息等大量数据

同时订单的推进还受到交易方式的约束，比如付款时间、发货时间、收货时间等约定

订单必须根据这些约束与支付、交付、发票结算等环节进行联动。

如果把所有信息都塞进一张订单表，会导致三个严重问题：

1. 数据冗余（一个订单多次支付就要重复存储订单信息）

2. 职责不清（支付团队和物流团队都要改同一张表引发冲突）

3. 扩展困难（新增支付方式就要改订单表结构）

因此，为了完整刻画整个交易过程并保证系统的灵活性和可维护性，订单模型被拆分为三大核心单据：

交易单记录买卖协议和商品信息

支付单记录资金流转过程

物流单记录货物履约状态

这就是电商系统经典的"三单模型"，各单据职责明确、相互独立又通过订单号关联协作，既解决了数据冗余问题，也让不同团队能够独立维护各自的业务领域，大大提升了系统的可扩展性和容错能力。

一笔订单通常包含多个商品，每个商品我们称为一个条目或子订单，而整个订单体系就是由交易单、支付单、物流单三大核心单据构成。

交易单

交易单是交易的"合同"，记录买卖双方达成的协议，包含基础信息（订单号、买卖家信息）

商品信息（子订单列表，比如iPhone 15一台7999元、手机壳两个单价39元）

价格信息（商品总价、运费、优惠金额、实付金额）以

时间约束（下单时间、15分钟付款期限、24小时发货期限、10天后自动确认收货）

其中一笔主订单可以包含多个子订单，每个子订单对应一个SKU库存单位

支付单

支付单是资金的"流水账"，记录资金流转的完整过程，包括支付单号、关联的订单号、支付金额、支付方式（支付宝或微信）、支付时间、支付状态以及第三方流水号

之所以要单独存储支付单，是因为一笔订单可能分多次支付（比如预售的定金加尾款）、可能多次退款（部分退款场景），而且支付能力需要独立演进不应影响订单表结构，所以一个订单可以关联多个支付单。

物流单

物流单是货物的"行程单"，记录商品从发货到签收的全过程，包含物流单号、关联订单号、收货地址（收货人、手机号、详细地址）

发货信息（发货仓库、发货时间、物流公司、快递单号）以及物流状态（已揽件、运输中、派送中、已签收）

物流单也需要单独存储是因为一笔订单可能多次发货（部分发货）、可能拆分包裹（不同仓库发货，比如iPhone从杭州仓发顺丰、手机壳和膜从上海仓发圆通），而且物流状态频繁更新不应影响订单主表。

三单之间的关联关系是一个交易单对应多个支付单（支持多次支付退款）和多个物流单（支持拆单发货）。它们通过订单号进行映射关联。

三单总结

举个实际案例

用户通过预售的方式购买iPhone 15，手机壳、钢化膜三件商品，会生成一笔交易单。

其中包含三个子订单（三种商品，一种一个子订单）

关联两笔支付单（定金支付一次和尾款支付一次）

拆分两个物流单（杭州仓发iPhone走顺丰、上海仓发手机壳和膜走圆通）

三单模型是电商系统的基石，各司其职又相互协同共同支撑起完整的交易流程，

这种设计符合单一职责原则和康威定律，让不同团队能够独立维护各自的业务领域，是大型电商系统架构的单据最佳实践。

第二秘诀-消息驱动设计

交易系统的核心架构

交易系统采用消息驱动设计，核心理念是通过消息队列解耦各个流程环节，既提高下单响应速度，又利用消息的排队特性实现对瞬时大流量的缓冲，避免压垮下游系统。

如果使用传统的同步调用模式，交易链路太长根本扛不住——用户下单后要依次扣库存、扣优惠券、增加积分、通知商家、发短信等等

每一步都要等待上一步完成，用户一次下单所需等待的时间将会漫长到无法接受。

消息驱动模式的优势在于，用户下单后订单快速落库并立即返回成功（仅需200毫秒）

同时发送消息到消息队列，库存系统、通知系统、优惠系统等下游系统收到消息后异步处理各自的业务，完全不必跟主链路强耦合。

在双十一这样的大促场景下，零点瞬间100万人下单，订单系统快速入库并发送消息到队列就能扛住压力

消息队列积压100万条消息慢慢分发，下游系统按各自的处理能力逐步消费不会被冲垮。

消息驱动的容错性也更强，同步模式下如果扣库存成功但扣优惠券失败就要整个订单回滚

而消息驱动模式下订单入库成功后即使优惠券系统消费失败也可以通过消息重试机制补偿，不影响订单成功。

当然消息的缺点在于无法保证不重复和顺序不错乱，因此交易系统必须配合状态机和幂等性设计作为"安全阀"来保障数据准确性。

状态机模式确保每次状态变更都会校验是否符合流转顺序，比如待支付必须经过待发货、配送中才能到已签收，不能直接跳步；

幂等性保证则防止重复操作，通俗讲就是执行过的操作不会再次执行，比如一笔订单已经付过款了再次执行付款会直接返回成功而不是重复扣钱。

此外交易系统还需要消息网关来屏蔽下游差异，因为下游系统众多且每个系统关心的消息不一样

商品系统只关心下单成功用于销量统计、会员系统只关心支付成功用于积分发放、店铺系统只关心订单取消用于退款

如果让交易系统直接对接所有下游会导致强耦合难以维护，消息网关作为中间层统一接收交易消息并按订阅规则分发给不同下游系统，既实现了解耦又保证了扩展性

第三秘诀-单元化架构

交易系统容灾与拓展的基石

单元化架构是把一个大系统拆成多个完全独立、自给自足的小单元。

这里的单元指的就是不同的机房，这种设计能带来高可用、容量可扩展、降低延迟等诸多好处。

在高可用方面，传统架构下全国用户都访问一个大机房，单点故障风险极高

一旦机房出现故障宕机会导致全国用户都无法下单，而单元化架构将用户按地域分流到不同单元

华东用户访问杭州单元、华北用户访问北京单元、华南用户访问广州单元

每个单元独立运行互不影响，即使杭州单元宕机也只影响华东用户，其他地区依然正常服务，大大降低了故障影响面。

在容量扩展方面，传统架构中所有应用、缓存以及数据库都在同一个机房内，业务翻倍意味着机器翻倍，会导致数据库压力翻倍难以扩展，即便采用分库分表的分布式数据库也无法快速平滑扩容

而单元化架构中每个单元内的应用、缓存、数据库都是独立的一套不与其他单元共用，业务翻倍时只需新增一个单元来分担流量，就能实现快速的线性扩展

避免了传统架构扩容时的复杂数据迁移和容量瓶颈问题，这种设计让交易系统能够从容应对业务的爆发式增长和大促期间的流量洪峰。

在低延迟方面，单元化部署具有天然的地域性优势，让用户就近访问距离最近的单元可以显著降低网络延迟

比如用户在上海但服务器在北京时往返时延需要50毫秒，而单元化后上海用户直接访问上海单元，往返时延降至5毫秒，延迟降低了90%，用户体验得到极大提升。

然而单元化在带来这些优势的同时，也因为数据隔离会引入新的挑战，典型场景是用户在北京下单时访问的是北京单元数据也存储在北京单元，如果用户坐飞机到了上海再次登录时访问的就是上海单元，这时会神奇地发现自己的订单不见了

因为上海单元和北京单元的数据并未同步。因此单元之间对于核心数据必须实现全局一致性，比如订单数据、支付数据、用户基本信息等这些需要全局唯一的数据

各单元间需要通过消息队列或数据同步中间件实时互相同步，既要保证用户在任何单元都能看到自己的完整数据

又要控制跨单元同步的延迟和成本，这对架构设计提出了更高的要求，需要在数据一致性、系统复杂度、成本之间找到最佳平衡点。

考虑到单元化会带来的实施成本 非核心系统可以不使用单元化架构

总结

说实话，这篇文章写得漫长到难以想象。如果你能读到这里，我要真诚地恭喜你——你的耐心和求知欲简直惊为天人。

坦白讲，本文展示的内容还不足初稿的十分之一。一路写下来，删了改、改了删，反反复复不知多少遍。后来我认命了——想在短短一篇公众号文章中就把交易的全链路讲清楚，本身就是一种奢望。

所以本文只是简要概述了交易的流程、核心系统功能，以及几个关键的方案设计。更多的细节，尤其是那些"魔鬼般的细节"，我打算放在下一篇《交易中台篇》中展开。

毕竟，交易系统太庞大了，每一个模块深挖下去都是一片海洋。与其囫囵吞枣，不如慢慢品味。

https://mp.weixin.qq.com/s/N9xNgRDukJR8X_uSahe7Ag