fbthrift：Facebook 的 Thrift 分支，重写编译器与异步 C++ 服务器

一个从内部演化而来的分支，不是 Apache Thrift 的发行版

fbthrift 的 README 第一句就划清界限：这不是 Apache Thrift 的分发版，而是 Facebook 内部演化分支，2014 年 2 月重新开源。它最初紧贴 Apache Thrift，但如今走向不同方向。最核心的变化是编译器被完全重写，并新增了全异步的 Thrift 服务器。这个定位直接影响你的选择：如果你期待与 Apache Thrift 生态无缝兼容，fbthrift 会带来额外迁移成本。它的价值在于 Facebook 大规模生产环境验证过的 RPC 框架，而非一个标准的 Thrift 实现。

三合一框架：代码生成、序列化、RPC

README 将 Thrift 拆成三块。代码生成器根据 .thrift 文件生成可序列化的数据结构，以及不同语言的客户端和服务端桩代码。序列化框架提供多种协议，让生成的结构跨语言使用。RPC 框架负责消息分帧、传输，并调用应用定义的函数。这三个目标服务于四个关键特性：易用性（开发者只关注 schema 和接口）、跨语言（Python 客户端连 C++ 服务器）、性能（协议和框架以性能为设计目标）、向后兼容（字段可增删且保持前后兼容）。这套设计并不新颖，但 fbthrift 的异步服务器是它区别于 Apache Thrift 的实质改进。

异步服务器的设计意图：高并发下的 C++ 服务

fbthrift 的 README 明确提到，新编译器实现了一个全异步的 Thrift 服务器。文档链接指向 cpp2 的详细说明，但仓库摘要没有展开内部机制。从依赖来看，它构建在 Folly 和 Wangle 之上，这两个 Facebook 库分别提供高性能并发原语和网络框架。异步服务器的核心价值在于，让 C++ 服务能处理大量并发连接，而不用为每个请求分配线程。这种设计适合高吞吐、低延迟的内部服务，但代价是编程模型更复杂，回调或协程的引入会提高调试难度。如果你的服务并发量不高，同步模型反而更简单。

构建方式：getdeps.py 统一管理依赖

构建 fbthrift 走 getdeps.py 脚本。在 Linux 或 macOS 上，先安装系统依赖：git clone 仓库后运行 ./build/fbcode_builder/getdeps.py install-system-deps --recursive fbthrift。然后构建：./build/fbcode_builder/getdeps.py --allow-system-packages build fbthrift。脚本会调用 CMake，输出在 scratch 区域，默认生成 installed/fbthrift/bin/thrift1（编译器）和 installed/fbthrift/lib/libthriftcpp2.a（客户端服务器库）。依赖分三层：系统（Boost、CMake、OpenSSL、Python、Zlib）、外部（{fmt}、GFlags、GLog、GTest）、Facebook（Fizz、Folly、Wangle、Zstd）。注意编译器本身只依赖 Boost、CMake 和 {fmt}，如果只用编译器可以限制依赖。CMake 选项 THRIFT_COMPILER_ONLY 控制是否只构建编译器。

Python 构建与验证：走 Docker 更省心

fbthrift 提供 thrift-python 的构建路径。README 推荐用 Docker BuildKit 容器：docker buildx build -t fbthrift-python-build -f .devcontainer/Containerfile .，然后进入容器运行构建命令。构建步骤包括安装系统依赖、构建、测试，最后用 pip 安装生成的 wheel。验证命令是 python3 -c "from thrift.python.types import StructMeta; print('thrift-python installed successfully')"。这个流程表明 Python 支持是独立于 C++ 的构建单元，但文档没有说明 Python 客户端与 C++ 服务器的互操作细节。如果你主要用 Python，需要确认生成代码的 API 是否符合预期，因为 fbthrift 的编译器与 Apache Thrift 不同。

CMake 集成：thrift_library 宏的便利与限制

在 CMake 项目中使用 fbthrift，需要包含 ThriftLibrary.cmake，然后调用 thrift_library 宏。宏参数包括 file_name、services、language、options、file_path、output_path。它会生成名为 file_name-<language> 的库，例如 Test.thrift 编译为 cpp2 时生成 Test-cpp2。这个库应作为依赖添加到任何包含生成代码的源文件。这种设计简化了构建集成，但要求项目必须采用 CMake。如果你使用其他构建系统（如 Bazel 或 Meson），需要自己处理代码生成步骤，这会增加维护成本。README 没有提供非 CMake 的集成示例。

真正的限制：依赖重、演进快、兼容性存疑

fbthrift 的明显短板是依赖链沉重。除了系统库，还必须拉取 Folly、Wangle、Fizz 等 Facebook 库，这些库本身更新频繁，且彼此版本耦合。README 显示最近一次发布是 v2020.08.24.00，但仓库最后 push 日期也是 2020 年 8 月，说明项目可能已停止活跃维护（但 archived 标记为否，需谨慎判断）。另外，fbthrift 的编译器重写后，生成的代码与 Apache Thrift 不兼容，这意味着迁移不是替换库那么简单，必须重新生成所有代码并调整 API 调用。对于只想用 Thrift 做序列化的项目，fbthrift 的 RPC 框架是多余的，Apache Thrift 或更轻量的替代品更合适。

与 Apache Thrift 的实质差异：编译器重写与异步服务器

Apache Thrift 是 fbthrift 的源头，但两者已分道扬镳。Apache Thrift 的编译器是原版，fbthrift 的编译器从零重写，这意味着 IDL 语法可能有差异，生成的代码结构也不同。fbthrift 的异步服务器是新增能力，Apache Thrift 的 C++ 服务器传统上是同步的（尽管也有异步选项，但设计不同）。如果你需要与 Apache Thrift 生态中的其他语言（如 Java、Go）互通，fbthrift 的兼容性取决于它对这些语言的支持程度，README 提到 C++、Python、Hack、Java 有强支持，但未说明与 Apache Thrift 协议的互操作性。实际选型时，应先用小规模测试验证跨语言调用是否成功。

编辑结论

fbthrift 适合需要在 C++ 服务端获得高并发异步 RPC 能力，并且愿意接受 Facebook 生态依赖（Folly、Wangle、Fizz）的团队。它不适合追求与 Apache Thrift 完全兼容、或希望轻量集成（仅用编译器）的项目。采用前应验证：确认你的目标语言（如 Python 或 Hack）在 fbthrift 中的支持成熟度，检查 getdeps.py 在目标平台上的依赖安装是否顺利，并评估未来升级时跟随 Facebook 内部演进节奏的代价。最后，fbthrift 的编译器已完全重写，与 Apache Thrift 的生成代码不兼容，迁移前必须重新生成所有 Thrift 定义。

官方来源

1. Official README
2. Project repository
3. Release notes