你们公司一般都用哪个 RPC 框架还是自己的轮子？

yar

都有吧。公司内部都有好多框架，开源的也很多，主要还是看业务场景吧。

//楼主光抛问题不分享自己的场景，噻~~

改装的 dubbo

dubbo

我来看看有多少人用 grpc 的......

@VeryEase 上次弄了下 没搞好。

xmlrpc

某个模块， thrift ，大约几万 qps

php-yar

thrift

rpc 作为经典的 KPI 项目，而且难度小容易实现，轮子必须非常多

自己早的轮子呀

@Tom008 thrift 还是不错的，之前公司的一个产品用的就是这套

用 yar 的我问一下，我一直不明白 rpc 调用对 http api 的优势在哪里。。。。
你们觉得 yar 的那个 php-cli 开着一个命令行的 php server 靠谱么，既然 yar 也是用的 http ，那速度和我直接正常的写个 http api 没有区别啊，而且 http api 还更成熟

用 dubbo 的还是挺多的 我们用 dubbo 和 thrift

@gouchaoer cli 起的服务，相比 fpm 这种更容易实现 php 层面的持久化，比如说你框架有 200 行 php 的初始化逻辑， fpm 方式下每个 http 请求都要初始化一下， cli 起的只要初始化一次。未来的 PHP 或许会渐渐淘汰 fpm 这种方式，每个请求都简单粗暴重来一次已经越来越跟不上时代了。

@gouchaoer 场景不同， yar 用于内部系统服务化，远程类直接当做本地类使用，调用方便。 http api 提供给外部调用，通常需要认证。

@sagaxu
@orderc
内部系统那也撑不住大流量啊，你想那只是一个单进程 php-cli ，而 php-cli 长期驻内存稳定性不好说。

而且 php-cli 的 socket 做的 server ， workerman 、 swooole 之类的，性能并不一定比 php-fpm 的强：

http://rango.swoole.com/archives/254

所以说就算本地内部使用，你没 log ，没并发，没负载均衡，没阻塞，没失败从启，那用 yar 之类的 rpc 我也没看到啥优势。。。无非就是函数调用更接近语言本身，还有就是传输的内容压缩过，但是这 2 点根本不是痛点，所以依然搞不懂 rpc 的优势在哪里

@gouchaoer yar 是基于 curl ，写的程序和普通 PHP 程序一样，由 php-fpm 执行，不需要 php-cli ，和 workerman 、 swoole 等需长驻内存的不一样。

@gouchaoer yaf 是 C 写的，框架本身是常驻内存的， swoole 框架只有底层核心部分是 C 写的，上层还有 php ，所以两者性能上面差距不大。而 yii 是纯 php 框架里最快的之一，它却比那两个慢好几倍，这正是常驻内存的价值体现。

除了框架自身开销，我们还会有一堆业务上的初始化逻辑，这是 fpm 的梦靥，除非你业务逻辑初始化也用 C 做成扩展。

cli 也不一定是单进程，比如 swoole 可以开多进程，充分利用多核性能。 qps 过万的时候，甚至连同机房 redis 的访问都嫌慢。

至于 cli 常驻靠不靠谱，我觉得可能不如 python/Java 这样经过十年以上检验的可靠，但是 php 不也一直在改善么?

@sagaxu 好吧，我一直以为 yaf 是运行在 php-fpm 内部的，那 yaf 本质上是和 swoole 和 yar 一样是 php-cli 的应用了……我小厂还是老实 yii 吧，流量达不到那么大，驾驭不了

内部服务 dubbo ，对客户端 grpc

Mark 学习

grpc

hprose 怎么没人提呢

thrift 或者 google 的 grpc