开篇碎碎念，有读者在催更了，看到留言的那一刻，想起自己立下的flag，顿时觉得羞愧难当。这也是写公众号的一个好处——有读者督促，让拖延症患者也不得不动起来。此前写了《交易系统篇》，今天来聊聊交易中台。

交易中台的诞生

了解一个事物，一定要知道这个事物诞生的缘由。交易中台是怎么来的？让我们从一个创业故事说起。

第一阶段：卖母婴产品

假设你开了一家电商公司，最开始卖的是母婴产品。

交易流程很简单：下单 → 支付 → 发货 → 收货

开发团队搭建了一套交易系统，运行得挺好。

第二阶段：拓展汽车保养服务

随着业务越做越大，你决定扩张范围，开始卖汽车保养服务。这时问题来了。汽车保养是虚拟商品，交易流程完全不同：

下单 → 支付 → 消费者到店核销

不需要物流发货，不需要收货地址。原来的系统改不了，你不得不让开发重新做了一套新的交易系统。

第三阶段：业务越来越多

公司越做越大：

涉足医疗健康行业：在线问诊 → 下单 → 门店发药

进入生鲜领域：买菜 → 前置仓 → 30分钟配送

做起了数字产品：会员卡 → 虚拟充值 → 即时到账

随着电商业务越来越大，接入的行业越来越多，售卖的商品千奇百怪。

每次来一个新业务，就要重做一套交易系统，费时费力。

你开始思考：

这些业务虽然不同，但很多能力都是相同的：

都需要下单

都需要支付

都需要订单管理

都需要售后处理

只有少部分环节是定制化的：

商品的展示形式不同（实物/虚拟/服务）

履约方式不同（快递/到店/即时配送）

下单流程的细节不同（要不要地址/要不要预约

那么，能不能把相同的部分整合到同一个系统中，把不同的部分做成可扩展的？这就是交易中台的诞生背景。

什么是交易中台？

交易中台的核心思想是：

定义交易的大框架，提供通用能力，开放定制接口。

具体来说：

中台提供什么？

1. 交易流程的标准框架

定义了交易的核心环节：

下单 → 支付 → 履约 → 售后

2. 通用的业务能力

订单管理（创建、查询、取消）

支付能力（对接支付渠道）

单据模型（交易单、支付单、物流单）

状态机（订单状态流转）

3. 基础设施支持

数据库（订单存储）

缓存（高并发支持）

消息中间件（异步解耦）

监控报警（稳定性保障）

业务方做什么？

业务方只需要做差异化的部分：

商品展示（自定义UI）

下单定制（特殊字段、特殊校验）

履约对接（对接不同的履约方式）

营销玩法（满减、优惠券、拼团）

举个例子

假设你要在中台上接入三个业务：

母婴电商

商品：纸尿裤、奶粉（实物）

履约：快递配送

下单定制部分为：需要填写收货地址

汽车保养

商品：保养服务（虚拟）

履约：到店核销

下单定制部分为：需要选择门店和预约时间

在线问诊

商品：问诊服务（服务）

履约：在线沟通 + 药品配送

下单定制部分为：需要填写病情描述

中台如何支撑？

中台提供了统一的下单能力：

对外呈现的是不同的形态，但底层是同一套中台能力。

交易中台的开发范式

交易中台的开发，遵循一套标准范式：

1. 定义标准流程

把交易流程抽象成几个核心阶段：

下单前 → 下单中 → 下单后

支付前 → 支付中 → 支付后

履约前 → 履约中 → 履约后

2. 提供扩展点

在每个阶段埋好扩展点（SPI），让业务方可以插入自己的逻辑。

举例：

下单流程：下单前校验（扩展点）

母婴业务在这个拓展点执行的事情校验库存

汽车保养业务在这个拓展点执行的事情是校验预约时段

下单后处理（扩展点）

母婴业务在这个拓展点执行的事情是扣减库存

汽车保养业务在这个拓展点执行的事情是生成核销码

3. 业务身份识别

中台通过业务身份（业务线ID）来识别不同的业务，走不同的定制逻辑。

if (业务线 == "母婴电商") {
走快递履约
} else if (业务线 == "汽车保养") {
走到店核销
}

4. 配置化 + 代码化

简单的差异：通过配置解决（比如字段显隐）

复杂的差异：通过代码扩展解决（比如特殊业务逻辑）

交易中台的核心价值

1. 快速接入新业务

不需要从0搭建交易系统，只需要做定制化开发。

上线周期从3个月缩短到1个月。

2. 降低维护成本

通用能力统一维护，不需要每个业务各自修改。

比如支付通道升级，中台统一升级，所有业务自动受益。

3. 技术能力沉淀

把多年积累的交易能力沉淀下来：

• 高并发处理

• 分布式事务

• 消息驱动

• 单元化部署

新业务直接复用，不用重复造轮车。

4. 灵活扩展

业务方可以在中台基础上做任意定制

交易中台的挑战

当然，交易中台也不是银弹，它也有挑战：

1. 抽象的难度

如何抽象出一套既通用又灵活的能力？

抽象太少，业务接不进来；抽象太多，业务受限制。

2. 扩展点的设计

扩展点太少，业务没法定制；扩展点太多，中台变得复杂。

3. 业务方的学习成本

中台有一套自己的开发范式，业务方需要学习。

文档、示例、培训都要跟上。

4. 性能和稳定性

中台支撑所有业务，一旦出问题，影响面巨大。

对稳定性要求极高。

每一层各司其职

共同支撑起庞大的交易体系

写在最后

交易中台的本质，是把通用能力沉淀下来，把差异化能力开放出去。

它不是一蹴而就的，而是在业务发展过程中逐步演进的：

从1个业务 → 2个业务 → N个业务

从简单抽象 → 深度抽象 → 平台化

这是一条漫长的路，但也是一条值得走的路。

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