尽管 XML 在数据编码方面尤为突出，仍然有很多情况下效率不高成为了阻碍，这是由编码 / 解码的效率不足与所占用的空间两方面所造成的。流行的二进制序列化格式有得到广泛使用的 ASN.1， Google 的 ProtocolBuffers，以及 Facebook 的 Thrift 。
一个新的格式现在为 GitHub 的后端提供支持：BERT ，它由 Tom Preston-Werner 在 Erlang 用于编码节点间通讯术语的外部术语格式(ETF) 的基础上所构建。
BERT 对 ETF 进行了扩展，加入了字典，时间和正则表达式等复杂数据类型。
BERT 不同于 ASN.1 与 Protocol Buffers 之处在于其格式不要求一个模式或者是 IDL 规范。Tom Preston-Werner 解释这使得 BERT 就好像是 JSON 这一思想的二进制版:
我喜欢 JSON。我喜欢抽取一种语言的子集并用它来促进进程间通信这种概念。这使我想起我关于 Erlectricity 所做的工作。两年以前我为 Erlectricity 写过一个 C 扩展来加速 Erlang 的外部术语格式的反序列化。
[…] 如果我将 Erlang 的外部术语格式的公共部分抽取出来，让它成为进程间通信的标准，会怎么样呢？如果让 Erlang 拥有像 JavaScript 的 JSON 那样的相同的事物又会怎样呢？如果能在这一格式的基础上构建一个 RPC 协议，又会如何？这些东西看起来会像什么样子，能简单的实现吗？
BERT-RPC 允许对托管在 BERT-RPC 服务器上的代码远程调用，它使用 BERTs 来编码 (节点的) 协商，并返回调用的值。Tom 提到了 BERT-RPC 的一些特性：
- 同步及异步的调用 […]
- 流 (来或往)
- 缓存指令
Ruby 代码可通过使用像 Ernie 这样的 BERT-PRC 服务器来获得。
已有现成的 BERT 和 BERT-RPC 规范。至于 Ruby 和 Erlang 实现的其它语言可替代实现包括 BERT for Javascript ， Python ，以及其它。
你更倾向于 BERT 这样的无模式方案呢，还是像 ASN.1 和 ProtocolBuffers 这样的基于 IDL 的选择？
查看英文原文： BERT as Dynamic Alternative to Protocol Buffers/Thrift
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论