对于 Notadd 我们本来期望它实现更多...
尽管我们也尝试做了很多努力,但是由于 PHP 本身的局限,以及考虑到开发环境配置的复杂程度,最终使用了折中方案。
接下来,我们谈谈整个技术选型历程,也供今后相关开发者做借鉴和参考:
起因
我们期望 Notadd 不仅能应用到 web 领域,在嵌入式开发领域也能有所应用,同时能够使用常用的 websocket 协议。
Swoole
swoole 是我们考虑的首选方案,但从扩展性来说,难以符合我们模块化的要求,对 HTTPS 和 HTTP2 支持不够完善,同时,安装上也难倒一些 phper。在 ARM 板的安装过于复杂。当然也有好的一点,2.0 的自动异步对并发量有不少提升。
workerman
主要问题还在于 workerman 对 HTTP2 等协议支持不够完善,同时 phpsocket.io 只支持服务端模式运行,MQTT 协议也没有相应的实现,而且以 ThinkPHP 开发者居多,成本较高。
AmPHP
amphp 有着最全的协议支持,同时有各种非阻塞拓展,可以说是最符合要求的,但是异步需要对 laravel 做很大的改动。
ReactPHP
ReactPHP 实现上足够优雅,但问题也足够多,并且 PHP-cli 本身报错机制不完善,给调试带来了很大困难。
PHP-PM
按照官方说明,几乎不需要大的修改,就能将 PHP 的并发量提升 10 倍。但是在测试过程中,无法正常运行 Laravel ,所以也只能放弃~
1.0 后续的计划
1.0 还将是 PHP 版本,并且也会有后续的更新,但会取消一些过于激进的更新,目前来说,Notadd 的门槛已经足够高。
在上线应用商店后,也将会提供 1.0 ( PHP ) 的安装包。包括之前一些比较激进的改动,也会根据开发者投票进行取舍。
当然,商城等模块依然会提供。
2.0 的计划
Notadd 2.0 将基于 Nodejs 开发,同时也提供一些 1.0 无法提供的功能和特性。
为什么是 nodeJS?
- 性能: 在 IO 密集型运算中,由于异步非阻塞机制,NodeJS 可以轻松实现单机 5W 并发,而 Laravel 只有 200。
- 方便:NodeJS 可以很方便地安装拓展,而 PHP 需要 pecl 或者 phpize 甚至重新编译,这对很多就不怎么熟悉环境部署的 PHPer 来说简直就是噩梦。
- 简单: 在 ARM 环境下只需要 Node 就够了,不再需要 Nginx 或者 Apache,而 PHP 内置的服务器只适合用于调试。
- 拓展:NodeJS 本身提供了很多针对于系统层的操作,另外,npmjs.org 上也有足够多的包来使用,这对后期的拓展来说,无疑方便了很多。
为什么是 nest.js ?
不论是 express ThinkJS KOA EGG 都无法单一满足于中大型项目的开发,目录结构也会极其复杂,而借鉴 spring 思想的 nest.js 来说无疑是最适合的,并且方便 Laravel 开发者过渡。第九影院nest 默认使用 typescript ~
为什么不直接用 Go 或者 JAVA?
说到底是开发成本原因,并且这些语言在 IO 密集型优势并不明显,只有 10-20% 差异,但是在开发效率上就差了很多,而且对于企业,招人也是问题。