摘要：接下來會(huì)對其中五個(gè)比較常見的運(yùn)行模式進(jìn)行說明。模式是目前主流的服務(wù)運(yùn)行模式，擁有高效可靠的性能，推薦大家使用。由于微軟的排他性，只能運(yùn)行于環(huán)境。

這里所說的 PHP 運(yùn)行模式， 其實(shí)指的是 SAPI （Server Application Programming Interface，服務(wù)端應(yīng)用編程端口 ）。SAPI 為 PHP 提供了一個(gè)和外部通信的接口， PHP 就是通過這個(gè)接口來與其它的應(yīng)用進(jìn)行數(shù)據(jù)交互的。針對不同的應(yīng)用場景， PHP 也提供了多種不同的 SAPI ，常見的有：apache、apache2filter、apache2handler、cli、cgi、embed 、fast-cgi、isapi 等等。

php_sapi_name() — 返回 web 服務(wù)器和 PHP 之間的接口類型?？赡芊祷氐闹蛋?aolserver、apache、 apache2filter、apache2handler、 caudium、cgi （直到 PHP 5.3）, cgi-fcgi、cli、 cli-server、 continuity、embed、fpm-fcgi、 isapi、litespeed、 milter、nsapi、 phttpd、pi3web、roxen、 thttpd、tux 和 webjames。

目前 PHP 內(nèi)置的很多 SAPI 實(shí)現(xiàn)都已不再維護(hù)或者變的有些非主流了，PHP 社區(qū)目前正在考慮將一些 SAPI 移出代碼庫。 社區(qū)對很多功能的考慮是除非真的非常必要，或者某些功能已近非常通用了，否則就在 PECL 庫中。

接下來會(huì)對其中五個(gè)比較常見的運(yùn)行模式進(jìn)行說明。

CLI（ Command Line Interface ）， 也就是命令行接口，PHP 默認(rèn)會(huì)安裝。通過這個(gè)接口，可以在 shell 環(huán)境下與 PHP 進(jìn)行交互 。在終端里輸入 php -v，會(huì)得到類似下圖的結(jié)果（安裝了 PHP 前提下）：

因?yàn)橛?CLI 的存在，我們可以直接在終端命令行里運(yùn)行 PHP 腳本，就像使用 shell、Python 那樣，不用依賴于 WEB 服務(wù)器。比如 Laravel 框架中的 Artisan 命令行工具，它其實(shí)就是一個(gè) PHP 腳本，用來幫助我們快速構(gòu)建 Laravel 應(yīng)用的。

CGI（Common Gateway Interface，通用網(wǎng)關(guān)接口）是一種重要的互聯(lián)網(wǎng)技術(shù)，可以讓一個(gè)客戶端，從網(wǎng)頁瀏覽器向執(zhí)行在網(wǎng)絡(luò)服務(wù)器上的程序請求數(shù)據(jù)。CGI 描述了服務(wù)器和請求處理程序之間傳輸數(shù)據(jù)的一種標(biāo)準(zhǔn)。

WEB 服務(wù)器只是內(nèi)容的分發(fā)者。比如 Nginx，如果客戶端請求了 /index.html，那么 Nginx 會(huì)去文件系統(tǒng)中找到這個(gè)文件，發(fā)送給瀏覽器，這里分發(fā)的是靜態(tài)數(shù)據(jù)；如果客戶端現(xiàn)在請求的是 /index.php，根據(jù)配置文件，Nginx 知道這個(gè)不是靜態(tài)文件，需要去找 PHP 解析器來處理，那么它會(huì)把這個(gè)請求經(jīng)過簡單處理后交給PHP 解析器。Nginx 會(huì)傳哪些數(shù)據(jù)給 PHP 解析器呢？url 要有吧，查詢字符串也得有吧，POST 數(shù)據(jù)也要有，HTTP 請求頭 不能少吧，好的，CGI 就是規(guī)定要傳哪些數(shù)據(jù)、以什么樣的格式傳遞給后方處理這個(gè)請求的協(xié)議。

