项目架构设计

我们的目标是以Spring Cloud为基础,从零开始搭建一个7x24小时运行的证券交易所。

除了Spring Cloud外,通常项目还需要依赖数据库、消息系统、缓存等各种组件。我们选择组件的原则是通用性高,使用广泛,因此,数据库选择MySQL 8.x,消息系统选择Kafka 3.x,缓存系统选择Redis 6.x。

由于我们的项目是一个7x24小时运行的证券交易系统,因此,我们简单分析一下业务系统的特点:

  • 证券交易系统的交易是基于交易对,例如,BTC/USD交易对表示用USD购买BTC,USD是计价货币(Quote Asset),BTC是交易资产(Base Asset);
  • 证券交易系统通过买卖双方各自的报价,按照价格优先、时间优先的顺序,对买卖双方进行撮合,实现每秒成千上万的交易量,可以为市场提供高度的流动性和基于微观的价格发现机制。

为了简化设计,我们把项目需求限定如下:

  • 仅支持BTC/USD一个交易对;
  • 不收取手续费,简化了收费逻辑;
  • 暂不考虑与银行和区块链系统对接,简化了资产的存取;
  • 暂不考虑风控相关的需求,以便专注于核心业务系统的开发;
  • 仅提供Web操作界面,暂不提供手机App;
  • 暂无后台管理功能。

项目名称暂定为Warp Exchange,采用GPL v3授权协议。项目最终完成后,效果如下:

warpexchange

系统模块

对一个系统来说,建立一个简单可靠的模型,不但能大大简化系统的设计,而且能以较少的代码实现一个稳定运行的系统,最大限度地减少各种难以预测的错误。

我们来看证券交易系统的业务模型。

对于证券交易系统来说,其输入是所有交易员发送的买卖订单。系统接收到订单后,内部经过定序,再由撮合引擎进行买卖撮合,最后对成交的订单进行清算,买卖双方交换Base和Quote资产,即完成了交易。

在撮合成交的过程中,系统还需要根据成交价格、成交数量以及成交时间,对成交数据进行聚合,以便交易员能直观地以K线图的方式看到历史交易数据,因此,行情系统也是证券交易系统的一部分。此外,推送系统负责将行情、订单成交等事件推送给客户端。

最后,证券交易系统还需要给交易员提供一个操作界面,通常是Web或手机App。UI系统将在内部调用API,因此,API才是整个系统下单和撤单的唯一入口。

整个系统从逻辑上可以划分为如下模块:

  • API模块(Trading API),交易员下单、撤单的API入口;
  • 定序模块(Sequencer),用于对所有收到的订单进行定序;
  • 交易引擎(Trading Engine),对定序后的订单进行撮合、清算;
  • 行情模块(Quotation),将撮合输出的成交信息汇总,形成K线图;
  • 推送模块(Push),将市场行情、交易结果、资产变化等信息以WebSocket等途径推送给用户;
  • UI模块(UI),给交易员提供一个Web操作界面,并把交易员的操作转发给后端API。

以上各模块关系如下:

                               query
                   ┌───────────────────────────┐
                   │                           │
                   │                           ▼
┌─────────┐   ┌─────────┐   ┌─────────┐   ┌─────────┐
│ Client  │──▶│   API   │──▶│Sequencer│──▶│ Engine  │
└─────────┘   └─────────┘   └─────────┘   └─────────┘
                   ▲                           │
                   │                           │
┌─────────┐   ┌─────────┐                      │
│ Browser │──▶│   UI    │                      │
└─────────┘   └─────────┘                      │
     ▲                                         ▼
     │        ┌─────────┐   ┌─────────┐   ┌─────────┐
     └────────│WebSocket│◀──│  Push   │◀──│Quotation│
              └─────────┘   └─────────┘   └─────────┘

其中,交易引擎作为最核心的模块,我们需要仔细考虑如何设计一个简单可靠,且模块化程度较高的子系统。对证券交易系统来说,交易引擎内部可划分为:

  • 资产模块:管理用户的资产;
  • 订单模块:管理用户的活动订单(即尚未完全成交且未取消的订单);
  • 撮合引擎:处理买卖订单,生成成交信息;
  • 清算模块:对撮合引擎输出的成交信息进行清算,使买卖双方的资产进行交换。

交易引擎是一个以事件驱动为核心的系统,它的输入是定序后的一个个事件,输出则是撮合结果、市场行情等数据。交易引擎内部各模块关系如下:

  ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐
     ┌─────────┐    ┌─────────┐
──┼─▶│  Order  │───▶│  Match  │ │
     └─────────┘    └─────────┘
  │       │              │      │
          │              │
  │       ▼              ▼      │
     ┌─────────┐    ┌─────────┐
  │  │  Asset  │◀───│Clearing │ │
     └─────────┘    └─────────┘
  └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘

经过这样的模块化设计,一个证券交易系统就具备了基本的雏型。