补充内容

fb协议处理的简要说明

Client应用会创建Stub，然后调用fbs中指定的method方法，之后会去调用channel->FBCallMethod。这些方法都是由flatbuffers自动生成的，而FBCallMethod是在brpc中定义的，此处是二者间的一个桥梁。由于FBCallMethod的实现与针对pb协议的CallMethod非常类似，所以我使用函数模板CallMethodInternal提取了二者中的公共部分，使用参数is_pb区分，CallMethod传入参数为true，FBCallMethod为false。发送路径上的序列化(SerializeFlatBuffersRequest)、Pack(PackFlatBuffersRequest)等操作已经被定义在了Protocol fb_protocol中。

序列化函数SerializeFlatBuffersRequest的执行逻辑非常简单，首先根据FBRpcRequestHeader大小来调整message前面预留的header buffer空间，然后零拷贝地将message中的SingleIOBuf append至目的IOBuf就结束了。值得注意的是，fb协议中header的各字段被硬编码了，不能像pb一样通过proto文件(baidu_rpc_meta.proto)调整。

函数PackFlatBuffersRequest的功能与baidu_std协议中的PackRpcRequest函数类似，只不过rpc header部分已经预先分配好。

Server应创建一个类，继承fb.h中生成的Service，并重载其virtual方法。在启动Server进程时，应将该类对象通过AddService将该service注册至brpc。接收到的请求会交由ProcessFlatBuffersRequest处理，它首先从msg->meta中提取出Header（这一步由SingleIOBuf::assign完成，可能会有拷贝）；然后配置Controller，从msg->payload中解析出fb message（同样会调用SingleIOBuf::assign）；交由应用响应。应用逻辑处理完成后，会通过SendFlatBuffersRpcResponse向Client发送response message，这里同样会将rpc header + message零拷贝地append到待发送IOBuf中。

性能测试

我基于multi_threaded_echo_c++改造了benchmark程序，分别基于pb和fb协议实现，benchmark_fb的实现在#3196中。该程序基于bthread模型，共享同一个channel；每次发送时创建message，该message包含32B固定字段+ string组成的浮动字段（由request_size指定），proto文件定义如下；采用同步发送；输出指标包括延迟和QPS。

syntax="proto2";
option cc_generic_services = true;

package test;

message BenchmarkRequest {
    required int32 opcode = 1;
    required int32 echo_attachment = 2;
    required int64 attachment_size = 3;
    required int64 request_id = 4;
    optional int64 reserved = 5;
    optional string message = 4;
};

message BenchmarkResponse {
    required int32 opcode = 1;
    required int32 echo_attachment = 2;
    required int64 attachment_size = 3;
    required int64 request_id = 4;
    optional int64 reserved = 5;
    optional string message = 4;
};

service BenchmarkService {
      rpc Test(BenchmarkRequest) returns (BenchmarkResponse);
};

测试目的是为了说明fb的处理效率优于pb。为了避免网络影响，测试在同机上进行，分别为client和server绑定4个核。
下表所示数据为thread_num=1，即bthread数目为1时的结果。测试过程中使用Req Size变化请求中的string长度来改变message总大小，由于message中包含32B的固定整数部分，所以message实际总大小为32B(固定部分) + Req Size，attachment为0。测试程序执行20s，记录平均QPS，单位为千次/秒。表格中pb(old)为原CallMethod实现，pb(new)为当前pr中基于函数模板CallMethodInternal的实现。表中最后一行展示的是fb相对于pb(new)的提升百分比，从该结果可知fb相对于pb有20～30%的性能提升，且使用函数模板后对pb几乎没影响。

下表所示为thread_num=64，即并发bthread数目为64的测试结果，可以看到即使message大小为8KB，fb的提升仍有20.4%。

另外测试发现即使携带attachment，仍能保持相近的提升百分比，因为attachment不会被序列化。

RPC, examples, ON CI and docs (including message prerequisites): commits.

The message/codegen prerequisite is tracked in #3558. The RPC, example, CI and documentation follow-up is now submitted as draft #3559 (incremental changes).

Thanks @Spicy-cream for your interest in FlatBuffers and collaboration on LinQuickDev#45.