分布式通信框架

      经过一个半月的编码，自己开发的分布式通信框架终于有了基本的雏形，采用TCP/IP协议，用Netty框架实现底层通信，序列化方式支持JDK自带的方式、支持Hessian、也支持Protobuf和Thrift，一般Java调Java用Hessian和Jdk序列化比较方便，直接将服务端注册，客户端生成代理即可使用。Protobuf和Thrift是为了应对跨语言调用准备的，可以通过伪代码生成业务依赖（接口、参数、返回值、异常等）。框架初步具备了负载均衡和容错，可以路由到具体的重载方法。目前只支持同步调用，后续将支持回调异步、Future异步和Oneway异步。

 

      之所以要自己开发通信框架主要有两个原因：

      1、开源框架都有自己的不足，比如Hessian架构在Http协议之上，效率低不说，不能脱离web容器，同时虽说可以支持跨语言，但没有一个统一的标准来生成各种语言的业务客户端，要手工编写各种业务依赖，同时对复杂参数的序列化支持并不好，自身并不具备负载均衡和容错的能力。Thrift相对比较简单，没有负载均衡和容错机制，没有集群功能。Protobuf本身只是一个序列化框架，仅有远程调用接口，并没有实现。ICE倒是一个不错的东西，但有点庞大，同时不满足下面的要求。

      2、和后续的分布式解决方案（分布式数据层、消息中间、集群和业务配置服务、监控系统）无缝集合，使这些底层应用解决一个个业务集群的同时，也能处于大集群的有效监控之中，为后期的自动化升降级做准备。

评论

24 楼 javatracker 2010-09-20  

HenryYu 写道

“用Netty框架实现底层通信。。。”

你框架最有价值的地方就是底层通信的实现，采取人家Netty的来封装，没有多大意思啦。要搞就从底层搞起呀

呵呵 没这个打算，也没这个必要。

23 楼 HenryYu 2010-09-20  

“用Netty框架实现底层通信。。。”

你框架最有价值的地方就是底层通信的实现，采取人家Netty的来封装，没有多大意思啦。要搞就从底层搞起呀

22 楼 javatracker 2010-09-20  

dennis_zane 写道

这个跟淘宝内部的RPC框架很相似，作者跟bluedavy聊过？

呵呵，在淘宝待过，受到过淘宝的影响。

21 楼 dennis_zane 2010-09-20  

这个跟淘宝内部的RPC框架很相似，作者跟bluedavy聊过？

20 楼 javatracker 2010-09-20  

javatracker 写道

kimmking 写道

javatracker 写道

仿照Activemq的模式？

感觉还是服务器端做一个loadbalance合适，统一控制dispatch策略，heartbeat检测，和failover。

没，参照了JBossRemoting和淘宝的，在客户端做的loadbalance。
在服务端做loadbalance的话，做loadbalance的这个服务端本身就是个单点。

LVS，TCP的四层交换技术？

这是一个实现方式，但不想在太底层实现，用LVS的话没办法和上层集群做统一协调，另外做LVS分发那台机器还是个单点，又要引入解决LVS单点的问题，所以还是客户端实现方便。

19 楼 mercyblitz 2010-09-20  

kimmking 写道

javatracker 写道

仿照Activemq的模式？

感觉还是服务器端做一个loadbalance合适，统一控制dispatch策略，heartbeat检测，和failover。

没，参照了JBossRemoting和淘宝的，在客户端做的loadbalance。
在服务端做loadbalance的话，做loadbalance的这个服务端本身就是个单点。

LVS，TCP的四层交换技术？

18 楼 javatracker 2010-09-20  

darwintest 写道

描述比较笼统，框架没看到

这个是公司项目，后面和老大商量考虑开源。

后面会出一些系列帖子来讨论实现细节。

17 楼 darwintest 2010-09-20  

描述比较笼统，框架没看到

16 楼 javatracker 2010-09-20  

javatracker 写道

仿照Activemq的模式？

感觉还是服务器端做一个loadbalance合适，统一控制dispatch策略，heartbeat检测，和failover。

