策略代码只占量化系统的 20%——剩下 80% 是让研究可持续、交易可信赖的基础设施。本篇讲架构的两个根本决策：研究与生产怎么分离、系统怎么分层，以及单体/微服务的务实选型。
第一原则：研究环境与生产环境的分离
研究环境：交互式（Notebook）、数据宽松（可以全量拉取）、允许试错、性能不重要。生产环境：无人值守、数据严格（只走校验过的管道）、拒绝意外（任何变更走发布流程）、可靠性至上。
两者隔离的原因不是洁癖，而是保护研究结论的可信度与生产系统的稳定性：研究代码直接连生产数据库 → 一次探索性的重查询拖垮生产；生产逻辑随手改 → 回测环境与实盘环境漂移，「回测通过」失去意义。连接两个世界的唯一通道是「发布流程」：研究代码 → 代码审查 + 回测复核 → 打版本 → 部署到生产（流程见策略上线 ）。
环境一致性的三个保证：依赖锁定（同一份 lock 文件，见代码质量 ）、同一因子代码（研究与回测共用实现，禁止「研究版重写一遍」）、数据快照版本（回测引用的数据版本在生产可追溯，见因子存储 ）。
三层架构：数据层、研究层、交易层
数据层（完整设计见因子存储 与调度 ）：核心 SLA 是「17:00 前完成当日数据落地与质量校验」——它是全系统的时间锚点，迟到会连锁推迟信号、调仓与监控。数据层的事故是全系统事故之母：一条复权因子错误会让所有量价因子、所有策略同时出错，且难以追溯——所以数据层的质量检查投入产出比最高。
研究层：重点不是算力而是可复现性——每个实验可追溯到代码版本 + 数据版本 + 参数；算力按需加（向量化因子计算用不了多少），管理不当的研究环境才是时间黑洞。研究层的常见病不是「算力不够」而是「实验不可考」：跑过 200 个实验却说不清哪个对应哪份代码哪份数据——实验登记表 + manifest 是解药。
交易层的关键设计：信号服务与执行服务的解耦——信号服务输出「目标组合」（策略逻辑），执行服务负责「从当前持仓到目标组合」（下单、拆单、重试）。解耦的好处：换券商只改执行层；同一策略换执行算法不用动信号代码；风控检查插在两层之间天然清晰（限额校验作用于「订单流」而不是「目标权重」）。
微服务 vs 单体：诚实的选型
微服务的适用条件：多团队并行开发（模块边界 = 团队边界才有效）、不同模块的伸缩/部署节奏差异大（信号服务日频部署、行情网关毫秒级稳定性）、故障隔离要求高（执行故障不能拖垮监控）。
单体的适用条件：1–3 人团队、策略数少、变更频率低——一个「模块化单体」（清晰的目录结构 + 接口分离 + 单进程内分模块）的运维成本是微服务的十分之一。
最常见的错误是反过来：个人研究者搭了一个五节点的「分布式量化平台」，然后花 80% 时间修基础设施、20% 时间研究——架构复杂度必须与研究规模匹配（第 04 章因子库的同款元原则）。个人量化的推荐形态：一个进程内的模块化单体（数据/策略/执行/风控四模块）+ cron 调度 + 外部推送告警，见学习路径 的工程极简版。
演进路径：什么时候升级架构
触发升级的信号（对应升级动作）：
- 因子数 > 50 或计算时长影响决策 → 数据层独立 + 增量计算（见调度与数据库 ）；
- 策略数 > 3 且共享标的池 → 信号/执行解耦 + 子账户记账（见多策略 ）；
- 出现第一次「生产事故找不到原因」 → 结构化日志与监控先行补课（见日志与监控 ）——监控比任何架构升级都优先；
- 团队 > 5 人 → 模块边界正式化（接口契约 + 独立部署），此时微服务才开始划算。
反向的忠告同样重要：如果上面四条信号一个都没出现，你现在的「简陋」架构就是最优架构——为不存在的规模设计系统，是把研究时间兑换成工程快感的慢性手术。