Thrift的服务端用的是异步非阻塞的吗？
fengme opened this issue · comments
实际通信环节还是走的http
这样只是序列化上使用了thrift，比之protobuf未必有多少优势
没有用Thrift的异步非阻塞等server model可惜了
希望作者看到之后，能谈谈看法，或者更新下这个项目
原生的thrift客户端简单的封装上已经很好用，如果用异步的直接用thrift的客户端比较好。
这个项目的来源实际上是源于现在的公司大规模的使用http+thrift的序列化的基础上抽象出来，目前整个公司使用情况感觉还是比较不错的。
http使用成本较低，比较容易套用spring cloud的技术栈
thrift对联调比较友好，
整体性能不是这个考虑的重点。一般rpc框架也不是服务的瓶颈。
但是，没有异步的比较可惜。
以后工作空闲点可能会再折腾几天
上面的回复不错，可以继续交流
thrift异步非阻塞模式下，thrift原生的客户端线程不安全，这个问题对于生产环境下大规模使用必须要先解决。
仅仅使用thrift的序列化，协议上还是http，这样意义没有较好地发挥thrift的优势，可能团队中有相当多c++开发人员才选择thrift，但是这样子的话，这些技术选型对项目本身的提升、促进意义并不大，不知道这样说是否准确？
thrift的异步非阻塞模式可能是效果最好的，protostuff的序列化可能比thrift的序列化效果更好（对数据的压缩、开发简便等方面），但实际情况还是要测试验证。
希望看到相关话题方面的更好的例子，特别是前后端都是异步非阻塞模型的实例
线程安全的问题应该好解决，一般都是用从对象池里面拿client连接来避免thrift线程安全问题，
这里有个实现，https://github.com/dempeZheng/forest-thrift，
选择协议确实要看公司的技术栈的，
http协议+thrift序列化 ，相比较http协议来说联调的成本还是低很多的（1.很多对restful理解深刻,2.入参多联调也会麻烦，）thrift序列化丢给对方一个thrift的idl就好了
异步非阻塞应该是趋势，但是需要包装很好的api支持，也对开发人员的素质要求较高，不然都是一堆callback，
我个人觉得推动异步的前提最好满足：
1.像写同步代码一样写异步，
2.全链路的监控
thrift异步的api的callback感觉还没有足够好，貌似还不能返回Future，
之前简单看了RxJava，如果现在我写RPRc应该会选择用RxJava包装一下接口，不过对于这个我理解比较浅，
如果是感兴趣异步服务端的实现，
http://code.zhizus.com/2016-09-19-motan-clientMessage.html
应该是吧 ，基于网络的 都可以做到，