“通过 Webman 中的 gRPC 集成释放云原生开发的力量”
问题描述
我建议在 Webman 中集成对 gRPC 服务的一流支持，这可以显着增强框架构建现代高性能应用程序的能力。
gRPC 已迅速成为云原生微服务架构中高效连接服务的事实上的标准。 gRPC 强调高吞吐量、低延迟连接、集成服务发现、负载平衡、身份验证和更小的消息大小，与传统 REST API 相比，可带来显着的性能提升。 Netflix、PayPal、Square 等领先科技巨头正在采用 gRPC。
通过添加 gRPC 集成，Webman 可以让开发人员轻松地在服务之间构建极快的内部 API。这将使得诸如实时数据流和聚合之类的用例成为可能，而这些用例很难通过 REST 实现。 gRPC 工具也广泛应用于几乎所有语言生态系统，降低了采用的障碍。
集成这些功能可以将 Webman 打造成一个专为云原生开发量身定制的前瞻性框架。它打开了支持尖端用例并减少开发开销的大门。
为此你搜索到了哪些方案及不适用的原因
目前没有实现，GRPC社区也没有实现完整php对grpc服务端和客户端
929 2 0
2个回答
相似问题
年代过于久远，无法发表回答
php可以使用grpc拓展，webman同样可以使用grpc拓展来开发；
protoc生成php代码在webman项目的特定区域，然后进行业务处理即可；
以上是webman作为grpc-client的方案；
由于webman/workerman及php本身不支持http2，所以想要作为grpc-server来说，需要有相应的支持内容；
另外，你提到的云原生大概率是golang的天下，php的相关应用主要也是以client的方面涉及的，很少有厂商和企业会选择php来作为云原生的server端。
实现http2（搜索amphp）和protobuf（php-ext）在php社区有方案，但都不是完美的，大部分插件或者应用都是需要有落地场景和应用场景的，这一部分至少在目前的环境中，没有给php太多的应用落地空间，所以社区一直没有好的完整的实现（这是现状）。
php 真要做只能swoole hyperf
但是以目前webman的性能和便捷性，其实完全可以和golang甚至java在云云原生分一杯羹的
PHP暂时没有做K8S相关开发的能力以及容器管理的能力，更多的是后端偏前或者是应用层；
另外gRPC并没有性能很高，它主要是golang的RPC框架；
业内不使用gRPC的话，其实使用protobuf的也比较多，thrift也比较多，都有，这东西不是银弹；
主要现在gRPC实现的语言很多，基本覆盖了前十的web开发语言，这样在既有系统切换或者扩展就会有很多选择。譬如一个用gong开发的核心系统，后面业务扩展，使用webman再来开发一个新模块，如果支持gRPC就会很快集成。如果webman也提供grpc服务端，也能让其他语言开发的系统很快接入。
空了我弄一个插件吧
谢谢你告诉我你对进一步推进这一点的想法。我相信这可以显著推动PHP应用程序开发的现代化，并解锁以前无法实现的新用例。我们有机会使PHP在云原生开发中与其他语言媲美，而gRPC是这个未来的关键组成部分。
我理解在过去，由于PHP的短暂执行模型，实现gRPC服务器支持是不可行的。然而，随着最近通过Swoole、PhpStan和ReactPHP实现长时间运行的PHP进程的发展，我相信现在是重新考虑gRPC功能的时机。
正如你所知，在一种语言中启用完全异步和双向流的gRPC为构建性能出色、弹性极强的系统打开了大门。对于支撑各种规模后端的PHP庞大开发者社区而言，将其与Java、Go和Python等语言相提并论，可以加速采用云原生微服务模式。开发者终于可以构建低延迟的API和事件驱动的架构，而无需使用REST或WebSockets带来的开销。
我和许多其他PHP开发者很乐意在生产应用中充分利用并推广这些功能。
这回答有点像AI生成的
你说的这些php生态只有swoole,最早Swoole就是你这么想的。
swoole 支持http2协议也是最方便直接的，原生C++语言容易扩展第三库。