大型互动应用思路四程序架构Word文档下载推荐.docx

上传人:b****1 文档编号:3139643 上传时间:2023-05-01 格式:DOCX 页数:12 大小:341.36KB
下载 相关 举报
大型互动应用思路四程序架构Word文档下载推荐.docx_第1页
第1页 / 共12页
大型互动应用思路四程序架构Word文档下载推荐.docx_第2页
第2页 / 共12页
大型互动应用思路四程序架构Word文档下载推荐.docx_第3页
第3页 / 共12页
大型互动应用思路四程序架构Word文档下载推荐.docx_第4页
第4页 / 共12页
大型互动应用思路四程序架构Word文档下载推荐.docx_第5页
第5页 / 共12页
大型互动应用思路四程序架构Word文档下载推荐.docx_第6页
第6页 / 共12页
大型互动应用思路四程序架构Word文档下载推荐.docx_第7页
第7页 / 共12页
大型互动应用思路四程序架构Word文档下载推荐.docx_第8页
第8页 / 共12页
大型互动应用思路四程序架构Word文档下载推荐.docx_第9页
第9页 / 共12页
大型互动应用思路四程序架构Word文档下载推荐.docx_第10页
第10页 / 共12页
大型互动应用思路四程序架构Word文档下载推荐.docx_第11页
第11页 / 共12页
大型互动应用思路四程序架构Word文档下载推荐.docx_第12页
第12页 / 共12页
亲,该文档总共12页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

大型互动应用思路四程序架构Word文档下载推荐.docx

《大型互动应用思路四程序架构Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《大型互动应用思路四程序架构Word文档下载推荐.docx(12页珍藏版)》请在冰点文库上搜索。

大型互动应用思路四程序架构Word文档下载推荐.docx

工作内容

我喜欢化繁为简,我简化出四类工作内容,在框架中需要体现,看下图:

其他问题

在第一张图中我们一共列出了11项考虑问题的角度,剩余的一些问题,我们不能一一展开了讲,但会在后续的内容中拾起这些问题。

解决问题

依据上面提到的问题,我们开始进行实际的构架设计。

前期准备

在构架之前我们首先要明确开发中使用的“代码规范”,代码规范应该涉及以下内容:

框架详细

如图,按照我们前面提到的问题,首先把程序的主体结构切分成4部分,system承担基础代码,app目录存放主要的业务逻辑,admin是系统的后台代码,3rd存放第三方代码库,如smarty等。

system

基本上可以被分为两类代码,一类用于搭建网站的流程,例如core.php负责初始化和对象的创建加载(谈到对象的创建方式,请看文章的后半部分),route.php负责URL的对应关系解析(具体请翻阅kohana、yii、cakephp、thinkphp等成熟框架中的定义),request.php负责了从发起请求到具体调用controller中的方法,并格式化输入变量的功能,例如统一处理GPC变量,如果分的不细可以使用request.php负责内容的返回和输出,否则你还需要一个response.php,有时候过剩的设计容易“画蛇添足”。

controller.php、view.php、ORM组成了最普遍应用的MVC系统,完整实现ORM功能需要若干文件组成,因此在这里没有写成orm.php,ORM可以依赖底层的db.php实现,也可以直接使用成熟的ORM产品,例如propel等。

另外一类代码如db.php、cache.php(实际上可能是memcached的访问类)、mail.php用于与具体的设备进行衔接。

validator.php就是前面讲到的表单处理问题,我们在下面的内容中会单独讲,其余的log会在下面的日志处理中讲到。

这套代码结构中没有写上一些关于“负载均衡”、“集群路由”等方面的设计,这些更细致的东西也无法用一篇文章来写,随着连载的完成,后续可以以专题的形式来填补。

app

app是整个项目的核心业务逻辑区,存放着具体的MVC内容,其中model中的任何模块是采用ORM来实现的,view可以自己构建也可以采用smarty来搭建,lib目录可以用来存放非controller的一些公共逻辑,可以由不同controller间相互调用。

这里的细节是我们采用了wwwroot目录仅把需要暴露的代码和静态文件暴露出来,其余的内容都无法直接访问到,这是一个好习惯。

其它结构

剩下的两个结构大家看看图即可,可讲的内容不多,这里唯一需要注意的是对后台系统可以与前端业务系统在数据库上就直接进行分离,互不干扰,当然这也不是今天要阐述的重点,可以在其它专题中我们再续。

执行流程

这是一个非常精简的执行流程示意图,首先通过index.php加载进来,这一般被称为“单一入口”,由system目录下的Core来执行初始化,创建一个唯一实例的Request对象,依据URL中的内容转化为具体的controller、action名称以及参数,内部创建controller并执行,其中before与after函数可以不必实现,由controller来具体调用model与view绑定,最终向客户端输出。

有几种流派,其中一种是喜欢model或view与controller进行自动绑定或自动渲染,大家可以翻看其它框架或类似内容的文章。

对象加载

对象的加载方式基本上分成三种:

<

?

php

//1.new

$obj=newClassName;

//2.1.factory

$obj=Core:

:

factory('

ClassName'

);

//2.2

$obj=ClassName:

factory();

//3.instnace

instance();

>

