HTTP服务七层架构技术探讨

前言：太久没有做过技术分享了，这里把曾经老的新浪论坛里面使用过的架构技术做了改进和整理，最后总结了这么一篇，欢迎拍砖。

1.为什么分层？

   计算机领域的体系结构普遍采用了分层的方式。

   从整体结构来看： 

   从最底层的硬件往高层依次有操作系统->驱动程序->运行库->系统程序->应用程序等等。   

   从网络分层模型OSI来讲,由上至下为：

   应用层->表示层-> 会话层->传输层->网络层->数据链路层->物理层       

   当然实际应用的TCP/IP协议的分层就没OSI标准这么复杂。   

   从C语言文件编写到生成可执行文件的过程来看： 

   预处理(展开后的C语言代码)->编译成汇编语言(特定CPU体系结构的汇编语言源文件)->汇编器生成目标文件（CPU可执行的二进制指令机器码）->链接器连接目标文件生成可执行文件（操作系统可以加载执行的二进制文件）

   这不算是软件的分层结构，但是可以理解为一种通过分层来简化复杂问题的思想。那么PHP语言可以认为是建立在C语言之上的层----其解释器Zend引擎是用C语言实现。毕竟用PHP这样的脚本语言编写动态网页要比用C语言方便得多。  

   当然还有我们最熟悉的MVC分层技术了，后面会做详细介绍。   

   那么分层的好处想必大家都已经比较熟悉，这是一种 “分而治之  大而化小”  的思想。说到分层就不得不提模块了，其实分层和模块是从两种维度来进行“分而治之”的方式。模块是从横向维度来将一个整体分割成若干个独立的部分，每个部分行使独立自己的职责，当然它们之间也可能有依赖关系，这通过其对外提供的服务来实现。如果将整个系统比做中国版图的话，那么模块方式将中国分为省，自治区等。 分层则是从纵向纬度将一个整体从高至低划分为若干个独立的层，一个完整的服务由底层至上层，层层传递最终产出。分层和模块可以同时运用，例如中国用模块方式分为省之后，然后每个省的行政机构利用分层方式来行使职责,从低到高有户，村，乡，区，市，省等等，每一层都向上一层汇报。 分层和模块会提高系统复杂度并影响效率（户不能直接向省汇报，而需要一级一级向上汇报），但是这样有利用系统的扩展和维护，每一层只需要关注自己提供的服务接口以及它下一层所提供的服务接口，试想一下如果省需要接受来自市，区，乡，村等所有下级层的汇报，那些省干部会很头疼的。

2.HTTP服务传统的三层架构MVC

  HTTP服务中最经典的分层架构非MVC莫属了， 几乎任何一个PHP开发框架都是支持MVC分层模式，此模式历史也比较悠久，是在上个世纪八十年代为编程语言Smalltalk设计的软件模式，至今已经被广泛引用。

 这里引用了百度百科中的图片：

那么关于MVC的优点我不做介绍，搜索引擎中能找到大量相关资料。

本文的标题是HTTP服务七层架构技术探讨，比MVC多出了四层，这样复杂的分层是否有必要呢？

关于这个问题仁者见仁智者见智，本人认为MVC分层粒度不够精细，当然你也可以继续坚持传统的三层，那么后文你也没必要看下去了。

那么为什么MVC分层不够精细呢，在我曾经使用开源框架的MVC模式的经验中发现，V和C层功能职责一般都很清晰稳定，但是M层却常常显得臃肿笨拙。

C层主要是负责整体流程控制，一般规范的架构中，流程都可以用一张或几张流程图画出，那么表明流程一般都是固定的。

V层主要是负责页面呈现，可能使用smarty模板引擎，也可能是自带的模板引擎，显示的页面可能是HTML，XML或则JSON，这些种类再多也都是可以度量的，所以M层也可以说是固定的。

而M层却关系到系统的业务逻辑，随着系统不断迭代更新，M层中的内容也会不断演变，而这一层中也有很多复杂的处理，如文件读取，数据库查询，缓存策略，逻辑运算，数据加工，数据打包等等。 

所以MVC三层模型中，M层是还能再做细分的，当M层有一个更精细合理的分层方式之后，我们的业务逻辑演变过程会更加的得心应手。