SofaRPC 5.14.3：Fory 序列化进场，Java RPC 的性能账又多了一种算法

预计阅读时间：9 分钟

SofaRPC v5.14.3 已发布。这次更新的重点很明确：在生产级 Java RPC 框架里加入 Apache Fory（原 Fury）序列化支持，同时修复 Triple 协议和代理生成相关问题。对正在维护 Java 服务调用链的团队来说，这类版本不只是“升个小版本”，而是关系到序列化开销、协议稳定性和 JDK8 兼容边界的一次补强。

这次变化真正影响哪里

SofaRPC 本身定位是高扩展、高性能、生产级 Java RPC 框架。RPC 框架里最容易被低估的成本，往往不是网络本身，而是对象在“Java 内存形态”和“网络传输字节”之间来回转换的成本。

v5.14.3 引入 Apache Fory 序列化支持，意味着使用 SofaRPC 的服务可以在已有序列化方案之外，多一个面向性能优化的选择。Fory 的价值通常体现在：

降低复杂对象序列化/反序列化的 CPU 消耗；
减少部分场景下的字节体积；
让高 QPS、低延迟链路有更多调优空间。

需要注意的是，序列化协议不是“越新越好”的单选题。它直接影响客户端和服务端是否能互相解码，也影响灰度发布时的新旧版本兼容。引入 Fory 前，最好先确认调用双方都升级到支持该序列化能力的版本。

Triple 协议和代理生成修复：稳定性比跑分更重要

除了新特性，v5.14.3 还修复了 Triple 协议和代理生成中的多个问题。这个信息虽然看起来没有“新增 Fory”抢眼，但对线上服务更关键。

Triple 协议相关修复通常会影响跨语言、HTTP/2 或 gRPC 生态兼容一类场景；代理生成问题则更贴近日常 Java 调用体验，比如接口代理、动态调用、泛化调用等路径。如果你的服务最近遇到过以下现象，这类修复值得关注：

RPC 接口代理偶发生成失败；
某些 Triple 调用在特定参数或返回值下表现异常；
升级依赖后调用链不稳定；
本地测试正常，但线上代理创建或协议协商失败。

源摘要明确提到该版本仍需要 JDK8 支持。也就是说，对于仍在 JDK8 上运行的大量传统 Java 服务，这次升级路线不会因为运行时版本被直接卡住。

可以这样实践：在测试环境验证 Fory 序列化

下面示例是一个“可改造”的最小验证工程，用于说明升级 SofaRPC 版本、显式配置序列化方式、跑一次本地调用链检查的基本思路。具体依赖模块名称可能需要按你们项目已有 SofaRPC 集成方式调整。

1. Maven 版本收敛

将 SofaRPC 版本集中到 5.14.3，避免服务端和客户端拉到不同版本。

<!-- pom.xml：按项目实际依赖模块调整 artifactId -->
<properties>
    <sofa.rpc.version>5.14.3</sofa.rpc.version>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
</properties>

<dependencies>
    <dependency>
        <groupId>com.alipay.sofa</groupId>
        <artifactId>sofa-rpc-all</artifactId>
        <version>${sofa.rpc.version}</version>
    </dependency>
</dependencies>

如果你们公司内部使用 BOM 或父 POM 管理依赖，优先在统一依赖管理层升级，而不是在业务模块里零散覆盖。

2. 用配置开关做灰度

假设项目允许通过配置选择序列化类型，可以先把 Fory 作为测试环境开关，而不是直接全量上线。

# rpc-test.properties
# 具体 key 以项目封装为准；这里展示推荐的配置思路
rpc.serialization=fory
rpc.protocol=bolt
rpc.timeoutMillis=3000

然后在启动脚本里注入配置：

#!/usr/bin/env bash
set -euo pipefail

export JAVA_OPTS="-Xms512m -Xmx512m -Drpc.config=rpc-test.properties"
java ${JAVA_OPTS} -jar target/order-service.jar

运行前需要改三处：

artifactId：替换成你项目实际使用的 SofaRPC 依赖；
rpc.serialization：替换成你们框架封装中真实的序列化配置项；
order-service.jar：替换成实际服务包名。

3. 加一个兼容性冒烟测试

序列化变更最怕“服务能启动，但对象解不开”。可以给核心 DTO 加一组冒烟测试，覆盖空字段、枚举、集合、嵌套对象。

import java.io.Serializable;
import java.math.BigDecimal;
import java.util.Arrays;
import java.util.List;

public class RpcSerializationSmokeTest {

    public static class OrderDTO implements Serializable {
        public String orderId;
        public BigDecimal amount;
        public List<String> tags;

        public OrderDTO() {
        }

        public OrderDTO(String orderId, BigDecimal amount, List<String> tags) {
            this.orderId = orderId;
            this.amount = amount;
            this.tags = tags;
        }
    }

    public interface OrderService {
        OrderDTO getOrder(String orderId);
    }

    public static void main(String[] args) {
        OrderDTO dto = new OrderDTO("O-10001", new BigDecimal("99.90"), Arrays.asList("vip", "coupon"));

        // 这里替换为你们项目中的 SofaRPC 客户端调用或序列化工具调用。
        // 目标不是做基准测试，而是确认典型 DTO 在新序列化方式下能完整往返。
        System.out.println("orderId=" + dto.orderId);
        System.out.println("amount=" + dto.amount);
        System.out.println("tags=" + dto.tags);
    }
}

编译运行：

javac RpcSerializationSmokeTest.java
java RpcSerializationSmokeTest

这段代码本身没有直接调用 SofaRPC API，因为不同团队通常会对 SofaRPC 做 Spring、XML、注解或内部 SDK 封装。你可以把 main 方法中的 DTO 构造替换为一次真实 RPC 调用：客户端发起请求，服务端原样返回 DTO，再断言字段一致。

升级建议：别把序列化切换当成普通配置变更

建议按下面顺序推进：

先统一版本：客户端、服务端、公共依赖都收敛到 SofaRPC 5.14.3；
再做双端验证：确认调用双方都支持 Apache Fory 序列化；
从非核心链路灰度：优先选择流量小、DTO 简单、回滚容易的服务；
观察关键指标：P99 延迟、CPU、GC、错误率、请求体大小；
保留回滚开关：序列化配置必须能快速切回原方案；
覆盖 Triple 调用场景：如果线上使用 Triple 协议，单独做协议级回归测试。

SofaRPC v5.14.3 的价值在于给 Java RPC 链路增加了一个新的性能调优选项，同时修掉协议和代理生成路径上的稳定性问题。真正上线时，不要只看“Fory 更快”这一句话，而要把它放进完整调用链里验证：对象模型、客户端版本、服务端版本、协议、灰度和回滚，一个都不能少。