一、项目全景与架构设计：量化交易平台整体架构、技术栈选型（Python + 港股API + 数据库）、项目目录结构设计
说实话，很多朋友刚开始做量化交易平台时，最容易犯的一个错误就是——上来就写代码。我当年也踩过这个坑，吭哧吭哧写了两个月，结果发现架构选错了，数据库设计不合理，整个项目推倒重来。嗯，那滋味可不好受。
所以，在动手之前，我们先花点时间把「骨架」搭好。这一章，我们就聊聊整个平台长什么样、用什么技术、目录怎么组织。
1.1 整体架构：三层分离，各司其职
我个人习惯把量化交易平台拆成三个层次。你想想看，一个交易系统无非就是三件事：拿数据、做决策、下订单。对应到架构上，就是数据层、策略层和执行层。
核心架构图：三层分离模型
为什么这么分？说白了，就是为了解耦。我在项目中遇到过好几次这样的情况：策略代码和数据获取代码混在一起，改一个行情接口，结果策略逻辑也跟着崩了。三层分离之后，每一层都可以独立测试、独立升级。
1.2 技术栈选型：Python + 港股API + 数据库
选技术栈这件事，我建议你遵循一个原则：用最熟悉的，而不是最流行的。当然，如果两者重合，那就更好了。
| 层级 | 技术选型 | 说明 |
|---|---|---|
| 编程语言 | Python 3.10+ | 生态丰富，开发效率高，量化社区首选 |
| 数据获取 | 港股API（富途OpenAPI / IB API / AKShare） | 实时行情、历史数据、财务指标 |
| 数据库 | PostgreSQL + Redis | PostgreSQL存结构化数据，Redis做缓存 |
| 数据处理 | Pandas + NumPy | 数据清洗、计算、回测 |
| 任务调度 | APScheduler / Celery | 定时拉取数据、执行策略 |
| 日志与监控 | Loguru + Prometheus | 记录交易日志，监控系统状态 |
💡 个人经验：数据库这块，我建议别一开始就上分布式。很多新手觉得「以后数据量大了怎么办」，结果把系统搞得太复杂。PostgreSQL单机扛个几亿条K线数据完全没问题。等真到了那个量级，你早就知道该怎么拆了。
1.3 项目目录结构设计
目录结构这件事，看起来是小事，但直接影响你后续的开发效率。我曾经接手过一个项目，所有代码都堆在根目录下，找文件全靠搜索——那叫一个酸爽。
下面是我个人比较推荐的结构，你可以直接拿来用：
hk_quant_platform/
├── config/ # 配置文件
│ ├── __init__.py
│ ├── settings.py # 全局配置
│ └── api_config.py # API密钥、参数
│
├── data/ # 数据层
│ ├── __init__.py
│ ├── fetcher.py # 数据获取模块
│ ├── cleaner.py # 数据清洗
│ └── storage.py # 数据存储
│
├── strategy/ # 策略层
│ ├── __init__.py
│ ├── base.py # 策略基类
│ ├── signals.py # 信号生成
│ └── backtest.py # 回测引擎
│
├── execution/ # 执行层
│ ├── __init__.py
│ ├── broker.py # 交易接口封装
│ ├── order_manager.py # 订单管理
│ └── risk_control.py # 风控模块
│
├── utils/ # 工具模块
│ ├── __init__.py
│ ├── logger.py # 日志配置
│ └── helpers.py # 辅助函数
│
├── tests/ # 测试
│ ├── test_data.py
│ ├── test_strategy.py
│ └── test_execution.py
│
├── logs/ # 日志文件
├── data_store/ # 本地数据缓存
├── requirements.txt # 依赖清单
├── main.py # 入口文件
└── README.md # 项目说明
⚠️ 避坑指南：我曾经把API密钥直接写在代码里，结果不小心提交到了GitHub公开仓库。嗯，那天的教训很深刻。所以，所有敏感信息（API密钥、密码）一定要放在config目录下，并且加入.gitignore。
1.4 数据流向：从行情到订单的完整链路
搞清楚了架构和目录，我们再看看数据是怎么在系统里流转的。说白了，就是一条流水线：
- 数据层：通过港股API拉取实时行情和历史数据，清洗后存入PostgreSQL
- 策略层：从数据库读取数据，运行策略逻辑，生成买卖信号
- 执行层：接收信号，通过交易接口下单，记录成交结果
- 反馈闭环：成交数据写回数据库，供策略复盘和优化
你想想看，这个流程其实和工厂流水线很像。每个环节只做自己的事，出了问题也容易定位。我在做第一个版本时，就是因为没有理清这个流向，导致数据在各个环节之间「打架」，调试起来特别痛苦。
1.5 为什么选Python？
这个问题经常有人问。我的回答很简单：因为快——开发快。C++执行快，但写一个策略可能要一周；Python可能半天就搞定了。对于量化交易来说，策略迭代的速度往往比执行速度更重要。
当然，Python也有短板，比如GIL限制。但说实话，对于个人或小团队的港股量化交易，Python完全够用。真到了需要高频交易的时候，再用C++重写核心模块也不迟。
核心要点总结：
- 架构采用三层分离：数据层 → 策略层 → 执行层
- 技术栈：Python + 港股API + PostgreSQL/Redis
- 目录结构按功能模块划分，配置与代码分离
- 数据流向清晰，每个环节职责单一
好了，架构和目录就聊到这里。记住一句话：好的架构不是设计出来的，是改出来的。先跑起来，再优化，这才是务实的做法。
公众号:蓝海资料掘金营，微信deep3321