从签名数字加密领域转到金融交易领域，一晃过去2年多了。接触到的交易系统细下想来也有3-4套了，不同架构不同风格的交易系统，如今再回头去看，去体会，总能有些新的感悟。
有的系统几经迭代，经历了十几年的金融交易考验，早已很完善，可代价就是经常改动一小点便是牵一发而动全身，维护难度几何倍增，越是后来人学习维护成本越高。有的系统虽然简洁，可是总和业务牵扯太多，稍微迭代几次，就会不可避免穿插了各种“特殊”业务需求，本来纯粹的系统也变得不存粹了，这也是很多时候的无奈之举，各种原因都有。
但是实话说，和业务相关太多了，终究是交易“上层”，仍非核心。只是对于真正的外部调用者，看起来处理业务的那个系统就是核心了。不过对于偏执技术的我来说，那也只能算是业务核心，真正的技术核心是处在其下更通用的“引擎”核心。每套这样的交易系统都会有这样一个“引擎”，一般由非业务技术去开发，很纯粹的一套组件接口和独立运行机制，其上的业务核心才是大多数金融科技公司开发人员日常面对维护的对象吧。
说起这样一套“引擎”核心，可以很自然想到，它就是提供几种基础的机制。
1、外部调用者如何接入调用，这是接入机制。
2、系统内部如何通信，何种协议，这是引擎内部具有的通信协助机制。
3、系统内部与外部的通信机制，或者说协议，这个可以和内部一样，也可以再另外设计。
4、标准的网络连接机制，网络包发送接收机制等，具备基础的网络数据传输能力。
仔细想下，具备这几种能力的核心，相当于“一剑通万法”，只要具备有这样能力的一个核心，不光是金融交易，任何别的领域或许都能用上，只要这种核心接口服务暴露的足够“抽象化”。
我个人接触到的核心交易系统，只有一套是Java，因为原团队是Java技术栈，又是电商出身，很自然的选型也是Java；其余几套都是C/C++,毕竟传统金融领域已经很成熟，如果业务上没什么大差别，比的就是性能速度，C系还是无出其右的。
这样一想，自然我也打算用C系语言开整了。又想想近几年越来越火的go，其实也不错。但是选自己熟悉的毕竟好点，而且以C++作为基准语言，外可接python, go, 扩展会相当方便。
接下来边想边写，行文会比较天马行空，基本想到啥写点啥，一点一点从零开始。
