Notadd 从 PHP 到 Node.js 的无奈与坑点

一点小遗憾

对于 Notadd 我们本来期望它实现更多... 尽管我们也尝试做了很多努力，但是由于 PHP 本身的局限，以及考虑到开发环境配置的复杂程度，最终使用了折中方案。 接下来，我们谈谈整个技术选型历程，也供今后相关开发者做借鉴和参考：

起因

我们期望 Notadd 不仅能应用到 web 领域，在嵌入式开发领域也能有所应用，同时能够使用常用的 websocket 协议。

Swoole

swoole 是我们考虑的首选方案，但从扩展性来说，难以符合我们模块化的要求，对 HTTPS 和 HTTP2 支持不够完善，同时，安装上也会难倒一些 phper 。并且在 ARM 板的安装过于复杂。当然也有好的一点，2.0 的自动异步对并发量有不少提升。

workerman

主要问题还在于 workerman 对HTTP2 等协议支持不够完善，同时 http://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 将基于 Nest.js 这是一个跟 spring 很相似的 NodeJS 框架。

为什么是nodeJS?

1. 性能： 在 IO 密集型运算中，由于异步非阻塞机制，NodeJS 可以轻松实现单机 5W 并发，而 Laravel 只有 200左右 。
2. 方便： NodeJS 可以很方便地安装拓展，而 PHP 需要 pecl 或者 phpize 甚至重新编译，这对很多就不怎么熟悉环境部署的 PHPer 来说简直就是噩梦。
3. 简单： 在 ARM 环境下只需要 Node 就够了，不再需要 Nginx 或者 Apache ，而 PHP 内置的服务器只适合用于调试。
4. 拓展： NodeJS 本身提供了很多针对于系统层的操作，另外，http://npmjs.org 上也有足够多的包来使用，这对后期的拓展来说，无疑方便了很多。

为什么是 Nest.js ?

不论是 express ThinkJS KOA EGG 都无法单一满足于中大型项目的开发，目录结构也会极其复杂，而借鉴 spring 思想的 nest.js 来说无疑是最适合的，并且方便 Laravel 开发者过渡。并且 Nest 默认使用 Typescript ， 也支持GraphQL

为什么不直接用 Go 或者 JAVA?

说到底是开发成本原因，并且这些语言在 IO 密集型优势并不明显，只有 10-20% 差异。