php熱部署

『壹』 express 中可不可以實現熱部署

在配置文件里對對應目錄加 reloadable=true 或者每次重啟伺服器。。。 或者，把部分業務別用java寫，比如用php，tomcat里用quercus，把前端用php實現，然後就可以在線頻繁改模板神馬的。

『貳』 Python的web項目如何進行動態重載和熱部署

真正意義上的代碼熱部署應該是類似erlang那樣的，將代碼更新到節點後不停服務，不斷連接的自動應用新代碼。auto reload什麼的還是會造成業務瞬間中斷。我感覺是可以從wsgi容器級別上實現，比如更新代碼後檢測到文件變更，然後通知容器創建新的wsgi application的實例，之後所有新的請求都發送到新的wdgi application實例上。等舊wsgi application實例的最後一個請求返回後就將其回收掉。不過貌似沒有看到類似的實現

『叄』 php為什麼不適合做微服務

php不適合做微服務原因：例如與硬體通訊.至於開發的話,你可以用swoole擴展或者grpc。

PHP畢竟是CGI腳本，很多底層的驅動級的工作還不能做，而且主要是其面向對象不夠完善，在SOA上的應用還是有些不足。當然因為PHP能夠做些位計算什麼的，可以很方便的做些幀協議的操作，比如Radius協議的實現等。

快捷高效：

PHP的內核是C語言編寫的基礎好效率高，可以用C語言開發高性能的擴展組件;PHP的核心包含了數量超過1000的內置函數，功能應有盡有很全面，開箱即用程序代碼簡潔；PHP數組支持動態擴容，支持以數字、字元串或者混合鍵名的關聯數組，能大幅提高開發效率。

PHP是一門弱類型語言，程序編譯通過率高，相對其他強類型語言開發效率快；PHP天然熱部署，在php-fpm運行模式下代碼文件覆蓋即完成熱部署；PHP經過20多年的發展，在互聯網上可以搜到海量的參考資料供參考學習。

『肆』 為什麼大型網站前端使用 PHP 後台邏輯用

