Graphene 源码阅读 ~ 源码结构

一般拿过一个项目我是习惯先了解一下项目的目录结构, 看一看项目是怎么组织依赖库, 构建脚本, 以及头文件和源代码文件的, 这样能够对整个项目结构大概有个数, 除了能够了解这个项目包含哪些模块, 模块与模块之间的调用关系之外, 还能在后面阅读代码时碰到对符号的引用时, 大概知道到哪里找它的定义, 对阅读和理解代码帮助会很大.

所以继前一篇 基础知识 之后, 本篇就来过一遍项目源码结构. 前一篇说了 Graphene 项目的源码已经并入 bitshares-core 项目维护了, clone 下来 bitshares-core 项目之后, 项目根目录的文件和目录很多, 但不难看出最重要的两个目录就是 libraries/ 和 progams/.

programs/ 目录组织比较简单, 一目了然. 不仅如此, 代码量也少, 基本上每个程序就一个 main.cpp 源文件, 所以重中之重还在 libraries.

libraries 的代码组织的可谓井井有条, 让人看了非常舒服:

libraries:

chain/
    include/graphene/chain/
                    protocol/
    protocol/
db/
    include/graphene/db/
app/
    include/graphene/app/
net/
    include/graphene/app/
wallet/
    include/graphene/wallet/
plugins/
    witness/
        include/graphene/witness/
    market_history/
        include/graphene/market_history/
    delayed_node/
        include/graphene/delayed_node/
    ...
fc/

可以看到, libraries/ 下的几大模块一目了然, 明显看名字就知道是做什么的. 而且代码结构高度一致, cpp 文件都位于各自一级目录, hpp 文件都位于各自的 include/graphene/ 目录下 . 首先是 plugins 目录, bitshares 的每一项功能都被设计成可拆卸的, 我们可以选择只运行一个稳定节点 (delayed_node) 而不成为见证人, 也可以选择是否要包含历史查询功能. 这能帮助只有某些需求的人节省大量系统资源, 非常灵活.

另外不得不说的一个模块是 fc, 这实际上是 git submodule 引入的外部模块, fc 最初也是 BM 开发的, 现在是并到 bitshares-fc 仓库了, fc 是基础工具库, 提供了一般编程过程中会涉及到的异步, 多线程, 结构体序列化等方便的功能.

chain 模块稍微有点不一样, 它还包含了一个 protocol 子模块. 在 protocol 子模块中能看到熟悉的字眼如 block, transaction, operations... 另外 chain 中还包含了两个重要的类: block_database 和 database, block_database 负责操作区块数据, database 实际上是继承了 db::object_database 类, 同时负责操作数据索引以及调用 block_database 操作区块数据.

app 和 net 提供的也是核心功能, 包括节点发现, p2p 连接, rpc 服务提供, 消息 handler (交易处理) 等. wallet 也自不必多说, 处理钱包文件等.

最后是 db 模块, 这里面定义了所有 bitshares 中的对象的基类以及索引结构, 上面说的 ob::object_database 就是直接操作索引的类, 加上操作数据的 chain::block_database 类, 就构成了 bitshares 数据库的主要部分.

Ok, 本篇就这样吧, 后续再逐个剖析下上面的各个模块