再談PHP未來之路

這門語言現(xiàn)在到底處于生命周期的哪個階段？其定位到底是怎樣的？諸如 PHP7、Swoole 的出現(xiàn)到底能給 PHP 帶來怎樣的變化？

當(dāng)我們拿 PHP 和 java 進(jìn)行比較的時候，我們往往就兩門語言本身進(jìn)行比較，如一個是弱類型一個是強(qiáng)類型，一個是數(shù)組打天下一個是各種數(shù)據(jù)結(jié)構(gòu)，甚至連花括號是不是換行寫都會被討論一番。但它們真正的區(qū)別并非這些。

當(dāng)我們談?wù)撘婚T語言的時候，我們是在談它的生態(tài)。

“生態(tài)”一詞在百度百科上的解釋是：“生態(tài)一詞，現(xiàn)在通常是指生物的生活狀態(tài)。指生物在一定的自然環(huán)境下生存和發(fā)展的狀態(tài)，也指生物的生理特性和生活習(xí)性。生態(tài)（Eco-）一詞源于古希臘字，意思是指家（house）或者我們的環(huán)境”。

生態(tài)具有如下特點(diǎn)：

1. 生態(tài)是系統(tǒng)，由多個部分組成的完整體；
2. 生態(tài)是開放系統(tǒng)；
3. 生態(tài)具有動態(tài)平衡性；
4. 維持其動態(tài)平衡的是源動力，源動力一旦消失，生態(tài)即消亡。例如地球生態(tài)系統(tǒng)的源動力是太陽能；一旦太陽消失，地球生態(tài)則不復(fù)存在（想想《流浪地球》）；

一種生物的生存狀態(tài)不取決于生物自身，而取決于環(huán)境，就如恐龍的滅絕并非恐龍自身退化了，而是環(huán)境改變了（或者說恐龍的進(jìn)化趕不上環(huán)境的變化）。

一門語言的興衰不取決于它自身，而取決于環(huán)境，具體來說是環(huán)境中源動力的強(qiáng)弱。

PHP 應(yīng) Web 而生，考查其興衰得考查互聯(lián)網(wǎng)的發(fā)展。

一般認(rèn)為互聯(lián)網(wǎng)大致經(jīng)歷了三個階段：

• 階段一：Web1.0 時代，傳統(tǒng)的內(nèi)容網(wǎng)站，如企業(yè)官網(wǎng)、行業(yè)門戶網(wǎng)站等，網(wǎng)站自身產(chǎn)生內(nèi)容，用戶僅查看內(nèi)容；
• 階段二：Web2.0 時代，用戶參與內(nèi)容的創(chuàng)建，如論壇、博客。階段一和階段二都是內(nèi)容為主，服務(wù)為輔（雖然內(nèi)容的產(chǎn)生方式有所不同）；
• 階段三：移動互聯(lián)網(wǎng)時代，信息流、內(nèi)容與服務(wù)并存；

以上三個階段的演化中，用戶參與度越來越高，交互方式越來越豐富，網(wǎng)站流量越來越大。

階段一和階段二是 PHP 的黃金時代，從階段二開始悄悄發(fā)生變化，而到了階段三，PHP 的黃金時代基本結(jié)束。

PHP 這門語言的特點(diǎn)是“簡單、實(shí)用”，入行門檻極低，一個編程小白，一周入門，兩天出個網(wǎng)站。一個典型的例子，在數(shù)據(jù)結(jié)構(gòu)上，不像其他語言有 Array、List、Map、Set，PHP 一個 Array 搞定所有的情況。

PHP 的這種“簡單”是通過犧牲性能為代價的。由于需要簡單，不能有各種類型限制，PHP 必須是動態(tài)語言；由于需要簡單，能封裝則封裝，一個 file_x_contents 搞定文件（甚至是網(wǎng)絡(luò)）讀寫（該函數(shù)是一次性將文件全部加載到內(nèi)存中，很多人開發(fā)不考慮其局限性而用在所有場景，導(dǎo)致內(nèi)存溢出）；由于 Array 承包了所有集合型數(shù)據(jù)結(jié)構(gòu)，其底層需要做各種處理不說，業(yè)務(wù)層也無法自主選擇更合適的數(shù)據(jù)結(jié)構(gòu)做針對性的優(yōu)化（雖然后來 SPL 提供了一些基本數(shù)據(jù)結(jié)構(gòu)）。

