|
锁定老帖子 主题：纯Java的高性能长连接RPC解决方案
精华帖 (5) :: 良好帖 (0) :: 新手帖 (2) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2013-01-17
youarestupid 写道 youarestupid 写道 richard_2010 写道 这算是HSF开源的帖子么？
另，帖子动不动就我的我的，HSF真的是你一个人写出来的么？ 还是要支持一下楼主的开源精神的。 希望楼主的RPC最终能实现“跨语言” 我说的“跨语言”不仅仅是客户端，服务端也应该是跨语言的，应该像Thrift那样拥有中间定义语言文件IDL. 仅仅在Java语言内折腾，价值不太大因为纯Java的RPC方案不少，java自带的RMI也挺好用的。 ProtoBuffer不适用么？ |
| 返回顶楼 | |
|
发表时间：2013-01-17
elam 写道 youarestupid 写道 youarestupid 写道 richard_2010 写道 这算是HSF开源的帖子么？
另，帖子动不动就我的我的，HSF真的是你一个人写出来的么？ 还是要支持一下楼主的开源精神的。 希望楼主的RPC最终能实现“跨语言” 我说的“跨语言”不仅仅是客户端，服务端也应该是跨语言的，应该像Thrift那样拥有中间定义语言文件IDL. 仅仅在Java语言内折腾，价值不太大因为纯Java的RPC方案不少，java自带的RMI也挺好用的。 ProtoBuffer不适用么？ protobuffer是序列化和反序列化的工具，实际上。可以理解是所以起到的作用是跨语言的一种协义转换，和长连接没有直接关系。当然，summercool-hsf的序列化可以自定义，也是支持protobuffer的 |
| 返回顶楼 | |
|
发表时间：2013-01-17
dragonsoar 写道 elam 写道 youarestupid 写道 youarestupid 写道 richard_2010 写道 这算是HSF开源的帖子么？
另，帖子动不动就我的我的，HSF真的是你一个人写出来的么？ 还是要支持一下楼主的开源精神的。 希望楼主的RPC最终能实现“跨语言” 我说的“跨语言”不仅仅是客户端，服务端也应该是跨语言的，应该像Thrift那样拥有中间定义语言文件IDL. 仅仅在Java语言内折腾，价值不太大因为纯Java的RPC方案不少，java自带的RMI也挺好用的。 ProtoBuffer不适用么？ protobuffer是序列化和反序列化的工具，实际上。可以理解是所以起到的作用是跨语言的一种协义转换，和长连接没有直接关系。当然，summercool-hsf的序列化可以自定义，也是支持protobuffer的 protobuffer还提供了一个轻量的RPC框架 我是说youarestupid提到的RPC跨语言的方案 |
| 返回顶楼 | |
|
发表时间：2013-01-17
elam 写道 dragonsoar 写道 elam 写道 youarestupid 写道 youarestupid 写道 richard_2010 写道 这算是HSF开源的帖子么？
另，帖子动不动就我的我的，HSF真的是你一个人写出来的么？ 还是要支持一下楼主的开源精神的。 希望楼主的RPC最终能实现“跨语言” 我说的“跨语言”不仅仅是客户端，服务端也应该是跨语言的，应该像Thrift那样拥有中间定义语言文件IDL. 仅仅在Java语言内折腾，价值不太大因为纯Java的RPC方案不少，java自带的RMI也挺好用的。 ProtoBuffer不适用么？ protobuffer是序列化和反序列化的工具，实际上。可以理解是所以起到的作用是跨语言的一种协义转换，和长连接没有直接关系。当然，summercool-hsf的序列化可以自定义，也是支持protobuffer的 protobuffer还提供了一个轻量的RPC框架 我是说youarestupid提到的RPC跨语言的方案 他说的是服务端的长连接也是跨语言，server的实现。protobuffer也只是我说的那种客户端和服务端传输上的跨平台语言，和他说的还不太一样。 不过你和我说的是一个意思，呵呵 |
| 返回顶楼 | |
|
发表时间：2013-01-18
youarestupid 写道 我最想要的RPC框架：
1、跨平台（Linux/Windows/Mac OS X） 2、跨语言（Java / C++两种即可） 3、双向推送（非“一问一答式响应”，而是服务端可以主动向客户端推送消息） 满足这三个要求的RPC框架，到目前为止我找不到，最接近的是百度的BGCC，但是BGCC不支持Mac OS X系统； 第二个比较接近的是Thrift，但是Thrift不支持“双向推送”，只能是“一问一答”式响应，即“客户端请求服务端的一个方法，接收到服务端的一个返回值”，服务端不能主动向客户端发起详细推送。 楼主如果能研究出我上面列举的三个特点的RPC框架，肯定能火起来。 一个tcp socket长连接就能满足你的要求。 楼主想法很好的，但是实际上没必要再对Netty进行包装，Netty已经设计对NIO TCP，UDP，SSL等设计得很规范了，要添加event service，再多定义几行代码几个接口就行了。 |
| 返回顶楼 | |
|
发表时间：2013-01-18
diggywang 写道 youarestupid 写道 我最想要的RPC框架：
1、跨平台（Linux/Windows/Mac OS X） 2、跨语言（Java / C++两种即可） 3、双向推送（非“一问一答式响应”，而是服务端可以主动向客户端推送消息） 满足这三个要求的RPC框架，到目前为止我找不到，最接近的是百度的BGCC，但是BGCC不支持Mac OS X系统； 第二个比较接近的是Thrift，但是Thrift不支持“双向推送”，只能是“一问一答”式响应，即“客户端请求服务端的一个方法，接收到服务端的一个返回值”，服务端不能主动向客户端发起详细推送。 楼主如果能研究出我上面列举的三个特点的RPC框架，肯定能火起来。 一个tcp socket长连接就能满足你的要求。 楼主想法很好的，但是实际上没必要再对Netty进行包装，Netty已经设计对NIO TCP，UDP，SSL等设计得很规范了，要添加event service，再多定义几行代码几个接口就行了。 Socket不是面向对象的，你没有办法像调用本地对象的方法一样执行服务端的方法， 而RPC就可以。 |
| 返回顶楼 | |
|
发表时间：2013-01-18
youarestupid 写道 diggywang 写道 youarestupid 写道 我最想要的RPC框架：
1、跨平台（Linux/Windows/Mac OS X） 2、跨语言（Java / C++两种即可） 3、双向推送（非“一问一答式响应”，而是服务端可以主动向客户端推送消息） 满足这三个要求的RPC框架，到目前为止我找不到，最接近的是百度的BGCC，但是BGCC不支持Mac OS X系统； 第二个比较接近的是Thrift，但是Thrift不支持“双向推送”，只能是“一问一答”式响应，即“客户端请求服务端的一个方法，接收到服务端的一个返回值”，服务端不能主动向客户端发起详细推送。 楼主如果能研究出我上面列举的三个特点的RPC框架，肯定能火起来。 一个tcp socket长连接就能满足你的要求。 楼主想法很好的，但是实际上没必要再对Netty进行包装，Netty已经设计对NIO TCP，UDP，SSL等设计得很规范了，要添加event service，再多定义几行代码几个接口就行了。 Socket不是面向对象的，你没有办法像调用本地对象的方法一样执行服务端的方法， 而RPC就可以。 如果要Socket实现RPC的功能，需要对socket进行大规模封装地。 |
| 返回顶楼 | |
|
发表时间：2013-01-18
youarestupid 写道 youarestupid 写道 diggywang 写道 youarestupid 写道 我最想要的RPC框架：
1、跨平台（Linux/Windows/Mac OS X） 2、跨语言（Java / C++两种即可） 3、双向推送（非“一问一答式响应”，而是服务端可以主动向客户端推送消息） 满足这三个要求的RPC框架，到目前为止我找不到，最接近的是百度的BGCC，但是BGCC不支持Mac OS X系统； 第二个比较接近的是Thrift，但是Thrift不支持“双向推送”，只能是“一问一答”式响应，即“客户端请求服务端的一个方法，接收到服务端的一个返回值”，服务端不能主动向客户端发起详细推送。 楼主如果能研究出我上面列举的三个特点的RPC框架，肯定能火起来。 一个tcp socket长连接就能满足你的要求。 楼主想法很好的，但是实际上没必要再对Netty进行包装，Netty已经设计对NIO TCP，UDP，SSL等设计得很规范了，要添加event service，再多定义几行代码几个接口就行了。 Socket不是面向对象的，你没有办法像调用本地对象的方法一样执行服务端的方法， 而RPC就可以。 如果要Socket实现RPC的功能，需要对socket进行大规模封装地。 如果你的设计是基于远程方法本地调用等这些RPC的角度来看，建议看一下http://akka.io/，这东西从设计开始就有一句很响亮的口号——It's time for RPC to retire，而且从现在的进度来看，Akka确实做得非常棒！ |
| 返回顶楼 | |
|
发表时间：2013-01-18
最后修改：2013-01-18
youarestupid说的RPC本质上就是一个全套的解决方案：
1.通过socket连接 2.以一种通用的数据格式 3.将一系列方法参数 4.序列化以后 5.发去另一台电脑 6.执行一个方法 7.返回一个结果/或者不返回结果 所以不管使用哪个rpc框架 只要每台机器都同时做server和client就好了 但是对于thrift这个IDL 我认为不如protobuf 如果是纯java环境 我推荐kryo 对比如下 https://github.com/eishay/jvm-serializers/wiki |
| 返回顶楼 | |
|
发表时间：2013-01-18
“深感一个好的分表分库框架可以大大提高系统的承载能力及系统的灵活性，而一个不好的分表分库方案，则让系统在大数据量处理的时候非常郁闷”，楼主能否介绍介绍你所认为的“好的分表分库框架”？
|
| 返回顶楼 | |
