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

 

　　前兩週參加完 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等也是很優秀的隔離方案。

　　

但咱們都知道，現實每每比理想骨感不少，這些方案在高壓力下會暴露出不少問題而體現雙語言的優點，這些在上面其實都提到，詳細說明一些很可貴到改變的點： 

　　一、PHP因爲其動態腳本語言的特性，包括類、函數、常量在內都須要在每次請求週期中重複執行後才能創建運行環境；爲了保證解析速度而犧牲編譯質量；應用了FastCGI但僅僅只是複用進程處理請求減小fork成本而不是像其餘語言，初始化完畢後經過FastCGI的接口得到數據並以對應接口返回數據等幾個緣由，基本上已經不可能在性能上追回當初更爛如今開着JIT牌跑車的Java了。 更況且，還缺乏了系統級共享數據的支持，使得核心數據一次性初始化後重復使用必須藉助擴展或中間件。

　　二、在PHP裏是如此的容易犯錯而難以發現，即便你用實質上出自官方的Zend Studio，也沒法改變一個事實：要保證你的程序高質量無大錯，得要有充足的經驗、足夠的嚴謹、以及——負責任的QA。淘寶的黃裳就曾經拿IDE這事開過玩笑。而玩笑背後的那個緣由「缺少中間件」最近幾年有很多的改善，主要是很多中間件的支持變得更普遍了從而讓PHP得益，但發展的根源其實仍是在C和Java社區。性能和易犯錯則是語言特性形成的技術難點，也是用來換取靈活、快捷的必要代價，很難去期望有根本的改善。

　　三、Java的世界裏也有JSTL、Velocity和Freemaker等，但和PHP靈活而強大的動態能力、豐富的函數和類庫、輕鬆的學習成本、多到使人髮指的文檔相比，簡直就是渣，就是渣啊！JSTL改完了要重啓Context啊有木有？Velocity不關緩存也要重啓啊有木有？Velocity開緩存性能低下啊有木有？即便這些都無論，調整下某個數據校驗規則要改Action也要重啓有木有？

　　好吧，吐槽結束。

 

　　實際工做中性能問題能夠經過良好的架構解決，容易犯錯的問題能夠經過框架和規範以及全面的測試來解決，中間件選擇少些但其實該有的都有了，Java的靈活性同樣有很多可供考慮的解決方案，不說 OSGi 之類，就算是挫得要死的摘掉節點重啓，完成後從新上節點的策略也都能湊效。

　　因此，你們會看到單一語言的技術團隊也不少，這個問題的真正考慮仍是更多在團隊自身的特色、積累等等。用了雙語言的，也知道本身爲何要用這些，不用的也清楚本身的路該怎麼走。最後的最後說一句：若是你不知道本身爲何要用雙語言方案的話，基本上你也就不須要考慮它了。

　　後端java最大的優點在於龐大的生態環境，你想解決的任何問題，java都有現成的方案，並且，相對其餘語言來講，基於jvm的方案在運行效率和運維成本上平均來講是最佳的（這裏不討論說什麼運維人員的能力之類的，只假設咱們的運維都只具備通常的平均水平），因此，後端自然是傾向java的，不管前端用什麼。

　　至於前端，最大的問題在於，一個網站的UI，變更至關頻繁，傳統的基於java的開發方案，jsp tag lib，freemaker， velocity。。。。你讓前端怎麼改，怎麼調試？不通過專門學習他們怎麼看得懂？並且，java的開發模式，動不動上來就是MVC，後端跟前端結合太緊密了，基本上前端很難自由的在ui層工做。反過來，基於PHP的前端方案，至少作前端的都能看得懂，都能調試得了，這就是巨大的生產力的解放了，講後端java作成rest服務，前端全部的動態代碼均可以交給前端工程師，對他們來說，最舒服的動態網頁方案，天然就是PHP，這個是歷史沉澱決定了，誰也無法改變，不管你多麼看不起PHP，包括我本身也是並不喜歡PHP，可是仍然要再強調一次，對前端工程師來講，最舒服最自在的動態網頁方案，仍然是PHP！就如同上面不少人回答的，PHP就是快，快在哪兒？PM說要改什麼，前端上手10分改好，30分鐘後已經release了。把任務發給後端工程師？那慢慢等吧。