没，参照了JBossRemoting和淘宝的，在客户端做的loadbalance。
在服务端做loadbalance的话，做loadbalance的这个服务端本身就是个单点。

15 楼 kimmking 2010-09-20  

javatracker 写道

kimmking 写道

javatracker 写道

kimmking 写道

框架初步具备了负载均衡和容错，可以路由到具体的重载方法。


前半句很惊艳，后半句很雷人。

是我没说清除，负载均衡目前就只是随机选择，容错是做了个简单的失败转移，自动恢复的功能。

路由到重载方法是，一般一些简单的rpc框架只是根据提供远程服务实例的Key路由到该实例，再根据调用的方法名称路由到某个具体的方法，如果有几个同名的重载方法，或者这些同名的重载方法的参数个数相同，类型又属于接口或子类的关系，框架就不知道调哪个方法了。

我想说的是这里做了特殊的处理，除了通过方法名路由外，又循环比较了参数类型，找到最合适的方法调用。

这叫支持重载方法的远程调用，不叫负载均衡。

负载均衡一般是说 我配置了n个服务器，上面都有同样的一个服务和方法，
然后可以配置一个规则，把请求转发给某个服务器来处理。

你实现的功能比较下参数列表即可。跟负载均衡没一点关系。

OK，看来我还是没说清除，“是我没说清除，负载均衡目前就只是随机选择，容错是做了个简单的失败转移，自动恢复的功能。”  这一句是对负载均衡和容错的解释，这一句后面的是对路由到重载方法的解释。这一句的再进一步解释是，目前支持服务端是一个集群，需要将IP和端口配置到客户端，客户端根据随机的选择服务端将请求发往服务端，如果某个服务端挂掉，则自动从随机列表中剔除，同时对这台机器进行心跳检测，如果检测到这台机器恢复则加回正常发送的随机检测列表供调用。如果在随机选到某台发送时挂掉，则将这台移到失败列表供心跳检测，同时再随机选择活着的服务端重发此请求。

目前需要在客户端配置ip和端口，后面做了集群功能后将不用配置IP和端口，客户端可以对服务端机器的情况进行自动感知。

仿照Activemq的模式？

感觉还是服务器端做一个loadbalance合适，统一控制dispatch策略，heartbeat检测，和failover。

14 楼 javatracker 2010-09-20  

kimmking 写道

javatracker 写道

kimmking 写道

框架初步具备了负载均衡和容错，可以路由到具体的重载方法。


前半句很惊艳，后半句很雷人。

是我没说清除，负载均衡目前就只是随机选择，容错是做了个简单的失败转移，自动恢复的功能。

路由到重载方法是，一般一些简单的rpc框架只是根据提供远程服务实例的Key路由到该实例，再根据调用的方法名称路由到某个具体的方法，如果有几个同名的重载方法，或者这些同名的重载方法的参数个数相同，类型又属于接口或子类的关系，框架就不知道调哪个方法了。

我想说的是这里做了特殊的处理，除了通过方法名路由外，又循环比较了参数类型，找到最合适的方法调用。

这叫支持重载方法的远程调用，不叫负载均衡。

负载均衡一般是说 我配置了n个服务器，上面都有同样的一个服务和方法，
然后可以配置一个规则，把请求转发给某个服务器来处理。

你实现的功能比较下参数列表即可。跟负载均衡没一点关系。

OK，看来我还是没说清除，“是我没说清除，负载均衡目前就只是随机选择，容错是做了个简单的失败转移，自动恢复的功能。”  这一句是对负载均衡和容错的解释，这一句后面的是对路由到重载方法的解释。这一句的再进一步解释是，目前支持服务端是一个集群，需要将IP和端口配置到客户端，客户端根据随机的选择服务端将请求发往服务端，如果某个服务端挂掉，则自动从随机列表中剔除，同时对这台机器进行心跳检测，如果检测到这台机器恢复则加回正常发送的随机检测列表供调用。如果在随机选到某台发送时挂掉，则将这台移到失败列表供心跳检测，同时再随机选择活着的服务端重发此请求。

