我对应用框架的一些思考
关于框架(FrameWork),尤其是PHP开发框架,现在真是漫天飞舞,让人眼花缭乱.想当初我设计第一个所谓的框架时,
PHP可用的框架基本上是空白,所以很多东西是参照Java的特点来作的,那时年轻,也有些轻狂,以为框架就这么容易做出来了.
设计框架会有一些偏差:
首先一个问题,框架=类库的聚合. 这种情况一般是设计者有些代码开发的经验,但是缺乏更广的知识沉淀.不经历风雨怎见
彩虹,如果没有涉足多个领域的痛苦折磨,仅仅在某个,某些项目甚至某个开发语言上有些涉足,就想,框架不过如此而已.于是乎,
框架就在复制粘贴的过程中产生了.
其实,一个框架代表的是一个思想,一种哲学,类库只是这种哲学的附属品罢了.
第二个问题是设计过度,偏离了实用. 这种问题产生于一些比较追求完美主义者甚至是大师,为了完美,设计而设计. 比如spring在最初版本中,
其MVC就有些不太实用的地方,这点对比webwork/xwork就能发现,不过后来随着使用者的增多和流行,这些问题也很快被消除.
看来,实践是检验真理的唯一标准.
上面2个问题在我身上都印证过. 尤其是第二个问题更为明显,自身功力不足,却强行希望看上去很美,导致了现实和理想之间的差距.所以,在doggy之前,
我虽然也自己实验过一些原型,不过很快就被扔掉了.
现在,在作doggy的实现时,我更多的是考虑,哪些功能是确实需要的,哪些是体现我的理念的,后者是首要实现的.
比如,doggy的一个最重要的思想是:支持TDD开发的模式,测试先行,测试驱动. 因此,对于测试的支持是首要必备的,
此外,对于持续构建,项目部署分发,也是实际中很现实的问题,这些也需要重点考虑.
至于扩展性则放在第三位,这里所谓的扩展,并未局限于框架代码本身,而是和整个系统的部署,所谓网站的系统架构上综合考虑的.
例如,在存储层的扩展,是需要考虑能否支持分布式存储,本机开发是一回事,但是能否部署到如mogilefs,hardoop.
如何支持fastcgi的部署,如何最大化利用lighttpd,nginx,varnish.
缓存上,3级缓存中,各级缓存在实际中如何去实现,这些需要doggy去支持,否则就无法扩展系统.
比如,在cms中,多数文章是可以使用静态文件生成,并分发到cdn等负载钧衡网络中,那么如何过期,如何刷新,
则需要考虑cdn网络如何去构建,是用nginx?nfs共享,磁盘阵列gfs?还是用squid,varnish的反向代理?
这些都是doggy需要去考虑的.
当构建web2.0的应用时,需要考虑的是另一种情况,此时,单纯采用静态化已经解决不了问题,那么需要使用
局部缓存,解决并发的数据读写,如何保证数据的实时更新和同步….
再比如,确保应用服务和静态服务的分离,项目的开发和部署的隔离…
因此,对我而言,应用框架需要解决不仅仅是代码层的优化,更要解决的是一些实际的应用.doggy框架,我姑且
仍认为它是一个应用框架,在应用层面则是提供一个解决这些问题的方案,这是我所关注的.
而其他的一些东西,我认为并不重要,比如,url/action的route方式,doggy只支持一种,足够.为什么?因为我可以通过
其他的方式去弥补,比如可以在Nginx的rewrite实现,可以使用lighttpd的lua实现,这些方案的效率远远高于
PHP,那么何必去实现这些吃力不讨好的东西呢.
因此,doggy不是通用的,它需要unix环境,不支持windows的部署,开发环境最佳是linux/osx,window则需要使用cygwin,必须使用一些
定制的pecl extension,PHP需要作一些特定的优化,webserver需要最适合的等等.
也许,我是在自娱自乐,但确实好用.
Imagick进步真快阿
在去年设计Doggy框架时,我选择MagickWand作为主要支持的图片操作的extension库.
当时列入我眼中的候选有magickwand和imagick. 有人可能会说,为什么不用gd2?
因为gd不论是性能还是功能都太弱了,作为普通的图片处理可以勉强胜任,但是如果需要实现类似flickr那样
的图片处理任务就歇菜了. 而ImageMagick则是很好很强大,可以轻易将很红很创意的图片变成
很黄很暴力,呵呵.
当时imagick使用的人很少,而且稳定性也不高,对于magickwand,我以前则用过,因此就选择了magickwand for php.
不过当时对于magickwand并不满意,因为其实它不过是magickwand的一个wrapper而已.
和gd一样需要resource handler, 并不符合我喜欢的OO的精神.
这几天又重新看了下imagick,版本升级到2.x,功能也改进很多.从作者的博客上看了些介绍,让我有些心动了.
由于是PHP native的extension,使用上也是OO,而且可以继承并扩展原生类,这点确实够诱惑,够强大.
计划假期启动doggy2的设计,我想是不是考虑换成imagick呢
一个奇怪现象带来的nginx对于fastcgi的优化
在作工作统计表的时候,发现一个特别蹊跷的问题:
页面在我的mac/leopard下一切都很好,包括Safari/Firefox,但是后来大家反应,
在Windows上,IE下只能看到页面的一半,后半部分完全没有,而且更为怪异的是,
Firefox也是这样.最最令人不解的是,只有在笔记本上的windows会出现这种情况,
而使用台式机的用户,IE6和Firefox都能正常.
开始以为是程序的问题,仔细检查,反复调试,都没有.我在自己的mac的windows虚拟机
和T41上也重现了这个问题.
一直非常郁闷,我的程序不会有如此智能阿?竟然 能分辨出是台式机还是笔记本?
呵呵.
终于,后来看nginx的文档时发现,nginx有个fastcgi_buffers的参数,默认,是4k或者8k.
也就是说,nginx每次会从后端的fastcgi接受这么多的数据放在缓冲中,依次输出.
这点nginx和lighttpd不同,lighttpd会一次性接收后全部输出.
而我原来的keep_alive设置为0,这样,windows上会认为此次的tcp链接已经中断,会复位,
当然这是我的猜测.
我于是作了优化,将8k设置128k,这样可以比较好的优化fastcgi的效率,保证一次性就能接受全部的输出.
终于,后来看nginx的文档时发现,nginx有个fastcgi_buffers的参数,默认,是4k或者8k.
也就是说,nginx每次会从后端的fastcgi接受这么多的数据放在缓冲中,依次输出.
这点nginx和lighttpd不同,lighttpd会一次性接收后全部输出.
而我原来的keep_alive设置为0,这样,windows上会认为此次的tcp链接已经中断,会复位,
当然这是我的猜测.
我于是作了优化,将8k设置128k,这样可以比较好的优化fastcgi的效率,保证一次性就能接受全部的输出.
于是乎,一切就正常了.
博客抢救记录
放假这几天基本是在机房泡着了，还有就是凌晨去吃马兰拉面。。。
本以为昨天能小憩一番，结果
刚睁开眼就噩耗频传。。
博客系统使用的磁盘由于劳累过度，以突如其来迅雷不及掩耳之势集体罢工。
接着是广告服务器。。。社区的内网又不通。。。TNND,坏事都赶一块了。
下午3点拿到新的硬盘，重新去机房换磁盘。本想省事，就重建raid5,结果这下完了，重建花了整整8个小时。。。
狂晕。
不过也没闲着，升级了5台服务器（幸亏之前配了网络部署环境，节省了2/3的时间），更换了4块硬盘，机房不让带吃的，把网配好已经头晕眼花，看看表，正好凌晨1点半，得，只能吃拉面了。
到家2点20，
开始恢复数据，重配系统。
恢复博客的时候出现了一些问题，由于这次升级到PHP5，结果中文不起作用了。
得，又去抓虫，还好功夫不大。
现在博客恢复了，这次把lighty换成了nginx,PHP更新到最新的5.2.5,应该会更稳定些。
这样和新社区就统一起来，使用同样的平台了。
PHP5打了附加的FASTCGI的补丁，可以解决大负载下的问题。
也许还有些问题，看看吧。
现在的任务就是拉上窗帘，睡一小觉。。。