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

[twogoods]

[update]

yar

[gemini]

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

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

[crytis]

改装的 dubbo

[jlak0106]

dubbo

[VeryEase]

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

[0915240]

@VeryEase 上次弄了下 没搞好。

[murmur]

xmlrpc

[9hills]

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

[orderc]

php-yar

[Tom008]

thrift

[sagaxu]

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

[zuoxiaomo]

自己早的轮子呀

[zuoxiaomo]

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

[gouchaoer]

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

[crossoverJie]

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

[sagaxu]

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

[orderc]

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

[gouchaoer]

@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 的优势在哪里

[orderc]

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

[sagaxu]

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

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

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

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