LAMP架构下的Web开发概念、流程及优化策略
架构设计 ——前端架构 •后端架构 •视觉体系
对接约定 ——接口约定 •标识约定 •通讯代码约定
开发 ——建立开发框架 •建立数据库 •实施编码
测试——功能测试 •性能测试
一、架构设计
二、对接约定
1、接口约定
前端请求四要素，文档中体现，程序中实现：约定请求方式（普通HTTP请求，XMLHTTP请求，SOAP请求，phprpc请求）；请求类型（POST,GET,HEADER）；请求地址；请求参数。
2、标识约定
为确保前后端并行开发，减少开发的时间周期，需要在开发前就做好标识约定，通过文档描述清楚前端模板变量和后端程序变量之间的约定关系，以及后端返回各种状态值的含义。 建议的最佳应用是：后端不对用户视图负责，只管输出状态代码。呈现给用户的视图由前端负责。
三、各类web服务器优缺点比较
• Nginx
优点：原生支持反向代理，带有简单的负载均衡及容错机制。速度最快。（10%-1000%），占用资源很少。
缺点：文档较少，手工配置，只能以fast-cgi方式运行php.
• Apache
优点：文档丰富，稳定（！？），应用环境多。
缺点：占用资源较多，高压力下表现性能不如nginx或lighttpd，手工配置。
•IIS
优点：文档丰富，win平台下安装简单配置方便
缺点：不支持跨平台，性能低下。
四、常见web系统组织图
五、PHP在web应用中的特点
• 语言弱类型 • 脚本运行，生命周期短 • 面向对象与面向过程并存 • 弱效率、重流程、强扩展
1、PHP的优点
• 适合web开发。将web开发中常用的行为、内容做了良好的封装。程序员可以很轻易的使用它们。
• 基于脚本的运行方式，修改代码后不需要重新编译，很多情况下也不需要重启服务器。
• 开发快捷，部署方便，支持环境众多。
• 非常优秀的扩展能力。非常多的扩展子件。
• 开发框架众多。对多种数据库支持很好
• 良好的社区支持，本身开源。修改容易
2、PHP的缺点
• 容易写出坏的代码。(解决方法:严格遵循规范)
• 效能不高。（解决方法:复杂业务使用C扩展）
• 每次执行都要经历扫描-编译-执行的阶段，无执久对象模型。（解决方法:使用APC）
• 命名混乱，参数混乱，得随时翻着手册
3、PHP框架
• 对开发者起编码约束作用。
• 提供了ORM,使对数据库变成对数据对象的访问,让程序员对数据的处理更加专注于面向对象上.
• 通过配置(无需改动代码)即能变更服务环境,使得迁移成本减小
• 方便程序员实现完整的MVC开发模式.使程序员更专注于业务领域,不再过多关注建立数据模型的底层代码以及处理视图展示.
• 内置大量开发中的常用工具。可随时调用。也可自己扩展编写。
• 本身即由PHP编写。可随时修改以满足达到自己的需求。
六、目前流行的PHP框架
• Qee /FleaPHP (领域设计驱动)
• ThinkPHP （大的类库J）
• Zend Framework（Pear的OOP版）
• Yii
• KiwiPHP （工业微内核）
• Symfony （配置最简单）
七、WEB中的MVC开发模式
应用场景一: M (数据模型,框架提供) C (控制器,框架实现) V (视图,应用者编写,框架自动载入) 应用者编写的,是供控制器装载的业务处理类
应用场景二: M (业务模型,应用者编写) C (业务控制器,应用者编写,由框架控制器自动载入) V (视图,应用者编写,框架自动载入)
现实中复杂应用场景:
1.用户请求: http://domain/blog/list/
2.分析URL,实例化逻辑控制类blog,执行方法list
3.在控制类news中,又分别实例化业务模型类blog和user,并做相应处理.
4.业务模型类blog,user中,调用数据模型(专用,非M层),对数据进行处理.
5.回到逻辑控制类中,展现视图$this->view->output( );
※运用中需要注意的地方
• PHP没有持久层,每一次访问请求都是独立运行,建立的模型对象不能持久存在,无法跨访问复用.如果框架/应用的设计过于繁琐,每次装载/初始化都会浪费不少时间.
• 各层之间的耦合度尽量降到最低,尤其是业务模型和业务逻辑之间要尽量分离.以便日后修改或复用.
• PHP本身只有较少功能是抛出异常,大部份是抛出错误(Notice,warning,error),代码编写中应时常对应用环境的正确性做手工检查,不符合条件时手工抛出异常,并设置异常接收器统一处理
八、访问模式
• 单入口模式
http://domain/index.php?control=blog&action=list
http://domain/index.php?control=news&action=read
• 多入口模式
http://domain/blog.php?action=list
http://domain/news.php?action=read
• PathInfo模式
http://domain/index.php/blog/list/
http://domain/index.php/news/read/
• Rewrite模式
http://domain/blog/list/
http://domain/news/read/
Rewrite及pathinfo的好处:对搜索引擎友好,对用户更直接
九、数据库抽象层、Active recode
• 数据库抽象层的作用： 减少与具体数据库的底层接触,提供跨数据库平台的访问接口,以实现数据操作与数据库类型的无关性.方便数据库系统的迁移变更.
• PHP本身提供的抽象层： Pear::DB(php4),PDO(php5,6)
• 框架中引入的各种类Active Recode系统
目的：将数据库字段与映射到对象，不用关心具体的SQL语句，只需要操作数据对象及调用相关的方法即可实现数据的CRUD操作。
好处：模型化了数据库，快捷开发，是数据库抽象层的进一步进化。
缺点：对于复杂数据模型的处理较为无力，例如多表连查、子查询； 缺乏灵活性，比如只想要一列数据，却取出了整行；与数据库字段名的耦合度太高。如通过配置改进，执行效率又打折扣；难以应付复杂的Web环境。（多种数据库，分布式数据库，缓存系统介入）
十、模板引擎
• 为什么引入模板引擎
视图：在web开发中通常就是指前端页面。模板引擎的引入，是为了实现视图层的分离，降低视图与逻辑、模型部份的耦合度。使得前端页面与程序部份可以并行工发、轻松整合的工具
• 常见的模板引擎及特点
PHP中常用的模板引擎有 Smarty, SmartTemplate
其中smarty提供了强劲的功能，STE则非常轻巧。
两者的核心原理，都是将页面中的变量标签替换成通过assign方法注册的PHP运行变量，并将替换后的页面（“编译”后的页面文件）生成缓存保存在磁盘中。或者提供一定的逻辑控制功能供前端使用。这样即方便将程序和视图分离,使前端设计人员更着重于表现和数据,而不用关心程序上的流程.
• 缺点
初次加载模板时,因生成缓存,需要额外的处理开销和IO开销， 之后加载模板时,会判断模板文件的最后修改时间是否大于生成的缓存文件时间,亦有一定的额外IO开销.
※使用模板引擎的注意事项
• 尽量折分公用组件。
• 不要在视图中使用太多的控制语句：就以前的经验来看,简单的if,变量循环输出即已足够。在视图中加入太多的控制语句会带来的问题，是对设计思想的破坏，因为它打乱了将视图层独立出来的最初目的，让前端的设计人员不得不过多的关注“程序”而非页面本身。要不然就得由程序员最终回头修改前端设计人员已经做好的模板文件。更重要的一点时：如果在模板中引入太多的控制语句，那还不如直接在页面中写<?php ,因为PHP的本身就是模板引擎。无论哪种都快不过它。所以,尽量将控制放在PHP程序体内,不要放到视图中去跑.
十一、LAMP架构下的加速系统
十二、各级加速系统说明
• WEB服务层
Nginx :自身支持反向代理,提供简单的负载均衡及从错机制,能很方便的搭建起web服务集群.
Lighttpd:超轻量,合适搭建静态访问服务器
Squid:对动态内容亦能做缓存处理.
• PHP层
APC:缓存opcode,减少了扫描和编译阶段,但仍无法实现持久对象.纯脚本效率提高在200%--500%,应用场景下实测通常能提高效率一倍.
• 数据层
共享内存：Memcache: Key=>Value对形式的内存数据缓存服务.基于TCP连接.常用于缓存数据库查询结果.支持分布式.
缺点:关机即无,每次连接的时间开销大.
推荐的工具
• Editplus+PHP
• XDEBUG+Eclipse PDT
• SmartTemplate
Xdebug+ WinCacheGrind
摘自：百度运维空间