DTeam 团队日志

Doer、Delivery、Dream

Dust:当Truffle遇上数据库开发

胡键 Posted at — Mar 20, 2019 阅读

以太坊开发中,Truffle几乎是事实的标准,用它可以方便地开发、测试和部署智能合约。虽然它一直对外宣称Dapp开发框架(隐含前后端一体化,结合node),但我认为它最大的功绩就是将合约的整个生命周期有效地管理起来。因为,考虑到不同项目团队偏好的技术栈不一样,前后端完全可能是另外一套完全不同的选择。但合约开发,你没得选。

因此在我看来,稍微复杂的区块链项目基本组成如下:

这里的合约工程即是Truffle大显身手的地方,虽然你也可以在一个使用web3j的后端工程中包含和管理合约,但我认为这种方式远比不上用Truffle来得方便。

从这个模式中是否看到传统项目中类似的场景,比如项目中数据库制品的管控,即项目中数据库部分的开发。稍微复杂一点的项目都会涉及到存储过程、触发器等数据库制品的开发。并且,对于创业项目,其早期应该尽可能采用简单架构,避免一上来就是微服务、事件驱动。用一些数据库的方式解决问题,看似老旧和扩展性存在瑕疵,但好处是实现快速,节约了人力和时间。待概念验证成功,开始盈利之后在做迁移也不会有太多问题。况且,如果对这部分有良好的管控,对于后期迁移也是好处多多。

本着这样的想法,我开始思考是否可以将Truffle的模式引入到传统项目的开发中,用类似的工具管理项目的数据库制品,于是一个Demo性质的工具诞生了:dust。这样,一个项目的结构就变成:

明眼人会提到,目前已经有类似flyway这样的db migration工具可以帮助我们来管理项目中数据库部分,那为啥还要有dust呢?这是个好问题!也正是因为有这样的疑问,dust也仅止于demo程度,只是用来满足我看到Truffle之后想要实现类似工具管理项目中数据库制品的“心瘾”。

不过,相比起flyway,dust还是有一些不同之处:它集成了一组成熟的工具集,并提供了一套解决方案来管理数据库制品的整个生命周期,即:“创建 -> 测试 -> 部署 -> 升级”。甚至它也将flyway也纳入其中,作为其底层支撑。

dust集成了:

它的基本使用非常简单自然:

  1. 创建Dust工程。
  2. 开发数据库制品,如表、存储过程、函数、任务、触发器等。
  3. 完成相应的测试代码。
  4. 本地运行测试。
  5. 部署数据库制品到不同的环境。

关于其详细使用,可以访问它的github仓库。在后续的内容中,我将简要说明一下dust的实现机制,满足有兴趣进一步了解其细节的读者的胃口。

CLI

dust是一个cli应用,因此选择好的cli框架会让整个事情事半功倍。在Java工具集中,picocli算得上是颜值担当,不仅支持常见cli系统的命令语法,而且还支持色彩。其实现效果并不比其他平台中流行的cli框架差。

dust本身的命令系统并不复杂,标准的:Command + SubCommand的实现,这一架构可以用picocli轻易做到。而且,还自动生成帮助系统,如下图。

image.png

具体实现请参见picocli文档和dust的实现。

dust工程

dust工程(使用create子命令创建)本质上就是一个gradle工程。创建它的过程很简单,就是从dust执行文件中资源的工程模板复制到指定目录即可,参考下面的代码:

private void copyFolder(Path dest) throws IOException, URISyntaxException {
    Path src = FileSystems.newFileSystem(URI.create("jar:" + getClass()
                    .getProtectionDomain()
                    .getCodeSource()
                    .getLocation())
            , new HashMap<>()).getPath("/template");
    Files.walk(src).forEach(source -> copy(source, dest.resolve(src.relativize(source).toString())));
}

private void copy(Path source, Path dest) {
    try {
        Files.copy(source, dest, REPLACE_EXISTING);
    } catch (Exception e) {
        e.printStackTrace();
    }
}

有了模板工程,又因为是gradle工程,有经验的开发者几乎可以不再需要使用“dust”命令了。但是,我想更进一步,就如同Truffle本身也是NPM工程,但也一样能用“Truffle deploy”这样的方式运行。