PHP 的這種“簡單”還犧牲了另一樣?xùn)|西：程序員的專業(yè)素質(zhì)。PHP 程序員根本不需要去了解真正的 Array 和 List 有什么區(qū)別，也不需要去管數(shù)據(jù)流、緩沖區(qū)。從長期來看，這一點(diǎn)是致命的，它使得 PHP 生態(tài)中的重要一環(huán)很脆弱，很可能是導(dǎo)致 PHP 最終衰落的真正因素。

在 Web1.0 時代，一方面內(nèi)容產(chǎn)生者是網(wǎng)站自身，另一方面人們只能通過桌面瀏覽器上網(wǎng)，這些因素使得這個階段絕大部分公司根本不會遇到高并發(fā)等性能問題，而且業(yè)務(wù)的簡單性使得單體應(yīng)用足以應(yīng)付一切，因而這個階段 PHP 的缺陷根本不足為患。于是，PHP 的優(yōu)勢（簡單上手、快速開發(fā)）讓這門語言大行其道，什么 JSP、ASP，根本不是對手。那個時期，人們談?wù)?java、C# 時，基本是在談 ERP，只有 PHP 才是 Web。

到了 2.0 時代，論壇、博客、SNS 的出現(xiàn)，使得用戶創(chuàng)建內(nèi)容成為可能。由于用戶的積極參與，網(wǎng)站服務(wù)器流量相對于 1.0 時代有了突增，特別是 SNS 的信息流特性，使得服務(wù)器面臨相當(dāng)?shù)奶魬?zhàn)。不過由于人們?nèi)匀皇峭ㄟ^ PC 瀏覽器上網(wǎng)，在一定程度上限制了使用頻率。這個時期，一些大公司針對 PHP 的性能缺陷做了自己的改造，如新浪的各種 c 擴(kuò)展（yaf、yar 等），facebook 的 HVVM。

在這兩個黃金時代，PHP 世界涌現(xiàn)了大量的經(jīng)典開源項(xiàng)目：WordPress、ecshop、Magento、Discuz、Thinkphp、Yii 等。

徹底結(jié)束掉 PHP 黃金時代的是移動互聯(lián)網(wǎng)的到來。iphone 改變了世界，也改變了 PHP 的命運(yùn)。

移動互聯(lián)網(wǎng)時代，人們隨時隨地都能上網(wǎng)，而且?guī)缀趺咳艘徊渴謾C(jī)，這帶來的直接效果就是 Web 使用需求出現(xiàn)了數(shù)量級的增長。另外，移動互聯(lián)網(wǎng)時代的另一個特點(diǎn)是內(nèi)容+服務(wù)的一體化，網(wǎng)站不再只是提供內(nèi)容，還提供服務(wù)（如各種 O2O），因而在使用頻率、交互體驗(yàn)上的需求都大大增強(qiáng)。

舉個例子，在 1.0 時代，瀏覽器和服務(wù)器根本不需要建立長連接，2.0 時代，由于信息流的出現(xiàn)，要求有輪詢機(jī)制，但由于當(dāng)時無論是瀏覽器還是 PHP 都不支持長連接，人們想了各種奇淫技巧來實(shí)現(xiàn)輪詢。移動互聯(lián)網(wǎng)時代，瀏覽器端有了 WebSocket，悲劇的是 PHP 本身卻不支持 WebSocket（由于 PHP 的運(yùn)行機(jī)制是一次請求后進(jìn)程就結(jié)束了，在語言核心層面無法提供 WebSocket 機(jī)制。要想在核心層面支持 WebSocket，必須改造 PHP 的整個運(yùn)行機(jī)制，這幾乎是不可能的）。

至此，一方面 PHP 的性能問題成了致命問題，另一方面 PHP 各種“方便”的機(jī)制（如由 php-fpm 代替 PHP 腳本自身的常駐進(jìn)程）滿足不了新的場景需求，反倒成了桎梏。

