威凡网全力打造:网页编程、软件开发编程、平面设计、服务器端开发、操作系统等在线学习平台!学编程,上威凡网!
PHP教程>> PHP基础 PHP技巧 PHP实例 PHP文摘 PHP模板 PHP总结
当前位置:首页 > PHP教程 > PHP文摘
上一节 下一节
 PHP发明人谈MVC和网站设计架构 貌似他不支持php用mvc
q:越来越多web 2.0网站走向应用平台,你认为打造这类平台的关键为何?

a:简单来看,应用平台就是api,任何ajax或 web 2.0类型的网站,都是在应用平台上运用了api来创造出视觉介面的互动效果。例如yahoo mail,透过简单的request呼叫,来读取後续的信件。打造这类网站,如何规画解决问题的方式,会决定了网站未来的扩充性(scalability),而非效能决定网站的发展。

q:如何规画网站架构,才会具有扩充性?

a:将一个网站应用,分成几十个独立小程式,前端透过 api提供服务,後端是应用程式引擎,这样做自然会有扩充性。因为应用的每一个部分,都有不同等级的使用方式,需要有不同的扩充程度(scaling level),需要不同的机制来处理。以开发yahoo mail而言,是要开发一个地址服务程式丶一个读信服务丶一个送信服务,而送信程式完全和读信程式无关。以yahoo的规模而言,需要让这些工作完全分离,才有扩充性。

q:这种规画网站的方式,什麽是最重要的关键?

a:关键是你必须建立分离丶模组化的独立端点,而不是全部放在同一个大篮子里。大多数现今mvc架构(mvc framework)的开发框架(framework),使用所谓的前端控制器(front control),每一次浏览器提出request请求时,就会呼叫这个前端控制器,再由前端控制器来分辨,使用者想要执行哪一支程式。这样做,一点意义都没有。

在浏览器层次,程式完全能知道使用者想要做什麽事情,例如使用者只是要读信,程式就不用再把需求送到伺服器,让伺服器判断使用者要读信还是送信。将这类决策工作拉出浏览器,由伺服器处理,就会浪费大量伺服器资源,来处理那些对使用者没有实际功用的工作。扩充性来自架构,很多开发框架,将所有事情绑在一起,限制了架构。选错开发框架,你就没有扩充性。

q:你是说mvc模式不利於网站扩充性?

a:mvc模式比较适合用在网页控制器(page control)的层次。基本上,每一个网页控制器都是独立模组,读信和查地址是不同的网页控制器,所以,读信程式就不会干扰到查地址程式。所以,在每一个端点使用mvc模式来打造小型的网页控制器,是不会有问题。但是,大多数采用mvc模式的框架,预设在网站中采用前端控制器,而非用网页控制器的方式,这样的mvc模式,只适合在小型或单一伺服器的网站。

q:你会如何选择开发框架呢?

a:一个框架都不要用。但是,我会从这些开发框架中,找出我需要的功能,拿出那个我需要的程式模组来用,或者参考其中的设计想法,而不是套用整个框架。我所看到的大多数框架,都没有专注在打造有效能的扩充性和可模组性。

q:难道开发者不需要框架或架构吗?

a:网站的确需要有架构,每一个人都需要框架,框架是一种解决问题的方法。但是你并不需要通用型框架,用一个前端控制器,来解决所有问题,这样通常没办法成功。每一个问题都不同,你需要引导框架,使用正确的设计模式,直接解决真正要处理的问题。只生产一款汽车,怎麽可能满足全世界人的需求!

用框架开发雏形系统就好,但真正的产品就不要全部套用。从框架开始比较容易,但你要拆开全部的框架,移除runtime检查丶拿掉不需要的功能,只留下你会用到的程式模组。你不需要一个通用型框架,因为它无法提供未来的扩充性,但也不用重头写起,你需要的是介於两者之间。

q:网站需要规画到多久以後的扩充需求?

a:我总是痛恨要帮未来考虑太多。当你无法预测未来,你就无法帮未来作决定。
网路变化太快,我通常只规画半年内的事情。现在决定半年以後的事情,可能会做出错误决策,反而让事情更糟。如果你没有解决当下的问题,而是想像未来会发生的问题,我认为不值得,我宁可解决眼前看得到的问题,真正聚焦在当下需要的产品。

