背景

早年我并不知道Python寫(xiě)的Web應(yīng)用是怎么部署的，總覺(jué)得像PHP、ASP一樣，僅僅提供一個(gè)語(yǔ)言級(jí)別的執(zhí)行模塊，直接嵌入Web服務(wù)器運(yùn)行，甚至于直接對(duì)外提供帶擴(kuò)展名的URL都是自然而然的事情。

前一陣學(xué)習(xí)了Python，總是如別人一樣，不自覺(jué)的和PHP進(jìn)行對(duì)比。隨著學(xué)習(xí)的逐步深入，更發(fā)現(xiàn)PHP的發(fā)展受限于其Web出身，恐將來(lái)難成正經(jīng)的通用開(kāi)發(fā)語(yǔ)言。

先說(shuō)說(shuō)PHP從歷史到今天分別是怎么運(yùn)行的： * CGI SAPI：由Web服務(wù)器的請(qǐng)求處理進(jìn)程fork+exec這個(gè)CGI，用環(huán)境變量單向傳遞Headers給應(yīng)用程序，應(yīng)用程序從stdin讀request body，其stdout會(huì)被Web服務(wù)器作為response headers和body輸出給客戶端。Web服務(wù)器和PHP CGI的關(guān)系是父子進(jìn)程間通信，當(dāng)應(yīng)用程序的響應(yīng)速度較慢時(shí)（忙于計(jì)算、外部I/O等），會(huì)阻塞對(duì)應(yīng)的Web服務(wù)器進(jìn)程/線程 * Apache2Handler等Web服務(wù)器模塊類(lèi)SAPI：Apache2調(diào)用Handler，并向其傳遞server_context；Handler利用server_context讀到Header、body等內(nèi)容之后構(gòu)造起PHP腳本的context，也就是$_SERVER之類(lèi)，然后開(kāi)始執(zhí)行PHP腳本。而腳本執(zhí)行的輸出也直接被Web服務(wù)器收集。PHP和Web服務(wù)器在同一個(gè)進(jìn)程內(nèi)執(zhí)行，處于完全從屬的地位。Apache2Handler方式本來(lái)可以通過(guò)多線程等方式讓Apache不受PHP阻塞，但由于PHP社區(qū)的堅(jiān)持，目前常見(jiàn)的Apache2+PHP配置都是prefork MPM的，以至于性能相當(dāng)一般 * FastCGI SAPI：原理是把每次fork處理一個(gè)請(qǐng)求，變成一個(gè)不退出的循環(huán)，每循環(huán)一輪就處理一個(gè)請(qǐng)求；多進(jìn)程listen在同一個(gè)socket上，實(shí)現(xiàn)并發(fā)。PHP-FPM是后來(lái)的一個(gè)民間補(bǔ)丁項(xiàng)目，提供了更好的進(jìn)程管理和附加功能，處理完License問(wèn)題之后，FPM合并入PHP主線。Web服務(wù)器和PHP的關(guān)系是網(wǎng)絡(luò)通信的關(guān)系，可以分離到不同服務(wù)器上部署。Web服務(wù)器可以使用多線程或者I/O復(fù)用技術(shù)來(lái)處理別的請(qǐng)求，性能會(huì)>比前二者好很多。但FPM的實(shí)現(xiàn)仍然不夠好。

PHP的各種擴(kuò)展模塊，大都是偏重于數(shù)據(jù)庫(kù)、字符串處理等應(yīng)用層面的功能，充分體現(xiàn)了其作為Web開(kāi)發(fā)利器的特點(diǎn)；而對(duì)于I/O、POSIX基礎(chǔ)功能，則關(guān)注較少。 Web開(kāi)發(fā)之外的領(lǐng)域，用PHP寫(xiě)?yīng)毩⑦\(yùn)行的服務(wù)器，并不是主流的用法。其依賴(lài)的pcntl、pthread等模塊也是較晚加進(jìn)來(lái)的，而且也沒(méi)啥人用。用以下幾個(gè)模塊可以很容易的創(chuàng)作一個(gè)獨(dú)立的HTTP靜態(tài)文件或SOA服務(wù)： 1. PEAR Net_Server（無(wú)人維護(hù)） 通用服務(wù)器框架 2. PEAR HTTP2 協(xié)議解析庫(kù) 3. PEAR HTTP_Server（無(wú)人維護(hù)） HTTP服務(wù)器框架 4. PECL pecl_HTTP（需要編譯） HTTP服務(wù)器框架，我沒(méi)編譯出來(lái)…… 但如果想在其中運(yùn)行一般的Web PHP腳本，就需要用PHP本身實(shí)現(xiàn)一個(gè)SAPI： * 輸入方面是很容易仿制的，除了需要構(gòu)造Predefined/Reserved Variables（感謝作者，$_SERVER等只是普通數(shù)組，只須填充內(nèi)容就差不多了，而不像ASP那樣是復(fù)雜的Request對(duì)象）再寫(xiě)一下上傳文件自動(dòng)存盤(pán)的處理就差不多了 * 輸出方面就比較麻煩，因?yàn)椤皩?xiě)”是動(dòng)作?？紤]到PHP深深的“假設(shè)stdout”情結(jié)，須使用output buffer機(jī)制收集輸出內(nèi)容。另外，header()函數(shù)等的實(shí)現(xiàn)可能會(huì)比較復(fù)雜

