---
title: FlatBuffers 的自描述性问题
date: '2014-08-18 13:18:40'
draft: false
summary: 像 FlatBuffers、Protocol Buffers 这类二进制格式如果不够自描述，就会把接口演进和客户端更新成本继续压回业务方身上。
slug: flatbuffers-not-self-describing-enough
syndication:
- platform: Weibo
  url: https://weibo.com/1648815335/BiTIx8ibY
- platform: Weibo
  url: https://weibo.com/1648815335/BiQglm6Z9
tags:
- serialization
- flatbuffers
- protocol-buffers
- api
topics:
- software-engineering
type: post
---

看了一下 `FlatBuffers` 之后，我当时没有立刻倾向采用。原因不只是“它还不够成熟”，更关键的是：这类数据格式往往不够自描述。

如果一种格式不是自描述的，就意味着协议设计、字段解释、版本兼容这套事情，最后还是得由业务方 `case by case` 去处理。这样一来，客户端更新成本就很高，接口演进也会变得更脆弱。

这也是为什么很多时候，二进制格式在纸面上看起来非常高效，但一旦放进真实系统里，优势会被大量协作成本吃掉。

如果最后为了弥补这些问题，又在 `Protocol Buffers` 之类的格式里再打包一层 `JSON`，其实就已经说明：你真正缺的不是“编码效率”，而是更稳定、更清晰的语义边界。

所以我对这类方案一直有个基本判断：如果它不能很好地处理自描述和演进问题，那它就更适合非常明确、相对稳定、由同一团队强控的接口场景，而不适合作为大范围协作接口的默认解法。