polarphp 0.0.1 alpha 发布:全新 PHP 运行时环境

p
 polarphp
发布于 2019年01月28日
收藏 31

polarphp 项目介绍

polarphp是一个全新的PHP语言的运行时环境,基于目前最新的zend virtual machine进行打造,支持最新的语言规范,同时提供了自己的运行时标准库 (libpdk)。

简单来说polarphp之于PHP语言的关系跟NodeJS之于Javascript语言一样,NodeJSv8引擎基础之上进行打造,为Javascript提供了一个在服务端运行的环境。同样polarphp也在zend engine的基础上进行打造,实现了一个除Web开发之外的一个全新的运行环境。

项目官网库:

https://gitee.com/polarphp/polarphp

https://github.com/polarphp/polarphp

欢迎小伙伴们多多star ^ _ ^

为什么发起 polarphp 项目

随着GoNodeJS的强势崛起,PHP的市场份额逐渐被蚕食,而PHP官方仍然坚守在Web编程领域,有些东西越是想守住就越守不住。polarphp借鉴NodeJSGo的相关特性对zendVM重新封装,去掉PHP一些古老弃用的特性和强Web属性,通过实现一套新的运行时框架libpdk,将PHP语言打造成为一门真正的通用性脚本语言,赋能PHP,让其拥有异步编程,协程,线程,内置的unicode支持,标准的文件IO等等特性,让PHP程序员不仅仅能做web应用,也能从容面对真正的服务端应用。

polarphp 提供的基础设施

  1. 直接面向终端,去掉SAPI从而更好的实现服务端环境。

  2. 规范化OPCODE形成规范,从而提供一种类似pyc文件的预编译机制。

  3. 提供原生多线程支持,借鉴Java在多线程方面的编程范式。

  4. 提供原生异步IO支持。

  5. 提供针对字符串的unicode支持。

  6. 提供一种全新的包组织方式,内置包依赖管理工具,类似Cargonpm

  7. 提供内置的API文档生成工具。

polarphp 大致架构

项目主要由三部分构成,主要有如下三个子模块

  1. polarvm

  2. zendAPI

  3. libpdk

这个模块大致的关系如下:

polarvm <=> zendAPI <=> libpdk

polarvm 介绍

现阶段实现对zend engine的封装,实现最基本的PHP执行环境,比如实现:

  1. 语言解析,OPCODE的执行。

  2. 实现基础运行环境,实现变量操作,数组操作,类加载机制,语言反射等等。

  3. zend engine的初始化,实现语言引擎与终端的链接,实现语言引擎对标准输入输出的直接控制。

  4. 实现语言引擎与标准库之间的回调机制。

zendAPI 介绍

做过PHP扩展的朋友应该知道,在我们开发扩展的时候,zend engine的很多接口都是通过宏调用的方式提供的,类型不安全,出错了不好调试,而且有些宏还长的特别像,同时操作数组的时候特别繁琐。zend enginegc是通过引用计数实现的,同时C语言又没有什么从语言层面帮我们管理计数的机制,从而我们在写扩展的时候管理内存不仅很繁琐而且一不小心就会造成内存泄露。特别是将写时复制和PHP变量之间的引用一起使用的时候,非常让能头痛。

如果我们的标准库如果直接基于原生的zend engine的接口,势必扩展性,可维护性会受到严重影响,特别是目前polarvm是基于zend engine二次开发的可观情况下。所以在语言引擎和标准库之间实现一个屏蔽层,对下实现对zend engine原生接口的封装,对上提供一套相对稳定且简单的面向对象的CPP编程接口。

zendAPI 提供如下的特性:

  1. 完全面向对象,对Zend Engine API进行二次定义

  2. 使用现代的C++11语法进行开发,便于维护

  3. 最大化屏蔽PHP版本对扩展开发的影响,zendAPI将对Zend Engine API不同版本带来的差异屏蔽掉

  4. 高覆盖的单元测试,保证代码质量

  5. 在封装的时候,尽最大能力保证性能

  6. 致力于项目库的二进制兼容

libpdk 介绍