在移動互聯(lián)、萬物成網(wǎng)的大背景下，微服務(wù)應(yīng)運(yùn)而生。一般認(rèn)為微服務(wù)本身并非新的概念，早期的 SOA 就有其身影。不過我們談?wù)撘粋€概念本身到底新不新沒有意義（就好比有人認(rèn)為中國的勾三股四弦五的發(fā)現(xiàn)比希臘的畢達(dá)哥拉斯定理要早，于是認(rèn)為該定理是中國人發(fā)現(xiàn)的；有人認(rèn)為中國的陰陽學(xué)說含有二進(jìn)制思想，便認(rèn)為二進(jìn)制是中國人發(fā)明的），重要的是一個概念何時形成了一套完整的體系，以及是如何來解決實(shí)際問題的。

微服務(wù)架構(gòu)是相對單體架構(gòu)來說的。我們先說說微服務(wù)的缺點(diǎn)：服務(wù)間調(diào)用關(guān)系復(fù)雜、難治理、問題排查復(fù)雜、分布式事務(wù)問題等。既然有這么多缺點(diǎn)，為啥微服務(wù)架構(gòu)當(dāng)今能大行其道？原因在于單體架構(gòu)解決不了當(dāng)今面臨的問題：巨大而復(fù)雜的業(yè)務(wù)群、高并發(fā)、高可用的系統(tǒng)需求。

微服務(wù)給 PHP 帶來什么呢？

當(dāng)我們將單體架構(gòu)拆解成一個個小的服務(wù)的時候，我們來考查一下編程語言的選擇，看看 PHP 還是不是最佳選擇：

• 首先微服務(wù)要輕量化。
• 其次服務(wù)要被多個業(yè)務(wù)端調(diào)用，其運(yùn)行要足夠快。
• 另外當(dāng)服務(wù)間通信非常頻繁時，通信協(xié)議要保持高效，此時 HTTP 協(xié)議并非最佳，很多公司傾向于 RPC 協(xié)議。
• 后端服務(wù)相對于前面的業(yè)務(wù)層來說，變動頻率相對要低一些，因而可以適當(dāng)?shù)貭奚恍╅_發(fā)效率。
• 要有較成熟的生態(tài)和框架支持（成熟的服務(wù)治理生態(tài)）。

從上面幾點(diǎn)來看，PHP 并非最佳選擇：

• 傳統(tǒng)的 PHP 架構(gòu)是 nginx + php-fpm + PHP script，顯然不夠輕量，成百上千個服務(wù)都馱著這么厚厚的一層殼，顯然存在資源浪費(fèi)問題。
• PHP 作為腳本語言，由于存在腳本解析消耗，運(yùn)行速度上趕不上 java、C++ 等靜態(tài)語言（不過在 PHP 引入 opcode cache 后情況得到了很大改善，而且對于 Web 來說大部分時候都是 I/O 密集型操作，語言本身的性能影響對于絕大部分的公司來說并非主要問題————不過一方面心理學(xué)研究表明人類的認(rèn)知并非完全理性的，人們認(rèn)為 PHP 比 java 性能差那就是差，不管實(shí)際差多少（這就好比我們認(rèn)為大品牌的東西一定比小品牌的好一樣，編程語言的世界也有品牌效應(yīng)））。
• PHP 核心沒有提供現(xiàn)成的 RPC 方案，但可以通過擴(kuò)展解決，這不是問題。問題是傳統(tǒng)的 PHP 架構(gòu)（nginx + fpm + script，一次請求完成后工作進(jìn)程即結(jié)束）并不能很好地應(yīng)用 RPC 通信的優(yōu)勢。
• 在生態(tài)和框架上，Swoole 貌似是個不錯的選擇，不過 Swoole 的微服務(wù)生態(tài)目前尚不成熟。
• 大部分的 PHP 程序員對服務(wù)化比較陌生（以及對性能、可靠性等非功能性需求的普遍漠視），上手較慢。

綜合考慮，大部分公司進(jìn)行服務(wù)化的時候，會選用主流靜態(tài)語言（java、C++ 以及后起之秀 golang 等）做服務(wù)，PHP 更多是來開發(fā)中間的業(yè)務(wù)聚合系統(tǒng)來調(diào)用這些服務(wù)。

