分布式通信框架

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

 

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

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

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

评论

44 楼 attend 2012-05-23  

用dubbo吧，挺好用的。

43 楼 zxlsky1314 2010-09-24  

同求开源，我目前所在的地方也是自己实现的基于socket的rpc通信框架

42 楼 kimmking 2010-09-24  

javatracker 写道

kimmking 写道

rain2005 写道

简单的自定义协议比http协议高效是毋庸置疑的，你看看有什么内部通讯协议采用http的，采用http无非就是客户端资源丰富。

内部的通讯协议，这个定义的范围太广。


银行的前置系统，ESB中都有高效的http处理。

前置系统肯定要HTTP的，前置HTTP直接用Web容器处理就可以了，另外银行由于事务的高要求，通信上这点速度损失已经不重要了，用什么协议都要等待那么一会，反正各家银行都那么慢。互联网就不一样了，你慢别人快的话肯定会损失一部分用户的。

ESB只是兼容http，ESB支持非常多的协议，他的目的不是让通信有多快，而是让尽可能多的异构系统相互通信，尽可能在不改变原来系统接口或结构的情况下将多个系统融合进来。

自定义框架一个优先作用就是规范各个系统，使之尽可能符合框架规定的规范来提高系统速度和稳定性，当然也会支持其他异构系统，但规范内的是占主流的。

前置必须得快，而且稳定，所以的系统都挂上面，慢了或不稳定都是要命的。
在ESB遍地开花的今天，性能现在是最重要的参考数据之一。

41 楼 javatracker 2010-09-24  

kimmking 写道

rain2005 写道

简单的自定义协议比http协议高效是毋庸置疑的，你看看有什么内部通讯协议采用http的，采用http无非就是客户端资源丰富。

内部的通讯协议，这个定义的范围太广。


银行的前置系统，ESB中都有高效的http处理。

前置系统肯定要HTTP的，前置HTTP直接用Web容器处理就可以了，另外银行由于事务的高要求，通信上这点速度损失已经不重要了，用什么协议都要等待那么一会，反正各家银行都那么慢。互联网就不一样了，你慢别人快的话肯定会损失一部分用户的。

ESB只是兼容http，ESB支持非常多的协议，他的目的不是让通信有多快，而是让尽可能多的异构系统相互通信，尽可能在不改变原来系统接口或结构的情况下将多个系统融合进来。

自定义框架一个优先作用就是规范各个系统，使之尽可能符合框架规定的规范来提高系统速度和稳定性，当然也会支持其他异构系统，但规范内的是占主流的。

40 楼 javatracker 2010-09-24  

Arden 写道

可以看看基于scala的分布式框架akka,另外我觉得ICE最大的好处是目前有对移动设备的支持，包括iphone,android.

多谢提醒，移动支持倒是一个不错的功能支持，目前的设计主要是不涉及用户客户端，一般是浏览器或手机客户端通过HTTP或其他协议向自身服务端请求，在自身服务端再依赖后端系统时才用这个框架，后面会考虑用户客户端的支持。

39 楼 Arden 2010-09-21  

可以看看基于scala的分布式框架akka,另外我觉得ICE最大的好处是目前有对移动设备的支持，包括iphone,android.

38 楼 kimmking 2010-09-21  

rain2005 写道

简单的自定义协议比http协议高效是毋庸置疑的，你看看有什么内部通讯协议采用http的，采用http无非就是客户端资源丰富。

内部的通讯协议，这个定义的范围太广。


银行的前置系统，ESB中都有高效的http处理。

37 楼 rain2005 2010-09-21  

简单的自定义协议比http协议高效是毋庸置疑的，你看看有什么内部通讯协议采用http的，采用http无非就是客户端资源丰富。

36 楼 myy 2010-09-21  

<div class="quote_title">myreligion 写道</div>
<div class="quote_div">
<div class="quote_title">ray_linn 写道</div>
<div class="quote_div">
<div class="quote_title">kimmking 写道</div>
<div class="quote_div">
<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>
</div>
<p><br>恩，我对HTTP效率低着个结论觉得很无语。 http的包头算是很mini的，何来效率低。。。</p>
</div>
<p> </p>
<p>http真的不快。我们做同样的事情，用socket长连接比开源的rcp包基于http实现的，快15倍左右。</p>
<p> </p>
<p>我们测试：在内网环境下，http方式1秒不过几百次查询，socket可以达到上万次，而且对机器连接文件数占用还少很多。<a href="/topic/696261">http://www.iteye.com/topic/696261</a> 的”性能如何“是测试数据。</p>
<p> </p>
<p> </p>
<p> </p>
</div>
<p>笼统说http低效是不合适的，通常http是短连接的，每次都要进行连接，用完后又断开，效率主要损耗在连接建立/拆除上，至于数据传输，都是一样走TCP/IP，没有更低效之说。</p>

