architecture.png

业务流

system_logic_flow.png

  • 客户端:

    1. 生成账户
    2. 导入账户
    3. 构建、签名、发送交易
    4. 查询余额、交易记录
  • 节点

    1. 提供查询:余额、gasPrice、account nonce
    2. 广播交易
  • 服务端

    1. 提供接口:节点信息、历史交易
    2. 消息推送
    3. 解析账本信息(历史交易记录)

钱包后端模块

后端由六个模块组成,分别是对前端 APP 提供接口服务、定时任务更新监听地址交易状态、同步解析账本信息到中心数据库服务、前端接口服务查询区块链信息的 gRPC 服务、最新区块监听服务(用以充值提醒)、区块链节点。

  • WalletAPI: 用以给前端提供接口,主要接口有查余额,交易状态及构建交易。
  • Ledger: 同步区块数据到 elasticsearch 方便检索,对 gRPC 服务提供查询余额、比特币的 UTXO 等
  • Node: 提供 RPC 服务,监听最新区块、查询以太坊账户信息、必要的区块数据同步解析到中心数据库
  • MQ: RabbitMQ 作为节点和 RPC 监听最新区块的消息中间件。包含消息生产者和消费者。
  • WalletRPC: 微服务通讯服务。作为区块链节点和钱包接口交互的跳板中间件,抽象节点服务区块链层。
  • ScheduleJob: 追踪监听地址尚未达到限定确认数的交易;获取第三方行情数据。

模块间事件驱动和数据流

模块之间的事件驱动及数据流,分三大模块:地址登记、充值到账消息推送、钱包操作和信息查询。系统间消息和数据流通过 MQ 和 RPC 链接。

登记地址

我们需要给钱包推送消息(充值消息或系统公告)故钱包所属的设备标识需和钱包地址关联。

  1. 客户端请求 WalletAPI,存储地址在钱包设备有关信息,比如设备标识
  2. WalletAPI 通过 gRPC 调用 WalletRPC 服务把需要监听的地址同步到 elasticsearch

RPC 服务端 (MonitorAddressRPC) 调用 SQL2Es 把钱包对外的网关 API 登记的地址同步到 elasticsearch ,方便充值监听检索。

通知

消息推送有两类,分别为系统公告和充值到账消息。系统公告放在运营后台,充值到账依赖节点最新区块的回调。

  • 最新区块消息生产者:节点产生新区块的回调,RabbitMQ 消息生产者把区块所有的交易信息推送到 MQ broker 。
  • 接受并处理最新区块:取回 MQ broker 中消息体,并把 raw block message 通过调用对应的 RPC 服务处理对应币种的充值。

RPC 服务端 (WalletNotifyRPC) 处理消息体,并在 elasticsearch 中检索是否存在与系统有关的交易,存在则调用第三方消息推送服务商触发推送。

钱包信息查询和操作

钱包信息查询包含余额查询、单条交易状态查询和历史交易记录查询,钱包操作只涉及到提现。

前端网关 API 服务职责不涉及与区块链节点的交易,通过 RPC 服务端 (WalletMiddlewareRPC) 获取区块链相关服务。

不同公链实现有所差异:

  • 比特币 (UTXO base) 的公链如果不是通过节点软件集成的钱包不能直接获取余额,而以太坊 (Account base) 可通过节点获取余额及账户交易索引。
  • 交易记录:比特币和以太坊都需要把公链的账本解析到中心数据库。

设计到的 RPC 方法如下:

  • 余额:Balance 比特币在解析好的 elasticsearch 数据库中获取,以太坊请求节点获取。
  • 历史记录:GetTxes 比特币和以太坊都从解析好的 elasticsearch 数据库获取
  • 交易状态:GetTx 比特币和以太坊请求节点获取
  • 构建交易: ConstructTx 比特币去解析好的数据中查找 UTXO 并去节点校验;以太坊从节点获取余额和账户交易索引构建

区块链账本数据同步

解析区块链账本的所有区块,结构化并同步到中心数据库 elasticsearch 。比特币的余额和 UTXO 、以太坊的历史交易是钱包业务涉及到的数据。

定时任务

  • 汇率数据抓取
  • 追踪监听地址交易状态

钱包需要第三方交易所汇率数据展示行情和资产估值统计,定时任务抓取第三方 API 刷新缓存数据。另外系统追踪监听地址尚未达到限定确认数的交易。

系统结构体系

wallet_service.png

写在最后

architecture.jpg

参考链接