初識 Swoole
前言
在之前的教程當中我們已經了解到了php的幾種運行模式：
-
CGI通用網關接口(Common Gateway Interface) -
Fast-CGI是cgi的升級版本，用PHP-FPM(FastCGI Process Manager)即fast-cgi進程管理器 -
mod以模塊的形式集成進Apache中，接受Apache提供的.php文件，并進行解析。 -
CLI命令行模式，直接使用PHP去執行.php文件時便是此模式。
盡管 CLI 模式可以完成更多有趣和強大的功能，但大多數php程序員很少使用 CLI 模式。
起源
Swoole是Rango在2010年底，因為公司業務需要自己實現一個Tcp Socket Server 實現SMT P協議接收數據，但是在當時PHP在這個領域幾乎是一片空白，所以Rango自己學習，最終完成了需求；隨后便開源了此套系統，希望能幫助其他PHPer解決在這個領域的問題，讓PHP從單純的Web開發擴展到更大的空間。
項目起源
Swoole 項目最初的想法是來自于之前所做的一個企業軟件項目。當時大概是2010年底，公司產品有一個需求是用戶可以任意生成一個 email 地址，然后其他用戶可以向這個email發郵件，后臺能實時將郵件內容解析成數據，并主動通知用戶。當時項目使用PHP開發的，在實現這個需求時遇到了難題，PHP只能依賴其他的STMP服務器，通過pop3協議定時查收新郵件來完成，這樣就不是實時的。如果要實現的實時系統必須自己寫一個TCP Socket Server實現SMTP協議接收數據。當時PHP在這個領域幾乎是空白，沒有一套成熟的網絡通信框架。為了實現需求，我從socket學起到TCP/IP、IO復用、libevent、多進程，最后終于實現了這套程序。做完這個項目后我就想把這套程序開源出來，希望能幫助其他PHPer解決在這個領域的難題。如果能有這樣一個框架，那么PHP就能從單純地做一個Web網站延伸到更大的空間。還有一個重要的原因是PHP程序的性能問題，我最早是學Java出身的，工作后才轉行成為一名PHP程序員。在使用PHP開發程序的過程中，我一直在思考的問題 PHP 和 Java 比最大的優勢是什么？簡單高效， PHP 在請求完成之后會釋放所有資源和內存，無須擔心內存泄漏。代碼的質量無論高低一樣運行的很流暢。但同時這也是 PHP 致命的缺點。一旦請求數量上升，并發很高的時候，快速創建資源，又馬上釋放，使得 PHP 程序運行效率急劇下降。另外一旦項目的功能的越來越復雜，代碼增多后，對于 PHP 也會是災難。這也是 PHP 的框架為什么沒有被 PHP 程序員廣泛接受，而 Java 不存在這個問題。再好的框架也會被這種低效的方式拖累，導致系統變慢。所以想到了使用 PHP 來開發 PHP 的應用服務器，讓 PHP 的代碼加載到內存后，擁有更長的生命周期，這樣建立的數據庫連接和其他大的對象，不被釋放。每次請求只需要處理很少的代碼，而這些代碼只在第一次運行時，被 PHP 解析器編譯，駐留內存。另外，之前 PHP 不能實現的，對象持久化、數據庫連接池，緩存連接池都可以實現。系統的運行效率會大大提高。
經過一段時間研究，目前已經初步得到實現。使用 PHP 本身編寫出 HTTP 服務器，以獨立服務器方式運行，單個程序頁面 ( 有對象生成，數據庫連接、 smarty 模板操作 ) 的執行時間由原來的 0.0x 秒，下降到 0.00x 秒。使用 Apache AB 并發 100 測試。比傳統 LAMP 方式， Request per Second 高出至少 10 倍。在我的測試機上 (Ubuntu10.04 Inter Core E5300 + 2G 內存 ) ， Apache 只跑到 83RPS 。 Swoole Server 可以跑到 1150 多 RPS。
這個項目就是Swoole的雛形。這個版本一直持續維護了2年多，在這個過程中逐步有了一些經驗積累，對這套技術方案的存在問題有了更深入的理解，比如性能差、限制較多無法直接調用操作系統接口、內存管理效率低下。
入職騰訊
2011年底我入職騰訊，負責朋友網的PHP平臺開發工作。驚奇地發現朋友網的同事不光這樣想了，他們直接做到了。朋友網團隊已經在生產環境中使用了這套方案。朋友網有三架馬車，第一個是PWS，這是一個純PHP編寫的WebServer，朋友網線上有600多臺服務器運行在PWS上，完全沒有使用Apache、PHP-FPM之類的程序。第二個是SAPS，這是使用純PHP開發的一個分布式隊列，當時大概由150臺服務器的集群在跑，很多圖片裁剪、頭像處理、消息同時、數據同步等邏輯全部使用了SAPS做邏輯異步化。第三個是PSF，這是一個PHP實現的Server框架，朋友網很多邏輯層的服務器都是基于PSF實現的。大概有300臺左右的集群在運行PSF服務器程序。在朋友網的這段時間，我學到了很多Linux底層、網絡通信的知識，積累了很多大型集群高并發環境的網絡通信跟蹤、調試經驗，為開發Swoole打下了一個很好的基礎。開發Swoole
在這期間也學習了解到了Node.js、Golang這些優秀的技術方案，得到了更多靈感。在2012年的時候就有了新的想法，決定使用C語言重新實現一個性能更強、功能更強大的版本。這就是現在的Swoole擴展。現在Swoole已經被很多PHP技術團隊用于實際項目的開發工作，國內國外都有。國內知名的有百度訂單中心、百度地圖、騰訊QQ公眾號和企業QQ、戰旗直播、360、當當網、窮游等。另外還有很多物聯網、硬件、游戲項目也在使用Swoole 。另外基于Swoole的開源框架也越來越多，比如TSF、Blink、swPromise 等等，在Github上也能找到很多Swoole相關的項目和代碼。
名字由來
Swoole這個名字不是一個英文單詞，是由我創造的一個音近字。我最早想到的名字是叫做sword-server，寓意是為廣大PHPer創造一把鋒利的劍，后來聯想到swoole。
現在
隨著Swoole進入4.0時代，原2.0時期協程的各種各樣的坑，在4.0都得到了解決。 如今的Swoole可以說是真正好用可靠的PHP異步網絡引擎。
2018年7月Rango辭去工作，組織了全職的研發團隊來開發 Swoole 內核、組件和工具鏈。在文檔、測試、社區運營方面也會投入更多資源。本段來源
Swoole 能做什么
以下內容來源于Swoole官方文檔
Swoole 是使用 C 和 C++ 語言編寫的PHP擴展， 內置了異步非阻塞、多線程的網絡IO服務器，PHP程序員僅需處理事件回調即可，無需關心底層。
同時Swoole也提供了許多非常多的內置功能如：
- PHP語言的異步多線程服務器
- 異步TCP/UDP網絡客戶端
- 異步MySQL
- 異步Redis
- 數據庫連接池
- AsyncTask
- 消息隊列
- 毫秒定時器
- 異步文件讀寫
- 異步DNS查詢
- Http/WebSocket服務器端/客戶端
- Http2.0服務器端/客戶端
與大家熟知的 Workerman 框架不同，Swoole更像是一個基礎庫給了開發者一把無比鋒利的寶劍，可以按照自己想要的方法去使用。
Swoole絕大部分功能都只能運行在 CLI 模式下，也正因為此開發者可以完全的掌控Server的一切，與傳統的 php-fpm 模式不同，Swoole需要開發者自行接管各種相關事件，和管理變量的生命周期等。
與傳統Web開發的區別
我們知道 php-fpm 是 fast-cgi 運行模式的進程管理器，當啟動Server時 php-fpm 會預創建若干個 fast-cgi 處理進程；
每當請求到達 Nginx 時 Nginx 檢查到請求的是.php文件時，就將請求轉發給 php-fpm Server 然后由 php-fpm 交給某個空閑的進程處理，當處理完成后由 php-fpm 返回給 Nginx 然后由 Nginx 響應給用戶。
傳統PHP開發者幾乎無需關注這其中發生的過程甚至根本不了解，正所謂成也蕭何敗蕭何，一方面雖然降低了開發者入門的門檻但另一方面也使得大量的PHP開發者幾乎不了解也不懂的真正的服務端開發。
而 SwooleServer 則是相當于取代了 php-fpm 作為管理器的位置， 由于Swoole 是運行在 CLI 模式下， 所以可以常駐運行和以守護進程運行， 但也正因為如此，也需要開發者自行處理變量的銷毀及各種異常和超時的處理。