背景
Xronos是基于宽界(QuantWorld)的进阶版本非开源量化交易系统，针对宽界的设计瓶颈而设计的系统。宽界系统的瓶颈：
- 过于依赖分发器。分发器承担了大量的事件分发任务，导致队列的消息不能及时被消费，最终导致各类消息被消费时与入队时有比较大的延迟（毫秒-秒级别），这是无法容忍的。如果某个subscriber执行的时间过长，则大大影响系统性能，这种同步且阻塞的机制是核心组件的上巨大缺陷。
- 过于依赖多线程。前面的文章有提到过并发和并行的区别，过于依赖并发的多线程容易导致共享内存的争抢. 对于共享内存，我们可使用原子性操作避免。即便如此，在某个线程在执行任务时，另一个线性却修改了共享变量，此时影响了当前线程对共享变量的读取，这样无法容忍。但如果对线程加锁，又会影响执行效率，即此时有线程等待或者自旋，浪费不少资源。
- 单机系统设计。单机系统设计可以在小系统上设计，但是较为庞大的系统设计是需要切分组件，服务拆分的, 而微服务设计则满足这个需求. 多个服务的拆分, 且服务之间使用消息中间件异步通信, 使得服务之间的耦合性更低, 服务消费能力更强, 执行效率更高.
- 事件只消费一次。当初宽界设计之初，没有使用
Kafka等消息中间件有几个考量，一是容易加大系统复杂度，二是Kafka的性能并不能达到自己所需（Kafka是一个堆依赖性高的消息中间件），因此自设计了一个消息分发器。在消息分发的时候并没有将事件保存，导致后续的回测系统难以开展设计，不仅加大了调试难度，也加大了策略的风险。 - JVM 频繁GC问题。JVM频繁GC问题会导致系统延迟太高（毫秒级），响应时间增大，因此系统在内存管理，JVM调优，以及系统设计上，程序编码上需要更加地精细.
针对以上五个问题，都会在Xronos中解决。
架构设计
设计原则
- 服务低耦合, 使用高速消息中间件
- 单机单线程, 多机(JVM/Machine)并行
- Consumner centric: 消费者pull模式
- Lambda架构: 尽可能地无状态执行
- Off-Heap: 降低GC频率
Xronos Architecture
