php 框架選擇

背景 
不少初級php甚至中級php都會陷入框架選擇困難症,要麼必須使用什麼框架,要麼必定不使用什麼框架,而對框架的選擇帶來的效益和負擔的成本並非很清晰 
框架大概分爲如下這些 
1. 簡單輕量:tp,ci (相似tp這種所謂很菜的框架在國內毫無疑問很流行) 
2. 號稱優秀框架,大而全重量,各類面向對象設計模式,與時俱進,風靡全球:yii, laravel 等 
3. api框架:lumen,slim 
4. c編寫底層的框架:Phalcon, yaf,swoole框架,騰訊PSF等 
5. 我的開發,非開源流行,公司內部框架:大多比tp,ci還簡單,團隊leader我的開發(其實大部分是實現個mvc三腳貓框架,可能leader本身寫易於維護吧),這種框架定製化比較強,leader能夠根據項目需求本身擴展,節省性能損耗 
6. 你本身開發:掌握良好框架設計原則你能夠從頭寫,實際上你能夠本身composer快速搭建一個框架,須要什麼再github上找找輕量流行庫,再composer擴展,可能更舒心 https://lvwenhan.com/php/405.html 
解析 
1.大公司不少php項目都採用很簡單的php框架(僅實現了mvc),cpu密集型的接口調用其餘團隊服務來作. 
bat級別公司多使用c編寫的框架(yaf, 騰訊PSF,swoole,hhvm等)來應對高併發業務場景(直播,遊戲後端,即時通信聊天室等也ok) , 
2.原則上來說,不管什麼語言框架,經過負載均衡都能抗住好併發,區別在於,例如高效語言框架來處理的話,一臺機能頂全部request,而用性能差的方案,須要100或1000臺機,而分佈式的處理會帶來不少的問題,不管是開發上(分佈式事務,分佈式鎖,分佈式文件同步,session同步等等問題,設計複雜度大大上升)仍是運維上(本來維護一兩臺機,後來要維護成百上千臺) 不管是機器成本仍是人員成本都成了很大的問題,也就致使了該方案不可行 
關於C10K、異步回調、協程、同步阻塞

3.php是解釋型語言,自己不適合cpu密集的服務,並且數據結構粒度太粗,全部結構用一個array來承擔(固然也有一些擴展庫實現細緻的數據結構),這樣開發方便可是性能損耗 
4.大公司面對的服務主要在高併發上,最核心的點實際上是性能問題,用php寫的框架並不會對性能帶來好處 
相似laravel,yii等優秀web框架,高併發下性能是扛不住的 
5.其實大而全的號稱優秀框架被拒絕的主要緣由是 
1.學習起來難,沒法掌握 (應該去掌握一下看看是否是對團隊後期招人有難度) 
2.性能差 http://rango.swoole.com/archives/254 (應該本身作些壓測)

那麼優勢 
這樣的框架實際上是採用了一些好的設計(容器ioc,aop),帶來開發和維護上的便捷(確實很是便捷和溫馨),還有是組件豐富(想用什麼導出excel,微信sdk等各類組件,發送請求接口等等考慮周全的組件),這裏面是好的產品設計思想,值得學習,適合用來開發對性能要求不高的管理平臺DMP(也可使用設計一樣好,並且輕量的lumen框架) 
學習這樣框架對我的編寫出擴展性強業務代碼也十分有益 
yii.laravel有個特色就是很像java,實際上他有點介於java和php的中間,沒有java連語言自己都很沉重,並且是強類型語言,因此並不存在說用他兩不如用java.而是吸取了面向對象的一些好的設計而已(實際上是偷襲rails,我應該寫點rails這個老大爺) 
缺點 
1.學習有一點的曲線,畢竟人家設計越精美你就越得花時間去學習他的想法,反編譯的過程,有些時候本身寫維護起來更溫馨 
2.還有就是帶來性能上的損耗,緣由是爲了框架高擴展而使用複雜精細的設計帶來的性能損耗,例如yii打印一個hello world要new幾十個類,跳轉路徑山路十八彎 
這種大而全的框架實際上是考慮了擴展性的抽象設計,適應各類需求變化,而實際上的項目可能選了型的方案就不會變,這種設計也會帶來性能損耗,實際上就算是鳥哥這種對底層很熟的人也不必定能設計出laravel這種框架,這是徹底不一樣的領域.用戶羣體不同,解決的問題徹底不一樣 
3.這種框架是全棧的,yii就更誇張,連前端的東西都封裝進去,用php來寫前端,這樣確定是帶來性能損耗的. 
實際上目前大部分項目的架構都是採用先後端分離,後端只作api接口,大可直接採用api框架(不須要渲染視圖V層),相似(lumen,slim),前端就使用前端技術棧,這樣的架構後面招人接手也容易,畢竟你花了不少時間研究出來,寫得很靈活的代碼,別人接手不必定能搞懂,你必須招一個很瞭解框架的人.或者你本身足夠自信能帶後來人掌握,這個就是將來成本,團隊leader必須考慮. 
固然最快確定是這樣全棧框架(實際上是偷襲了rails,開發超雞快)一我的呼呼呼搞定所有.

相似ci,thinkphp這種,其實就是有點像普通大公司裏本身寫的框架,組件功能上可能還更多一些.不過就沒有設計那麼靈活,好比我想直接換個orm框架,是不能夠的,由於tp已經將這塊耦合進tp(其實也不是不能夠,仍是有辦法的,例如能夠ci換上laravel的orm) 
固然,設計上有一些通用通過驗證確實是好的設計原則,可是沒有這種原則也照樣能夠搞定,就是可能寫的沒那麼好看,(實際上不少時候解決了問題就好,優雅沒人知道),不少大公司的項目就是這樣相似vip(實際上vip的模式也不必定是最好的,開發效率沒有那麼高,基本就是一個功能寫一個接口,沒有面向對象設計在裏面,須要很屌的人hold住團隊,修改框架適應項目)

Fix 
首先一個項目要看服務類型.來選框架 
若是是內部使用的管理平臺

事實上沒有必要糾結於必定要用laravel或yii這種,作管理平臺的話,使用這種框架會更快更靈活,代碼較優雅,不過有必定學習曲線,對團隊成員要求要一些,你們都要學習框架那套所謂優秀的寫法.

內部使用後臺管理: lumen + vue 
前臺的話(後續)

參考 
國內C源碼PHP框架選擇與評價 Yaf Yar Swoole workerman？

擴展 
Swoole比Node.js有哪些優點？有哪些知名的Swoole案例？ 
關於選擇php仍是java 
不能否認java是個很優秀的面向對象的語言,設計很是精良,組件也十分豐富,生態也繁華 
很差的是,強類型語言開發效率沒有php高,並且正是由於設計精良致使了新手不友好,新手老是很痛苦的記憶api使用方法 
新手應該選擇php,入門快速,隨着後面的修煉,打通任督二脈之後再來使用java,更通暢.固然php+c 已經能作任何事情 
鳥哥 http://www.laruence.com/2012/08/06/2681.html 
http://rango.swoole.com/archives/category/php 韓天峯 php職業生涯 
http://www.csdn.net/article/2015-10-22/2825997-PHP 
韓天峯博客 
http://rango.swoole.com 
swoole官網 
http://www.swoole.com/