1.1 ProtoBuf 的局限性#

ProtoBuf 是优秀的序列化协议，但它有一些限制：

• 仅定义数据结构：ProtoBuf 主要关注 Message 定义，服务定义（Service）是后来才加入的
• RPC 框架绑定：使用 gRPC 时，你被绑定到 Google 的生态（HTTP/2、gRPC 协议）
• 类型系统有限：不支持某些复杂类型（如 Set）

1.2 Thrift 的核心优势#

Thrift 是 Facebook 开源的跨语言 RPC 框架，它的设计目标是：

底层逻辑：Thrift 不仅是序列化协议，更是完整的 RPC 解决方案。它包含：

• IDL 层：定义数据结构和服务接口
• 协议层：多种序列化协议（Binary/Compact/JSON）可选
• 传输层：多种传输方式（Socket/HTTP/FramedTransport）可选
• 服务端模型：多种并发模型（Simple/ThreadPool/NonBlocking）可选

与 ProtoBuf 的核心差异：

• Thrift 是”全家桶”，ProtoBuf 是”单一工具”
• Thrift 的协议层和传输层可以自由组合
• Thrift 原生支持更丰富的类型系统（Set、Exception）

2.1 基础类型#

Thrift 支持的基础类型比 ProtoBuf 更丰富：

1
// 布尔型
2
bool is_active
3

4
// 整数型（有符号）
5
i8  tiny_num    // 8位，对应 Go 的 int8
6
i16 small_num   // 16位，对应 Go 的 int16
7
i32 normal_num  // 32位，对应 Go 的 int32
8
i64 big_num     // 64位，对应 Go 的 int64
9

10
// 浮点型
11
double price    // 64位浮点数，对应 Go 的 float64
12

13
// 字符串和二进制
14
string username // UTF-8 字符串
15
binary avatar   // 二进制数据（对应 Go 的 []byte）

底层逻辑：Thrift 的类型系统直接映射到各语言的原生类型，不像 ProtoBuf 需要通过 varint 编码优化。

2.2 容器类型#

Thrift 支持三种容器类型：

1
// List：有序列表，允许重复
2
list<string> hobbies
3

4
// Set：无序集合，不允许重复
5
set<i64> follower_ids
6

7
// Map：键值对映射
8
map<string, string> metadata

与 ProtoBuf 的差异：

• ProtoBuf 只有 repeated（对应 List）和 map
• Thrift 原生支持 set，ProtoBuf 需要用 repeated + 去重逻辑模拟

2.3 结构体定义#

1
struct User {
2
    1: required i64 id           // 必填字段
3
    2: required string username  // 必填字段
4
    3: optional string email     // 可选字段
5
    4: optional bool is_active = true  // 可选字段，带默认值
6
}

关键概念：

• 字段编号：1:, 2: 是字段的唯一标识，类似 ProtoBuf 的 Tag
• required/optional：显式声明字段是否必填
  • required：序列化时必须有值，反序列化时必须存在
  • optional：可以不设置，反序列化时缺失不会报错

底层逻辑：Thrift 的 required 会在运行时检查，如果缺失会抛出异常。ProtoBuf 在 proto3 中移除了 required，所有字段都是可选的。

2.4 枚举和异常#

1
// 枚举定义
2
enum UserStatus {
3
    NORMAL = 1,
4
    BANNED = 2,
5
    DELETED = 3
6
}
7

8
// 异常定义（类似结构体，但用于错误处理）
9
exception UserNotFoundException {
10
    1: string message
11
    2: i64 user_id
12
}

底层逻辑：Thrift 的 exception 会被映射到各语言的异常机制：

• Go：生成实现 error 接口的结构体
• Java：生成继承 Exception 的类
• Python：生成继承 Exception 的类

2.5 服务定义#

1
service UserService {
2
    // 定义 RPC 方法
3
    User getUser(1: i64 user_id) throws (1: UserNotFoundException e)
4

5
    // void 返回类型
6
    void deleteUser(1: i64 user_id)
7

8
    // oneway：不等待响应（异步调用）
9
    oneway void logEvent(1: string event)
10
}

关键概念：

• throws：声明可能抛出的异常
• oneway：客户端发送请求后立即返回，不等待服务端响应（类似消息队列）

底层逻辑：oneway 方法在网络层不会等待响应包，适合日志、监控等场景。

3.1 Binary Protocol#

最常用的协议，紧凑且高效。

1
transport := thrift.NewTSocket("localhost:9090")
2
protocol := thrift.NewTBinaryProtocol(transport, true, true)
3
client := userservice.NewUserServiceClient(thrift.NewTStandardClient(protocol, protocol))

底层逻辑：

• 使用固定长度编码（i32 占 4 字节，i64 占 8 字节）
• 字段按顺序编码：[字段类型][字段ID][字段值]
• 不压缩，但解析速度快

3.2 Compact Protocol#

压缩版本，牺牲少量性能换取更小的体积。

