|
锁定老帖子 主题：纯Java的高性能长连接RPC解决方案
精华帖 (5) :: 良好帖 (0) :: 新手帖 (2) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2013-01-16
这算是HSF开源的帖子么？
另，帖子动不动就我的我的，HSF真的是你一个人写出来的么？ |
| 返回顶楼 | |
|
发表时间：2013-01-16
richard_2010 写道 这算是HSF开源的帖子么？
另，帖子动不动就我的我的，HSF真的是你一个人写出来的么？ 还是要支持一下楼主的开源精神的。 希望楼主的RPC最终能实现“跨语言” |
| 返回顶楼 | |
|
发表时间：2013-01-16
youarestupid 写道 richard_2010 写道 这算是HSF开源的帖子么？
另，帖子动不动就我的我的，HSF真的是你一个人写出来的么？ 还是要支持一下楼主的开源精神的。 希望楼主的RPC最终能实现“跨语言” 我说的“跨语言”不仅仅是客户端，服务端也应该是跨语言的，应该像Thrift那样拥有中间定义语言文件IDL. 仅仅在Java语言内折腾，价值不太大因为纯Java的RPC方案不少，java自带的RMI也挺好用的。 |
| 返回顶楼 | |
|
发表时间：2013-01-16
最后修改：2013-01-16
据我所知，HSF目前是不跨语言的
如lz所说要跨语言，上层还需要再实现协议，这样跟web service还有什么区别，性能能可观么 不是不赞同lz的开源精神，只是他帖子里面很多“我的我的”把所有的功劳都归为自己了，你觉得是他一个人的工作么？ |
| 返回顶楼 | |
|
发表时间：2013-01-16
youarestupid 写道 richard_2010 写道 这算是HSF开源的帖子么？
另，帖子动不动就我的我的，HSF真的是你一个人写出来的么？ 还是要支持一下楼主的开源精神的。 希望楼主的RPC最终能实现“跨语言” 代码已经开源了，所以大家可以比对一下是否和别人的是否有代码抄袭的地方，呵呵~ 代码实际是两个人写的，但是确实是没有抄别人。因为当时在一家创业公司时弄的框架。 然后呢，确实是感觉淘宝的hsf需要osgi，我本人不喜欢所以就自己写了。然后，有的人在想是不是把人家淘宝的hsf拿出来抄了下，这个还真没有。毕竟我没有看过人家代码 具体大家我感觉吧也不用想是不是我抄了人家淘宝或是谁的代码，其实一比就行。然后呢，我想大家方便用多好，管他谁抄谁是不是？好用就行了呗，呵呵~ |
| 返回顶楼 | |
|
发表时间：2013-01-16
richard_2010 写道 据我所知，HSF目前是不跨语言的
如lz所说要跨语言，上层还需要再实现协议，这样跟web service还有什么区别，性能能可观么 不是不赞同lz的开源精神，只是他帖子里面很多“我的我的”把所有的功劳都归为自己了，你觉得是他一个人的工作么？ 服务端跨语言，我是真没有这个实力。实话，呵呵~ 我说的我的是我对HSF这个框架设计的理念，不是想说我把别人的想法拿过来全都变成我的意思，不用过份解读，就是想让大家都方便点，呵呵 然后呢，性能上肯定比web service强多了。 测试一下就可以了，因为在协议上我当时挑了很多，也测试了不少。最后使用的是kryo做的默认的协议，然后又做了层缓存，源代码里面都有。大家可以测试一下性能然后呢，长连接这个对性能比短连接又高了很多，其实这些数据大家都网上可以直接找到。kryo的性能，我测试了之后确实是让兴奋，谢谢有这么好的开源产品，呵呵 然后可能有人在想，你一个人能写出来？我不信，这个也没有事，其实一个这样的工具框架一个人真能写出来。不过你要说里面代码都是我写的这肯定也不是。当时，我遇到一个非常好的同事，也是我招的人当中非常满意的人之一，刚开始是我一个人写的，后来我精力有限让他接手。他自己为了这个投入了不少心血和精力，我们经过多少没有陪媳妇睡觉的日子弄的啊。因为我们要测试手机端，和服务端等等的测试。数据量的大小，性能，单连接，多连接，服务端多核和单核，还有交换机闪断，拨网站，确实是我们真的好多夜晚没有睡好；没有第三个的人了，哈哈。我确定是两个异性恋的男人，呵呵~ 做技术，就希望大家来批评。没有事的，只是我是希望咱们说的事都是对一个事有用，有好处的，这样才能让一个东西变的更好啊，呵呵 |
| 返回顶楼 | |
|
发表时间：2013-01-16
下过来代码好好观摩下
其实我对lz的分库分表中间件更感兴趣 |
| 返回顶楼 | |
|
发表时间：2013-01-16
youarestupid 写道 youarestupid 写道 richard_2010 写道 这算是HSF开源的帖子么？
另，帖子动不动就我的我的，HSF真的是你一个人写出来的么？ 还是要支持一下楼主的开源精神的。 希望楼主的RPC最终能实现“跨语言” 我说的“跨语言”不仅仅是客户端，服务端也应该是跨语言的，应该像Thrift那样拥有中间定义语言文件IDL. 仅仅在Java语言内折腾，价值不太大因为纯Java的RPC方案不少，java自带的RMI也挺好用的。 RMI在压力不大，和网络比较稳定的情况下还是不错的。然后呢，要是压力大了就不太好了。 具体可以测试下看，我测试了一下，然后也用RMI做过那种信息汇报，就遇到了问题。不过汇报信息压力不大，也一直没有改，呵 |
| 返回顶楼 | |
|
发表时间：2013-01-16
最后修改：2013-01-16
youarestupid 写道 dragonsoar 写道 youarestupid 写道 我最想要的RPC框架：
1、跨平台（Linux/Windows/Mac OS X） 2、跨语言（Java / C++两种即可） 3、双向推送（非“一问一答式响应”，而是服务端可以主动向客户端推送消息） 满足这三个要求的RPC框架，到目前为止我找不到，最接近的是百度的BGCC，但是BGCC不支持Mac OS X系统； 第二个比较接近的是Thrift，但是Thrift不支持“双向推送”，只能是“一问一答”式响应，即“客户端请求服务端的一个方法，接收到服务端的一个返回值”，服务端不能主动向客户端发起详细推送。 楼主如果能研究出我上面列举的三个特点的RPC框架，肯定能火起来。 1.我的这个RPC远程调用，是纯java开发的，是否能跨平台这个我没有严格测试，Windows和Linux下面肯定可以，这个我有亲自测试过 2.如果想跨语言，这个要分成两点来讲。一、是客户端跨语言还是服务端，如果我的是纯Java开发的，那么肯定是服务端就是Java了，没有什么跨语言之说了。如果是客户端，我这个是有一个默认的协议实现。如果想自己定义协义也是可以的，所以是不是可以满足你的跨语言了呢？ 3.双向推送这个太简单了，我这个是长连接，就是可以双向推送的。现在某国内最大的手机端IM服务商之一的推送就是用这个基础上来实现的（这个应用就是大家现在拿手机天天刷的那个应用，呵）。 我个人感觉你可能没有研究过或是体会一下RPC我这个应用的理念。你要是仔细看一下，你就知道这个是一个自定义度非常高的一个框架了 我是从java 1.1的RMI开始用RPC的，对RPC的应用概念不可谓不清楚。 对于你的框架，实现不了我所说的“跨语言”，我说得跨语言是通过定义中间IDL语言文件来实现生成c++的客户端和服务端代码，生成java的客户端和服务端代码。 你的是纯java的，无法实现c++客户端，如果像你说得，要通过自己定义协议实现自己写一套c++客户端，去调用你的服务端，那么我想问的是，那样的话，还用你的RPC干什么，直接用socket不久可以了？ 使用RPC就是要实现远程过程调用，对于c++和java来说，就是远程调用对象方法，你要求人家自己实现c++客户端和自己定义通信协议，那么跟直接用socket有什么区别？ 按你所说的需求，http://www.zeroc.com/这个中间件看似比较适合。 |
| 返回顶楼 | |
|
发表时间：2013-01-16
dragonsoar 写道 richard_2010 写道 据我所知，HSF目前是不跨语言的
如lz所说要跨语言，上层还需要再实现协议，这样跟web service还有什么区别，性能能可观么 不是不赞同lz的开源精神，只是他帖子里面很多“我的我的”把所有的功劳都归为自己了，你觉得是他一个人的工作么？ 服务端跨语言，我是真没有这个实力。实话，呵呵~ 我说的我的是我对HSF这个框架设计的理念，不是想说我把别人的想法拿过来全都变成我的意思，不用过份解读，就是想让大家都方便点，呵呵 然后呢，性能上肯定比web service强多了。 测试一下就可以了，因为在协议上我当时挑了很多，也测试了不少。最后使用的是kryo做的默认的协议，然后又做了层缓存，源代码里面都有。大家可以测试一下性能然后呢，长连接这个对性能比短连接又高了很多，其实这些数据大家都网上可以直接找到。kryo的性能，我测试了之后确实是让兴奋，谢谢有这么好的开源产品，呵呵 然后可能有人在想，你一个人能写出来？我不信，这个也没有事，其实一个这样的工具框架一个人真能写出来。不过你要说里面代码都是我写的这肯定也不是。当时，我遇到一个非常好的同事，也是我招的人当中非常满意的人之一，刚开始是我一个人写的，后来我精力有限让他接手。他自己为了这个投入了不少心血和精力，我们经过多少没有陪媳妇睡觉的日子弄的啊。因为我们要测试手机端，和服务端等等的测试。数据量的大小，性能，单连接，多连接，服务端多核和单核，还有交换机闪断，拨网站，确实是我们真的好多夜晚没有睡好；没有第三个的人了，哈哈。我确定是两个异性恋的男人，呵呵~ 做技术，就希望大家来批评。没有事的，只是我是希望咱们说的事都是对一个事有用，有好处的，这样才能让一个东西变的更好啊，呵呵 看过代码，确实写的不错，就是ConfigServer那块没怎么看明白！之前我们也写过类似框架，只是ConfigServer是C写的。感谢netty，现在写网络通讯用netty确实方便不少。 |
| 返回顶楼 | |
