👇👇最新2024IDEA永久激活(支持全家桶）👇👇
关注上面公众号回复“激活码”，获取2024年最新激活码我们之前有个业务是在线客服功能，最开始的实现就是php+swoole实现的。有可能啊，代码不行，水平也不行，部署上去占用很高，容器一天要重启好几次，有可能就是某个地方泄露了。
后来把im连接客户端的这部分用go重写了，只负责收消息，发消息。然后扔到队列里让php的业务端来处理，花了两天的时就改造完成了。容器再也没有重启过了，而且占用比较低。
swoole一开始我们就是坚定的拥护者，几乎把大部分的业务都重写了。但是以我个人学习的过程，我认为学习swoole和学go几乎差不多，虽然在swoole在语法和基础函数上可以通用（减少学习时间），但是后期学习过于陡峭，遇到问题要去翻源码或是用c的那套工具链。我想大部分phper是没有这个能力的。
swoole对于php来说，我理解就是除了语法没变外，几乎就是另外一套“语言”。
很多概念像是协程，异步，常驻内存，这些东西在fpm的环境里几乎没有任何经验上的复用。如果只是少学个语法，我认为还不如直接去学习go。
php是需要swoole的，感觉应该补充fpm的不足，并不是取代他。但是现在swoole的框架，重写一大堆的库（支持协程），又是注解。有种要取而代之的样子，就像是我需要一双“筷子”，但是直接给我砍了棵树。
我们讨论的php的优势，是建立在fpm的基础之上，但是swoole的体系之下，是否定了这个模式，这种并不是“加持”而且“割据”。
现在对这个东西已经不是特别在意了，自从经历过一些很坑很坑的业务之后，深切的发现，工具好用才是最主要的。
尤其是在业务初期，重心是，如何快速的，正确的把业务做出来，万恶之源都来自于过早的优化。
Go也好，添加了Swoole的PHP也好，最终都是要为业务服务，如果不能解决好业务问题，这些技术都是浮云。如果达到一定的量级，像Facebook那样重新发明PHP也不是不可以。当然，也可以直接通过加入更多的机器解决问题。【Golang VS PHP】哪个更适合你
真正用过 swoole 的人不会喷 swoole，真正用过 go 的人不会神化 go。
有点人用 go 写出 PHP 样子，有的人用 PHP 写出了 go 一样的高性能。
go 再完美不也没取代 PHP 吗？
语言只是工具，总有适用与不适用的场景，何必分高低决生死？
扫一扫
727
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