至此，PHP 走下“神壇”，官方那句“PHP 是有史以來最好的語言”永成過去式。

不少人認(rèn)為，PHP7 和 Swoole 給 PHP 在服務(wù)化時代帶來新希望，因?yàn)槔碚撋希厦嫣岬降膯栴} PHP7 和 Swoole 都能較好的解決。

首先 PHP7 帶來了極大的性能提升，而且引入強(qiáng)類型、嚴(yán)格模式等新特性，使得 PHP 越來越像強(qiáng)類型語言。其次 Swoole 的出現(xiàn)使得 PHP 很容易像 java、go 那樣實(shí)現(xiàn)常駐進(jìn)程服務(wù)而不需要依賴 nginx + php-fpm，那么 由“nginx + php-fpm + script” 的 CGI 模式在服務(wù)化時遇到的問題也都得到了很好的解決。

那么，PHP7（以及即將到來的 PHP8 的 JIT 特性）和 Swoole 能給 PHP 帶來第二個黃金時代嗎？

個人認(rèn)為不能。還是那句話，當(dāng)我們談?wù)撜Z言時，實(shí)際上是在談?wù)撋鷳B(tài)。

編程語言的生態(tài)系統(tǒng)中有個很重要的角色：開發(fā)者群體。PHP 自出生時的目標(biāo)就是“簡單、強(qiáng)大、實(shí)用”，實(shí)現(xiàn)了高度的封裝，讓開發(fā)人員專心面對業(yè)務(wù)。這對工程是好事，對開發(fā)人員的成長（以及開發(fā)人員生態(tài)）來說卻不是。絕大部分的 PHPer 都是業(yè)務(wù)工程師，幾乎所有工作都是各種業(yè)務(wù)的 CRUD，很少涉及稍底層的東西，也鮮有關(guān)乎設(shè)計(jì)、架構(gòu)的。在我周圍的，以及面試遇到的，大部分人根本不了解設(shè)計(jì)模式、數(shù)據(jù)結(jié)構(gòu)、算法、計(jì)算機(jī)原理，寫出來的代碼也僅僅是實(shí)現(xiàn)了業(yè)務(wù)的功能性需求，很少考慮非功能性需求。另外，在傳統(tǒng) PHP 的 CGI 模式下，PHP 腳本并不需要考慮自我恢復(fù)、自我保護(hù)能力如限流、重試、異步等這些在微服務(wù)架構(gòu)下必須考慮的東西。

另外，由于大部分 PHP 程序員平時都是使用 MVC 框架提供的功能實(shí)現(xiàn) CRUD，較少進(jìn)行對象建模（PHP 并非生來就是面向?qū)ο笳Z言，OO 特性是后面加進(jìn)去的），導(dǎo)致大部分有相當(dāng)工作經(jīng)驗(yàn)的 PHPer 的建模能力都很弱，而微服務(wù)的一個重要工作就是對單體項(xiàng)目按業(yè)務(wù)領(lǐng)域進(jìn)行拆分、建模，這對 PHPer 來說是個相當(dāng)大的挑戰(zhàn)。

一個結(jié)果是，PHP 程序員普遍專業(yè)素質(zhì)都很弱，根本勝任不了復(fù)雜的系統(tǒng)架構(gòu)————這里的復(fù)雜性有兩個層面：技術(shù)層面和業(yè)務(wù)層面。

PHP7 和 Swoole 雖然彌補(bǔ)了語言自身的短板，卻彌補(bǔ)不了生態(tài)中非語言部分的缺陷。有人認(rèn)為這些缺陷是歷史造成的，不能代表未來。萬物的生命都是連續(xù)的、演化的，歷史往往決定了未來，雖然身處現(xiàn)在的我們察覺不出。既然 PHP 生態(tài)在解決復(fù)雜系統(tǒng)問題時不具備優(yōu)勢，那么公司就會自然而然地選擇其它更具優(yōu)勢的生態(tài)系統(tǒng)，自此便形成惡心循環(huán)（現(xiàn)實(shí)中我們遇到的情況是，很多使用 PHP 作為主要語言的中小公司業(yè)務(wù)規(guī)模上來后，不得不從外面聘請架構(gòu)師，這些架構(gòu)師大部分都是 java 出身，到公司第一件事就是強(qiáng)行 PHP 轉(zhuǎn) java）。

