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