一、交易系统概述
大家好，我是老张。在金融科技领域摸爬滚打了十几年，今天咱们来聊聊交易系统。说实话，每次带新人时，我总喜欢先从历史讲起——不是掉书袋，而是因为只有理解了系统为什么长成这样，你才能真正驾驭它。
1.1 金融交易系统的发展历程
金融交易系统，说白了就是帮人买卖股票、期货、外汇这些金融产品的电子平台。我入行那会儿，还见过老交易员用手势在交易所里比划呢。
第一阶段：人工交易时代（1990年代前）
那时候的交易员，穿着红马甲在交易所大厅里喊单。你想想看，一个订单从客户下单到成交，中间要经过电话、传单、人工录入……慢不说，还容易出错。我记得有个老前辈跟我说过，当年一个乌龙指事件，能让整个交易所乱成一锅粥。
第二阶段：电子化交易时代（1990-2005年）
计算机开始进入交易领域。订单从手工填单变成了键盘录入，成交也从人工撮合变成了电子撮合。这个阶段，我参与过几个券商的柜台系统改造——说白了就是把纸质流程搬到电脑上。嗯，那时候的数据库还是DB2，存储过程写得那叫一个复杂。
第三阶段：分布式交易时代（2005年至今）
随着互联网的普及，交易量暴增。传统的单体架构扛不住了。我2010年在某头部券商做架构师时，亲眼看着他们的核心交易系统从一台IBM小型机，慢慢拆成了几十台x86服务器。为什么会这样？因为一台机器再强，也扛不住千万级的并发请求啊。
核心观点：交易系统的演进，本质上就是一场与「延迟」和「容量」的赛跑。谁的系统更快、更能扛，谁就能在市场上占得先机。
1.2 核心业务概念
做交易系统，有三个概念你必须刻在脑子里：订单、成交、行情。我面试架构师时，第一个问题就是「你给我讲讲这三者的关系」。答不上来的，基本就凉了。
1.2.1 订单（Order）
订单就是交易指令。你告诉系统：我想买100股茅台，价格不超过2000块。这就是一个订单。
订单有几个关键属性：
- 方向：买还是卖？这个不用多说
- 价格：限价单、市价单、止损单……不同价格类型，撮合逻辑完全不同
- 数量：要买多少股/手
- 有效期：当日有效、一直有效（GTC）、立即成交否则撤销（IOC）
避坑指南：我曾经遇到过一个坑——订单的「价格精度」问题。某次对接交易所，他们要求价格保留4位小数，但我们的系统只支持2位。结果呢？所有订单都被拒了。所以设计订单模型时，一定要把精度做成可配置的。
1.2.2 成交（Trade）
成交就是订单匹配成功的结果。一个买单和一个卖单，价格对上了，就产生一笔成交。
成交的核心属性：
- 成交价格：实际成交的价格
- 成交数量：实际成交的数量
- 成交时间：精确到微秒甚至纳秒
- 成交编号：全局唯一的标识
这里有个细节要注意：一个订单可能被拆成多笔成交。比如你想买1000股，但市场上只有300股卖单，那就先成交300股，剩下的700股继续挂着。我见过不少新手，把订单和成交当成一对一的关系来设计，结果对账时对不上——嗯，那场面挺尴尬的。
1.2.3 行情（Market Data）
行情就是市场的实时数据。包括：
- 最新价：最近一笔成交的价格
- 买卖盘口：买一到买五、卖一到卖五的价格和数量
- 成交量/额：累计成交的数据
- 涨跌幅：相对于前收盘价的变动比例
行情数据的特点是：量大、频次高、实时性要求极高。A股市场每天产生几十亿条行情数据，你想想看，这得什么样的系统才能扛得住？
1.3 系统架构演进：从单体到分布式
好，咱们来看看交易系统的架构是怎么一步步演进的。我画了一张图，帮你理清思路：
这张图展示了交易系统架构的三个阶段。咱们一个一个来看：
1.3.1 单体架构
早期的交易系统，就是一个大单体。订单接收、风控检查、撮合引擎、清算结算……所有功能都塞在一个进程里。数据库也是一台机器搞定。
优点很明显：简单。开发快，部署也快。但缺点更致命：
- 单点故障：任何一个模块出问题，整个系统就挂了
- 扩展困难：交易量上来了，只能换更强的机器——成本高得吓人
- 耦合严重：改一个功能，可能影响整个系统
我2012年接手过一个遗留系统，就是这种单体架构。每次上线都提心吊胆，因为改一行代码，整个系统都要重新部署。有一次凌晨三点上线，结果回滚了五次——那滋味，真不好受。
1.3.2 垂直拆分
后来大家发现，可以把系统按业务拆开。比如：订单系统、风控系统、清算系统……每个系统独立部署，有自己的数据库。
这样做的好处：
- 故障隔离：风控挂了，订单还能收
- 独立扩展：订单量大，就多部署几台订单服务器
- 团队自治：不同团队负责不同子系统
但问题也来了：子系统之间怎么通信？数据怎么同步？我记得当时我们用消息队列（MQ）来解耦，但消息丢失、重复消费这些问题，够你喝一壶的。
1.3.3 分布式架构
到了2015年以后，微服务架构开始流行。交易系统也全面走向分布式。每个服务都是独立的进程，通过RPC或消息队列通信。
分布式架构的核心特点：
- 服务化：每个功能都是一个微服务
- 水平扩展：加机器就能提升性能
- 高可用：多副本、故障自动切换
- 最终一致性：用BASE理论代替ACID
注意：分布式不是银弹。我见过不少团队，业务量还没起来就盲目上微服务，结果被分布式事务、服务发现、链路追踪这些问题搞得焦头烂额。记住：架构选型要匹配业务规模。
1.4 本章小结
好了，咱们把这一章的内容串一下：
- 交易系统从人工喊单，到电子化，再到分布式，走了三十多年
- 订单、成交、行情是三大核心概念，设计时一定要吃透
- 架构演进的核心驱动力是「量」——交易量上来了，架构就得变
我个人习惯，每章结尾留个思考题：如果你现在要设计一个交易系统，你会选择单体还是分布式？为什么？想清楚这个问题，后面的内容你会理解得更深。