1、认识 chronicle-bytes

Chronicle-Bytes 是一个类似于 Java NIO 的 ByteBuffer 的高效字节操作库，但它提供了许多扩展功能。这个项目由 OpenHFT 开发并维护，旨在提供高性能、低延迟的数据处理解决方案。Chronicle-Bytes 设计用于高频率交易和其他对性能有极端要求的场景，它支持序列化和反序列化多种数据类型，同时保持内存的高效利用。

2、了解下 rpc ？

一讲 rpc ，很多人会想到 dubbo （国产）和 grpc。估计还会联想到注册与发现服务；可能还会联想到微服务。可能就会觉得这个事儿“老重啦”，害怕！

其实很简单的，你请求一次 http 就是个 rpc 请求了（远程过程调用嘛）。最典型的就是 http + json 请求了。

3、现在讲 httputils + chronicle-bytes

这里我们会用到两个重要的 solon 框架的插件：一个是 abc 序列化插件（abc 适配了多个编解码方案，其中有 chronicle-bytes），一个是 httputils 工具插件。

<!-- 这是 chronicle-bytes 的编解码包装器 -->
<dependency>
    <groupId>org.noear</groupId>
    <artifactId>solon-serialization-abc</artifactId>
</dependency>

<dependency>
    <groupId>net.openhft</groupId>
    <artifactId>chronicle-bytes</artifactId>
    <version>${chronicle-bytes.version}</version>
</dependency>

<dependency>
    <groupId>org.noear</groupId>
    <artifactId>solon-net-httputils</artifactId>
</dependency>

这里要感谢 solon 框架，它强调三元合一（mvc 与 rpc 是自然一体的）。下面，开始干活啦...

• 公用包（也可以在客户端，服务端分别定义实体类。只要实现 ChrBytesSerializable 接口即可 ）

这里定义一个 chronicle-bytes 实体类。注意要实现 ChrBytesSerializable 接口。

@Getter
@Setter
public class MessageDo implements ChrBytesSerializable {
    private long id;
    private String title;

    @Override
    public void serializeRead(BytesIn in) {
        id = in.readLong();
        title = in.readUtf8();
    }

    @Override
    public void serializeWrite(BytesOut out) {
        out.writeLong(id);
        out.writeUtf8(title);
    }
}

• 服务端（只支持 @Body 数据接收，只支持实体类）

在 solon web 项目里，添加一个控制器（注解可以用 @Remoting 或 @Controller）。使用 @Remoting 时，方法上不需要加 @Mapping 注解。

#添加插件
org.noear:solon-web
org.noear:solon-serialization-abc
net.openhft:chronicle-bytes:${chronicle-bytes.version} # 提供 chronicle-bytes 序列化支持

@Mapping("/rpc/demo")
@Remoting
public class HelloServiceImpl  implements HelloService {
    @Override
    public MessageDo hello(@Body MessageDo message) { //还可接收路径变量，与请求上下文
        return message;
    }
}

• 客户端应用 for HttpUtils（只支持 body 数据提交，只支持实体类）

#添加插件
org.noear:solon-net-httputils
org.noear:solon-serialization-abc
net.openhft:chronicle-bytes:${chronicle-bytes.version} # 提供 chronicle-bytes 序列化支持

//应用代码
@Component
public class DemoCom {
    public MessageDo hello() {
        MessageDo message = new MessageDo();
        message.setId(3);
        
        //指明请求数据为 ABC，接收数据要 ABC
        return HttpUtils.http("http://localhost:8080/rpc/demo/hello")
                .serializer(AbcBytesSerializer.getInstance())
                .header(ContentTypes.HEADER_CONTENT_TYPE, ContentTypes.ABC_VALUE)
                .header(ContentTypes.HEADER_ACCEPT, ContentTypes.ABC_VALUE)
                .bodyOfBean(message)
                .postAs(MessageDo.class);
    }
}

4、总结

总体上，跟 json 没什么大的区别。主要是指定了：序列化器、内容类型、接收类型，让各端能识别类据类型。

5、还可以使用“注解式 http 客户端”框架

肯定也会有人觉得，一个接口还好，如果有很多接口就要写很多重复的http请求代码了。所以，“注解式 http 客户端” 很重要，这也是很多 rpc 框架流行的原因，就像调用本地接口一样，使用远程接口。

nami 是 solon 框架的 rpc 客户端（或者，注解式 http 客户端），支持各种序列化。（只要是“支持序列化定制”的注解式 http 客户端，都可用！）

• 添加两个依赖包

#添加插件
org.noear:nami-coder-abc # abc 编解码支持
org.noear:nami-channel-http     # http 请求通道支持，也可以是 socketd（支持 tcp, udp, ws）
net.openhft:chronicle-bytes:${chronicle-bytes.version} # 提供 chronicle-bytes 序列化支持

• 代码应用（只支持 body 数据提交，只支持实体类）

@NamiClient(url = "http://localhost:8080/rpc/demo", headers = {ContentTypes.ABC, ContentTypes.ABC_ACCEPT})
public interface HelloService {
    MessageDo hello(@NamiBody MessageDo message);
    //方法2
    //方法3
    //方法4
    //方法5
    //方法6
}

@Component
public class DemoCom {
    @NamiClient //注入
    HelloService helloService;
  
    public MessageDo hello() {
         MessageDo message = new MessageDo();
         message.setId(3);
        
         rerturn helloService.hello(message);
    }
}