有人可能覺得我是 PHP 黑，畢竟我也沒有做過嚴(yán)格的調(diào)查來得出上面的結(jié)論。但我們可以通過一些現(xiàn)象管中窺豹：

• 我們可以很容易找到用 java、C++ 寫的設(shè)計(jì)模式、數(shù)據(jù)結(jié)構(gòu)與算法方面的暢銷書，卻幾乎找不到 PHP 的。
• 我們在博客園、CSDN 等技術(shù)博客上能看到大量 java、C++、C# 程序員的博客，卻很少看到 PHP 的。
• 我們看到技術(shù)博客上大量 java 程序員在談?wù)摳鞣N設(shè)計(jì)、服務(wù)、“三高”架構(gòu)，卻很少見到 PHP 的。
• 我們能看到 java、C++ 程序員到處參加各種技術(shù)峰會，卻很少見到 PHPer（除了 PHP 自己的專項(xiàng)會議）。

你會覺得僅憑 PHP7 與 Swoole 能讓幾乎不談設(shè)計(jì)模式、不研究數(shù)據(jù)結(jié)構(gòu)與算法、很少寫博客、很少參加峰會的 PHPer 們開拓出一片服務(wù)化的新天地嗎？

PHP 曾經(jīng)輝煌過，在移動互聯(lián)網(wǎng)之前，在單體為王的時代，就像 Delphi 在 Windows 桌面應(yīng)用為王的時代取得的輝煌一樣?，F(xiàn)實(shí)的需求是語言生態(tài)系統(tǒng)的源動力，當(dāng)需求發(fā)生不可逆轉(zhuǎn)的改變時，午日終將西傍。

那么，接下來的問題是：PHP 會很快沒落嗎？

這個問題實(shí)際是在問：如今 PHP 是否還在某些場景下具有優(yōu)勢（即是否還存在現(xiàn)實(shí)需求這一源動力）？

PHP 的優(yōu)勢是簡單、門檻低、實(shí)現(xiàn)功能快捷，很適合如下場景：

• 業(yè)務(wù)、系統(tǒng)相對簡單，無需服務(wù)化；
• 對性能不是很敏感；
• 需要快速實(shí)現(xiàn)、快速迭代；

在上面這些場景下，微服務(wù)（以及 java、C++ 等靜態(tài)語言）的優(yōu)點(diǎn)并不能彌補(bǔ)其缺點(diǎn)，因而推薦使用單體架構(gòu)或者簡單的服務(wù)化（僅僅進(jìn)行主要服務(wù)拆分，并不引入復(fù)雜的服務(wù)治理體系），這種情形下 PHP 的優(yōu)勢就顯現(xiàn)出來了。一般中小公司正是滿足上面的場景，因而我們發(fā)現(xiàn)即使是在移動互聯(lián)網(wǎng)時代 PHP 輝煌不再，但仍有大量中小公司采用 PHP 作為核心開發(fā)語言。

另外一個事實(shí)是，由于所有的大公司都是由小公司成長來的，在公司規(guī)模尚小的時候，他們大多也是采用 PHP 作為核心語言的，規(guī)模成長后，雖然 PHP 的各種短板阻礙了系統(tǒng)的發(fā)展，但由于已經(jīng)有大量的 PHP 項(xiàng)目，完全重新用其他語言開發(fā)一遍不太現(xiàn)實(shí)，因而他們會采用各種優(yōu)化手段，比如編寫 PHP 擴(kuò)展或者將 PHP 編譯成某種靜態(tài)語言（如 C++），或者將單體項(xiàng)目中的某些核心功能拆解成服務(wù)，單體項(xiàng)目調(diào)用后端服務(wù)接口————這種情況下，PHP 項(xiàng)目成了粘合層。

