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/