libpdk 的定位是polarphp语言环境中的标准库,PDKPHP Development Kit几个单词的缩写。在设计上参考JavaJDK的模块组织风格,为PHP提供一套严谨并且功能强大的运行时标准库,让实现服务端高效编程成为可能,比如使用PHP实现类似Netty那样的事件驱动的网络框架,或者CoreDNS那样的应用项目成为可能。同时也可以让开发终端程序比如npmCargoPM2等等类似的程序更加便捷。在Web领域,libpdkpolarphp能够脱离SAPI直接像go那样自己对端口进行监听,从而实现gin那样的轻量级的服务框架更加方便,底层基于事件循环模型和多线程模型。

项目库地址: https://github.com/polarphp/libpdk

PDK计划了如下几个模块

  • Base module (基础模块,实现最基本的功能,比如输入输出,文件系统,进程与线程,事件模型等等)

  • Network module(网络模块,在基础模块之上,实现一套高性能的网络框架,让编写服务端系统更加便捷)

  • Web module (Web模块,实现常见的Http协议,提供一个类型SerletWeb运行时容器)

  • GUI module (用户界面模块,未来实现,让PHP具备编写常见的客户端系统,基于openGL实现)

polarphp 的开发计划

因为开发资源有限,开发计划暂定如下:

  1. 使用cmakezend VM进行编译,生成polarphp定制版的PHP语言虚拟机。

  2. 语言支持项目,语言测试框架,移植LLVM项目的lit测试框架。

  3. 实现polarphp驱动程序,实现从命令行执行PHP代码。

  4. polarphp虚拟机进行回归测试,暂定跑通PHP的语言虚拟机相关回归测试。

  5. 实现polarphp的内置函数。

  6. 发布核心虚拟机的docker镜像。

  7. 整合libpdk运行时框架。

  8. 实现人性化安装,尽量以最少的步骤进行polarphp的安装。

  9. 实现包管理器。

  10. 实现语言配套小工具,比如文档生成工具等等。

polarphp 优先支持的操作系统

  • debain

  • centos

  • ubuntu

  • openSUSE

  • macOS

未来打算原生支持Windows操作系统,目前正在进行知识储备。

polarphp 目前的现状

目前项目处于一个非常前期的阶段,通过docker镜像来实现项目的迭代发布,目前主要是我一个人在业余时间进行开发,欢迎大家一起玩。2019年一个重要的任务就是完善polarphp标准库libpdk,以及实现在主流的Linux操作系统上稳定的运行。

如何参与

目前我们暂时只针对中国的用户,所以采用了微信和QQ群的交流方式,下面是二维码,有兴趣的同学可以扫码加入:(推荐使用微信^ _ ^)

   

目前有以下工作组

  1. 语言核心团队

  2. 标准库团队

  3. 生态链项目团队

  4. 文档团队

  5. 官方网站维护团队

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:polarphp 0.0.1 alpha 发布:全新 PHP 运行时环境
加载中

精彩评论

p
polarphp
谢谢大家,不管未来怎么样,我们polarphp团队会持续进行迭代开发,吸收其他语言的有点融入PHP,再次感谢大家的支持。
左华栋
左华栋
phper 里睁眼看世界的第一人
红薯
红薯
一个非常有勇气的项目,坚持下去就是胜利
Minho
Minho
不兼容现有PHP项目是最大问题,swoole已经实现了你这个功能了。
wei2011
wei2011

引用来自“Doeeking”的评论

奈何大势已去也

引用来自“开源中国-首席村长”的评论

全球80%正在运行的网站都是用php开发的,你告诉我什么叫大势?
"全球80%正在运行的网站都是用php开发的"这是phper中流传最广的梗了,也是phper自信的源泉。然而仔细想想,除了php这种特征明显的语言,其它语言写的网站根本没有任何特征能判断出后端语言。对于web页面,其实只是一个字符串而已,后端用什么拼接根本无从知道,所以只能通过判断有没有后缀,比如php页面会有xx.php,或者运行服务器头的信息,但通过nginx代理后,什么特征都没有了。w3techs.com自己也提供了一个在线检查网站使用的技术的工具:https://w3techs.com/sites,用它测试也是这样,测试一些php网站能检查后服务端语言为php,但测试oschina.net或zhihu.com根据检测不出来后端语言

