前兩週參加完 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也要重啓有木有?
小型網站:PHP作後端,html、CSS、JavaScript作前端。
中型網站:Java作後端,PHP、html、CSS、JavaScript作前端。
大型網站:C++作後端,PHP、html、CSS、JavaScript作前端。
超大網站:Go作後端,PHP、html、CSS、JavaScript作前端。