最近糾結了一下，如果開發一個大型的網站，我到底應該使用php還是jsp，後台到底使用php還是用java，我的選擇要麼是php要麼是java，因為我喜歡linux、unix，當然window平台也必須支持，以便哦的妹紙可以查看。這就要求用一些跨平台相當好的軟體+工具+語言，所以選擇只能是這么幾個。最後我的決定是php+java，一個前台一個後台，理由如下： php和java在開源社區的活躍度嚴重超過了其他的語言，使用人數也都是相當之多；活躍的開發工程師們能夠給我幫助，且這倆都能很好的跨平台，不用花費大量的人力物力去維護 我也做過一個物聯網的網關網站，比較復雜，當時採用的是jsp+java，復雜程度可想而知，單單說開發過程，網站部分繁瑣，每次想查看結果運行網站的時候還需要重新打包部署一下，嚴重影響了哦的開發效率，每天的時間都是在等待（因為網站比較復雜，打包部署需要浪費一些時間）。相對來說呢，php就沒有了，php靈活，好學，上手快，容易修改，容易發布，關鍵是熱部署，這個真讓哦眼睛大亮。當然看待任何事物都需要兩種眼光，php也會有缺點，比如沒有太好的開發IDE，所以拼寫錯誤很正常，且php的sql注入危險較大點，執行效率不高，安全性不如java。還有一些理由，來自知乎的米米們給的建議： Java的優點則是穩定可靠、運行效率高（尤其是JIT的出現之後差距更大了）、不容易犯錯（強類型、預編譯、必須攔截異常等等），缺點是開發和發布的效率相對較低。盡管優秀的工程師能在一定程度上改變以上的問題，但通常而言，哪能到處都是高手多如狗的夢之隊？ 從MVC的層次結構上說，在一般網站項目的開發周期中，需求變更最頻繁、調整最多的是View，其次是Controller，最後是Model。這非常好理解，沒事干誰天天改數據結構？每次版本升級控制結構都要改的啦，或多或少而已。再次是兩者之間的通信，目前RPC技術已經足夠成熟，無論是Web Service/Hessian/RESTful API都能夠讓開發人員專注在功能開發上，而不需要過多的考慮異構平台的差異和通訊的細節。這也就意味著在大公司里同時應用兩種語言的方案並不會引入過多的復雜度和工作量。當然，文檔量的下限倒是因此被拔高了不少，但事實上大部分團隊對此其實都是喜聞樂見的：別每天說文檔重要但沒空了，你不寫其他同事怎麼配合？ 靠近用戶的前端，使用PHP能夠更快的完成前端頻繁而瑣碎的更新，自如的應對各種需求的變化。頁面的結構調整、用戶輸入內容的基本驗證、僅只和用戶交互有關的簡單邏輯等都很適合使用PHP來開發，甚至可以通過類似Smarty等模板技術將其頁面的變動遷移到前端團隊。而基本的業務邏輯和數據的更新採用Java開發，可以有效的提高復用度、提升性能和吞吐能力、規避安全問題等。而開發效率稍有降低換來的是可維護性的提升，發布速度慢就更不是問題了，因為通常對於基礎業務邏輯的調整往往都是整體修改，並層層測試確認才能發布的。 所以，大型網站前端採用PHP後端採用Java，既好招人又好維護、系統穩定還性能高、連安全性都大大增加。代碼復用、文檔完備度居然也都改善了。讓你在以上這些好處觸手可及時，對架構師知識譜系在廣度上要求更高一些這事根本就不是個問題。
單一方案其實一樣可以做良好的隔離，PHP同樣可以提供Service，而性能問題其實很多時候是演算法和架構的問題而不是語言差異的問題。如Velocity或JSTL等也是很優秀的隔離方案。
但這些方案在高壓力下會暴露出很多問題而體現雙語言的優勢，這些在上面其實都提到，詳細說明一些很難得到改變的點：
1. PHP由於其動態腳本語言的特性，包括類、函數、常量在內都需要在每次請求周期中重復執行後才能建立運行環境；為了保證解析速度而犧牲編譯質量；應用了FastCGI但僅僅只是復用進程處理請求減少fork成本而不是像其他語言，初始化完畢後通過FastCGI的介面獲得數據並以對應介面返回數據等幾個原因，基本上已經不可能在性能上追回當初更爛現在開著JIT牌跑車的Java了。
2. 在PHP里是如此的容易犯錯而難以發現，即使你用實質上出自官方的Zend Studio，也無法改變一個事實：要保證你的程序高質量無大錯，得要有充足的經驗、足夠的嚴謹、以及——負責任的QA。淘寶的黃裳就曾經拿IDE這事開過玩笑。而玩笑背後的那個原因「缺乏中間件」最近幾年有不少的改善，主要是不少中間件的支持變得更廣泛了從而讓PHP得益，但發展的根源其實還是在C和Java社區。性能和易犯錯則是語言特性造成的技術難點，也是用來換取靈活、快捷的必要代價，很難去指望有根本的改善。
3. Java的世界裡也有JSTL、Velocity和Freemaker等，但和PHP靈活而強大的動態能力、豐富的函數和類庫、輕松的學習成本、多到令人發指的文檔相比，簡直就是渣，就是渣啊！JSTL改完了要重啟Context啊有木有？Velocity不關緩存也要重啟啊有木有？Velocity開緩存性能低下啊有木有？即使這些都不管，調整下某個數據校驗規則要改Action也要重啟有木有？
實際工作中性能問題可以通過良好的架構解決，容易犯錯的問題可以通過框架和規范以及全面的測試來解決，中間件選擇少些但其實該有的都有了，Java的靈活性一樣有不少可供考慮的解決方案哪怕是挫得要死的摘掉節點重啟，完成後重新上節點的策略。
所以，大家會看到單一語言的技術團隊也很多，這個問題的真正考慮還是更多在團隊自身的特點、積累等等。用了雙語言的，也知道自己為什麼要用這些，不用的也清楚自己的路該怎麼走。最後的最後說一句：如果你不知道自己為什麼要用雙語言方案的話，基本上你也就不需要考慮它了

