项目架构设计

我们的目标是以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。

以上各模块关系如下：

  1.                                query
  2.                    ┌───────────────────────────┐
  3.                    │                           │
  4.                    │                           ▼
  5. ┌─────────┐   ┌─────────┐   ┌─────────┐   ┌─────────┐
  6. │ Client  │──▶│   API   │──▶│Sequencer│──▶│ Engine  │
  7. └─────────┘   └─────────┘   └─────────┘   └─────────┘
  8.                    ▲                           │
  9.                    │                           │
  10. ┌─────────┐   ┌─────────┐                      │
  11. │ Browser │──▶│   UI    │                      │
  12. └─────────┘   └─────────┘                      │
  13.      ▲                                         ▼
  14.      │        ┌─────────┐   ┌─────────┐   ┌─────────┐
  15.      └────────│WebSocket│◀──│  Push   │◀──│Quotation│
  16.               └─────────┘   └─────────┘   └─────────┘

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

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

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

  1.   ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐
  2.      ┌─────────┐    ┌─────────┐
  3. ──┼─▶│  Order  │───▶│  Match  │ │
  4.      └─────────┘    └─────────┘
  5.   │       │              │      │
  6.           │              │
  7.   │       ▼              ▼      │
  8.      ┌─────────┐    ┌─────────┐
  9.   │  │  Asset  │◀───│Clearing │ │
  10.      └─────────┘    └─────────┘
  11.   └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘

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

读后有收获可以支付宝请作者喝咖啡：

项目架构设计 - 图2