实现这一步有一个投机取巧的方法,事先在模板工程中写好相应的gradle task,接下来用picocli的command封装,直接在程序中触发gradle task调用即可。这里就用到了gradle-tooling-api。但这里需要留意向task传入参数的方法,代码如下:

@Override
public void run() {
    Path projectPath = Paths.get(".").toAbsolutePath().normalize();
    try (ProjectConnection connection = GradleConnector.newConnector().forProjectDirectory(projectPath.toFile()).connect()) {
        connection.newBuild().forTasks("deploy").setJvmArguments("-Dexec.args=" + datasource)
                .setStandardOutput(System.out)
                .setStandardError(System.err)
                .run();
    }
}

留意其中的setJvmArguments。

这样,你就可以用类似“dust deploy”的方式来触发build.gradle中deploy任务的执行了。这同样是grails这类框架的实现思路。

测试代码

这部分很简单,因为模板工程中引入了Spock依赖。在使用时,开发者只需在test目录下创建spock specification,然后运行“dust test”就能触发。当然,其背后仍然是触发“gradle test”这个任务啦。

本地测试环境

一般来讲,涉及到数据库的测试环境都不那么友好,然而testcontainers的出现给大家带来了一丝曙光。其原理跟上面说的一样,引入相应依赖,直接在测试代码中使用即可。最后由“dust test”触发。

部署脚本

部署采用的是flyway的Java-based migrations,同时也采用其命名规范。我个人推荐“Versioned Migrations”,不建议采用“Repeatable Migrations”。因为在实际情况中,后者使得制品历史消失了,本身已经违背了引入Migration的目的。而且,DML类的变动总涉及到数据的迁移,因此坚持“一直前向”是最适合的策略。而且,为了避免频繁修改脚本,我建议不要在项目早期引入dbmigration,而是待数据库制品都相对稳定时,再开始不迟。

为了达到类似Truffle部署脚本的效果,项目模板工程预置了三个文件:

一般来讲,这三个文件不需要dust使用者关心,故请不要去删除或修改它!!!关于部署脚本,很简单,继承DustBaseMigration就好了:

public class V1__CreateUser extends DustBaseMigration {
    @Override
    protected String[] files() {
        return new String[]{
                "./artifacts/myuser.sql"  // 数据制品文件名
        };
    }
}

迁移脚本中要求实现的 files() ,其指定了数据库制品的执行顺序,甚至你也可以在 artifacts 目录下添加数据初始化文件,然后通过部署脚本完成部署。如:

@Override
protected String[] files() {
    return new String[]{
            "./artifacts/myuser.sql",         // 创建 myuser 表
            "./artifacts/insert_myuser.sql",  // 插入数据
    };
}

是不是有了点Truffle Migration脚本的感觉了?

由于迁移脚本采用的是 flyway 的 Java-based migrations ,若发现当前提供的 DustBaseMigration 类无法满足你的要求,请直接使用 flyway 提供的相应工具类。

哦,忘说了,dust在迁移时会自动baseline,同时设置迁移版本为0,因此创建迁移脚本时V后的数字务必大于0。

环境

这个简单,在项目模板中引入dust-conf.json,形式如下:

{
  "development": {
    "url": "jdbc:postgresql://127.0.0.1:5432/earth_test?useUnicode=true&characterEncoding=utf8",
    "user": "earth_admin",
    "password": "admin"
  },
  "production": {
    "url": "jdbc:postgresql://127.0.0.1:5432/jupiter_test?useUnicode=true&characterEncoding=utf8",
    "user": "jupiter_admin",
    "password": "admin"
  }
}

是不是越来越像Truffle了,哈哈!

安装脚本

要将dust发布成命令行格式,还需完成最后一步:dust运行脚本的编写,这里我们可以求助于gradle的application插件。它提供了几个任务自动完成相关工作:

模板工程的build.gradle

最后说说模板工程的build.gradle,因为它需要进行一些定制才能实现我们需要的目录结构: image.png

虽然是gradle工程(严格的说是gradle groovy项目工程,java工程的超集),但是不是跟常见的目录结构不一样?这其中奥秘就在于下面两行:

sourceSets.main.groovy.srcDirs += ["migrations"]
sourceSets.test.groovy.srcDirs += ["test/groovy"]

总结

至此,整个Truffle的面向数据库开发的克隆版本就这样搭建完成了,挺好玩的吧,希望大家能喜欢。