项目架构设计

我们的目标是以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 │ │
     └─────────┘    └─────────┘
  └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