CGI 模式運(yùn)行原理：當(dāng) Nginx 收到瀏覽器 /index.php 這個(gè)請求后，首先會(huì)創(chuàng)建一個(gè)對應(yīng)實(shí)現(xiàn)了 CGI 協(xié)議的進(jìn)程，這里就是 php-cgi（PHP 解析器）。接下來 php-cgi 會(huì)解析 php.ini 文件，初始化執(zhí)行環(huán)境，然后處理請求，再以 CGI 規(guī)定的格式返回處理后的結(jié)果，退出進(jìn)程。最后，Nginx 再把結(jié)果返回給瀏覽器。整個(gè)流程就是一個(gè) Fork-And-Execute 模式。當(dāng)用戶請求數(shù)量非常多時(shí)，會(huì)大量擠占系統(tǒng)的資源如內(nèi)存、CPU 時(shí)間等，造成效能低下。所以在用 CGI 方式的服務(wù)器下，有多少個(gè)連接請求就會(huì)有多少個(gè) CGI 子進(jìn)程，子進(jìn)程反復(fù)加載是 CGI 性能低下的主要原因。

CGI 模式的好處就是完全獨(dú)立于任何服務(wù)器，僅僅是做為一個(gè)中介：提供接口給 WEB 服務(wù)器和腳本語言或者是完全獨(dú)立編程語言。它們通過 CGI 協(xié)議搭線來完成數(shù)據(jù)傳遞。這樣做的好處了盡量減少它們之間的關(guān)聯(lián)，使得各自更加獨(dú)立、互不影響。

CGI 模式已經(jīng)是比較古老的模式了，這幾年都很少用了。

FastCGI（Fast Common Gateway Interface，快速通用網(wǎng)關(guān)接口）是一種讓交互程序與 Web 服務(wù)器通信的協(xié)議。FastCGI 是早期通用網(wǎng)關(guān)接口（CGI）的增強(qiáng)版本。FastCGI 致力于減少網(wǎng)頁服務(wù)器與 CGI 程序之間交互的開銷，從而使服務(wù)器可以同時(shí)處理更多的網(wǎng)頁請求。

根據(jù)定義可以知道，F(xiàn)astCGI 也是一種協(xié)議，實(shí)現(xiàn)了 FastCGI 協(xié)議的程序，更像是一個(gè)常駐型（long-live）的 CGI 協(xié)議程序，只要激活后，它可以一直執(zhí)行著，不會(huì)每次都要花費(fèi)時(shí)間去 fork 一次。

FastCGI 模式運(yùn)行原理：FastCGI 進(jìn)程管理器啟動(dòng)之后，首先會(huì)解析 php.ini 文件，初始化執(zhí)行環(huán)境，然后會(huì)啟動(dòng)多個(gè) CGI 協(xié)議解釋器守護(hù)進(jìn)程 (進(jìn)程管理中可以看到多個(gè) php-cig 或 php-cgi.exe)，并等待來自 WEB 服務(wù)器的連接；當(dāng)客戶端請求到達(dá) WEB 服務(wù)器時(shí)，F(xiàn)astCGI 進(jìn)程管理器會(huì)選擇并連接到一個(gè) CGI 解釋器， WEB 服務(wù)器將 CGI環(huán)境變量和標(biāo)準(zhǔn)輸入發(fā)送到 FastCGI 的子進(jìn)程 php-cgi 中； php-cgi 子進(jìn)程完成處理后便將標(biāo)準(zhǔn)輸出和錯(cuò)誤信息返回給 WEB 服務(wù)器；此時(shí) php-cgi 子進(jìn)程就會(huì)關(guān)閉連接，該請求便處理結(jié)束，接著繼續(xù)等待并處理來自 FastCGI 進(jìn)程管理器的下一個(gè)請求連接。

FastCGI 模式采用了 C/S 結(jié)構(gòu)，可以將 WEB 服務(wù)器和腳本解析服務(wù)器分開，同時(shí)在腳本解析服務(wù)器上啟動(dòng)一個(gè)或者多個(gè)腳本解析守護(hù)進(jìn)程。當(dāng) WEB 服務(wù)器每次遇到動(dòng)態(tài)程序時(shí)，可以將其直接交付給 FastCGI 進(jìn)程來執(zhí)行，然后將得到的結(jié)果返回給瀏覽器。這種方式可以讓 WEB 服務(wù)器專一地處理靜態(tài)請求或者將動(dòng)態(tài)腳本服務(wù)器的結(jié)果返回給客戶端，這在很大程度上提高了整個(gè)應(yīng)用系統(tǒng)的性能。

另外，在 CGI 模式下，php-cgi 在 php.ini 配置變更后，需要重啟 php-cgi 進(jìn)程才能讓新的 php-ini 配置生效，不可以平滑重啟。而在 FastCGI 模式下，PHP-FPM 可以通過生成新的子進(jìn)程來實(shí)現(xiàn) php.ini 修改后的平滑重啟。