『伍』 後端就像汽車發動機引擎，不同的後端php，java，node等

如果你需要後端渲染HTML,需要後端支持熱部署,需要後端內置大量Web開發庫函數,那就用PHP.因為Python和Node都不支持熱部署,都需要手動或自動重啟服務進程才能使代碼更新生效,而且其語言自帶的庫函數並不如PHP豐富,而且Python和Node默認沒有模板引擎的功能,PHP則天生就支持嵌入到HTML中的模板功能.就算你需要後端只寫介面,PHP同樣適用,區別在於PHP不再輸出HTML而是輸出JSON罷了,PHP中用內置的json_encode就能輕松把PHP數組(資料庫查詢結果)編碼為JSON.
性能方面 Nginx+PHP7-FPM 的組合足夠,PHP-FPM容器在底層用C實現了一套多進程架構,利用多核應對並發不是問題.而且PHP-FPM還有進程池機制,運維和開發人員可以把存在嚴重IO阻塞操作的腳本請求放到一個單獨的動態進程池中處理,避免阻塞到其他進程池,也就是說,PHP-FPM能在腳本級別的粗粒度上分離IO阻塞.

『陸』 PHP為什麼會被認為是草根語言

從PHP誕生之日起，PHP就開始在Web應用方面為廣大的程序員服務。同時，作為針對Web開發量身定製的腳本語言，PHP一直秉承簡單、開源的思想，這也使得PHP得以快速的發展，並且大力地推動Web2.0的出現與發展。但是，長期以來，PHPer(PHP Programmers)被認為是處於草根階層的程序員，被認為是技術含量少，層次低的程序員。這點在國內尤其突出。
記得一個技術主管說過這樣一個事情。他給一個程序員分配了PHP的開發任務，沒想到那個程序員居然說：「我是學Java出身的，你讓我去寫 PHP，你這不是在貶低我嗎？」。這件事情給我印象很深、觸動也很大。雖然這不能代表大部分程序員的看法，但是這么認為的人應該不少。還有人說，現在如果是大型的政府項目，PHP是肯定不會被列入考慮的范圍之內的。
那麼為什麼PHPer會被認為是草根階層，是因為它很簡單，人人都可以學會，所以沒什麼難度嗎？我以前也是這么認為。PHP入門很快，處理文件，數據，遠程連接，網路編程都非常方便，官方也有這樣的說法：PHP學習的成本很低，所以你容易去使用它。這個想法也是普遍的，甚至大部分的PHPer 自己都這樣認為。
說到這里，我想大家就會想到我為什麼要寫這些文字。因為一年多的PHP推廣工作讓我了解到許許多多的使用PHP的公司的大概情況。在這些過程中我慢慢體會到其中的根本原因。這里我說是根本原因雖然是個人的看法，但是我覺得事實就是如此。
那麼為什麼PHPer會被看成草根階層，根本原因是PHPer所作的事情(通過代碼實現)的絕大部分都是表現層的東西，這個熟悉PHP的人都知道。當然也會有PHP會說他用MVC結構編寫的某某框架具備的如何如何的功能。但是這些還是表現層。所以只會處理表現層的程序員就被看成草根階層了。事實上也是如此，因為這種情況下PHP確實很難構造大型的應用。
這就找到原因了，不是的。為什麼PHPer總是在負責表現層的東西呢。答案是底層的數據處理(Web應用就是數據存儲和查找)我們一般不去觸及。好，那麼說到這里有些人可能已經想到了，那不就是資料庫嗎？對，就是資料庫。讓PHPer一直當草根的元兇就是資料庫。為什麼？
PHPer對MySQL的依賴過大
因為目前流行的web架構中，前端是負載均衡系統，中間是web伺服器，後面是資料庫伺服器。所以，大部分PHPer工作在Web伺服器層面。因為資料庫已經很好地為我們組織數據了。所以PHP中沒有太多的演算法，而且大家潛意識下也覺得不需要，更何況會影響性能。
這種情況下，PHPer就成為了資料庫使用者，他總是在操作資料庫。而不是在做程序。一個最簡單的PHP腳本就是，連接資料庫，把數據取出來，然後用命令輸出到瀏覽器。整個過程不超過10行代碼。給人的感覺就是太簡單了。沒有任何技術含量。為什麼了，因為數據處理部分都已經被資料庫做完了。尤其是MySQL的使用。MySQL是免費的，所以大多數程序員可以自由地使用它，另外MySQL的速度夠快了，所以做個PHP應用程序非常的簡單。這就相當於給你槍以後你覺得沒有必要學習武功一樣。當然，我不是說槍沒有武功好。而是說，槍的出現，小孩都可以輕松便捷地殺人了。
我們再詳細說說為什麼是資料庫。這里我說一個例子。我去過北京一家非常著名的網站，當時我們還有一個比較資深的PHP程序員在那說些系統架構的事情。我記得當時那個程序員問大家一個數據結構中的演算法問題的時候，全場沒有一個人能答得出來(包括我)。然後那個程序員就開始給大家講些很基礎的數據結構的東西了。讓我一下子回想到大學時候學的數據結構課。而這些基礎的數據排序、查找、傳遞的問題在其他高級語言(比如C)是非常普遍的。但是在PHP沒有。PHPchina.com的論壇也有個板塊叫PHP的數據結構和演算法。這個板塊的帖子也是寥寥無幾。
說到這里，大家明白了吧？大部分PHPer僅僅處理表現層的東西，而在MySQL的便捷使用下，PHPer幾乎不用觸及任何數據結構與演算法的情況下完成大部分開發任務，所以一個才有上面的，沒有一個PHP程序員能夠回答出那道數據結構的問題，換成是C等語言，情況可能就大不相同了。是PHPer草根，才讓PHP顯得草根。
仔細回想下，目前網路上大家討論的最多的是兩個方面的問題。一個是PHP的類的使用(處理過程的封裝)，還有一個是開發框架問題。但是我們仔細分析的話，發現這些所謂的PHP中比較復雜的概念裡面沒有數據處理。為什麼，有資料庫。用一個Adodb或者PHP5的PDO就可以搞定了。真的搞定了嗎？不是，這些無非是在連接資料庫，沒有數據處理。所以PHPer似乎就沒有什麼可以拿出檯面上的東西。
再說一個具體的代碼問題，無級分類。這個概念我想大家都不會陌生了吧。我見過兩種處理方式。第一個是地道的PHPer的處理方式，也是目前比較流行的。就是用資料庫來處理。而且欄位很少，只需要加個父類的欄位並加以判斷就行了。而且這個方法很實用。效率也高。但是這個不是數據處理的范疇了，而是資料庫的查找。
第二個是C程序員用PHP寫出來的，他把所有的分類信息都從資料庫取出來，然後用數據結構演算法進行排列分布，然後輸出。
這里我們不對這兩種方式的效率進行對比，我想大家都有各自的想法。但是我想說明一個問題，就是這兩種做法的本質的區別。PHPer習慣性地用資料庫來處理，而且有很巧的處理方式，效率也很高。這種方式就是資料庫查詢。而第二種方法是比較有特點的。他認為資料庫就是存放數據的地方，具體的邏輯處理還要靠自己的邏輯。
因此，結論是第二種方法的使用者覺得自己強些，因為數據的邏輯是他組織的。並且覺得PHPer的那種做法無非就是會查詢資料庫罷了。所以他認為PHPer是草根級的，只懂得操作資料庫和排列頁面(smarty搞搞那種)。
讓資料庫回歸本職工作
說到這里，我想大家都已經回憶了不少自己平時用PHP做開發的經歷了吧，是否發現大家確實都在操作資料庫呢。
那麼我們來討論下這個問題。資料庫不好嗎？為什麼我一直用資料庫處理數據都沒有問題。我要說的是資料庫是有問題的，而且有很大的問題。當然這里我並不是說不能用資料庫，也不是在貶低資料庫的性能。而是，我們沒有充分認識到資料庫所起到的作用。
我的想法源起於這樣一個事情，有一次一個網站的技術總監問我，為什麼他們的網站那麼慢，要怎麼辦。當時，我的MSN里Zend總部的工程師正好在線，我就問他PHP響應比較慢了，怎麼辦？他當時直接告訴我，是資料庫問題。肯定是資料庫沒有優化設計好。所以，我沒有給那個技術總監確切的答案了，因為他們的資料庫設計我們是不能涉及的。所以就給了大概的資料庫優化的建議。這樣的事情屢次發生，我就開始懷疑，為什麼Zend總部的工程師每次都跟我說是資料庫的問題呢，難道我們不能從PHP層面來解決這個問題嗎？答案是不能。因為PHP目前的運行速度已經是很快了，通過Zend的性能分析也能看到一個用戶的點擊，PHP的運行時間只有10%不到，那PHP在干嗎？它在等。等資料庫的查詢結果。這個方面在目前的PHP產品中有了很大的提高，那就是 Caching和網頁靜態化兩個方案。
Caching可能大家會比較陌生，但是網頁靜態化現在連PHP產品的用戶都非常清楚了。速度快、容易被搜索到等等，好處不言而喻。開玩笑地說，現在網站的主頁實現網頁靜態化只需要硬碟足夠大。J至於Caching就比較復雜些，也是大多數PHPer感到頭疼的地方。甚至於有些人會用C來實現。因為Caching中的數據有效期驗證、查找、提取、更新等等都是比較難處理。當然，也有人會用資料庫來處理 Caching問題。
所以，當訪問量激增的時候，PHP架構的網站會出現的很多問題都因資料庫而起。資料庫的同步問題還不算什麼。關鍵是資料庫的響應速度會有指數級的降低。這個問題我在10月23號LAMP發布會的時候問過MySQL的副總裁。他當時也沒有給我比較完美的答案(這也我的意料之中)，因為資料庫總會有瓶頸的，除非是神仙資料庫，哈哈!
這里有個題外話，LAMP大會的時候我跟Yahoo的一個技術高管聊的時候，我問他Yahoo在選擇MySQL還是Oracle的時候是怎麼考慮，他的答案令我非常驚訝。他說大部分的時候我們是會用MySQL的，因為它的性能已經達到我們的要求。但是什麼時候我們會選用Oracle呢，就是當我們需要存儲收費用戶的數據的時候。我就問為什麼，難道Oracle比MySQL穩定嗎？他說，這個倒沒有特別考慮。關鍵是如果使用Oracle的話，當出現問題的時候我們可以找到負責人，Oracle會負責事故的處理，但是如果用MySQL的話，我們找誰去?
所以，我們對資料庫的看法應該糾正過來，就是說資料庫不是萬能的。如果有實力的話自己開發資料庫。聽說Google就是那樣的。
那麼我們怎麼看待資料庫呢？我個人的理解是資料庫只是用來降低開發成本的手段。因為採用資料庫以後我們不需要考慮數據的存儲，尤其是排序和查找。但是這會帶來什麼問題呢？就是當業務膨脹的時候，資料庫就成為瓶頸了。這個時候問題就會非常棘手。因為這個是底層的數據處理。牽一發而動全身。
所以我認為正確的觀點是，資料庫是一個數據備份機。怎麼理解，我們只需要保證數據的存儲有效性就行了。而這本來就是資料庫的核心功能，只不過因為資料庫的方便的排序等功能讓大家把過多的處理都交給資料庫來操作了。一個用戶的點擊PHP就把一大堆的任務交給資料庫，然後把結果排列下給用戶就完事了。這對資料庫是不公平的。也是因此大家開始抱怨資料庫的性能了。
針對這個觀點，我們再舉個例子，有一次我去拜訪一個大型的網路公司(基本上國內只要上過互聯網的都知道)，他們使用PHP很少，但是我了解到他們其它業務是怎麼使用資料庫。他們自豪地跟我介紹說他們在資料庫的外圍有個第二資料庫(我這里起名叫第二資料庫)。為什麼叫第二資料庫呢，原來它是一個緩存系統。那麼開發工程師怎麼去這個緩存系統獲取數據呢？那個技術總監自豪地說，他們這個緩存系統有SQL查詢語句。我當時很驚訝，但是後來想想確實需要這個。因為當你的緩存系統達到一定量級的時候從緩存獲取數據都非常復雜，乾脆寫個SQL查詢語句讓緩存系統分析、處理並返回數據。而且他們告訴我，在他們那裡，就算是用PHP的話也是讓PHP去那個緩存系統讀取數據。
所以說，如果你能處理好這樣的問題的話，把數據存放在資料庫，然後資料庫只起到備份的作用。然後你用自己的中間層來處理分析數據，效果是90% 以上的用戶不訪問資料庫。有人就會說了，這不就類似連接池的東西嗎？是的，因為資料庫的瓶頸是無法解決的，我們只能在Web伺服器和資料庫中間加個中間層來做緩沖。
可能大家會說了，切，這個我們早就知道了。那好，這里我要說的是它引發的兩點思考：
第一，有些語言已經有連接池技術的基礎上，那些程序員可以方便地使用連接池而構建大型應用。那麼如果他們認為 PHPer只會是用資料庫，那麼我們是不是可以說他們只會是用連接池呢？連接池和資料庫在這個概念上有何區別？
第二，當PHPer開始構建自己的緩存系統的時候，他是不是突破了PHPer只會是用資料庫的層次？因為他參與了數據邏輯的處理工作。那麼他還是草根嗎？
最後，懂得獨立思考的PHPer不是草根，什麼事情都丟給資料庫去做的才是。

