前兩周參加完 ThinkInLamp 的 PHP 架構師大會，聽鳥哥一上午的分享，感慨很多，PHP 業界雖然方向不明荒廢了兩三年的時間，終究還是又重新崛起了。
其實包括 Java 的重啟問題，現在也已經很多解決方案了，再不濟，雙進程 Load Balance 切換也很容易做（但可能引發冷啟動問題）。
而 PHP 的性能問題隨着 @Laruence 在 PHPNG 上的努力，眼看着 JIT 快來了，ZVAL 也優化了，尤其是做數據分析最坑的 Array 常量引用和 Array 結構大小等問題都得到了解決，必然在未來有着更廣闊的空間。 現在也有了類似 @韓天峰 的 Swoole 這樣的解決方案，真正做到了 fastcgi.com 所提出的那套標准 FastCGI 方案，消除了每次啟動重建上下文、初始化數據的成本，並且還能以 Backend / Web Server / TCP or UDP Server 等多種方式工作。
但這些，並沒有讓異構語言環境消亡，反而在業界越來越多見了。 核心關鍵點還是在於開源業界的興起使得我們有更多更好的選擇，而且架構的發展也越來越容易、越來越有必要以異步交互等方式解耦。 非核心模塊或中間件選用異構語言的開源項目，用到超出其性能上限或有特殊業務訴求涉入開發提升也是挺常見的事情。
而分層分模塊之后，不同模塊根據自己的業務場景、需求用不同語言實現已經越來越常見，當然也有一部分原因是公司技術團隊的成分。 而 PHP 和 Java 作為 Web 開發當中市占率最高的兩項，在組合里常常一起出現也就不足為奇了。 今天 Python / NodeJS / Go 等也已經有很多開源項目加入到異構系統的大軍里來了。
// 原答案，大概是2012年左右寫的吧。
首先，為什么是PHP和Java，不是其他。這和兩者的開源社區都很活躍，並且都很適合進行Web開發有很大的關系，而且都很適合Linux環境下運行，可以在運維上統一管理。
盡管.Net市場占有率也不低，但由於Windows和SQL Server的License費用、開源社區不活躍等多種問題相對而言考慮得少一些。TIOBE TOP 10中適合Web開發的語種還包括了Python Perl Ruby，其中Perl已經是昨日黃花，主要在服務器腳本領域還有較多應用，Web上已經不太可能Yesterday oncemore了。Python最近上升勢頭挺猛，但僅需要考慮文檔較少、招聘相對困難基本就注定了暫時不會是大網站的主流選擇。Ruby就不更不用提了。
再看一下兩個語言之間的差異。 PHP靈活，上手快，易修改，發布快捷，缺點是容易犯錯（常見如拼寫錯誤、SQL注入、上傳執行等）、執行效率不高、缺乏全局緩存。Java的優點則是穩定可靠、運行效率高（尤其是JIT的出現之后差距更大了）、不容易犯錯（強類型、預編譯、必須攔截異常等等），缺點是開發和發布的效率相對較低。盡管優秀的工程師能在一定程度上改變以上的問題，但通常而言，哪能到處都是高手多如狗的夢之隊？
然后從MVC的層次結構上說，在一般網站項目的開發周期中，需求變更最頻繁、調整最多的是View，其次是Controller，最后是Model。這非常好理解，沒事干誰天天改數據結構？每次版本升級控制結構都要改的啦，或多或少而已。而View，啥時候兩天不改BU啊PM啊UED啊大概是集體休年假了吧？
再次是兩者之間的通信，目前RPC技術已經足夠成熟，無論是Web Service/Hessian/RESTful API都能夠讓開發人員專注在功能開發上，而不需要過多的考慮異構平台的差異和通訊的細節。這也就意味着在大公司里同時應用兩種語言的方案並不會引入過多的復雜度和工作量。當然，文檔量的下限倒是因此被拔高了不少，但事實上大部分團隊對此其實都是喜聞樂見的：別每天說文檔重要但沒空了，你不寫其他同事怎么配合？
總的來說，靠近用戶的前端，使用PHP能夠更快的完成前端頻繁而瑣碎的更新，自如的應對各種需求的變化。頁面的結構調整、用戶輸入內容的基本驗證、僅只和用戶交互有關的簡單邏輯等都很適合使用PHP來開發，甚至可以通過類似Smarty等模板技術將其頁面的變動遷移到前端團隊。而基本的業務邏輯和數據的更新采用Java開發，可以有效的提高復用度、提升性能和吞吐能力、規避安全問題等。而開發效率稍有降低換來的是可維護性的提升，發布速度慢就更不是問題了，因為通常對於基礎業務邏輯的調整往往都是整體修改，並層層測試確認才能發布的。
所以，大型網站前端采用PHP后端采用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 的重啟問題，現在也已經很多解決方案了，再不濟，雙進程 Load Balance 切換也很容易做（但可能引發冷啟動問題）。
而 PHP 的性能問題隨着 @Laruence 在 PHPNG 上的努力，眼看着 JIT 快來了，ZVAL 也優化了，尤其是做數據分析最坑的 Array 常量引用和 Array 結構大小等問題都得到了解決，必然在未來有着更廣闊的空間。 現在也有了類似 @韓天峰 的 Swoole 這樣的解決方案，真正做到了 fastcgi.com 所提出的那套標准 FastCGI 方案，消除了每次啟動重建上下文、初始化數據的成本，並且還能以 Backend / Web Server / TCP or UDP Server 等多種方式工作。
但這些，並沒有讓異構語言環境消亡，反而在業界越來越多見了。 核心關鍵點還是在於開源業界的興起使得我們有更多更好的選擇，而且架構的發展也越來越容易、越來越有必要以異步交互等方式解耦。 非核心模塊或中間件選用異構語言的開源項目，用到超出其性能上限或有特殊業務訴求涉入開發提升也是挺常見的事情。
而分層分模塊之后，不同模塊根據自己的業務場景、需求用不同語言實現已經越來越常見，當然也有一部分原因是公司技術團隊的成分。 而 PHP 和 Java 作為 Web 開發當中市占率最高的兩項，在組合里常常一起出現也就不足為奇了。 今天 Python / NodeJS / Go 等也已經有很多開源項目加入到異構系統的大軍里來了。
// 原答案，大概是2012年左右寫的吧。
首先，為什么是PHP和Java，不是其他。這和兩者的開源社區都很活躍，並且都很適合進行Web開發有很大的關系，而且都很適合Linux環境下運行，可以在運維上統一管理。
盡管.Net市場占有率也不低，但由於Windows和SQL Server的License費用、開源社區不活躍等多種問題相對而言考慮得少一些。TIOBE TOP 10中適合Web開發的語種還包括了Python Perl Ruby，其中Perl已經是昨日黃花，主要在服務器腳本領域還有較多應用，Web上已經不太可能Yesterday oncemore了。Python最近上升勢頭挺猛，但僅需要考慮文檔較少、招聘相對困難基本就注定了暫時不會是大網站的主流選擇。Ruby就不更不用提了。
再看一下兩個語言之間的差異。 PHP靈活，上手快，易修改，發布快捷，缺點是容易犯錯（常見如拼寫錯誤、SQL注入、上傳執行等）、執行效率不高、缺乏全局緩存。Java的優點則是穩定可靠、運行效率高（尤其是JIT的出現之后差距更大了）、不容易犯錯（強類型、預編譯、必須攔截異常等等），缺點是開發和發布的效率相對較低。盡管優秀的工程師能在一定程度上改變以上的問題，但通常而言，哪能到處都是高手多如狗的夢之隊？
然后從MVC的層次結構上說，在一般網站項目的開發周期中，需求變更最頻繁、調整最多的是View，其次是Controller，最后是Model。這非常好理解，沒事干誰天天改數據結構？每次版本升級控制結構都要改的啦，或多或少而已。而View，啥時候兩天不改BU啊PM啊UED啊大概是集體休年假了吧？
再次是兩者之間的通信，目前RPC技術已經足夠成熟，無論是Web Service/Hessian/RESTful API都能夠讓開發人員專注在功能開發上，而不需要過多的考慮異構平台的差異和通訊的細節。這也就意味着在大公司里同時應用兩種語言的方案並不會引入過多的復雜度和工作量。當然，文檔量的下限倒是因此被拔高了不少，但事實上大部分團隊對此其實都是喜聞樂見的：別每天說文檔重要但沒空了，你不寫其他同事怎么配合？
總的來說，靠近用戶的前端，使用PHP能夠更快的完成前端頻繁而瑣碎的更新，自如的應對各種需求的變化。頁面的結構調整、用戶輸入內容的基本驗證、僅只和用戶交互有關的簡單邏輯等都很適合使用PHP來開發，甚至可以通過類似Smarty等模板技術將其頁面的變動遷移到前端團隊。而基本的業務邏輯和數據的更新采用Java開發，可以有效的提高復用度、提升性能和吞吐能力、規避安全問題等。而開發效率稍有降低換來的是可維護性的提升，發布速度慢就更不是問題了，因為通常對於基礎業務邏輯的調整往往都是整體修改，並層層測試確認才能發布的。
所以，大型網站前端采用PHP后端采用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做后端，html、CSS、JavaScript做前端。
中型網站：Java做后端，PHP、html、CSS、JavaScript做前端。
大型網站：C++做后端，PHP、html、CSS、JavaScript做前端。
超大網站：Go做后端，PHP、html、CSS、JavaScript做前端。
中型網站：Java做后端，PHP、html、CSS、JavaScript做前端。
大型網站：C++做后端，PHP、html、CSS、JavaScript做前端。
超大網站：Go做后端，PHP、html、CSS、JavaScript做前端。