[Disscuss]dubbo对protobuf 序列化严格只支持protobuf生成的类型

[hengyunabc]

以gRPC为例，只支持pb生成的类型，不支持pb里定义的原生类型，如int32/string 等。

比如下面的gRPC配置是不合法的，不能返回int32，要定义包装一层：

// The test service definition.
service Test {
  // Sends a greeting
  rpc SayHello (HelloReply) returns int32;
}

---

目前dubbo里pb支持了原始类型，但 map只支持 <String,String> 。

1. 这样子对于用户来说是很困惑的，为啥 map只能是<String,String> 。
2. 目前没有太好的办法解决所有的类型问题，可能到最终也没有办法解决

---

所以，建议dubbo里去掉原始类型的支持，和gRPC类似，只支持pb生成的类型。

1. 本质上rpc函数的参数和返回值，都是一个pb定义的对象，它是有tag的，它里面是可以增加/废弃字段的。如果只有原始类型的话，那么就没有tag了
2. gRPC本身不支持pb里的原始类型，说明gRPC本身知道里面的坑
3. 用pb本身的方式来包装一下，对性能来说，没有损失

[Warkeeper]

关于 map 只支持 <String,String>，是因为需要序列化/反序列化 RpcInvocation 中的成员变量 attachments，Dubbo 非常依赖这个对象来传递 RPC 调用的上下文，所以单独为它定义了 proto。具体可参考接口ObjectOutput中定义的 writeAttachments 方法，以及 protobuf 对这个方法的实现。

关于包装返回值和参数，dubbo 本身既支持使用原始类型，也支持使用包装类型，从用户的角度来看，多一个选择总是好的，因此我不赞成去掉对原始类型的支持。