『柒』 為什麼大型網站前端使用 PHP 後台邏輯用 Java

php和java在開源社區的活躍度嚴重超過了其他的語言，使用人數也都是相當之多；活躍的開發工程師們能夠給我幫助，且這倆都能很好的跨平台，不用花費大量的人力物力去維護。php靈活，好學，上手快，容易修改，容易發布，關鍵是熱部署。
Java的優點是穩定可靠、運行效率高（尤其是JIT的出現之後差距更大了）、不容易犯錯（強類型、預編譯、必須攔截異常等等），缺點是開發和發布的效率相對較低。盡管優秀的工程師能在一定程度上改變以上的問題，但通常而言，哪能到處都是高手多如狗的夢之隊？
從MVC的層次結構上說，在一般網站項目的開發周期中，需求變更最頻繁、調整最多的是View，其次是Controller，最後是Model。這非常好理解，沒事干誰天天改數據結構？每次版本升級控制結構都要改的啦，或多或少而已。
再次是兩者之間的通信，目前RPC技術已經足夠成熟，無論是Web Service/Hessian/RESTful API都能夠讓開發人員專注在功能開發上，而不需要過多的考慮異構平台的差異和通訊的細節。這也就意味著在大公司里同時應用兩種語言的方案並不會引入過多的復雜度和工作量。當然，文檔量的下限倒是因此被拔高了不少，但事實上大部分團隊對此其實都是喜聞樂見的：別每天說文檔重要但沒空了，你不寫其他同事怎麼配合？
靠近用戶的前端，使用PHP能夠更快的完成前端頻繁而瑣碎的更新，自如的應對各種需求的變化。頁面的結構調整、用戶輸入內容的基本驗證、僅只和用戶交互有關的簡單邏輯等都很適合使用PHP來開發，甚至可以通過類似Smarty等模板技術將其頁面的變動遷移到前端團隊。而基本的業務邏輯和數據的更新採用Java開發，可以有效的提高復用度、提升性能和吞吐能力、規避安全問題等。而開發效率稍有降低換來的是可維護性的提升，發布速度慢就更不是問題了，因為通常對於基礎業務邏輯的調整往往都是整體修改，並層層測試確認才能發布的。
所以，大型網站前端採用PHP後端採用Java，既好招人又好維護、系統穩定還性能高、連安全性都大大增加。代碼復用、文檔完備度居然也都改善了。讓你在以上這些好處觸手可及時，對架構師知識譜系在廣度上要求更高一些這事根本就不是個問題。
為什麼不是僅用PHP或是僅用Java？
其實也有很多公司為了保證團隊組織不至於過度復雜，會更傾向於採用單一語言，尤其是中小公司。
單一方案其實一樣可以做良好的隔離，PHP同樣可以提供Service，而性能問題其實很多時候是演算法和架構的問題而不是語言差異的問題。如Velocity或JSTL等也是很優秀的隔離方案。
但這些方案在高壓力下會暴露出很多問題而體現雙語言的優勢，這些在上面其實都提到，詳細說明一些很難得到改變的點：
1. PHP由於其動態腳本語言的特性，包括類、函數、常量在內都需要在每次請求周期中重復執行後才能建立運行環境；為了保證解析速度而犧牲編譯質量；應用了FastCGI但僅僅只是復用進程處理請求減少fork成本而不是像其他語言，初始化完畢後通過FastCGI的介面獲得數據並以對應介面返回數據等幾個原因，基本上已經不可能在性能上追回當初更爛現在開著JIT牌跑車的Java了。
2. 在PHP里是如此的容易犯錯而難以發現，即使你用實質上出自官方的Zend Studio，也無法改變一個事實：要保證你的程序高質量無大錯，得要有充足的經驗、足夠的嚴謹、以及——負責任的QA。淘寶的黃裳就曾經拿IDE這事開過玩笑。而玩笑背後的那個原因「缺乏中間件」最近幾年有不少的改善，主要是不少中間件的支持變得更廣泛了從而讓PHP得益，但發展的根源其實還是在C和Java社區。性能和易犯錯則是語言特性造成的技術難點，也是用來換取靈活、快捷的必要代價，很難去指望有根本的改善。
3. Java的世界裡也有JSTL、Velocity和Freemaker等，但和PHP靈活而強大的動態能力、豐富的函數和類庫、輕松的學習成本、多到令人發指的文檔相比，簡直就是渣，就是渣啊！JSTL改完了要重啟Context啊有木有？Velocity不關緩存也要重啟啊有木有？Velocity開緩存性能低下啊有木有？即使這些都不管，調整下某個數據校驗規則要改Action也要重啟有木有？

