前言
上期我们分享了从0开始搭建交易系统，分析了系统的结构和重点模块。今天我们继续分析交易系统中的API网关。
既然是做交易系统，那么API是比不可少的部分；API的稳定性和易用性决定了交易系统的稳定和扩展能力。市面上的API有很多，从市场上来区分有传统金融的和数字货币的。传统金融交易所提供的API易用性比较差，所以就有很大第三方公司做二次封装提高了易用性。当然每家的效率都不一样，擅长的领域也不一样。数字货币每家交易所都有自己的API，因为还在发展早期，所以API也是不断改进的过程，目前看下来做得比较好的API就是OKEX和Coinbase的。整体来看数字货币市场比传统金融在技术上和效率上要差一点，毕竟真正发展起来的时间还太短的，相信未来会越来越好的。
接下来我们以数字货币市场为主来进行分析。
如何解决API网关适配
我们知道每一家交易所的API设计都不一样，这里的不一样不只是字段名称的不一样；差异性主要体现在字段名称，交互方式，完善性方面；甚至有时候同一个交易所同类性质的接口字段都不一样。所以这就为我们解决API网关的易用性带来了难度。
火币的例子：
查询账户列表 /v1/account/accounts
{
监控账户变化 accounts.update#${mode}
{
OKEX的例子：
查询账户列表 /api/spot/v3/accounts
{
OKEX这一点就做得很好，获取账户的时候就把资产返回了，火币还得单独去拉资产接口。
通过上面简单的例子，如何设计网关的类模型就非常重要了。直接上图：
核心思路就是网关接口+网络交互+适配器；最终形成每个交易所不同网关，甚至是每个交易所不同市场不同网关。
如何提升API网关效率
我们知道每个交易所的API和推送数据都是有限频的，不同交易所也不一样。所以如何最大化让自己的交易系统效率达到限频率极限非常重要。不管是做高频还是低频交易，时间都是盈利的重要因素。
目前数字货币市场数据对接主要以Websocket+Rest Api的方式，所以我们在网关底层在选择这两种方式的交互框架就非常重要了。
- Websocket框架： 对于Websocket对接重点关注的是连接稳定和数据收发效率，切记避免使用同步阻塞的方式进行收发数据效率真的不高而且容易卡住。会写JAVA的代码的知道Netty是socket最优的框架，稳定易用，而且数据接收和发送效率也非常高。所以Websocket可以采用Netty框架
- Rest Api: API接口的对接可以使用OKHttp，这个框架易用并且做了连接优化，连接缓存可以建设接口交互的时间消耗
- 线程优化：对于Websocket接收推送数据的优化这里可以使用线程进行数据回调给上层应用，但要注意的是同频道的回调线程只能有一个，达成同频道的执行同步性(因为量化交易的行情，账户，订单变化要保持顺序性，不然会执行错乱)。
- 网关边界：网关内部实现切记不可参与上层业务的功能，只提高交易所交互即可。网关本身太过复杂将会影响上层应用的灵活性
结语：
网关的易用性和效率是关键，所有违背这两个方面的因素都应该删除。
