场景设想,某个网站的用户小A打开了chrome,输入网站的网址,然后点击访问。然后浏览器开始运作,客户端就带着一大把要求兴冲冲地去找服务器了,这些要求包括可接受的内容形式,编码格式,语言,还有缓存要求,连接时间,和访问者有关的cookie等等。当然机器是不认识域名这种东西的,先是跑到本地hosts找找有没有对应域名,发现没有,然后经路由转向当地基站,然后在这里找到对应域名的IP地址,此时也就是找到了要访问的服务器的地址。当然IP地址里还要加上端口,服务器的门可不止一个,为了避免冲突各个门都各有各的用途,所以客户端必须指定由那个被授权的门进入,否者会惨遭拒绝。
客户端的请求历经千辛万苦终于顺利进入服务器,服务器收到请求后先看看其具体请求的是哪个文件,然后由统一入口找到那个文件,发现是一个PHP文件,然后服务器赶紧召唤它的得力助手PHP解释器,由PHP解释器把PHP代码翻译成具体的数据,PHP在翻译的过程中发现很多数据存放在一个叫做数据库的仓库里,然后PHP也找来仓库管理员数据库语言按需求对仓库里相应的数据进行增删查改。说起来为了更加高效地满足上述四个需求,仓库里数据的存储做出了大量空间的牺牲。当然业务过于繁忙的时候仓库会忙不过来的,所以对于那些经常会用到的数据,可以选择在仓库旁边建个小棚屋,把那些数据也复制一份到小棚屋里,一般这样的小棚屋有缓存,队列(redis)等形式。去小棚屋里拿数据当然会快些,只是小棚屋比较简陋,没有数据库那么好的结构,也没有那么细的分门别类,所以数据会有些乱,可满足的业务需求相对就要少些。当PHP解释器把文件翻译完成之后,服务器就根据客户端要求把这个文件发送给客户端。当然,如果客户端传递过来的请求头里有 COOKIE的话,服务器还会找到其对应的SESSION一并发送给客户端。
客户端收到文件后,浏览器就开始对其解析,发现其带有样式信息.css和交互信息.js,然后浏览器接着向服务器请求这些信息。接下来又发现文件里还有图片信息,于是再次向服务器请求图片信息,如此继续,知道获得整个文件所需的所有资源,至此一次访问结束,接下来又是一个周期的开始。
根据上述过程,一个网站项目的资源也应该分门别类存放,便于管理。网站应该由一个统一入口(index.php)接入,相关.css .js,音视频,图片等资源分门别类放在对应的文件夹下。坚持MVC的架构方式,View部分也应该区分整体,头,尾和具体页面。Model尽量做到只与数据库或者缓存打交道而无关具体业务,Controller也只负责调度。其中需要用到的常用方法也尽量封装在Lib里。