q:那麽,有任何准则是架构人员可以遵循的吗?

a:最主要的原则是,仔细考虑如何分配程式模组,尽可能将程式拆解成更小的元件,调校出适当的api,你应该规画的是使用者端点的事情,例如浏览器请求的类型是什麽?应用程式要如何回应?是否可以切割?是否可以把这些工作分配到完全分离的伺服器上执行?即使是在同一台伺服器上,你也能从使用者端点的角度来架构应用程式,有一天,当你的规模变大後,就可以很容易加入第二台伺服器,只要在前端伺服器不储存任何资料,就能进行流量分担。一般开发者最大的错误是,让程式码之间的交互关连(interrelation)太深,每个不同的元件都需要和其他外元件沟通,这样做很难调校出很乾净的api。开发者会无法抽离出效率慢的api放到辅助伺服器中,而让主要伺服器只执行必要api。

q:切割服务丶拆解程式的难度是什麽?

a:必须在开始之前,就要非常了解问题。当你写完第一个版本的程式,才着手拆解问题,那几乎是不可能,很难事後处理。这的确很难,因为问题会一直改变。但是,若你从简单的架构开始,并且保持这个精神来区隔程式模组。每次当网站发生变化时,问题的变化也只会影响到一小部分,你就能够非常清楚那个地方,能够直接解决问题。就好像乐高游戏一样,盖好每一个小块积木,哪边还有不足,就只需要再补上一小块就好,不用对整体改变太多。

q:除了扩充性以外,如何提高网站效能呢?

a:要提高效能,得先知道每一支程式花了多少时间。我会问,使用者送出request请求後,要多久才会收到第一个byte的资料?很多开发人员不晓得这个时间(first byte latency)是多久,不晓得自己的程式码用掉多少时间?可以透过profile来追踪效能,画出视觉化的效能流程图,来了解瓶颈在哪。

甚至要考虑到单一机器上的延迟,透过系统层级的追踪程式,知道程式执行的每一个系统呼叫(system call)耗费多久。还要考虑浏览器中的延迟,从使用者实际感受的速度来改善网页执行方式等。
每次你增加一个新功能,要能计算出新功能会增加多少毫秒,想一想这麽做值不值得。

q:那麽,网站的安全性又需注意哪些原则?

a:基本精神很简单,只要用资料防火墙的概念来设计网站。网路防火墙会严密监控每一个通讯埠,只让没有安全疑虑的封包通过,但网站开发者刚好相反,只挡掉自以为有危险的内容。开发者不能信赖任何从外部取得的资料,借用防火墙概念和手法,建立资料防火墙,就能提高网站安全性。

q:好的架构师需要什麽样的条件?

a:必须非常了解技术,了解每一个细节,例如设计资料储存机制,要了解哪种资料可以储存丶可以存多大的档案,放多少资料丶每秒钟可以放多快?如何复制资料?前端必须使用哪种资料格式等。架构师可以不用像 dba,知道如何修复oracle资料库的错误,但是要能够了解oracle资料库拥有的能耐。这种人很难找,必须要失败过很多次,才会有足够的经验。

q:台湾还有不少旧网站使用php 4,他们应该现在升级到php 5吗?还是等待php 6?

a:尽快升级到php 5。只要作一些测试和修改,就能得到更好的效能和安全,为什麽不做?不需等待php 6,开源社群的运作方式,无法承诺推出时间。很多新功能已经放到php 5.3版中,赶快从4升到5最重要。
申明:本教程内容由威凡网编辑整理并提供IT程序员分享学习,如文中有侵权行为,请与站长联系(QQ:254677821)!
上一节 下一节
相关教程  
其他教程  
PHP基础
PHP技巧
PHP实例
PHP文摘
PHP模板
PHP总结

违法和不良信息举报中心】邮箱:254677821@qq.com
Copyright©威凡网 版权所有 苏ICP备2023020142号
站长QQ:254677821