[轉]爲何大型網站前端使用 PHP 後臺邏輯用 Java？

最近糾結了一下，若是開發一個大型的網站，我到底應該使用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或是僅用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的靈活性同樣有很多可供考慮的解決方案哪怕是挫得要死的摘掉節點重啓，完成後從新上節點的策略。
因此，你們會看到單一語言的技術團隊也不少，這個問題的真正考慮仍是更多在團隊自身的特色、積累等等。用了雙語言的，也知道本身爲何要用這些，不用的也清楚本身的路該怎麼走。最後的最後說一句：若是你不知道本身爲何要用雙語言方案的話，基本上你也就不須要考慮它了。