"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模块，规划者，发布者和文件系统。

交易所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，进行图像化的展示。

如果在OCAP服务里面集成？

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

了解更多的ArcBlock Exchange服务

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

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