PHP-FPM（PHP-FastCGI Process Manager）是 PHP 語言中實(shí)現(xiàn)了 FastCGI 協(xié)議的進(jìn)程管理器，由 Andrei Nigmatulin 編寫實(shí)現(xiàn)，已被 PHP 官方收錄并集成到內(nèi)核中。

FastCGI 模式的優(yōu)點(diǎn)：

從穩(wěn)定性上看，F(xiàn)astCGI 模式是以獨(dú)立的進(jìn)程池來運(yùn)行 CGI 協(xié)議程序，多帶帶一個(gè)進(jìn)程死掉，系統(tǒng)可以很輕易的丟棄，然后重新分配新的進(jìn)程來運(yùn)行邏輯；

從安全性上看，F(xiàn)astCGI 模式支持分布式運(yùn)算。FastCGI 程序和宿主的 Server 完全獨(dú)立，F(xiàn)astCGI 程序掛了也不影響 Server；

從性能上看，F(xiàn)astCGI 模式把動(dòng)態(tài)邏輯的處理從 Server 中分離出來，大負(fù)荷的 IO 處理還是留給宿主 Server，這樣宿主 Server 可以一心一意處理 IO，對于一個(gè)普通的動(dòng)態(tài)網(wǎng)頁來說, 邏輯處理可能只有一小部分，大量的是圖片等靜態(tài)。

FastCGI 模式是目前 PHP 主流的 WEB 服務(wù)運(yùn)行模式，擁有高效可靠的性能，推薦大家使用。

PHP 常常與 Apache 服務(wù)器搭配形成 LAMP 配套的運(yùn)行環(huán)境。把 PHP 作為一個(gè)子模塊集成到 Apache 中，就是 Module 模式，Apache 中的常見配置如下：

LoadModule php5_module modules/mod_php5.so

這使用了 LoadModule 命令，該命令的第一個(gè)參數(shù)是模塊的名稱，名稱可以在模塊實(shí)現(xiàn)的源碼中找到。第二個(gè)選項(xiàng)是該模塊所處的路徑。如果需要在服務(wù)器運(yùn)行時(shí)加載模塊，可以通過發(fā)送信號(hào) HUP 或者 AP_SIG_GRACEFUL 給服務(wù)器，一旦接受到該信號(hào)，Apache 將重新裝載模塊，而不需要重新啟動(dòng)服務(wù)器。通過注冊到 apache2 的 ap_hook_post_config 掛鉤，在 Apache 啟動(dòng)的時(shí)候啟動(dòng)此模塊以接受 PHP 文件的請求。

例如，當(dāng)客戶端訪問 PHP 文件時(shí)，Apache 就會(huì)調(diào)用 php5_module 來解析 PHP 腳本。Apache 每接收到一個(gè)請求，都會(huì)產(chǎn)生一個(gè)進(jìn)程來連接 PHP 完成請求。在 Module 模式下，有時(shí)候會(huì)因?yàn)榘?PHP 作為模塊編進(jìn) Apache，而導(dǎo)致出現(xiàn)問題時(shí)很難定位是 PHP 的問題還是 Apache 的問題。

過去，憑借著豐富的模塊和功能，企業(yè)往往將 Apache 作為 WEB 服務(wù)器，于是以 Module 模式運(yùn)行的 PHP + Apache 的組合很常見。近些年，以異步事件驅(qū)動(dòng)、高性能的 Nginx 服務(wù)器的崛起，市場份額快速增長，以 FastCGI 模式運(yùn)行的 PHP + Nginx 組合，擁有更佳的性能，有趕超 Apache 的趨勢。

ISAPI（Internet Server Application Program Interface）是微軟提供的一套面向 Internet 服務(wù)的 API 接口，一個(gè) ISAPI 的 DLL，可以在被用戶請求激活后長駐內(nèi)存，等待用戶的另一個(gè)請求，還可以在一個(gè) DLL 里設(shè)置多個(gè)用戶請求處理函數(shù)，此外，ISAPI 的 DLL 應(yīng)用程序和 WEB 服務(wù)器處于同一個(gè)進(jìn)程中，效率要顯著高于 CGI。由于微軟的排他性，只能運(yùn)行于 Windows 環(huán)境。

用的比較少，在這里就不做詳細(xì)介紹了。

以上內(nèi)容整理自網(wǎng)絡(luò)，參考文章：

SAPI概述

PHP的運(yùn)行模式

PHP 運(yùn)行模式

CGI、FastCGI和PHP-FPM關(guān)系圖解

搞不清FastCgi與PHP-fpm之間是個(gè)什么樣的關(guān)系