　　上面說過，傳統的java的前端方案，上來就是MVC，模板引擎，一堆東西，這些玩意兒，作企業應用是很好的，作網站？的確好像不多據說哈。爲何？我抄一段別處的文字（不用考慮版權，這就是我本身寫的）

　　在過去十年，基於Java的MVC框架如同雨後春筍通常層出不窮，但都不肯意麪對或者解決的問題是，它對前端設計師極不友好，並且，開發效率及其低下，互聯網企業鮮有基於Java，尤爲是基於MVC來構建本身的網站，是有深入的緣由的： 

 　　一、對前端設計師極不友好。MVC模式下，可編程的模板語言成爲很是重要的角色，而以視覺創造爲主要工做的前端設計師，他們熟悉的是HTML和CSS，而嵌入模板文件的各種動態代碼，對他們來講即便不是如同天書，也是及其讓人及其困惑的，固然，他們必然要面對這些內容，所以，傳統的PHP必然成爲他們的最佳，由於，這個至少是比較容易讓人理解的。 

　　二、開發效率低下。互聯網企業的開發一般是快速迭代的，並無明確的需求一說，傳統的PHP開發模式之因此受到青睞，就在於它易於變動，開發速度快，MVC模式的開發在這一點基本完敗，所以，不多有互聯網企業會基於Java來構建本身的前端頁面，即便有，也一般是基於JSP的自有框架。 

 

更進一步的，在過去將近10年的MVC歷史中，咱們其實一直都被下面的問題困擾着： 

一、前端設計師和工程師一直在抱怨嵌入到頁面的動態代碼讓他們很難對頁面進行大規模的重構，而另外一方面，後端開發人員也常常抱怨他們要花很大的精力才能修復前端對頁面的重構帶來的問題。 

二、開發人員常常還會由於模板語言貧乏的功能而飽受折磨。一些特殊的複雜渲染邏輯常常須要富有經驗的開發人員才能寫出極具技巧性的代碼來實現。而這樣的代碼，一般會成爲誰也沒法理解的魔術代碼。 

三、開發人員對MVC低下的開發效率極度不滿，咱們一直在渴望能夠有一個更加高效的開發模式。

好了，題歸正傳，若是咱們必定要用java來作前端，究竟有沒有比上面列舉的這些MVC，模板之類的更好的辦法？答案是有的，那就是view first。由Lift(不知道的lift的請參看：Lift (web framework))最早提出並倡導的view first的理念，應該算是對網站開發模式的一個漂亮的總結，實際上，PHP的前端方案，自己就是暗合view first的理念的。經過view first的理念，避開了繁瑣的MVC架構，同時，lift提供了一個純html的模板引擎，使得前端工程師能夠在徹底不考慮後端實現的狀況下獨立工做，對先後端的協同工做效率，能夠說是有着劃時代的意義的。

asta4自己最初的目的就是提供一個lift的java移植版，固然，在後期開發中，逐漸仍是有了一些不一樣的東西，但從總體上說，lift對前端最重要的兩個特性，在asta4d是幾乎原樣移植過來的：

 

一、view first

二、css selector driving template engine

 

前端的純html模板中不會嵌入任何後端的動態代碼，前端工程師只須要跟html打交道，咱們的前端和後端是分開兩個部門的，常規的工做流程是：

一、任務書或者bug ticket下來，前端開branch，開始作或者改頁面

二、若是是頁面的bug對應，一般到這一步就已經結束了，若是是新功能，或者bug須要後端協做，那麼ticket轉給後端

三、後端拿到ticket，開工幹活，完事，push。

四、release

　　注意，這個過程當中，前端和後端幾乎不會交流，由於他們不須要交流！前端經過html和css，以及js表達本身的想法，後端只負責一件事情，把前端須要的數據填上去，是的，就是填數據而已，因此只有後端看不懂前端的數據應該填在哪兒，或者應該填什麼數據的時候，纔會須要有限的交流。

　　咱們的一個實際經驗是，一次耗費了前端部門2我的月的UI徹底重構工做，當前端工做完成後，後端部門只花了30分鐘，就完成了全部須要修改的地方，是的，30分鐘，在前端完成工做後30分鐘，咱們的重構分支就合併到主幹準備release了。

 

 

 

來自：知乎

連接：https://www.zhihu.com/question/20314377