『捌』 為什麼大型網站前端使用 PHP 後台邏輯用 Java

從這幾個方面看
一、運行機制：
Java代碼被編譯成位元組碼後，會在虛擬機里由JIT進行二次編譯成為本地碼，據傳言其執行速度可以和C++相媲美，經過我自己測試，用Java實現一個簡單的Memcache協議的緩存伺服器，在Java 1.6下運行，和memcache本身相比，同樣數據量的存取時間比大概是3:2，雖然有差距，但是比想像的要好很多。Java 1.7在JIT方面做了大量的改進，性能比Java 1.6還要好。
PHP是直接對文本代碼進行解釋執行，即便有opcode緩存技術，仍然有不可逾越的性能鴻溝。PHP的opcode類似於java的class位元組碼，仍是解釋執行。
二、處理並發：
Java在並發處理上採取單進程多線程的方式，web應用會隨著web server的啟動而啟動，而來自web 瀏覽器的請求將被分配給線程池內的閑置線程處理，也就是說當有請求到達的時候，進程是准備好的，線程是准備好的，Java要做的僅僅是業務邏輯處理了。
PHP在並發處理上時採取多進程的方式，在web server里沒有物理的web應用概念，每個請求都相當於一個獨立的應用，而進程也隨著請求的到達才啟動，而隨著請求的結束而消亡。在Fast CGI環境下，有類似於線程池的進程池技術，對性能提高有很大的幫助。然而一方面web server和Fast cgi通訊仍需要通過socket，多出了一定的IO損耗，另一方面進程池內的進程間也很難進行通訊，所以在並發處理上仍然無法和Java相比。
三、資料庫應用：
Java可以採用資料庫連接池技術，節省下資料庫連接過程帶來的時間損失。
PHP沒有這個好處，原因來自上面的第二條。
在資料庫介面上java有JDBC，PHP有PDO，這兩個很類似。然而Java有非常多的ORM技術框架(如Hibernate)使資料庫操作變得異常簡單，而PHP的運行方式決定了它是ORM的禁區（當然也可以做ORM，只是做到什麼程度是由你對ORM帶來的性能損耗的忍受程度決定的）。
四、緩存技術
Java是單進程，很多緩存可以直接在Java的heap中做，而無需藉助外在的工具，當然也有很好的緩存框架，比如Ehcache，因為沒有網路IO，所以性能非常高。
PHP多進程單線程決定了它只能藉助外來的緩存伺服器，比如Memcache.
五、熱部署
Java的熱部署能力很弱，如果希望修個BUG而不停服是很難做到的。
PHP天然熱部署。
現在明白為什麼後台邏輯用java了吧

