我应该如何为事件采购序列化域模型快照

Eti*_*veu 7 java serialization snapshot cqrs event-sourcing

我们正在使用LMAX Disruptor构建应用程序.使用事件源时,您经常希望保留域模型的定期快照(有些人称之为内存映像模式).

我需要一个比我们目前用于在拍摄快照时序列化我们的域模型更好的解决方案.我希望能够以可读的格式"漂亮地"打印这个快照以进行调试,我希望简化快照模式迁移.

目前,我们正在使用Googles的Protocol Buffers将我们的域模型序列化为文件.我们选择了这个解决方案,因为协议缓冲区比XML/JSON更紧凑,使用紧凑的二进制格式似乎是一个很好的想法来序列化一个大的Java域模型.

问题是,Protocol Buffers是针对相对较小的消息而设计的,我们的域模型非常大.所以域模型不适合一个大的分层protobuf消息,我们最终将各种protobuf消息序列化到一个文件,如下所示:

for each account {
    write simple account fields (id, name, description) as one protobuf message
    write number of user groups
    for each user group {
        convert user group to protobuf message, and serialize it
    }
    for each user {
        convert user to protobuf message, and serialize it
    }
    for each sensor {
        convert sensor to protobuf message, and serialize it
    }
    ...
}
Run Code Online (Sandbox Code Playgroud)

这很烦人,因为操纵异构protobuf消息流很复杂.如果我们有一个包含所有域模型的大型protobuf消息会更容易,如下所示:

public class AggregateRoot {
    List<Account> accounts;
}

--> convert to big hierarchical protobuf message using some mapping code:

message AggregateRootMessage {
    repeated AccountMessage accounts = 1;
}

--> persist this big message to a file
Run Code Online (Sandbox Code Playgroud)

如果我们这样做,可以很容易地绘制快照:只需阅读大的protobuf消息,然后使用protobuf的TextFormat对其进行漂亮打印.使用我们当前的方法,我们需要逐个读取各种protobuf消息,然后再打印它们,这更难,因为流中的protobuf消息的顺序取决于当前的快照模式,所以我们的漂亮打印工具需要注意这一点.

我还需要一个工具,在我们的域模型发展时将快照迁移到新的快照模式.我仍然在研究这个工具,但这很难,因为我必须处理各种protobuf消息流,而不是只处理一个大消息.如果它只是一个大消息,我可以: - 获取快照文件 - 将文件解析为一个大的Java protobuf消息,使用.proto模式为前一个快照版本 - 将这个大的protobuf消息转换为一个大的protobuf消息为新版本,使用Dozer和一些映射代码 - 使用.proto模式为新版本在新文件中编写此新protobuf消息

但由于我正在处理各种类型的protobuf消息流,我的工具需要以正确的顺序处理此流.

所以,是的...我想我的问题是:

  • 你知道任何可以将大域模型序列化到文件中的序列化工具,没有protobuf的限制,可能使用流来避免OutOfMemorryErrors吗?

  • 如果您使用事件源或内存映像,您使用什么来序列化您的域模型?JSON?XML?protobuf的?别的什么?

  • 我们做错了吗?你有什么建议吗?

Nit*_*thi 5

我定义问题解决方案的方法是将"规范"与"传输语法"分开.现在,我们已经定义了我们需要处理有线表示的消息规范,这可能支持机器效率和人类可读性之间的不同需求.

  • 二进制模式 - 最简单但不可读
  • character - 表示命令和参数更具可读性,并提供强大的存储空间
  • 明文 - 说出调试目的

解决方案必须提供可切换的行为.我们可以将我们的解决方案建立在ASN.1和相关的工具集上,这与工具语言和平台无关,尽管Java(Bouncycastle等人)提供了丰富的生态系统.我们在网络上使用了相当大的消息blob而没有已知的问题:)

希望它能给出一些指示.


Juk*_*kka 2

只是从我的头脑中(实际上不知道你的快照文件会有多大):

您尝试过 Google 的 Gson JSON 库吗?它似乎提供版本控制(https://sites.google.com/site/gson/gson-user-guide#TOC-Versioning-Support)和流媒体(https://sites.google.com/site/gson/ Streaming)用于基于 JSON 的文档。

现在我们正在讨论 JSON,那么如何将快照存储在 CouchDB ( http://en.wikipedia.org/wiki/CouchDB ) 文档中呢?

JSON 可能会占用更多空间,但它是可读的。