最新评论(52

JPer
JPer

引用来自“JPer”的评论

要是官方出的就好了,php分为俩个版本,一个cli,一个cgi;这样php程序员就可以尝试到很多异步特性;

引用来自“eechen”的评论

PHP网站一般跑在CGI模式下.
但PHP一直都有CLI版本.
用php这个命令执行php脚本,其实就是CLI运行模式.
像Swoole,WorkerMan,ReactPHP这些都是跑在PHP的CLI模式下的引擎.

PHP的几种SAPI:
php(cli,cli-server)
php-cgi(cgi-fcgi)
php-fpm(fpm-fcgi)
libphp7.so/php7apache2_4.dll(apache2handler)

如果你要使用PHP使用异步和协程来编程,以我的观点来看,现在最强大的就是Swoole这个PHP扩展库.
Swoole还有一个非常强大的特性,就是可以将基于php_stream实现的扩展,PHP网络客户端代码一键协程化.
具体一点,就是PHP原有的file_get_contents/mysqli/pdo_mysql等以及第三方的phpredis都可以自动实现协程并发.
但要注意的是,Swoole提供的异步协程API只能用于PHP的CLI模式,不能用于CGI之类的模式.
具体就是,Swoole的大多数API在PHP-FPM和Apache MOD_PHP上不能用.

引用来自“JPer”的评论

swoole我个人不是很待见,除非官方收入,或者官方出个高可用的版本,swoole吐槽的也不是一年俩年了;java就是很好的替代方案;

引用来自“eechen”的评论

Java跟Swoole有什么关系?
传统Java靠的是多线程来处理并发.
你要比,也是拿Java的Vert.x之类的跟Swoole对比.
否则真没什么好比的.

我觉得吐槽Swoole可以,但我发现很多吐槽Swoole甚至连PHP基础都不行.
所以,还是少吐槽,多学习吧.
如果你认为像"左华栋"这样的用户的吐槽是干货,我建议你多擦擦自己的眼睛.

引用来自“JPer”的评论

swoole宣传的那些特性正是其他语言最拿手最稳定的特性,而swoole呢?php基础是什么?引擎钻过,还要钻啥?抱歉,swoole就是很糟糕;

引用来自“eechen”的评论

你连PHP一直都存在的CLI模式都不了解,还说什么PHP要分CLI和CGI版本,你真好意思说你钻研过PHP引擎?
Swoole支持的异步协程机制,是其他语言最拿手的?别开玩笑了,一点都不好笑.

Swoole的完备性要比Node.js之流高得多:
• Swoole内置异步的HTTP服务器,除了能处理PHP请求,还能处理静态文件(资源存在,直接返回,无需编程,只需指定网站根目录),而Node.js默认不行.
• Swoole内置异步的WebSocket服务器,而Node.js则没有,比如需要使用第三方的Socket.IO.同时Swoole也内置了异步的MQTT/TCP/UDP服务器.
• Swoole内置异步的HTTP/Redis/MySQL/PostgreSQL等客户端,而Node.js没有内置或者不好用,比如Node.js的HTTP客户端一般都是用第三方的request.
• Swoole中仍然可以使用PHP原有的file_get_contents/phpredis/pdo_mysql等同步客户端,且支持在底层自动切换到协程实现异步.
• Swoole支持类似Go语言goroutine+channel的CSP并发编程模型.
• Swoole服务器为每个TCP连接(包括HTTP/WebSocket等)分配了一个唯一的fd编号,作为相关服务器事件回调函数的上下文变量,而Node.js却没有.
• Swoole内置心跳检测和日志记录等功能,开发者无需编程,只需传入配置项即可使用,而Node.js当然也没有.
• Swoole内置reactor多线程,worker多进程,task多进程的实现和架构,进程崩溃自动重启.
而Node.js默认没有,需要开发者自行使用cluster多进程模块编程,或者使用第三方工具如PM2.
• Swoole在事件回调函数里可以使用PHP的require实现局部热部署,配合PHP的匿名函数和匿名类,开发时修改代码无需重启服务就能生效.
而Node.js不行,需要使用一些第三方工具比如PM2自动重启服务来完成.
• Swoole不用框架就能快速开发,Node.js不用框架,做个文件上传功能都很麻烦,而Swoole则内置了$req->files用于获取上传的文件.

知之为知之.

引用来自“JPer”的评论

大哥,我给你个杠杆你能把宇宙翘起来!
第一:你老是说啥nodejs,我和你说nodejs了吗;
第二:php区分cgi和cli俩种处理方式这谁不清楚,不用你来科普,入门就知道;
第三:别在swoole了,我都听烦了,别把你工作场景强制灌输给别人;
我就一句话:swoole那些所谓的特性对于phper来说确实很心怡,但是对我来说很糟糕,很烂,知道吗?

引用来自“eechen”的评论

既然糟糕,那就应该举例说说哪里糟糕,否则就是为了黑而黑,混淆视听,罔顾事实,可不是一个技术人应该干的事.
就一个非常小小小的问题,官方demo写的timer运行中为啥会假呢?一个这玩意还能搞出bug,还协程线程呢
一位极其不愿意透漏姓名的马先生
一位极其不愿意透漏姓名的马先生
php主要部署相对于别的语言开始变得繁琐了,可能大家会说有docker,那并不是解决问题的关键
一位极其不愿意透漏姓名的马先生
一位极其不愿意透漏姓名的马先生
如果能用go去解析编译你这个,相信会成功的,其他的没用,hvvm都不行别说别的
eechen
eechen

引用来自“JPer”的评论

要是官方出的就好了,php分为俩个版本,一个cli,一个cgi;这样php程序员就可以尝试到很多异步特性;

引用来自“eechen”的评论

PHP网站一般跑在CGI模式下.
但PHP一直都有CLI版本.
用php这个命令执行php脚本,其实就是CLI运行模式.
像Swoole,WorkerMan,ReactPHP这些都是跑在PHP的CLI模式下的引擎.

PHP的几种SAPI:
php(cli,cli-server)
php-cgi(cgi-fcgi)
php-fpm(fpm-fcgi)
libphp7.so/php7apache2_4.dll(apache2handler)

如果你要使用PHP使用异步和协程来编程,以我的观点来看,现在最强大的就是Swoole这个PHP扩展库.
Swoole还有一个非常强大的特性,就是可以将基于php_stream实现的扩展,PHP网络客户端代码一键协程化.
具体一点,就是PHP原有的file_get_contents/mysqli/pdo_mysql等以及第三方的phpredis都可以自动实现协程并发.
但要注意的是,Swoole提供的异步协程API只能用于PHP的CLI模式,不能用于CGI之类的模式.
具体就是,Swoole的大多数API在PHP-FPM和Apache MOD_PHP上不能用.

引用来自“JPer”的评论

swoole我个人不是很待见,除非官方收入,或者官方出个高可用的版本,swoole吐槽的也不是一年俩年了;java就是很好的替代方案;

引用来自“eechen”的评论

Java跟Swoole有什么关系?
传统Java靠的是多线程来处理并发.
你要比,也是拿Java的Vert.x之类的跟Swoole对比.
否则真没什么好比的.

我觉得吐槽Swoole可以,但我发现很多吐槽Swoole甚至连PHP基础都不行.
所以,还是少吐槽,多学习吧.
如果你认为像"左华栋"这样的用户的吐槽是干货,我建议你多擦擦自己的眼睛.

引用来自“JPer”的评论

swoole宣传的那些特性正是其他语言最拿手最稳定的特性,而swoole呢?php基础是什么?引擎钻过,还要钻啥?抱歉,swoole就是很糟糕;

引用来自“eechen”的评论

你连PHP一直都存在的CLI模式都不了解,还说什么PHP要分CLI和CGI版本,你真好意思说你钻研过PHP引擎?
Swoole支持的异步协程机制,是其他语言最拿手的?别开玩笑了,一点都不好笑.

Swoole的完备性要比Node.js之流高得多:
• Swoole内置异步的HTTP服务器,除了能处理PHP请求,还能处理静态文件(资源存在,直接返回,无需编程,只需指定网站根目录),而Node.js默认不行.
• Swoole内置异步的WebSocket服务器,而Node.js则没有,比如需要使用第三方的Socket.IO.同时Swoole也内置了异步的MQTT/TCP/UDP服务器.
• Swoole内置异步的HTTP/Redis/MySQL/PostgreSQL等客户端,而Node.js没有内置或者不好用,比如Node.js的HTTP客户端一般都是用第三方的request.
• Swoole中仍然可以使用PHP原有的file_get_contents/phpredis/pdo_mysql等同步客户端,且支持在底层自动切换到协程实现异步.
• Swoole支持类似Go语言goroutine+channel的CSP并发编程模型.
• Swoole服务器为每个TCP连接(包括HTTP/WebSocket等)分配了一个唯一的fd编号,作为相关服务器事件回调函数的上下文变量,而Node.js却没有.
• Swoole内置心跳检测和日志记录等功能,开发者无需编程,只需传入配置项即可使用,而Node.js当然也没有.
• Swoole内置reactor多线程,worker多进程,task多进程的实现和架构,进程崩溃自动重启.
而Node.js默认没有,需要开发者自行使用cluster多进程模块编程,或者使用第三方工具如PM2.
• Swoole在事件回调函数里可以使用PHP的require实现局部热部署,配合PHP的匿名函数和匿名类,开发时修改代码无需重启服务就能生效.
而Node.js不行,需要使用一些第三方工具比如PM2自动重启服务来完成.
• Swoole不用框架就能快速开发,Node.js不用框架,做个文件上传功能都很麻烦,而Swoole则内置了$req->files用于获取上传的文件.

知之为知之.

引用来自“JPer”的评论

大哥,我给你个杠杆你能把宇宙翘起来!
第一:你老是说啥nodejs,我和你说nodejs了吗;
第二:php区分cgi和cli俩种处理方式这谁不清楚,不用你来科普,入门就知道;
第三:别在swoole了,我都听烦了,别把你工作场景强制灌输给别人;
我就一句话:swoole那些所谓的特性对于phper来说确实很心怡,但是对我来说很糟糕,很烂,知道吗?
既然糟糕,那就应该举例说说哪里糟糕,否则就是为了黑而黑,混淆视听,罔顾事实,可不是一个技术人应该干的事.
JPer
JPer

引用来自“JPer”的评论

要是官方出的就好了,php分为俩个版本,一个cli,一个cgi;这样php程序员就可以尝试到很多异步特性;

引用来自“eechen”的评论

PHP网站一般跑在CGI模式下.
但PHP一直都有CLI版本.
用php这个命令执行php脚本,其实就是CLI运行模式.
像Swoole,WorkerMan,ReactPHP这些都是跑在PHP的CLI模式下的引擎.

PHP的几种SAPI:
php(cli,cli-server)
php-cgi(cgi-fcgi)
php-fpm(fpm-fcgi)
libphp7.so/php7apache2_4.dll(apache2handler)

如果你要使用PHP使用异步和协程来编程,以我的观点来看,现在最强大的就是Swoole这个PHP扩展库.
Swoole还有一个非常强大的特性,就是可以将基于php_stream实现的扩展,PHP网络客户端代码一键协程化.
具体一点,就是PHP原有的file_get_contents/mysqli/pdo_mysql等以及第三方的phpredis都可以自动实现协程并发.
但要注意的是,Swoole提供的异步协程API只能用于PHP的CLI模式,不能用于CGI之类的模式.
具体就是,Swoole的大多数API在PHP-FPM和Apache MOD_PHP上不能用.

引用来自“JPer”的评论

swoole我个人不是很待见,除非官方收入,或者官方出个高可用的版本,swoole吐槽的也不是一年俩年了;java就是很好的替代方案;

引用来自“eechen”的评论

Java跟Swoole有什么关系?
传统Java靠的是多线程来处理并发.
你要比,也是拿Java的Vert.x之类的跟Swoole对比.
否则真没什么好比的.

我觉得吐槽Swoole可以,但我发现很多吐槽Swoole甚至连PHP基础都不行.
所以,还是少吐槽,多学习吧.
如果你认为像"左华栋"这样的用户的吐槽是干货,我建议你多擦擦自己的眼睛.

引用来自“JPer”的评论

swoole宣传的那些特性正是其他语言最拿手最稳定的特性,而swoole呢?php基础是什么?引擎钻过,还要钻啥?抱歉,swoole就是很糟糕;

引用来自“eechen”的评论

你连PHP一直都存在的CLI模式都不了解,还说什么PHP要分CLI和CGI版本,你真好意思说你钻研过PHP引擎?
Swoole支持的异步协程机制,是其他语言最拿手的?别开玩笑了,一点都不好笑.

Swoole的完备性要比Node.js之流高得多:
• Swoole内置异步的HTTP服务器,除了能处理PHP请求,还能处理静态文件(资源存在,直接返回,无需编程,只需指定网站根目录),而Node.js默认不行.
• Swoole内置异步的WebSocket服务器,而Node.js则没有,比如需要使用第三方的Socket.IO.同时Swoole也内置了异步的MQTT/TCP/UDP服务器.
• Swoole内置异步的HTTP/Redis/MySQL/PostgreSQL等客户端,而Node.js没有内置或者不好用,比如Node.js的HTTP客户端一般都是用第三方的request.
• Swoole中仍然可以使用PHP原有的file_get_contents/phpredis/pdo_mysql等同步客户端,且支持在底层自动切换到协程实现异步.
• Swoole支持类似Go语言goroutine+channel的CSP并发编程模型.
• Swoole服务器为每个TCP连接(包括HTTP/WebSocket等)分配了一个唯一的fd编号,作为相关服务器事件回调函数的上下文变量,而Node.js却没有.
• Swoole内置心跳检测和日志记录等功能,开发者无需编程,只需传入配置项即可使用,而Node.js当然也没有.
• Swoole内置reactor多线程,worker多进程,task多进程的实现和架构,进程崩溃自动重启.
而Node.js默认没有,需要开发者自行使用cluster多进程模块编程,或者使用第三方工具如PM2.
• Swoole在事件回调函数里可以使用PHP的require实现局部热部署,配合PHP的匿名函数和匿名类,开发时修改代码无需重启服务就能生效.
而Node.js不行,需要使用一些第三方工具比如PM2自动重启服务来完成.
• Swoole不用框架就能快速开发,Node.js不用框架,做个文件上传功能都很麻烦,而Swoole则内置了$req->files用于获取上传的文件.

知之为知之.
大哥,我给你个杠杆你能把宇宙翘起来!
第一:你老是说啥nodejs,我和你说nodejs了吗;
第二:php区分cgi和cli俩种处理方式这谁不清楚,不用你来科普,入门就知道;
第三:别在swoole了,我都听烦了,别把你工作场景强制灌输给别人;
我就一句话:swoole那些所谓的特性对于phper来说确实很心怡,但是对我来说很糟糕,很烂,知道吗?
eechen
eechen

引用来自“JPer”的评论

要是官方出的就好了,php分为俩个版本,一个cli,一个cgi;这样php程序员就可以尝试到很多异步特性;

引用来自“eechen”的评论

PHP网站一般跑在CGI模式下.
但PHP一直都有CLI版本.
用php这个命令执行php脚本,其实就是CLI运行模式.
像Swoole,WorkerMan,ReactPHP这些都是跑在PHP的CLI模式下的引擎.

PHP的几种SAPI:
php(cli,cli-server)
php-cgi(cgi-fcgi)
php-fpm(fpm-fcgi)
libphp7.so/php7apache2_4.dll(apache2handler)

如果你要使用PHP使用异步和协程来编程,以我的观点来看,现在最强大的就是Swoole这个PHP扩展库.
Swoole还有一个非常强大的特性,就是可以将基于php_stream实现的扩展,PHP网络客户端代码一键协程化.
具体一点,就是PHP原有的file_get_contents/mysqli/pdo_mysql等以及第三方的phpredis都可以自动实现协程并发.
但要注意的是,Swoole提供的异步协程API只能用于PHP的CLI模式,不能用于CGI之类的模式.
具体就是,Swoole的大多数API在PHP-FPM和Apache MOD_PHP上不能用.

引用来自“JPer”的评论

swoole我个人不是很待见,除非官方收入,或者官方出个高可用的版本,swoole吐槽的也不是一年俩年了;java就是很好的替代方案;

引用来自“eechen”的评论

Java跟Swoole有什么关系?
传统Java靠的是多线程来处理并发.
你要比,也是拿Java的Vert.x之类的跟Swoole对比.
否则真没什么好比的.

我觉得吐槽Swoole可以,但我发现很多吐槽Swoole甚至连PHP基础都不行.
所以,还是少吐槽,多学习吧.
如果你认为像"左华栋"这样的用户的吐槽是干货,我建议你多擦擦自己的眼睛.

引用来自“JPer”的评论

swoole宣传的那些特性正是其他语言最拿手最稳定的特性,而swoole呢?php基础是什么?引擎钻过,还要钻啥?抱歉,swoole就是很糟糕;
你连PHP一直都存在的CLI模式都不了解,还说什么PHP要分CLI和CGI版本,你真好意思说你钻研过PHP引擎?
Swoole支持的异步协程机制,是其他语言最拿手的?别开玩笑了,一点都不好笑.

Swoole的完备性要比Node.js之流高得多:
• Swoole内置异步的HTTP服务器,除了能处理PHP请求,还能处理静态文件(资源存在,直接返回,无需编程,只需指定网站根目录),而Node.js默认不行.
• Swoole内置异步的WebSocket服务器,而Node.js则没有,比如需要使用第三方的Socket.IO.同时Swoole也内置了异步的MQTT/TCP/UDP服务器.
• Swoole内置异步的HTTP/Redis/MySQL/PostgreSQL等客户端,而Node.js没有内置或者不好用,比如Node.js的HTTP客户端一般都是用第三方的request.
• Swoole中仍然可以使用PHP原有的file_get_contents/phpredis/pdo_mysql等同步客户端,且支持在底层自动切换到协程实现异步.
• Swoole支持类似Go语言goroutine+channel的CSP并发编程模型.
• Swoole服务器为每个TCP连接(包括HTTP/WebSocket等)分配了一个唯一的fd编号,作为相关服务器事件回调函数的上下文变量,而Node.js却没有.
• Swoole内置心跳检测和日志记录等功能,开发者无需编程,只需传入配置项即可使用,而Node.js当然也没有.
• Swoole内置reactor多线程,worker多进程,task多进程的实现和架构,进程崩溃自动重启.
而Node.js默认没有,需要开发者自行使用cluster多进程模块编程,或者使用第三方工具如PM2.
• Swoole在事件回调函数里可以使用PHP的require实现局部热部署,配合PHP的匿名函数和匿名类,开发时修改代码无需重启服务就能生效.
而Node.js不行,需要使用一些第三方工具比如PM2自动重启服务来完成.
• Swoole不用框架就能快速开发,Node.js不用框架,做个文件上传功能都很麻烦,而Swoole则内置了$req->files用于获取上传的文件.

知之为知之.
JPer
JPer

引用来自“JPer”的评论

要是官方出的就好了,php分为俩个版本,一个cli,一个cgi;这样php程序员就可以尝试到很多异步特性;

引用来自“eechen”的评论

PHP网站一般跑在CGI模式下.
但PHP一直都有CLI版本.
用php这个命令执行php脚本,其实就是CLI运行模式.
像Swoole,WorkerMan,ReactPHP这些都是跑在PHP的CLI模式下的引擎.

PHP的几种SAPI:
php(cli,cli-server)
php-cgi(cgi-fcgi)
php-fpm(fpm-fcgi)
libphp7.so/php7apache2_4.dll(apache2handler)

如果你要使用PHP使用异步和协程来编程,以我的观点来看,现在最强大的就是Swoole这个PHP扩展库.
Swoole还有一个非常强大的特性,就是可以将基于php_stream实现的扩展,PHP网络客户端代码一键协程化.
具体一点,就是PHP原有的file_get_contents/mysqli/pdo_mysql等以及第三方的phpredis都可以自动实现协程并发.
但要注意的是,Swoole提供的异步协程API只能用于PHP的CLI模式,不能用于CGI之类的模式.
具体就是,Swoole的大多数API在PHP-FPM和Apache MOD_PHP上不能用.

引用来自“JPer”的评论

swoole我个人不是很待见,除非官方收入,或者官方出个高可用的版本,swoole吐槽的也不是一年俩年了;java就是很好的替代方案;

引用来自“eechen”的评论

Java跟Swoole有什么关系?
传统Java靠的是多线程来处理并发.
你要比,也是拿Java的Vert.x之类的跟Swoole对比.
否则真没什么好比的.

我觉得吐槽Swoole可以,但我发现很多吐槽Swoole甚至连PHP基础都不行.
所以,还是少吐槽,多学习吧.
如果你认为像"左华栋"这样的用户的吐槽是干货,我建议你多擦擦自己的眼睛.
swoole宣传的那些特性正是其他语言最拿手最稳定的特性,而swoole呢?php基础是什么?引擎钻过,还要钻啥?抱歉,swoole就是很糟糕;
JPer
JPer

引用来自“JPer”的评论

要是官方出的就好了,php分为俩个版本,一个cli,一个cgi;这样php程序员就可以尝试到很多异步特性;

引用来自“eechen”的评论

PHP网站一般跑在CGI模式下.
但PHP一直都有CLI版本.
用php这个命令执行php脚本,其实就是CLI运行模式.
像Swoole,WorkerMan,ReactPHP这些都是跑在PHP的CLI模式下的引擎.

PHP的几种SAPI:
php(cli,cli-server)
php-cgi(cgi-fcgi)
php-fpm(fpm-fcgi)
libphp7.so/php7apache2_4.dll(apache2handler)

如果你要使用PHP使用异步和协程来编程,以我的观点来看,现在最强大的就是Swoole这个PHP扩展库.
Swoole还有一个非常强大的特性,就是可以将基于php_stream实现的扩展,PHP网络客户端代码一键协程化.
具体一点,就是PHP原有的file_get_contents/mysqli/pdo_mysql等以及第三方的phpredis都可以自动实现协程并发.
但要注意的是,Swoole提供的异步协程API只能用于PHP的CLI模式,不能用于CGI之类的模式.
具体就是,Swoole的大多数API在PHP-FPM和Apache MOD_PHP上不能用.

引用来自“JPer”的评论

swoole我个人不是很待见,除非官方收入,或者官方出个高可用的版本,swoole吐槽的也不是一年俩年了;java就是很好的替代方案;

引用来自“左华栋”的评论

没啥可吐槽的。php 两级分化很严重,能注意到这些问题的基本都会 go 或者 java node ,除非是历史原因,否则选择swoole 的可能性很小。 一些传统的 php-fpm 足够满足了,也不会想这些,他们php5.3 都能继续用。。。
对头,目前的swoole是被逼无奈的场景下才回去选择他,否则绝对不回因为有几个协程、定时器等特性选择它的,我想说的就是swoole太糟糕了,学习是有成本的,就swoole来说我个人觉得没有必要付出,java本人搞了78年了,不如把这个时间浪费在学习go上,而不是这个所谓翻天覆地的swoole!!!
久峰爱玩火

引用来自“斌哥1”的评论

生成类似.pyc, .class文件这个很赞,期待官方能出,一直不出呀

引用来自“eechen”的评论

PHP有一个函数,叫: opcache_compile_file
PHP有一个配置,叫: opcache.file_cache
opcache扩展满足不了他
久峰爱玩火

引用来自“JPer”的评论

要是官方出的就好了,php分为俩个版本,一个cli,一个cgi;这样php程序员就可以尝试到很多异步特性;

引用来自“eechen”的评论

PHP网站一般跑在CGI模式下.
但PHP一直都有CLI版本.
用php这个命令执行php脚本,其实就是CLI运行模式.
像Swoole,WorkerMan,ReactPHP这些都是跑在PHP的CLI模式下的引擎.

PHP的几种SAPI:
php(cli,cli-server)
php-cgi(cgi-fcgi)
php-fpm(fpm-fcgi)
libphp7.so/php7apache2_4.dll(apache2handler)

如果你要使用PHP使用异步和协程来编程,以我的观点来看,现在最强大的就是Swoole这个PHP扩展库.
Swoole还有一个非常强大的特性,就是可以将基于php_stream实现的扩展,PHP网络客户端代码一键协程化.
具体一点,就是PHP原有的file_get_contents/mysqli/pdo_mysql等以及第三方的phpredis都可以自动实现协程并发.
但要注意的是,Swoole提供的异步协程API只能用于PHP的CLI模式,不能用于CGI之类的模式.
具体就是,Swoole的大多数API在PHP-FPM和Apache MOD_PHP上不能用.
打这么多字 说这些废话 逼王啊
返回顶部
顶部