FastRPC 3.2 发布,高性能 C++ 协程 RPC 框架 - 开源中国社区
FastRPC 3.2 发布,高性能 C++ 协程 RPC 框架
feimat 2016年06月30日

FastRPC 3.2 发布,高性能 C++ 协程 RPC 框架

feimat feimat 发布于2016年06月30日 收藏 46 评论 17

有免费的MySQL,为什么还要买? >>>  

FastRPC 3.2 发布了,本次发布主要修复以下问题:

    1、优化定时器性能;

    2、优化协程http调用库性能;

    3、修复定时器内存释放漏洞。

FastRPC是一款内部封装了类似go语言协程+通道特性的C++ RPC框架,使得你能够使用同步的代码编写出异步效果同时提供RPC的功能。例如:可是的mysql redis的操作在保持同步编码方式下达到异步的效果。另外框架特别推出了协程模式下的线程池、资源池、定时器使用,使得多线程和协程间可轻易切换进行编程,达到一些无法hook的阻塞系统调用可用多线程来补充(例如C++调用python的阻塞库)

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:FastRPC 3.2 发布,高性能 C++ 协程 RPC 框架
分享
评论(17)
最新评论
0
普通的分三层,但是client锁定连接,用连接池;后来发展到一个连接发出请求后,不等待响应,也可以继续发送第2个请求,每个请求附带request ID.
0

引用来自“强子哥哥”的评论

http://git.oschina.net/qiangzigege/MyThrift 基于Thrift的轮子,已经在生产环境中跑了快1年了,毫无问题。只支持RPC,不支持服务发现。

引用来自“feimat”的评论

厉害,不过注意thrift底层是同步的,要是加上异步协程就更好了
你说的异步应该是每个请求包带ID的那种,一个socket可以多次复用吧,Thrift在0.9.3里面有几个新类以Async开头,我还不确定是不是这种类。早期主要是客户端拿 socket连接池,后端分三层:accept层,Selector IO层,业务线程池。
0

引用来自“强子哥哥”的评论

http://git.oschina.net/qiangzigege/MyThrift 基于Thrift的轮子,已经在生产环境中跑了快1年了,毫无问题。只支持RPC,不支持服务发现。

引用来自“feimat”的评论

厉害,不过注意thrift底层是同步的,要是加上异步协程就更好了

引用来自“巴拉迪维”的评论

厉害
thrift底层是可以异步的。
0
不错的样子
0
0

引用来自“强子哥哥”的评论

http://git.oschina.net/qiangzigege/MyThrift 基于Thrift的轮子,已经在生产环境中跑了快1年了,毫无问题。只支持RPC,不支持服务发现。

引用来自“feimat”的评论

厉害,不过注意thrift底层是同步的,要是加上异步协程就更好了
厉害
0

引用来自“强子哥哥”的评论

http://git.oschina.net/qiangzigege/MyThrift 基于Thrift的轮子,已经在生产环境中跑了快1年了,毫无问题。只支持RPC,不支持服务发现。
厉害,不过注意thrift底层是同步的,要是加上异步协程就更好了
0
http://git.oschina.net/qiangzigege/MyThrift 基于Thrift的轮子,已经在生产环境中跑了快1年了,毫无问题。只支持RPC,不支持服务发现。
0

引用来自“强子哥哥”的评论

有服务发现吗? 如果仅仅是RPC,那没有太多意义吧。

引用来自“feimat”的评论

支持http服务 类似web框架

引用来自“强子哥哥”的评论

那就是没有服务发现啊,那还是不好,RPC本身已经有很多解决方案了,很好的SOA方案相对少一些

引用来自“feimat”的评论

服务器发现个人觉得是建立在rpc上层业务加会好点,因为有些业务不需要服务发现,还要活生生价格zk配置,感觉麻烦了
例如像一般无状态的web服务 都是由nginx负载均衡来处理服务发现,有些分布式又需要zk做服务发现。可以考虑吧服务发现作为功能加入,但不是必须
0

引用来自“强子哥哥”的评论

有服务发现吗? 如果仅仅是RPC,那没有太多意义吧。
只能用php和python调用吗
0

引用来自“强子哥哥”的评论

有服务发现吗? 如果仅仅是RPC,那没有太多意义吧。

引用来自“feimat”的评论

支持http服务 类似web框架

引用来自“强子哥哥”的评论

那就是没有服务发现啊,那还是不好,RPC本身已经有很多解决方案了,很好的SOA方案相对少一些
服务器发现个人觉得是建立在rpc上层业务加会好点,因为有些业务不需要服务发现,还要活生生价格zk配置,感觉麻烦了
0

引用来自“强子哥哥”的评论

有服务发现吗? 如果仅仅是RPC,那没有太多意义吧。

引用来自“feimat”的评论

支持http服务 类似web框架
那就是没有服务发现啊,那还是不好,RPC本身已经有很多解决方案了,很好的SOA方案相对少一些
0

引用来自“强子哥哥”的评论

有服务发现吗? 如果仅仅是RPC,那没有太多意义吧。
支持http服务 类似web框架
0
rpc框架
0
有服务发现吗? 如果仅仅是RPC,那没有太多意义吧。
0

引用来自“554330833a”的评论

java怎么使用?
还不支持java
0
java怎么使用?
顶部