35 楼 东吴周郎 2010-09-20  

无码无真相
mar  k 

34 楼 javatracker 2010-09-20  

myreligion 写道

javatracker 写道

myreligion 写道

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

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

太遗憾了，看来只有自己弄了。不过我会公开出来的，呵呵，希望多指点～～

呵呵，一起交流，这个最终会开源的，不过现在还不太稳定，还有功能没加上，也没得到老大的批准呢。

33 楼 myreligion 2010-09-20  

javatracker 写道

myreligion 写道

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

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

太遗憾了，看来只有自己弄了。不过我会公开出来的，呵呵，希望多指点～～

32 楼 myreligion 2010-09-20  

<div class="quote_title">ray_linn 写道</div>
<div class="quote_div">
<div class="quote_title">kimmking 写道</div>
<div class="quote_div">
<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>
</div>
<p><br>恩，我对HTTP效率低着个结论觉得很无语。 http的包头算是很mini的，何来效率低。。。</p>
</div>
<p> </p>
<p>http真的不快。我们做同样的事情，用socket长连接比开源的rcp包基于http实现的，快15倍左右。</p>
<p> </p>
<p>我们测试：在内网环境下，http方式1秒不过几百次查询，socket可以达到上万次，而且对机器连接文件数占用还少很多。<a href="http://www.iteye.com/topic/696261">http://www.iteye.com/topic/696261</a> 的”性能如何“是测试数据。</p>
<p> </p>
<p> </p>
<p> </p>

31 楼 javatracker 2010-09-20  

<div class="quote_title">ray_linn 写道</div>
<div class="quote_div">
<div class="quote_title">kimmking 写道</div>
<div class="quote_div">
<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>
</div>
<p><br>恩，我对HTTP效率低着个结论觉得很无语。 http的包头算是很mini的，何来效率低。。。</p>
</div>
<p> </p>
<p>效率的高低是相对，说HTTP低是相对于TCP/IP的，分布式系统可能是多层依赖，每层依赖都需要消耗传输时间，HTTP协议是TCP/IP之上的协议，架构在HTTP协议之上就多了一次再编码和解码的过程，而且传输的数据也比直接用TCP/IP大。假设A依赖B，B依赖C，C又依赖D，这样在每一次的传输过程中多消耗一点的时间，对用户来说就多几倍的等待，对提高页面响应来说是个问题，作为底层框架应尽可能的减少这种消耗。</p>

30 楼 javatracker 2010-09-20  

javatracker 写道

mercyblitz 写道

javatracker 写道

kimmking 写道

javatracker 写道

kimmking 写道

javatracker 写道

仿照Activemq的模式？

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

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

LVS，TCP的四层交换技术？

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

哦，明白了，不过这样客户又很多选择的服务器，难道采用轮询？

估计是failover~

恩，但是又感觉像DNS轮询，一般DNS服务器把一串IP发给浏览器，浏览器会获取其中一个（实现不同，行为不同），不过楼主可以说一下怎么来实现的。

目前和轮询也差不多，采用随机的方式，在一个IP列表中随机选在一个发送请求。

29 楼 ray_linn 2010-09-20  

<div class="quote_title">kimmking 写道</div>
<div class="quote_div">
<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>
</div>
<p><br>恩，我对HTTP效率低着个结论觉得很无语。 http的包头算是很mini的，何来效率低。。。</p>

28 楼 mercyblitz 2010-09-20  

mercyblitz 写道

javatracker 写道

kimmking 写道

javatracker 写道

kimmking 写道

javatracker 写道

仿照Activemq的模式？

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

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

LVS，TCP的四层交换技术？

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

哦，明白了，不过这样客户又很多选择的服务器，难道采用轮询？

估计是failover~

恩，但是又感觉像DNS轮询，一般DNS服务器把一串IP发给浏览器，浏览器会获取其中一个（实现不同，行为不同），不过楼主可以说一下怎么来实现的。

27 楼 tedeyang 2010-09-20  

分布式体现在哪里？

26 楼 kimmking 2010-09-20  

javatracker 写道

kimmking 写道

javatracker 写道

kimmking 写道

javatracker 写道

仿照Activemq的模式？

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

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

LVS，TCP的四层交换技术？

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

哦，明白了，不过这样客户又很多选择的服务器，难道采用轮询？

估计是failover~

25 楼 mercyblitz 2010-09-20  

kimmking 写道

javatracker 写道

kimmking 写道

javatracker 写道

仿照Activemq的模式？

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

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

LVS，TCP的四层交换技术？

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

哦，明白了，不过这样客户又很多选择的服务器，难道采用轮询？