第1章量化平台演进史

一、量化平台演进史：从单体架构到微服务的必然之路

做量化交易系统这些年，我最大的感触就是——架构不是设计出来的，是被逼出来的。

2015年我刚入行时，团队只有5个人。老板说：「搞个能跑策略的系统就行。」于是我们撸了一个单体应用，所有功能塞在一个Jar包里。说实话，当时觉得挺爽的，开发快、部署简单、调试方便。

但后来呢？

噩梦开始了。

1.1 单体架构的「黄金时代」与「至暗时刻」

先说说单体架构长什么样。说白了就是：

一个进程里塞了行情接收、策略计算、订单管理、风控检查、账户管理
共享一个数据库，所有模块直接读写同一张表
部署就是打个Jar包扔到服务器上

我画了张图，你看一眼就明白了：

这种架构在团队小、业务简单时，确实香。我记得第一版上线只用了两周，跑得还挺稳。

但问题出在规模上。

单体架构的三大痛点：

耦合太深：改一行风控代码，整个系统要重新部署。有一次我改了个行情模块的日志，结果把策略引擎搞挂了——因为共享了同一个线程池配置。
扩展困难：行情模块需要高吞吐，但策略模块需要低延迟。你没法单独给行情加机器，只能整体扩容。成本高得离谱。
故障蔓延：一个模块内存泄漏，整台机器挂掉。我记得有一次账户模块的缓存没清理，直接导致全系统OOM，交易停了整整40分钟。

1.2 第一次重构教训：为了微服务而微服务

2017年，我决定拆分。

当时看了很多微服务的文章，热血沸腾。心想：拆！必须拆！

结果呢？

拆成了20多个服务，每个服务都独立部署。但问题来了：

服务间通信用HTTP，延迟从2ms飙到了50ms
每个服务都要单独配置数据库连接池，运维成本翻了三倍
分布式事务搞不定，订单状态经常不一致

我踩过的坑：

我曾经把一个策略计算模块拆成了5个微服务，觉得这样「更灵活」。结果每次策略上线要协调5个服务同时发布，回滚更是噩梦。说白了，过度拆分比不拆分更可怕。

那次重构持续了4个月，最后性能反而下降了30%。老板找我谈话：「你这是在搞科研还是在做交易？」

嗯，这话我记到现在。

1.3 第二次重构教训：忽略了数据一致性

2019年，我换了家公司，又做了一次拆分。

这次学乖了，没拆那么碎。只拆了4个核心域：行情、策略、交易、风控。

但新的问题出现了——数据一致性。

举个例子：行情服务收到一笔成交，需要同时更新策略服务的持仓、交易服务的订单状态、风控服务的额度。在单体里，一个事务就搞定了。但在微服务里，每个服务都有自己的数据库。

我当时用了最终一致性方案，消息队列异步处理。结果呢？

有一次消息队列积压，持仓数据延迟了3秒
策略引擎基于旧数据下了反向单，直接亏了20万

我的建议：

量化交易对数据一致性要求极高。如果你要拆分，必须优先考虑数据边界。我现在的做法是：强一致性的操作留在同一个服务里，最终一致性的操作才走消息队列。别为了「微服务」而牺牲数据准确性。

1.4 从单体到微服务的必然之路

说了这么多教训，你可能会问：那到底要不要拆？

我的答案是：看阶段。

阶段	团队规模	策略数量	推荐架构
初创期	1-5人	1-3个	单体架构
成长期	5-15人	3-10个	模块化单体
成熟期	15人以上	10个以上	微服务架构

说白了，不要为了技术而技术。我见过太多团队，3个人就搞微服务，结果光维护K8s集群就累得半死。

但如果你到了成熟期，微服务确实是必然之路。为什么？

独立迭代：行情团队可以独立发版，不用等策略团队
弹性伸缩：行情模块流量大，单独加机器；策略模块计算密集，单独升配置
故障隔离：一个服务挂了，不影响其他服务。我记得有一次风控服务宕机，交易服务照样跑，只是暂停了新订单——这比全系统瘫痪强太多了

最后说一句：架构演进不是一蹴而就的。我经历过两次失败的重构，才明白这个道理。你如果也在做拆分，记住三点：

先理清业务边界，再谈技术拆分
数据一致性是第一优先级
别为了微服务而微服务

嗯，这就是我的经验。下一章我们聊聊具体的拆分策略——怎么划分子域、怎么设计服务接口、怎么处理分布式事务。到时候我会拿我现在的生产架构给你拆解。