傳統(tǒng)上，協(xié)議解析是SAPI的工作，PHP從屬于Web服務(wù)器，以至于沒(méi)積累出什么好用的協(xié)議解析庫(kù)；而PHP書(shū)寫(xiě)的Web應(yīng)用向來(lái)都是直接調(diào)用SAPI提供的函數(shù)，積習(xí)難改，以至于想用PHP本身來(lái)寫(xiě)Web服務(wù)器就須要去實(shí)現(xiàn)一個(gè)SAPI，但又會(huì)遭遇到這個(gè)語(yǔ)言本身的Web烙印太深、假設(shè)太多，以及不夠“動(dòng)態(tài)”的問(wèn)題。 傳統(tǒng)上，網(wǎng)絡(luò)通信向來(lái)也不須由PHP來(lái)處理，以至于也沒(méi)積累出什么好用的通信框架庫(kù)。

最終，PHP成了一個(gè)Web only的開(kāi)發(fā)語(yǔ)言。真可謂成也Web、敗也Web。

一些新興的PECL擴(kuò)展提供了高性能I/O框架，比如swoole，但因?yàn)樯鲜鯯API的問(wèn)題，目前尚未出現(xiàn)像Python那樣用PHP本身寫(xiě)的PHP Web服務(wù)器。

相比之下，不用寫(xiě)<%的Python語(yǔ)言，其發(fā)展道路就更加general purpose一些： 1. 標(biāo)準(zhǔn)庫(kù)中有os、multiprocess、threading、select等模塊，一看就是面向系統(tǒng)編程而非僅僅針對(duì)Web開(kāi)發(fā) 2. 標(biāo)準(zhǔn)庫(kù)中的SocketServer及其MixIn classes、HTTPServer等可用于寫(xiě)服務(wù)器；CGI模塊可用于解析HTTP協(xié)議請(qǐng)求 3. 標(biāo)準(zhǔn)庫(kù)中的wsgiref是純Python的。也就是說(shuō)，用Python語(yǔ)言寫(xiě)一個(gè)WSGI Server很容易且是提倡的做法 4. yield語(yǔ)法加入語(yǔ)言比較早，可以實(shí)現(xiàn)協(xié)程 在Web應(yīng)用方面，Python的WSGI接口已經(jīng)基本統(tǒng)一江湖。WSGI不是通信協(xié)議，而是語(yǔ)言級(jí)別的調(diào)用約定（關(guān)于這個(gè)函數(shù)后面帶幾個(gè)什么樣的參數(shù)的約定），而WSGI可以用純Python實(shí)現(xiàn)，因此不會(huì)遇見(jiàn)用PHP實(shí)現(xiàn)SAPI的尷尬。由于Python沒(méi)有像PHP那樣深深的Web烙印*（甚至早年在Web上的部署并不太方便）*加上標(biāo)準(zhǔn)庫(kù)中很早就帶有各種基礎(chǔ)模塊，導(dǎo)向結(jié)果就是出現(xiàn)了很多優(yōu)秀的高性能框架和服務(wù)器軟件?，F(xiàn)在流行的組合是用 gunicorn WSGI Server運(yùn)行WSGI應(yīng)用程序，管理多個(gè)worker充分利用多處理器，用gevent消除I/O等待時(shí)的浪費(fèi)；對(duì)外提供HTTP服務(wù)，前面套一個(gè)nginx提供靜態(tài)文件和訪問(wèn)控制、rewrite等功能。

總結(jié)

以上是生活随笔為你收集整理的【思考】PHP——成也Web，败也Web的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。