"Good intentions never work, you need good mechanisms to make anything happen." says Jeff Bezos.

深入理解OCAP实现(4):Exchange服务的工作流程以及如何集成到OCAP服务

作者 Lei Zhou (ArcBlock 团队后端开发工程师)

今年5月,借由一个幸运的机会,加入了ArcBlock团队成为了一名后端工程师。 能够参与OCAP服务的项目是一个让人兴奋的经历。OCAP服务在成长初期一直迭代发布新的版本,旨在让我们的OCAP服务更加的有效,功能更加强大。7月 OCAP和 Playground 发布了实时币价的新功能支持,通过Exchange服务从主要的交易所收集和提供实时的币价。今天,让我们一起来回顾一下Exchange服务的成长历程和工作流程。

Exchange服务框架

Exchange服务是一个用Elxir语言开发的应用程序,通过收集,分析和保存加密货币的价格数据。同时,Elixir在ArcBlock成立初期就成为了我们后端产品开发的首要语言。整个Exchange服务分成了四个部分,交易所API模块,规划者,发布者和文件系统。

Diagram

交易所API模块

目前,我们收集币价从主要的6家交易所,这些不同的交易所有着不同的接口和不同返回值的数据结构。对于这种情况,我们会有6个交易所的的API模块去收集和统一API返回的币价信息的格式,每个模块负责一个交易所。在被这些模块处理之后,被分析的数据保持了格式的一致性。

规划者

目前,我们从交易所收集BTC和ETH的实时币价。这些不同的支流汇集在一起作为Exchange服务的输入数据。在这里会有一个规划者去定时触发发布者,让其周期性的从交易所收集数据。如果你想做一些周期性的工作,有很多的Elixir的库可以使用,他们本质上也是基于GenServer,比如Quantum。 在Exchange服务里面我们是用Quantum,一个Elixr非常不错的定期规划处理cron-like job的库。

发布者

我们选择用Phoenix PubSub去广播消息,使用GenServer去处理事件。GenServer作为OTP的重要组成部分,简化了重复的任务操作,让程序员集中于应用程序本身逻辑。GenServer在Elixir和Erlang的世界里面应用广泛,从业务逻辑里面拆分了接口逻辑(比如webserver,一个终端的读写或者一个GUI)。

在其背后的发布和订阅的想法也是很简单的,开始于不同的进程(在这里是指Exchange的API的模块), 等待从这些模块里面被分析处理的数据返回, 然后集中组合这些模块返回的数据,再广播数据到文件系统和Amazon的kinesis。

我们选择Amazon Kinesis去加载和分析流数据,让我们即刻对收到的数据进行处理和分析,服务于Exchange服务,无需等到收集完全部数据后才开始进行处理数据。

文件系统和LKG机制

发布者广播数据到文件系统,同步到Amazon的S3上。Amazon S3在这里扮演文件的存储, 帮助我们备份,保存和恢复的角色。

当比如有API请求错误发生时候,Last know good作为一个备份,保存了每个交易所,每个币种的最新的一条数据。

为什么要监控和分析服务?

我们现在使用Datadog去建立实时互动的监控板, 发送度量指标和事件,用于操控服务和图形化服务的运行状态。

在服务层面上,监控和评估是为了系统地追踪服务的工作情况, 去度量服务的有效性。帮助我们决定当一个新的版本部署之后,我们还需要做哪些改变。监控和评估给我们做任何服务的变动提供了信息基础,也是帮助我们更明智的做决定。

对于度量指标,使用Statix去收集数据和一些我们更关心的指标,之后通过StatsD发送到Datadog,进行图像化的展示。

BTC datadog

如果在OCAP服务里面集成?

因为我们的OCAP服务使用的是GraphQL,因此就没有版本化的需要,我们可以简单的添加上新的域和类型在我们的API里面,不会影响到现有的查询语句。在这里,我添加了一个定时任务,从Amazon Kinesis周期性的获得最新的币价数据,通过一个resolver去给相应的域提供实时的币价。

了解更多的ArcBlock Exchange服务

希望读者愉快的了解我们Exchange服务整体的架构和工作流程,以及如何结合到OCAP服务的过程。在未来,在我们的服务里面,会提供更多的币价支持。

最后,如果您想要加入高质量高效率的团队,请加入ArcBlock吧!