NautilusTrader · 系统总图与核心组件

Ⅱ · 框架解剖 — 2.1

先看系统边界：行情、策略、风险、执行与账户状态在同一内核里各自负责什么。

NautilusTrader 的核心不是一个策略类，而是一个由 NautilusKernel 装配的交易运行时。外部适配器负责连接数据源与交易场所；Kernel 内部负责把行情、订单命令和订单事件送到恰当的组件，并维护可供各组件读取的交易状态。

组件图同时标出边界与关系：外部连接器不承担策略逻辑；策略不直接连接场所；订单事件与行情事件都可以回写共享状态并通知订阅者。

图中的箭头有四种含义：行情和订单事件是输入或发布的事实；订单命令是策略发出的动作；Cache 是共享状态；持久化是可选的状态保存边界。读图时先区分这些关系，再看组件名称。

组件	在系统中的职责
`DataEngine`	接收并规范化报价、成交、bar、盘口和自定义数据；管理订阅与数据请求。
`MessageBus`	通过主题、命令和事件把消息交给订阅者或目标端点。
`Cache`	保存品种、账户、订单、持仓和最新市场数据等共享状态，并提供索引读取。
`RiskEngine`	在订单进入执行通道前进行字段、数量、交易状态和限速等预交易检查。
`ExecutionEngine`	把命令路由到执行客户端，处理场所回报，并协调订单与持仓的更新。
`Portfolio`	由账户、订单、持仓和市场数据事件推导余额、敞口、保证金及盈亏等组合状态。
`Trader`	注册策略、actor 与执行算法，管理它们的生命周期和事件订阅。

Strategy 位于 Trader 管理的用户组件一侧。它接收市场数据或订单事件，读取必要状态，再调用订单接口提交命令；它不需要直接处理网络连接或场所协议。

Cache 和 MessageBus 解决的是两个不同问题：前者回答“当前已知状态是什么”，后者回答“刚刚发生了什么，应通知谁”。例如，报价到达后可先写入 Cache，再按主题发布；策略在回调中既能使用本次报价，也能读取账户、订单或持仓的当前状态。

状态查询不是消息回放，消息回放也不等于状态查询。把两者分开，策略、风控和执行组件才能对同一对象状态使用一致的口径。

三种环境共享 Kernel 与策略接口，变化集中在数据客户端、执行客户端和时钟等边界。Sandbox 说明这不是简单的“回测 / 实盘”二分，而是可以把实时数据和模拟执行组合成独立运行环境。

官方架构文档将可靠性、性能、模块化、可测试性、可维护性和可部署性列为质量属性官方文档。事件驱动、端口与适配器、故障后由外部监督进程恢复等设计选择，都是为了让上图里的职责边界可以在不同环境中替换或监控，而不是额外的一套功能。

单个节点中会影响交易决策的核心处理按确定顺序推进；网络、日志和持久化等 I/O 可在外围异步工作后再把结果送回核心。这是事件顺序与生命周期设计的一部分，后页会在行情与订单两条路径中具体展开。