本文详细介绍了如何通过去除Dubbo中的Request、Response、Codec、Invocation，改用Netty的ChannelBuffer作为会话域，并重写Transportor和Future类，实现对Thrift协议请求和响应的简化处理。通过引入HeaderExchangeHandler来区分客户端和服务器端的发送和接收操作，最终提供了一个稳定高效的RPC解决方案。
前2天把dubbo-rpc-thrift重写了下，老大看了后说，这个还可以再简化，把不要的东西去掉，然后我又重写了下。
这次修改的地方设计到这些个方面：
1.抛弃dubbo里的Request，Response，Codec，Invocation。会话域用Netty的ChannelBuffer，里面装thrift协议的请求和响应的Frame。
2.重写Transportor，用Netty的LengthFieldPrepender的加头Length，用LengthFieldBasedFrameDecoder作decoder解析Frame，然后直接用它的handler。
3.添加HeaderExchangeHandler，分server端和client端，因为去掉Request和Response了，received方法无法区分side，所以要写2个Handler。在HeaderExchangechannel的send里，直接序列化message为ChannelBuffer，发送出去，然后返回重写的Future。
4.重写DefaultFuture，添加字段serviceName，methodName，在Future.Received()后，解析响应的Frame，有异常直接抛异常，没异常直接返回结果。
等稳定后，就放代码到GitHub上
这次修改的地方设计到这些个方面：
1.抛弃dubbo里的Request，Response，Codec，Invocation。会话域用Netty的ChannelBuffer，里面装thrift协议的请求和响应的Frame。
2.重写Transportor，用Netty的LengthFieldPrepender的加头Length，用LengthFieldBasedFrameDecoder作decoder解析Frame，然后直接用它的handler。
3.添加HeaderExchangeHandler，分server端和client端，因为去掉Request和Response了，received方法无法区分side，所以要写2个Handler。在HeaderExchangechannel的send里，直接序列化message为ChannelBuffer，发送出去，然后返回重写的Future。
4.重写DefaultFuture，添加字段serviceName，methodName，在Future.Received()后，解析响应的Frame，有异常直接抛异常，没异常直接返回结果。
等稳定后，就放代码到GitHub上
扫一扫
286
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