目前需要在客户端配置ip和端口，后面做了集群功能后将不用配置IP和端口，客户端可以对服务端机器的情况进行自动感知。

13 楼 kimmking 2010-09-20  

javatracker 写道

kimmking 写道

框架初步具备了负载均衡和容错，可以路由到具体的重载方法。


前半句很惊艳，后半句很雷人。

是我没说清除，负载均衡目前就只是随机选择，容错是做了个简单的失败转移，自动恢复的功能。

路由到重载方法是，一般一些简单的rpc框架只是根据提供远程服务实例的Key路由到该实例，再根据调用的方法名称路由到某个具体的方法，如果有几个同名的重载方法，或者这些同名的重载方法的参数个数相同，类型又属于接口或子类的关系，框架就不知道调哪个方法了。

我想说的是这里做了特殊的处理，除了通过方法名路由外，又循环比较了参数类型，找到最合适的方法调用。

这叫支持重载方法的远程调用，不叫负载均衡。

负载均衡一般是说 我配置了n个服务器，上面都有同样的一个服务和方法，
然后可以配置一个规则，把请求转发给某个服务器来处理。

你实现的功能比较下参数列表即可。跟负载均衡没一点关系。

12 楼 javatracker 2010-09-20  

kimmking 写道

框架初步具备了负载均衡和容错，可以路由到具体的重载方法。


前半句很惊艳，后半句很雷人。

是我没说清除，负载均衡目前就只是随机选择，容错是做了个简单的失败转移，自动恢复的功能。

路由到重载方法是，一般一些简单的rpc框架只是根据提供远程服务实例的Key路由到该实例，再根据调用的方法名称路由到某个具体的方法，如果有几个同名的重载方法，或者这些同名的重载方法的参数个数相同，类型又属于接口或子类的关系，框架就不知道调哪个方法了。

我想说的是这里做了特殊的处理，除了通过方法名路由外，又循环比较了参数类型，找到最合适的方法调用。

11 楼 kimmking 2010-09-20  

<div class="quote_title">ray_linn 写道</div>
<div class="quote_div">Hessian架构在Http协议之上，效率低不说，不能脱离web容器 <br><br>--- 这是个伪命题把？ http协议最强的地方，就是几乎所有的firewall都打开了80口</div>
<p> </p>
<p>一般来说， http效率不算低。</p>
<p> </p>
<p>长连接，异步servlet，SEDA，线程池。</p>
<p>串起来，是一个很高效的系统。</p>
<p> </p>

10 楼 kimmking 2010-09-20  

框架初步具备了负载均衡和容错，可以路由到具体的重载方法。


前半句很惊艳，后半句很雷人。

9 楼 javatracker 2010-09-20  

ray_linn 写道

Hessian架构在Http协议之上，效率低不说，不能脱离web容器

--- 这是个伪命题把？ http协议最强的地方，就是几乎所有的firewall都打开了80口

对的，不同的东西有不同的适用场景，由于内部搞分布式系统架构升级，所以不会遇到firewall的问题，因此自己搞了一个。

8 楼 javatracker 2010-09-20  

myreligion 写道

你是在做一个基于socket的RPC框架吗？我最近也有这方面的打算，普通rpc的http实在太低效了，我们需要一个更快的。如果您已经完成了，是不是开源的哪？能否分享一下？呵呵。

后面会分享一下设计方面的东西，开源要过一段时间征求老大的意见。

7 楼 javatracker 2010-09-20  

http4j 写道

鼓励一下，不过提醒一下，楼主你在自言自语么？框架在哪里？

呵呵 自己总结一下，框架基本功能已经开发完成，后面需要做集群方面和多语言客户端的支持，目前时机不成熟，后面会向老大提出使其开源。

6 楼 ray_linn 2010-09-20  

Hessian架构在Http协议之上，效率低不说，不能脱离web容器

--- 这是个伪命题把？ http协议最强的地方，就是几乎所有的firewall都打开了80口

5 楼 liyun_1981 2010-09-20  

楼主的想法不错，望楼主能详细说下你的概要设计，最好能发个源码或测试版本上来，让大家来帮你测一下，这样才有意义。