随着交易实践的深入，每年动辄过万元的软件服务费对于量化入门用户而言，是一项实实在在的负担。除此以外，商业软件在可扩展性方面的限制甚多，导致许多的策略想法无法实现。
因此在设计上，平台的难点在于系统的可扩展性。要让一个系统兼容不同交易所接口，同时也要让一套开发模式兼容不同类型的交易策略。
交易所接口的调研
不同的交易所所采用的通信协议各不相同，但通信模式基本上可以抽象成两种：一种叫应答模式，一种叫订阅推送模式。
所谓应答模式，就像是HTTP请求，每个请求对应一个服务端响应。例如老虎证券的交易接口采用的正是HTTP协议来实现应答模式。然而，HTTP并非是唯一的实现方式，例如国内期货CTP平台接口，就并非采用HTTP协议，而是基于TCP连接的非通用协议。
所谓订阅推送模式，就像websocket协议，客户端与服务端建立连接后，服务端可以主动向客户端推送数据包。例如老虎证券的行情接口采用的便是websocket协议。基于C++的接口可选的方案更多，有的平台使用基于TCP发送，有的平台基于UDP发送。
站在开发者用户的角度，不需要关心传输是是基于TCP还是UDP，也不需要知道数据是用通用协议封装还是自定义协议封装。因为接口的SDK往往已经处理好数据包解析的工作。
不管对接哪个交易所平台的接口，只要理解了以上两种通信模式，就不难理解平台接口的设计逻辑。不同的平台接口，数据结构差异非常大，因此在设计本地交易系统时，防腐层设计的通用性直接影响系统的可扩展性。本文仅对系统的难点与关键点作概括性介绍，关于防腐层更详细的实现方式可参考Northstar项目源码，在此便不作展开。
策略模式的调研
由于笔者本人对量化交易的策略认识有限，且更多是基于期货市场的交易策略。因此在设计交易平台时，只考虑了基于技术指标的交易策略、基于价差的套利对冲策略两种策略模式。而且策略模式也是主要基于个人交易场景。像基金公司对持仓有要求的、基于因子进行调仓换股的策略模式，并不适用。
策略编程模式的选型
综观坊间**的量化交易平台，不管是商业软件还是开源软件，站在用户的角度看，编程模式无非就两种：一种是基于行情数据的事件驱动型架构，一种是基于策略轮询的循环计算型。Northstar采用的是基于行情数据事件驱动的编程模型，通过行情数据的刷新来驱动策略逻辑的执行。
可灵活接入行情的模拟账户
模拟账户本质上就是模拟交易与模拟结算。有不少商业软件在试用阶段仅允许用户使用模拟账户进行交易，在付费购买后又仅允许用户使用实盘账户进行交易。
在笔者看来，模拟账户对用户而言，是起到UAT环境的作用：即当用户的交易策略编码完毕后，还需要借助模拟账户来在实盘运行一段时间，以用实盘数据来对交易策略进行预生产验证。以CTP为例，不管是SimNow环境还是仿真环境，都无法用真实的行情进行实时行情同步验证。因此量化交易平台自带一个模拟账户，能接入不同的行情进行模拟交易显得尤为重要。
灵活可控的历史回放（回测）
坊间商业软件对策略回测的实现方案通常是针对某个策略进行回测。回测本质上就是历史数据的重放。大部分商业软件不知道是出于哪方面的考虑，都不支持历史回放功能。但在笔者看来，历史回放是一个*自然直观的回测方案，它甚至不需要单独实现一个回测模块。只需要设置好回放时段，配上不同的回放精度和回放速度，便可以对策略进行验证。如果多个策略绑定的是同一个合约，一次回放便可实现多个策略同时回测的效果。若是一个策略绑定了多个合约，只需要选择同时回放多个合约的数据。
可视化设计的思考
不是每个量化交易系统都需要做可视化设计，也完全可以黑箱化运行，仅通过日志文件来记录程序的状态变化过程。只是当系统越来越复杂时，一个可视化界面让用户更易用更高效。比如当策略涉及几十个指标值输出时，一个好的可视化界面会更容易定位问题；同时，可视化界面能对策略研发起到关键作用。