1
protocol := thrift.NewTCompactProtocol(transport)

底层逻辑：

• 使用 varint 编码整数（类似 ProtoBuf）
• 字段 ID 使用 zigzag 编码
• 体积比 Binary 小 20-30%，但编解码稍慢

3.3 JSON Protocol#

人类可读的格式，用于调试或与前端交互。

1
protocol := thrift.NewTJSONProtocol(transport)

底层逻辑：

• 直接序列化为 JSON 字符串
• 体积最大，性能最差
• 适合调试或跨语言兼容性要求高的场景

3.4 协议对比#

4.1 TSocket#

最基础的 TCP Socket 传输。

1
transport := thrift.NewTSocket("localhost:9090")

底层逻辑：直接使用 TCP 连接，每次 RPC 调用对应一次完整的请求-响应。

4.2 TFramedTransport#

带帧头的传输，用于非阻塞服务器。

1
transport := thrift.NewTFramedTransport(thrift.NewTSocket("localhost:9090"))

底层逻辑：

• 每个消息前加 4 字节的长度头：[长度][消息体]
• 服务端可以先读取长度，再读取完整消息体
• 适合 NonBlocking Server（基于 epoll/kqueue）

4.3 TBufferedTransport#

带缓冲的传输，减少系统调用次数。

1
transport := thrift.NewTBufferedTransport(thrift.NewTSocket("localhost:9090"), 8192)

底层逻辑：在内存中维护读写缓冲区，积累到一定大小再调用 write()，减少系统调用开销。

5.1 生成 Go 代码#

假设你有一个 user.thrift 文件：

1
namespace go user
2

3
struct User {
4
    1: required i64 id
5
    2: required string username
6
}
7

8
service UserService {
9
    User getUser(1: i64 user_id)
10
}

生成代码：

1
thrift --gen go user.thrift

• gen-go/user/user.go：所有 Thrift 生成的接口、客户端、服务端代码都在这一个 user.go 文件中。

5.2 实现服务端#

1
package main
2

3
import (
4
    "context"
5
    "fmt"
6
    "github.com/apache/thrift/lib/go/thrift"
7
    "your-module/gen-go/user"
8
)
9

10
// 实现服务接口
11
type UserServiceHandler struct
12

13
func (h *UserServiceHandler) GetUser(ctx context.Context, userID int64) (*user.User, error) {
14
    return &user.User{
15
        ID:       userID,
16
        Username: "TestUser",
17
    }, nil
18
}
19

20
func main() {
21
    handler := &UserServiceHandler{}
22
    processor := user.NewUserServiceProcessor(handler)
23

24
    transport, _ := thrift.NewTServerSocket(":9090")
25
    server := thrift.NewTSimpleServer4(
26
        processor,
27
        transport,
28
        thrift.NewTBufferedTransportFactory(8192),
29
        thrift.NewTBinaryProtocolFactoryDefault(),
30
    )
31

32
    fmt.Println("Starting server on :9090")
33
    server.Serve()
34
}

底层逻辑：

• Processor：负责解析请求、调用 Handler、序列化响应
• Transport：负责网络 I/O
• ProtocolFactory：负责创建序列化协议实例

6.1 核心差异#

6.2 选择建议#

选择 Thrift 的场景：

• 需要灵活的协议层和传输层组合
• 需要使用 Set 类型
• 需要显式的 required 字段校验
• 已有 Thrift 生态（如使用 Kitex）

选择 ProtoBuf 的场景：

• 需要与 gRPC 生态集成
• 需要更好的向后兼容性（proto3 的设计更宽松）
• 需要更广泛的语言支持（ProtoBuf 社区更活跃）

7.1 字段演化#

Thrift 支持字段的增删改，但需要遵循规则：

1
struct User {
2
    1: required i64 id
3
    2: required string username
4
    // 3: string old_field  // 已废弃，不要删除编号
5
    4: optional string email  // 新增字段，使用新编号
6
}

底层逻辑：

• 不要修改已有字段的编号
• 不要将 optional 改为 required（会导致旧客户端反序列化失败）
• 废弃字段保留编号，避免未来冲突

7.2 性能优化#

1
// 使用对象池复用 Transport
2
var transportPool = sync.Pool{
3
    New: func() interface{} {
4
        transport, _ := thrift.NewTSocket("localhost:9090")
5
        return thrift.NewTBufferedTransport(transport, 8192)
6
    },
7
}
8

9
func callRPC() {
10
    transport := transportPool.Get().(thrift.TTransport)
11
    defer transportPool.Put(transport)
12

13
    transport.Open()
14
    defer transport.Close()
15

16
    protocol := thrift.NewTBinaryProtocol(transport, true, true)
17
    client := user.NewUserServiceClient(thrift.NewTStandardClient(protocol, protocol))
18

19
    result, _ := client.GetUser(context.Background(), 123)
20
    fmt.Println(result)
21
}

底层逻辑：复用 Transport 对象可以减少连接建立开销和内存分配。