將 PHP 作為粘合語言的不光是因?yàn)闅v史遺留問題，還有不少公司新項(xiàng)目也會采用這種架構(gòu)，這樣既充分利用了 PHP 的開發(fā)效率（因?yàn)檎澈蠈油容^靠前端，需求變動較頻繁，開發(fā)效率是必須要考慮的重要因素），也保證了核心服務(wù)的性能。

那么，接下來的問題是，作為快速原型語言和粘合層語言，有沒有其他語言比 PHP 更具優(yōu)勢？

至少國內(nèi)不用談 Python 和 RoR（在國外這兩者在 Web 開發(fā)上的占有率也不及 PHP），Python 程序員的重心已轉(zhuǎn)大數(shù)據(jù)、人工智能了， RoR 至少在國內(nèi)一直不溫不火，在程序員的招聘上比 PHP 要難很多。

nodejs 曾經(jīng)被認(rèn)為是 PHP 的最大對手，一個很大的原因是人們認(rèn)為如果一個公司使用 nodejs 作為后端語言，那么他只需要一樣技術(shù)棧（前后端都是 js 程序員，而 js 程序員和 PHP 一樣一抓一大把），體現(xiàn)了莫大的成本優(yōu)勢。但事實(shí)是 nodejs 并沒有對 PHP 造成根本威脅，未來也不太可能會，原因是持上面觀點(diǎn)的人認(rèn)為統(tǒng)一技術(shù)棧就一定能節(jié)約成本，但這是個偽命題。一門語言具有解決某個問題的能力不代表人們就一定會拿它去解決問題，就好比 PHP 也能進(jìn)行 socket 編程，但很少公司在生產(chǎn)環(huán)境大規(guī)模使用 PHP 編寫服務(wù)器。js 天生就是 Web 前端語言，因而絕大部分 js 程序員都是一直做前端開發(fā)的，而前端開發(fā)和后端開發(fā)模式上有很大不同。前端在很長一段時間都是面向 DOM 編程，即使是有了模塊化、React 這些新玩法后，前端開發(fā)的重心仍然是事件驅(qū)動的交互式編程。后端開發(fā)的重心在于建模（即使不對業(yè)務(wù)進(jìn)行對象建模，也至少需要面向數(shù)據(jù)庫進(jìn)行數(shù)據(jù)建模）以及業(yè)務(wù)邏輯的實(shí)現(xiàn)，做后端開發(fā)，數(shù)據(jù)庫、Linux 服務(wù)器是繞不開的，而這兩者恰恰是大部分前端程序員所缺乏的（換句話說，要招一個既很熟悉前端開發(fā)又很熟悉后端開發(fā)的 js 程序員是非常難的）。結(jié)果就是，招一個 js 程序員用 nodejs 開發(fā)后端系統(tǒng)，其成本遠(yuǎn)大于招一個 PHPer。

因而，PHP 在未來可預(yù)見的很長時期內(nèi)不會沒落，它會作為中小公司的快速原型語言和大公司的粘合層語言長期存在。

另一個結(jié)論是：Python、Ruby On Rails、nodejs 這些語言雖然不會對 PHP 造成根本威脅，但會跟 PHP 一同在 Web 開發(fā)領(lǐng)域長期存在————因?yàn)樗鼈兊脑磩恿κ窍嗤?，?PHP 相對于它們的優(yōu)勢又不足以完全抹殺掉它們的存在。

總結(jié)：

最后，我將上面的分析總結(jié)成四個論斷：

• 論斷一：PHP 在移動互聯(lián)網(wǎng)到來之前出現(xiàn)過黃金時期，如今輝煌不再；
• 論斷二：PHP 在未來可預(yù)見的很長時期內(nèi)不會沒落；
• 論斷三：后黃金時代 PHP 的定位：中小公司的快速原型語言以及大公司的中間粘合層語言；
• 論斷四：PHP7 和 Swoole 讓 PHP 在和其他同層級語言（如 Python、RoR、nodejs）的競爭中保持優(yōu)勢，但無法給 PHP 帶來根本的變化（無法改變 PHP 的定位）；

以上就是再談PHP未來之路的詳細(xì)內(nèi)容，更多關(guān)于PHP的資料請關(guān)注腳本之家其它相關(guān)文章！