這門語(yǔ)言現(xiàn)在到底處于生命周期的哪個(gè)階段?其定位到底是怎樣的?諸如 PHP7、Swoole 的出現(xiàn)到底能給 PHP 帶來(lái)怎樣的變化?
當(dāng)我們拿 PHP 和 java 進(jìn)行比較的時(shí)候,我們往往就兩門語(yǔ)言本身進(jìn)行比較,如一個(gè)是弱類型一個(gè)是強(qiáng)類型,一個(gè)是數(shù)組打天下一個(gè)是各種數(shù)據(jù)結(jié)構(gòu),甚至連花括號(hào)是不是換行寫都會(huì)被討論一番。但它們真正的區(qū)別并非這些。
當(dāng)我們談?wù)撘婚T語(yǔ)言的時(shí)候,我們是在談它的生態(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):
- 生態(tài)是系統(tǒng),由多個(gè)部分組成的完整體;
- 生態(tài)是開(kāi)放系統(tǒng);
- 生態(tài)具有動(dòng)態(tài)平衡性;
- 維持其動(dòng)態(tài)平衡的是源動(dòng)力,源動(dòng)力一旦消失,生態(tài)即消亡。例如地球生態(tài)系統(tǒng)的源動(dòng)力是太陽(yáng)能;一旦太陽(yáng)消失,地球生態(tài)則不復(fù)存在(想想《流浪地球》);
一種生物的生存狀態(tài)不取決于生物自身,而取決于環(huán)境,就如恐龍的滅絕并非恐龍自身退化了,而是環(huán)境改變了(或者說(shuō)恐龍的進(jìn)化趕不上環(huán)境的變化)。
一門語(yǔ)言的興衰不取決于它自身,而取決于環(huán)境,具體來(lái)說(shuō)是環(huán)境中源動(dòng)力的強(qiáng)弱。
PHP 應(yīng) Web 而生,考查其興衰得考查互聯(lián)網(wǎng)的發(fā)展。
一般認(rèn)為互聯(lián)網(wǎng)大致經(jīng)歷了三個(gè)階段:
- 階段一:Web1.0 時(shí)代,傳統(tǒng)的內(nèi)容網(wǎng)站,如企業(yè)官網(wǎng)、行業(yè)門戶網(wǎng)站等,網(wǎng)站自身產(chǎn)生內(nèi)容,用戶僅查看內(nèi)容;
- 階段二:Web2.0 時(shí)代,用戶參與內(nèi)容的創(chuàng)建,如論壇、博客。階段一和階段二都是內(nèi)容為主,服務(wù)為輔(雖然內(nèi)容的產(chǎn)生方式有所不同);
- 階段三:移動(dòng)互聯(lián)網(wǎng)時(shí)代,信息流、內(nèi)容與服務(wù)并存;
以上三個(gè)階段的演化中,用戶參與度越來(lái)越高,交互方式越來(lái)越豐富,網(wǎng)站流量越來(lái)越大。
階段一和階段二是 PHP 的黃金時(shí)代,從階段二開(kāi)始悄悄發(fā)生變化,而到了階段三,PHP 的黃金時(shí)代基本結(jié)束。
PHP 這門語(yǔ)言的特點(diǎn)是“簡(jiǎn)單、實(shí)用”,入行門檻極低,一個(gè)編程小白,一周入門,兩天出個(gè)網(wǎng)站。一個(gè)典型的例子,在數(shù)據(jù)結(jié)構(gòu)上,不像其他語(yǔ)言有 Array、List、Map、Set,PHP 一個(gè) Array 搞定所有的情況。
PHP 的這種“簡(jiǎn)單”是通過(guò)犧牲性能為代價(jià)的。由于需要簡(jiǎn)單,不能有各種類型限制,PHP 必須是動(dòng)態(tài)語(yǔ)言;由于需要簡(jiǎn)單,能封裝則封裝,一個(gè) file_x_contents 搞定文件(甚至是網(wǎng)絡(luò))讀寫(該函數(shù)是一次性將文件全部加載到內(nèi)存中,很多人開(kāi)發(fā)不考慮其局限性而用在所有場(chǎng)景,導(dǎo)致內(nèi)存溢出);由于 Array 承包了所有集合型數(shù)據(jù)結(jié)構(gòu),其底層需要做各種處理不說(shuō),業(yè)務(wù)層也無(wú)法自主選擇更合適的數(shù)據(jù)結(jié)構(gòu)做針對(duì)性的優(yōu)化(雖然后來(lái) SPL 提供了一些基本數(shù)據(jù)結(jié)構(gòu))。
PHP 的這種“簡(jiǎn)單”還犧牲了另一樣?xùn)|西:程序員的專業(yè)素質(zhì)。PHP 程序員根本不需要去了解真正的 Array 和 List 有什么區(qū)別,也不需要去管數(shù)據(jù)流、緩沖區(qū)。從長(zhǎng)期來(lái)看,這一點(diǎn)是致命的,它使得 PHP 生態(tài)中的重要一環(huán)很脆弱,很可能是導(dǎo)致 PHP 最終衰落的真正因素。
在 Web1.0 時(shí)代,一方面內(nèi)容產(chǎn)生者是網(wǎng)站自身,另一方面人們只能通過(guò)桌面瀏覽器上網(wǎng),這些因素使得這個(gè)階段絕大部分公司根本不會(huì)遇到高并發(fā)等性能問(wèn)題,而且業(yè)務(wù)的簡(jiǎn)單性使得單體應(yīng)用足以應(yīng)付一切,因而這個(gè)階段 PHP 的缺陷根本不足為患。于是,PHP 的優(yōu)勢(shì)(簡(jiǎn)單上手、快速開(kāi)發(fā))讓這門語(yǔ)言大行其道,什么 JSP、ASP,根本不是對(duì)手。那個(gè)時(shí)期,人們談?wù)?java、C# 時(shí),基本是在談 ERP,只有 PHP 才是 Web。
到了 2.0 時(shí)代,論壇、博客、SNS 的出現(xiàn),使得用戶創(chuàng)建內(nèi)容成為可能。由于用戶的積極參與,網(wǎng)站服務(wù)器流量相對(duì)于 1.0 時(shí)代有了突增,特別是 SNS 的信息流特性,使得服務(wù)器面臨相當(dāng)?shù)奶魬?zhàn)。不過(guò)由于人們?nèi)匀皇峭ㄟ^(guò) PC 瀏覽器上網(wǎng),在一定程度上限制了使用頻率。這個(gè)時(shí)期,一些大公司針對(duì) PHP 的性能缺陷做了自己的改造,如新浪的各種 c 擴(kuò)展(yaf、yar 等),facebook 的 HVVM。
在這兩個(gè)黃金時(shí)代,PHP 世界涌現(xiàn)了大量的經(jīng)典開(kāi)源項(xiàng)目:WordPress、ecshop、Magento、Discuz、Thinkphp、Yii 等。
徹底結(jié)束掉 PHP 黃金時(shí)代的是移動(dòng)互聯(lián)網(wǎng)的到來(lái)。iphone 改變了世界,也改變了 PHP 的命運(yùn)。
移動(dòng)互聯(lián)網(wǎng)時(shí)代,人們隨時(shí)隨地都能上網(wǎng),而且?guī)缀趺咳艘徊渴謾C(jī),這帶來(lái)的直接效果就是 Web 使用需求出現(xiàn)了數(shù)量級(jí)的增長(zhǎng)。另外,移動(dòng)互聯(lián)網(wǎng)時(shí)代的另一個(gè)特點(diǎn)是內(nèi)容+服務(wù)的一體化,網(wǎng)站不再只是提供內(nèi)容,還提供服務(wù)(如各種 O2O),因而在使用頻率、交互體驗(yàn)上的需求都大大增強(qiáng)。
舉個(gè)例子,在 1.0 時(shí)代,瀏覽器和服務(wù)器根本不需要建立長(zhǎng)連接,2.0 時(shí)代,由于信息流的出現(xiàn),要求有輪詢機(jī)制,但由于當(dāng)時(shí)無(wú)論是瀏覽器還是 PHP 都不支持長(zhǎng)連接,人們想了各種奇淫技巧來(lái)實(shí)現(xiàn)輪詢。移動(dòng)互聯(lián)網(wǎng)時(shí)代,瀏覽器端有了 WebSocket,悲劇的是 PHP 本身卻不支持 WebSocket(由于 PHP 的運(yùn)行機(jī)制是一次請(qǐng)求后進(jìn)程就結(jié)束了,在語(yǔ)言核心層面無(wú)法提供 WebSocket 機(jī)制。要想在核心層面支持 WebSocket,必須改造 PHP 的整個(gè)運(yùn)行機(jī)制,這幾乎是不可能的)。
至此,一方面 PHP 的性能問(wèn)題成了致命問(wèn)題,另一方面 PHP 各種“方便”的機(jī)制(如由 php-fpm 代替 PHP 腳本自身的常駐進(jìn)程)滿足不了新的場(chǎng)景需求,反倒成了桎梏。
在移動(dòng)互聯(lián)、萬(wàn)物成網(wǎng)的大背景下,微服務(wù)應(yīng)運(yùn)而生。一般認(rèn)為微服務(wù)本身并非新的概念,早期的 SOA 就有其身影。不過(guò)我們談?wù)撘粋€(gè)概念本身到底新不新沒(méi)有意義(就好比有人認(rèn)為中國(guó)的勾三股四弦五的發(fā)現(xiàn)比希臘的畢達(dá)哥拉斯定理要早,于是認(rèn)為該定理是中國(guó)人發(fā)現(xiàn)的;有人認(rèn)為中國(guó)的陰陽(yáng)學(xué)說(shuō)含有二進(jìn)制思想,便認(rèn)為二進(jìn)制是中國(guó)人發(fā)明的),重要的是一個(gè)概念何時(shí)形成了一套完整的體系,以及是如何來(lái)解決實(shí)際問(wèn)題的。
微服務(wù)架構(gòu)是相對(duì)單體架構(gòu)來(lái)說(shuō)的。我們先說(shuō)說(shuō)微服務(wù)的缺點(diǎn):服務(wù)間調(diào)用關(guān)系復(fù)雜、難治理、問(wèn)題排查復(fù)雜、分布式事務(wù)問(wèn)題等。既然有這么多缺點(diǎn),為啥微服務(wù)架構(gòu)當(dāng)今能大行其道?原因在于單體架構(gòu)解決不了當(dāng)今面臨的問(wèn)題:巨大而復(fù)雜的業(yè)務(wù)群、高并發(fā)、高可用的系統(tǒng)需求。
微服務(wù)給 PHP 帶來(lái)什么呢?
當(dāng)我們將單體架構(gòu)拆解成一個(gè)個(gè)小的服務(wù)的時(shí)候,我們來(lái)考查一下編程語(yǔ)言的選擇,看看 PHP 還是不是最佳選擇:
- 首先微服務(wù)要輕量化。
- 其次服務(wù)要被多個(gè)業(yè)務(wù)端調(diào)用,其運(yùn)行要足夠快。
- 另外當(dāng)服務(wù)間通信非常頻繁時(shí),通信協(xié)議要保持高效,此時(shí) HTTP 協(xié)議并非最佳,很多公司傾向于 RPC 協(xié)議。
- 后端服務(wù)相對(duì)于前面的業(yè)務(wù)層來(lái)說(shuō),變動(dòng)頻率相對(duì)要低一些,因而可以適當(dāng)?shù)貭奚恍╅_(kāi)發(fā)效率。
- 要有較成熟的生態(tài)和框架支持(成熟的服務(wù)治理生態(tài))。
從上面幾點(diǎn)來(lái)看,PHP 并非最佳選擇:
- 傳統(tǒng)的 PHP 架構(gòu)是 nginx + php-fpm + PHP script,顯然不夠輕量,成百上千個(gè)服務(wù)都馱著這么厚厚的一層殼,顯然存在資源浪費(fèi)問(wèn)題。
- PHP 作為腳本語(yǔ)言,由于存在腳本解析消耗,運(yùn)行速度上趕不上 java、C++ 等靜態(tài)語(yǔ)言(不過(guò)在 PHP 引入 opcode cache 后情況得到了很大改善,而且對(duì)于 Web 來(lái)說(shuō)大部分時(shí)候都是 I/O 密集型操作,語(yǔ)言本身的性能影響對(duì)于絕大部分的公司來(lái)說(shuō)并非主要問(wèn)題————不過(guò)一方面心理學(xué)研究表明人類的認(rèn)知并非完全理性的,人們認(rèn)為 PHP 比 java 性能差那就是差,不管實(shí)際差多少(這就好比我們認(rèn)為大品牌的東西一定比小品牌的好一樣,編程語(yǔ)言的世界也有品牌效應(yīng)))。
- PHP 核心沒(méi)有提供現(xiàn)成的 RPC 方案,但可以通過(guò)擴(kuò)展解決,這不是問(wèn)題。問(wèn)題是傳統(tǒng)的 PHP 架構(gòu)(nginx + fpm + script,一次請(qǐng)求完成后工作進(jìn)程即結(jié)束)并不能很好地應(yīng)用 RPC 通信的優(yōu)勢(shì)。
- 在生態(tài)和框架上,Swoole 貌似是個(gè)不錯(cuò)的選擇,不過(guò) Swoole 的微服務(wù)生態(tài)目前尚不成熟。
- 大部分的 PHP 程序員對(duì)服務(wù)化比較陌生(以及對(duì)性能、可靠性等非功能性需求的普遍漠視),上手較慢。
綜合考慮,大部分公司進(jìn)行服務(wù)化的時(shí)候,會(huì)選用主流靜態(tài)語(yǔ)言(java、C++ 以及后起之秀 golang 等)做服務(wù),PHP 更多是來(lái)開(kāi)發(fā)中間的業(yè)務(wù)聚合系統(tǒng)來(lái)調(diào)用這些服務(wù)。
至此,PHP 走下“神壇”,官方那句“PHP 是有史以來(lái)最好的語(yǔ)言”永成過(guò)去式。
不少人認(rèn)為,PHP7 和 Swoole 給 PHP 在服務(wù)化時(shí)代帶來(lái)新希望,因?yàn)槔碚撋希厦嫣岬降膯?wèn)題 PHP7 和 Swoole 都能較好的解決。
首先 PHP7 帶來(lái)了極大的性能提升,而且引入強(qiáng)類型、嚴(yán)格模式等新特性,使得 PHP 越來(lái)越像強(qiáng)類型語(yǔ)言。其次 Swoole 的出現(xiàn)使得 PHP 很容易像 java、go 那樣實(shí)現(xiàn)常駐進(jìn)程服務(wù)而不需要依賴 nginx + php-fpm,那么 由“nginx + php-fpm + script” 的 CGI 模式在服務(wù)化時(shí)遇到的問(wèn)題也都得到了很好的解決。
那么,PHP7(以及即將到來(lái)的 PHP8 的 JIT 特性)和 Swoole 能給 PHP 帶來(lái)第二個(gè)黃金時(shí)代嗎?
個(gè)人認(rèn)為不能。還是那句話,當(dāng)我們談?wù)撜Z(yǔ)言時(shí),實(shí)際上是在談?wù)撋鷳B(tài)。
編程語(yǔ)言的生態(tài)系統(tǒng)中有個(gè)很重要的角色:開(kāi)發(fā)者群體。PHP 自出生時(shí)的目標(biāo)就是“簡(jiǎn)單、強(qiáng)大、實(shí)用”,實(shí)現(xiàn)了高度的封裝,讓開(kāi)發(fā)人員專心面對(duì)業(yè)務(wù)。這對(duì)工程是好事,對(duì)開(kāi)發(fā)人員的成長(zhǎng)(以及開(kāi)發(fā)人員生態(tài))來(lái)說(shuō)卻不是。絕大部分的 PHPer 都是業(yè)務(wù)工程師,幾乎所有工作都是各種業(yè)務(wù)的 CRUD,很少涉及稍底層的東西,也鮮有關(guān)乎設(shè)計(jì)、架構(gòu)的。在我周圍的,以及面試遇到的,大部分人根本不了解設(shè)計(jì)模式、數(shù)據(jù)結(jié)構(gòu)、算法、計(jì)算機(jī)原理,寫出來(lái)的代碼也僅僅是實(shí)現(xiàn)了業(yè)務(wù)的功能性需求,很少考慮非功能性需求。另外,在傳統(tǒng) PHP 的 CGI 模式下,PHP 腳本并不需要考慮自我恢復(fù)、自我保護(hù)能力如限流、重試、異步等這些在微服務(wù)架構(gòu)下必須考慮的東西。
另外,由于大部分 PHP 程序員平時(shí)都是使用 MVC 框架提供的功能實(shí)現(xiàn) CRUD,較少進(jìn)行對(duì)象建模(PHP 并非生來(lái)就是面向?qū)ο笳Z(yǔ)言,OO 特性是后面加進(jìn)去的),導(dǎo)致大部分有相當(dāng)工作經(jīng)驗(yàn)的 PHPer 的建模能力都很弱,而微服務(wù)的一個(gè)重要工作就是對(duì)單體項(xiàng)目按業(yè)務(wù)領(lǐng)域進(jìn)行拆分、建模,這對(duì) PHPer 來(lái)說(shuō)是個(gè)相當(dāng)大的挑戰(zhàn)。
一個(gè)結(jié)果是,PHP 程序員普遍專業(yè)素質(zhì)都很弱,根本勝任不了復(fù)雜的系統(tǒng)架構(gòu)————這里的復(fù)雜性有兩個(gè)層面:技術(shù)層面和業(yè)務(wù)層面。
PHP7 和 Swoole 雖然彌補(bǔ)了語(yǔ)言自身的短板,卻彌補(bǔ)不了生態(tài)中非語(yǔ)言部分的缺陷。有人認(rèn)為這些缺陷是歷史造成的,不能代表未來(lái)。萬(wàn)物的生命都是連續(xù)的、演化的,歷史往往決定了未來(lái),雖然身處現(xiàn)在的我們察覺(jué)不出。既然 PHP 生態(tài)在解決復(fù)雜系統(tǒng)問(wèn)題時(shí)不具備優(yōu)勢(shì),那么公司就會(huì)自然而然地選擇其它更具優(yōu)勢(shì)的生態(tài)系統(tǒng),自此便形成惡心循環(huán)(現(xiàn)實(shí)中我們遇到的情況是,很多使用 PHP 作為主要語(yǔ)言的中小公司業(yè)務(wù)規(guī)模上來(lái)后,不得不從外面聘請(qǐng)架構(gòu)師,這些架構(gòu)師大部分都是 java 出身,到公司第一件事就是強(qiáng)行 PHP 轉(zhuǎn) java)。
有人可能覺(jué)得我是 PHP 黑,畢竟我也沒(méi)有做過(guò)嚴(yán)格的調(diào)查來(lái)得出上面的結(jié)論。但我們可以通過(guò)一些現(xiàn)象管中窺豹:
- 我們可以很容易找到用 java、C++ 寫的設(shè)計(jì)模式、數(shù)據(jù)結(jié)構(gòu)與算法方面的暢銷書(shū),卻幾乎找不到 PHP 的。
- 我們?cè)诓┛蛨@、CSDN 等技術(shù)博客上能看到大量 java、C++、C# 程序員的博客,卻很少看到 PHP 的。
- 我們看到技術(shù)博客上大量 java 程序員在談?wù)摳鞣N設(shè)計(jì)、服務(wù)、“三高”架構(gòu),卻很少見(jiàn)到 PHP 的。
- 我們能看到 java、C++ 程序員到處參加各種技術(shù)峰會(huì),卻很少見(jiàn)到 PHPer(除了 PHP 自己的專項(xiàng)會(huì)議)。
你會(huì)覺(jué)得僅憑 PHP7 與 Swoole 能讓幾乎不談設(shè)計(jì)模式、不研究數(shù)據(jù)結(jié)構(gòu)與算法、很少寫博客、很少參加峰會(huì)的 PHPer 們開(kāi)拓出一片服務(wù)化的新天地嗎?
PHP 曾經(jīng)輝煌過(guò),在移動(dòng)互聯(lián)網(wǎng)之前,在單體為王的時(shí)代,就像 Delphi 在 Windows 桌面應(yīng)用為王的時(shí)代取得的輝煌一樣?,F(xiàn)實(shí)的需求是語(yǔ)言生態(tài)系統(tǒng)的源動(dòng)力,當(dāng)需求發(fā)生不可逆轉(zhuǎn)的改變時(shí),午日終將西傍。
那么,接下來(lái)的問(wèn)題是:PHP 會(huì)很快沒(méi)落嗎?
這個(gè)問(wèn)題實(shí)際是在問(wèn):如今 PHP 是否還在某些場(chǎng)景下具有優(yōu)勢(shì)(即是否還存在現(xiàn)實(shí)需求這一源動(dòng)力)?
PHP 的優(yōu)勢(shì)是簡(jiǎn)單、門檻低、實(shí)現(xiàn)功能快捷,很適合如下場(chǎng)景:
- 業(yè)務(wù)、系統(tǒng)相對(duì)簡(jiǎn)單,無(wú)需服務(wù)化;
- 對(duì)性能不是很敏感;
- 需要快速實(shí)現(xiàn)、快速迭代;
在上面這些場(chǎng)景下,微服務(wù)(以及 java、C++ 等靜態(tài)語(yǔ)言)的優(yōu)點(diǎn)并不能彌補(bǔ)其缺點(diǎn),因而推薦使用單體架構(gòu)或者簡(jiǎn)單的服務(wù)化(僅僅進(jìn)行主要服務(wù)拆分,并不引入復(fù)雜的服務(wù)治理體系),這種情形下 PHP 的優(yōu)勢(shì)就顯現(xiàn)出來(lái)了。一般中小公司正是滿足上面的場(chǎng)景,因而我們發(fā)現(xiàn)即使是在移動(dòng)互聯(lián)網(wǎng)時(shí)代 PHP 輝煌不再,但仍有大量中小公司采用 PHP 作為核心開(kāi)發(fā)語(yǔ)言。
另外一個(gè)事實(shí)是,由于所有的大公司都是由小公司成長(zhǎng)來(lái)的,在公司規(guī)模尚小的時(shí)候,他們大多也是采用 PHP 作為核心語(yǔ)言的,規(guī)模成長(zhǎng)后,雖然 PHP 的各種短板阻礙了系統(tǒng)的發(fā)展,但由于已經(jīng)有大量的 PHP 項(xiàng)目,完全重新用其他語(yǔ)言開(kāi)發(fā)一遍不太現(xiàn)實(shí),因而他們會(huì)采用各種優(yōu)化手段,比如編寫 PHP 擴(kuò)展或者將 PHP 編譯成某種靜態(tài)語(yǔ)言(如 C++),或者將單體項(xiàng)目中的某些核心功能拆解成服務(wù),單體項(xiàng)目調(diào)用后端服務(wù)接口————這種情況下,PHP 項(xiàng)目成了粘合層。
將 PHP 作為粘合語(yǔ)言的不光是因?yàn)闅v史遺留問(wèn)題,還有不少公司新項(xiàng)目也會(huì)采用這種架構(gòu),這樣既充分利用了 PHP 的開(kāi)發(fā)效率(因?yàn)檎澈蠈油容^靠前端,需求變動(dòng)較頻繁,開(kāi)發(fā)效率是必須要考慮的重要因素),也保證了核心服務(wù)的性能。
那么,接下來(lái)的問(wèn)題是,作為快速原型語(yǔ)言和粘合層語(yǔ)言,有沒(méi)有其他語(yǔ)言比 PHP 更具優(yōu)勢(shì)?
至少國(guó)內(nèi)不用談 Python 和 RoR(在國(guó)外這兩者在 Web 開(kāi)發(fā)上的占有率也不及 PHP),Python 程序員的重心已轉(zhuǎn)大數(shù)據(jù)、人工智能了, RoR 至少在國(guó)內(nèi)一直不溫不火,在程序員的招聘上比 PHP 要難很多。
nodejs 曾經(jīng)被認(rèn)為是 PHP 的最大對(duì)手,一個(gè)很大的原因是人們認(rèn)為如果一個(gè)公司使用 nodejs 作為后端語(yǔ)言,那么他只需要一樣技術(shù)棧(前后端都是 js 程序員,而 js 程序員和 PHP 一樣一抓一大把),體現(xiàn)了莫大的成本優(yōu)勢(shì)。但事實(shí)是 nodejs 并沒(méi)有對(duì) PHP 造成根本威脅,未來(lái)也不太可能會(huì),原因是持上面觀點(diǎn)的人認(rèn)為統(tǒng)一技術(shù)棧就一定能節(jié)約成本,但這是個(gè)偽命題。一門語(yǔ)言具有解決某個(gè)問(wèn)題的能力不代表人們就一定會(huì)拿它去解決問(wèn)題,就好比 PHP 也能進(jìn)行 socket 編程,但很少公司在生產(chǎn)環(huán)境大規(guī)模使用 PHP 編寫服務(wù)器。js 天生就是 Web 前端語(yǔ)言,因而絕大部分 js 程序員都是一直做前端開(kāi)發(fā)的,而前端開(kāi)發(fā)和后端開(kāi)發(fā)模式上有很大不同。前端在很長(zhǎng)一段時(shí)間都是面向 DOM 編程,即使是有了模塊化、React 這些新玩法后,前端開(kāi)發(fā)的重心仍然是事件驅(qū)動(dòng)的交互式編程。后端開(kāi)發(fā)的重心在于建模(即使不對(duì)業(yè)務(wù)進(jìn)行對(duì)象建模,也至少需要面向數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)建模)以及業(yè)務(wù)邏輯的實(shí)現(xiàn),做后端開(kāi)發(fā),數(shù)據(jù)庫(kù)、Linux 服務(wù)器是繞不開(kāi)的,而這兩者恰恰是大部分前端程序員所缺乏的(換句話說(shuō),要招一個(gè)既很熟悉前端開(kāi)發(fā)又很熟悉后端開(kāi)發(fā)的 js 程序員是非常難的)。結(jié)果就是,招一個(gè) js 程序員用 nodejs 開(kāi)發(fā)后端系統(tǒng),其成本遠(yuǎn)大于招一個(gè) PHPer。
因而,PHP 在未來(lái)可預(yù)見(jiàn)的很長(zhǎng)時(shí)期內(nèi)不會(huì)沒(méi)落,它會(huì)作為中小公司的快速原型語(yǔ)言和大公司的粘合層語(yǔ)言長(zhǎng)期存在。
另一個(gè)結(jié)論是:Python、Ruby On Rails、nodejs 這些語(yǔ)言雖然不會(huì)對(duì) PHP 造成根本威脅,但會(huì)跟 PHP 一同在 Web 開(kāi)發(fā)領(lǐng)域長(zhǎng)期存在————因?yàn)樗鼈兊脑磩?dòng)力是相同的,而 PHP 相對(duì)于它們的優(yōu)勢(shì)又不足以完全抹殺掉它們的存在。
總結(jié):
最后,我將上面的分析總結(jié)成四個(gè)論斷:
- 論斷一:PHP 在移動(dòng)互聯(lián)網(wǎng)到來(lái)之前出現(xiàn)過(guò)黃金時(shí)期,如今輝煌不再;
- 論斷二:PHP 在未來(lái)可預(yù)見(jiàn)的很長(zhǎng)時(shí)期內(nèi)不會(huì)沒(méi)落;
- 論斷三:后黃金時(shí)代 PHP 的定位:中小公司的快速原型語(yǔ)言以及大公司的中間粘合層語(yǔ)言;
- 論斷四:PHP7 和 Swoole 讓 PHP 在和其他同層級(jí)語(yǔ)言(如 Python、RoR、nodejs)的競(jìng)爭(zhēng)中保持優(yōu)勢(shì),但無(wú)法給 PHP 帶來(lái)根本的變化(無(wú)法改變 PHP 的定位);
以上就是再談PHP未來(lái)之路的詳細(xì)內(nèi)容,更多關(guān)于PHP的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
您可能感興趣的文章:- 詳解各種PHP函數(shù)漏洞
- 如何使用SublimeText3配置 PHP IDE環(huán)境
- PHPStorm+Xdebug進(jìn)行emote Debug時(shí)無(wú)法進(jìn)入斷點(diǎn)問(wèn)題排查
- php中foreach遍歷類對(duì)象的總結(jié)
- php-fpm報(bào)502問(wèn)題的解決辦法
- PHP實(shí)現(xiàn)創(chuàng)建以太坊錢包轉(zhuǎn)賬等功能
- 如何使用php生成zip壓縮包
- 詳解PHP使用非對(duì)稱加密算法RSA
- php常見(jiàn)的網(wǎng)絡(luò)攻擊及防御方法
- PHP7下安裝并使用xhprof性能分析工具
- PHP遠(yuǎn)程調(diào)用以及RPC框架
- PHP代碼加密和擴(kuò)展解密實(shí)戰(zhàn)