『玖』 java和PHP開發效率差多少，求兩個都用過的給個大概比例。

首先，各個語言之間各有優勢，說PHP比Java好，或者說Java比PHP好，都不全面的。比如PHP，開發了之後，直接載入就OK了，而Java雖然有熱部署，但是，卻有時候需要重啟web容器。這是java的一大弱點，但是，java比之php也有很多優點，我個人對PHP不怎麼了解，對Java也算是一個新手，說Java jar包難找，的確，有些Jar包第一次碰到的確需要寫時間，但是，也就一次，對於一個做web開發的java程序員而言，要是還停留在找jar包的層次，說明你還只是剛剛接觸web（因為web開發很多內容都是重復性或者相似性的）
其二，說javaweb編程時jsp編程，這個我不敢苟同，至少我在開發的時候，我不會往jsp上寫多少邏輯，也許會有，但是絕大部分邏輯都是後台的，剩下的就和jsp沒關了，是html的事了
其三，說道MVC模式，這正是軟體開發維護方便的地方，層次結構便於程序架構和邏輯分析，如果是非常小的項目，邏輯等等這些東西都不重要的話，那就無所謂了，完全可以在一個類中全部實現。包的層次結構完全沒必要了，這個時候，我只能說，Maven那玩意就是多餘的了，但是，稍大一點的工程，企業級開發，我估計都會用到這種模式。
其四，說道資料庫編程，java都能說簡單的不能在簡單了，在這一點上，java不僅跨操作系統平台，也跨資料庫平台。編程上快多了，當然，編程快了，效率相對會低一些。
然後說道配置Java環境，對於我這個java菜鳥而言，我可以在幾分鍾之內就配置好（當然這里不考慮安裝軟體的時間。問題是你不可能有事沒事就來配環境
還有一點，java天然支持多線程，而這一點，確是PHP的軟肋，當然這里沒貶低PHP的意思，語言各有優缺點嘛。
所以，碰到說PHP多好的，往往是自己主要是用著PHP，想找點心裡滿足感的，說Java如何如何，大多也是，對於語言本身而言，只要有人在用，就說明有其存在的合理性。語言是死的，人是活的。企業決定用哪種語言，往往決定於開發項目的工程師，他精通什麼，用什麼就好。