第一种使用了直接创建,第二种使用了工厂方法,第三种是在类内部建立了一个唯一实例变量,创建的对象在全局访问中是唯一的,只要对象不存在上下文切换,也不参与并行都可以采用这种方式节省资源,对于PHP而言instance方法是非常友好的。

表单验证

Web最直接的输入来源于大量的表单,表单验证方式如果不能统一,在表单处理上就会产生很多BUG,并且只能随着上线后由用户来反馈问题,而可以使用一个统一的验证机制来处理表单认证问题。

其实另外一个隐含的问题是如何统一JS与后端程序之间的双认证问题,为了提升用户体验,大部分网站会采用JS前端认证,而为了保证安全后端也会认证,如果两套认证的条件不一致就会造成问题。

错误日志

以上图表算是一种总结,到底怎样才算一个完善的错误日志系统,大多数系统只实现了其中一两种,最简单的方式就是信息分级利用常量就可以做到例如:

define('

ERROR_MEMCACHED_INFO'

1);

ERROR_DB_INFO'

2);

ERROR_CONTROLLER_INFO'

4);

ERROR_CORE_INFO'

8);

ERROR_INFO'

ERROR_CORE_INFO|ERROR_CONTROLLER_INFO);

if(ERROR_INFO&

ERROR_CORE_INFO){

echo"

coreiniterror."

;

}

ERROR_MEMCACHED_INFO){

memcachedgeterror."

稍微高级一点的做法是对set_error_handler()、set_exception_handler()、register_shutdown_function()进行注册,把任何的错误或异常捕获下来,并转存到日志当中,或输出到页面,对于这三个函数的用法请参考PHP官方手册。

对待运行中产生的日志,如果非常重要的,例如ERROR_CORE_INFO级的错误信息,可以直接以短信的方式发送到程序员的手机上,也可以发送到其邮箱或内部通讯工具上,发到微博上也行。

长期下来日志会变的巨大,一定要实现一种合理的策略,例如按周回滚日志,实现方法比较容易,我们就不多举例了。

更高级一点的做法是收集一定的系统信息,例如脚本执行时间、当前的CPU占用、内存、磁盘使用情况等汇总起来,对于一些极难发现的问题,可以起到排查作用。

伪类实现也是一种常用的测试或调试方法,例如代码:

interfaceIDatabase{

functionquery($sql);

classDatabaseimplementsIDatabase{

functionquery($sql){

mysql_query($sql,$this->

link);

classDatabase_DebugimplementsIDatabase{

echo"

sql="

.$sql."

\n"

classCore{

functionfactory($className,$debug=false){

$class=null;

if($debug===true){

$class=$className."

_Debug"

}else{

$class=$className;

}

returnnew$class;

functionmain(){

$db=Core:

Database'

true);

$db->

query("

SELECT1"

SELECT2"

}main();

利用工厂方法创建对象,在创建时选择是否从测试类中进行创建,只要测试类与实际的执行类都从一个接口中实现,就可以实现随时进行切换。

至于更更高级的“单元测试”大家可以通过学习PHPUnit来熟悉,这里只强调代码应该具备良好的局部测试能力,也就是说代码的一个局部应该具备完整的输入和输出,方便通过一种模拟来对局部逻辑进行验收。

关于测试与日志更详细和具体的内容,我希望未来通过更明确的专题单独和大家讨论,今天点到为止,但思路是给大家了。

程序性能

前面有什么样的问题,后面就要都点到了,最后写一下程序性能上的一些问题,同样请看图:

这部分知识就像一个半人本机械的组合体一样,一半是程序问题另一半是系统构架问题,所以这部分最难讲,需要用更大的篇幅来描述,伴随着连载大家也许能最终了解全貌,今天还是抛砖引玉。

负载均衡可以使用负载均衡设备控制,也可以通过程序进行代理,负载均衡既有外部访问的问题,也有内部上的问题,总之就是一种算法,用于均衡处理目录下的文件、用户的访问、数据的读写、缓存的分配等等,算法方式也比较多,例如轮训、HASH分配等,需要读者自己弥补知识。

多环境配置大型网络公司常面临到的问题,因为在他们内部常会把环境分的比较细,分成本地环境、测试环境、线上环境,因此如何处理多种环境下不同的配置需要找到合理的办法,其实方法也容易,仔细思考一下,我今天就抛出问题吧。

持久连接基本上与程序关系就更不大了,代码实现也比较简单,就是选用可持久连接的函数,利用Nginx与FASTCGI就可以简单实现数据库、memcached等设备的持久性连接。

服务化

大型互动网站应该不仅仅由一个域名、一套程序来构成,需要针对不同的内容切分域名和服务,例如邮件服务、缓存服务、文档服务、上传服务这些服务都是可以从一套程序中分解独立出来的,尤其是上传服务是最好理解的,没必要每套程序都实现复杂的上传处理。

总结

写文章真不比写程序要容易,要照顾读者,文中提供的都是代码片段,本身没有经过正式运行的测试,不免会有不严谨之嫌,但作为连载文章,写作时间还是很有压力的。

 

本文摘自《草根》第5期

浪湾,此人草根出身,02年开始啃PHP编程,转眼间已在LAMP领域滚打七年。

目前就职于凤凰网,专注于大型网站构架的研究,博客地址

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 幼儿教育 > 幼儿读物

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2