[Sw] Swoole 生態迷局，基於 Swoole 的第 109 框架

 

這兩天，又一全棧式 Swoole 協程框架面世了 - hyperf，實現思路是我心裏點了贊同的，就集成現有 PHP 生態優質組件到 Swoole 的協程中來。

有人想到，爲何不是 Swoole 集成到 Web 框架中，固然已經有案例了，若是是老項目這麼作是能夠經過常駐內存提高性能的，而且利用到 Swoole 一些特性。

可是天花板也正是傳統 Web 框架的限制，它們運行組件不是爲常駐內存和協程而設計的，因此99.9%沒法透明支持 Swoole 的，這是歷史使然。

php-fpm 是多進程模型打天下的，Web 服務器是 Nginx 多，PHP 從不用考慮太多，憋說話，加機器就能解決的問題算問題嗎。

如今科技進步了，都會觸類旁通了，眼界也必需要高呀，要省機器，要高性能，要雲原生，矛盾就這麼出現了。

全部基於 Swoole 的開發框架，上來必先普及一番 Swoole 協程的注意事項，這些注意事項都是在 Swoole 官方 wiki 上都有的，但依然穿插在框架文檔的各個地方，

你們都這樣作，厭惡感莫名就上來了，爲何 Swoole 官方 wiki 上有，你的開發框架文檔上還要再拷貝一份呢，其實在我看來，這不會是簡單的拷貝，

起碼是框架做者深諳 Swoole 協程用法，拷貝順帶本身的理解敲上去的，由於不寫的話，確定大夥兒一用都是坑，到時候先吐槽，啥玩意兒，還不如我裸寫的呢。

是的，當你把 Swoole 官方 wiki 上的特性、注意事項都瞭然於胸的時候，裸寫是最爽的，性能最高，可是咋維護呀，這必須解決呀。

那麼些個框架都出來很久了，用用看？要是寫個小開源衍生做品，用就用唄，掛就掛了，不兼容就不兼容了，存檔就存檔了，無論那麼多。

誰還沒裸寫過，這時候你義正詞嚴的創造了基於 Swoole 的第 109 個框架 swoole-micro .

 

Link：http://www.javashuo.com/article/p-rucartzb-ds.html