在反序列化后，且调用API前加一个过滤器，识别是什么协议，老协议按老逻辑走，新协议按新协议逻辑走，多个过滤器构成一个调用链

当下云原生微服务框架 Service meth大火，通过在meth层做兼容应该可以解决多RPC协议问题

rpc的调用是微服务间直连调用，请问协议转换这层逻辑放在哪里，换了新协议是指在当前rpc框架更换协议还是直接更换了rpc框架

我想到的一种思路是，上线带监控的rpc，把未包含的协议监控起来，逐步上线支持

RPC架构层次： ♻️序列化框架：作用是将方法调用时传入的发送数据从对象转为二进制，序列化一般用在协议里面的payload里面（最简单就是java对象序列化为二进制流封装为消息体然后基于http传输）如jdk、msgpack、protobuf、json、hessian等，推荐首选的还是 Hessian 与 Protobuf。 ♻️编解码框架：编解码是对网络传输消息进行处理，把二进制的数据(payload)进一步封装（或者拆解）为rpc的协议(消息头+消息体)。 ♻️协议：包括协议头和协议体，协议的作用就是用于分割二进制数据流。每种协议约定的数据包格式是不一样的。是网络传输数据格式的约定，作用将发送的数据按照一定的规约进行序列化为二进制流，有http/tcp/ftp等协议，grpc就是就是基于http的协议。 ->补充：协议解析过程就是把一连串的二进制数据变成一个 RPC 内部对象，但这个对象一般是跟协议相关的，所以为了能让 RPC内部处理起来更加方便，我们一般都会把这个协议相关的对象转成一个跟协议无关的 RPC 对象。 ♻️Proxy：作用是让RPC框架根据调用的服务接口提前生成动态代理实现类，实现类似本地的调用感觉。 ♻️负载均衡框架：结合服务注册中心实现服务端列表的路由选择和调用，如restTemplate、ribbon、feignClient等。 ♻️熔断降级框架：实现调用过程中的熔断保护和降级函数。

magic number和协议可以缓存到map中，或者redis中，从配置中心读取，当配置中心修改后，热更新到对应的缓存中。

dubbo就支持多种协议

插件化，支持自定义协议插件即可

这个RPC多协议维护起来也很酸爽吧😭

这种是单端口多协议吗？