易栈网-膘叔

原文作者：yizhu2000

链接：http://www.phpv.net/html/1663.html

本人作为一位web工程师，着眼最多之处莫过于性能与架构，本次幸得参与sd2.0大会，得以与同行广泛交流,于此二方面，有些架构设计的心得，不敢独享，与众友分享，本文是这次参会与众同撩交流的心得.

架构设计的几个心得：

一，不要过设计：never over design

这是一个常常被提及的话题，但是只要想想你的架构里有多少功能是根本没有用到，或者最后废弃的，就能明白其重要性了，初涉架构设计，往往倾向于设计大而化 一的架构，希望设计出具有无比扩展性，能适应一切需求的增加架构，web开发领域是个非常动态的过程，我们很难预测下个星期的变化，而又需要对变化做出最 快最有效的响应。。

ebay的工程师说过，他们的架构设计从来都不能满足系统的增长，所以他们的系统永远都在推翻重做。请注意，不是ebay架构师的能力有问题，他们 设计的架构总是建立旧版本的瓶颈上，希望通过新的架构带来突破，然而新架构带来的突破总是在很短的时间内就被新增需求淹没，于是他们不得不又使用新的架构
web开发，是个非常敏捷的过程，变化随时都在产生，用户需求千变万化，许多方面偶然性非常高，较之软件开发，希望用一个架构规划以后的所有设计，是不现实的

二，web架构生命周期：web architecture‘s life cycle

既然要杜绝过设计，又要保证一定的前瞻性，那么怎么才能找到其中的平衡呢？希望下面的web架构生命周期能够帮到你

所设计的架构需要在1－10倍的增长下，通过简单的增加硬件容量就能够胜任，而在5－10倍的增长期间，请着手下一个版本的架构设计，使之能承受下一个10倍间的增长

google之所以能够称霸，不完全是因为搜索技术和排序技术有多先进，其实包括baidu和yahoo，所使用的技术现在也已经大同小异，然而，google能在一个月内通过增加上万台服务器来达到足够系统容量的能力确是很难被复制的

三，缓存：Cache

空间换取时间，缓存永远计算机设计的重中之重，从cpu到io，到处都可以看到缓存的身影，web架构设计重，缓存设计必不可少，关于怎样设计合理的缓 存，jbosscache的创始人，淘宝的创始人是这样说的：其实设计web缓存和企业级缓存是非常不同的，企业级缓存偏重于逻辑，而web缓存，简单快 速为好。。

缓存带来的问题是什么？是程序的复杂度上升，因为数据散布在多个进程，所以同步就是一个麻烦的问题，加上集群，复杂度会进一步提高，在实际运用中，采用怎样的同步策略常常需要和业务绑定

老钱为搜狐设计的帖子设计了链表缓存，这样既可以满足灵活插入的需要，又能够快速阅读，而其他一些大型社区也经常采用类此的结构来优化帖子列表，memcache也是一个常常用到的工具

链接:钱宏武谈架构设计视频 http://211.100.26.82/CSDN_Live/140/qhw.flv

Cache的常用的策略是：让数据在内存中，而不是在比较耗时的磁盘上。从这个角度讲，mysql提供的heap引擎（存储方式）也是一个值得思考的方法,这种存储方法可以把数据存储在内存中,并且保留sql强大的查询能力,是不是一举两得呢?

我们这里只说到了读缓存，其实还有一种写缓存，在以内容为主的社区里比较少用到，因为这样的社区最主要需要解决的问题是读问题，但是在处理能力低于 请求能力时，或者单个希望请求先被缓存形成块，然后批量处理时，写缓存就出现了，在交互性很强的社区设计里我们很容易找到这样的缓存

四，核心模块一定要自己开发：DIY your core module

这点我们是深有体会，钱宏武和云风也都有谈到，我们经常倾向于使用一些开源模块，如果不涉及核心模块，确实是可以的，如果涉及，那么就要小心了，因为当访 问量达到一定的程度，这些模块往往都有这样那样的问题，当然我们可以把问题归结为对开源的模块不熟悉，但是不管怎样，核心出现问题的时候，不能完全掌握其 代码是非常可怕的

五，合理选择数据存储方式：reasonable data storage

我们一定要使用数据库吗，不一定，雷鸣告诉我们搜索不一定需要数据库，云风告诉我们，游戏不一定需要数据库，那么什么时候我们才需要数据库呢，为什么不干脆用文件来代替他呢？
首先我们需要先承认，数据库也是对文件进行操作。我们需要数据库，主要是使用下面这几个功能，一个是数据存储，一个是数据检索，在关系数据库中，我们其实非常在乎数据库的复杂搜索的能力，看看一个统计用的tsql就知道了(不用仔细读,扫一眼就可以了)

select   c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(select   count(Id)   from   review   where   Reviewid=a.Id)   as   countNum   from   Creativity   as   a,User_info   as   b,class   as   c,class2   as   d   where   a.user_id=b.id   and   a.Creativity_Class=c.Id   and   a.Creativity_Class_2=d.Id 

select   a.Id,max(c.Class_name),(max(d.Class_name_2),max(a.Creativity_Title),max(b.User_name),count(e.Id)   as   countNum   from   Creativity   as   a,User_info   as   b,class   as   c,class2   as   d,review   as   e   where   a.user_id=b.id   and   a.Creativity_Class=c.Id   and   a.Creativity_Class_2=d.Id   and   a.Id=e.Reviewid   group   by   a.Id ..............................................

我们可以看出需要数据库关联，排序的能力，这个能力在某些情况下非常重要，但是如果你的网站的常规操作，全是这样复杂的逻辑，那效率一定是非常低 的，所以我们常常在数据库里加入许多冗余字段，来减小简单查询时关联等操作带来的压力，我们看看下面这张图，可以看到数据库的设计重心，和网站(指内容型 社区)需要面对的问题实际是有一些偏差的

同样其他一些软件产品也遇到同样的问题所以具我了解，有许多特殊的运用都有自己设计的特殊数据存储结构与方法，比如有的大型服务程序采取树形数据存储结构，lucene使用文件来存储索引和文件

从另外一个角度上看，使用数据库，意味着数据和表现是完全分离的（这当然是经典的设计思路），也就是说当需要展示数据时，不得不需要一个转换的过 程，也可以说是绑定的过程，当网站具备一定规模的时候，数据库往往成为效率的瓶颈，所以许多网站也采用直接书写静态文件的方法来避免读取操作时的绑定

这并不是说我们从今天起就可以把我们亲爱的数据库打入冷宫，而是我们在设计数据的持久化时，需要根据实际情况来选择存储方式，而数据库不过是其中一个选项

六，搞清楚谁是最重要的人：who's the most important guy

在用例需求分析的时候常常讲到涉众，就是和你的设计息息相关的人，在web中我们一定以为最重要的涉众莫过于用户了。，在一个传统的互动社 区开发中，最重要的东西是内容，用户产生内容，所以用户就是上帝，至于内容挑选工具，不就是给坐我后面三排的妹妹们用的吗？凑或行了，实在有问题我就在数 据里手动帮你加得了。。这大概是眼下许多小型甚至中型网站技术人员的普遍想法。钱宏武在他的讲座里谈到了这个问题：实际上网站每天产生的内容非常的多，普 通人是不可能看完的，而编辑负责把精华的内容推荐到首页上，所以很多用户读到的内容其实都依赖于编辑的推荐，所以设计让编辑工作方便的工具也是非常重要， 有时甚至是最重要的。

七，不要执着于文档：don't be crazy about document

web开发的文档重要吗？什么文档最重要？我的看法是web开发中交流>文档，

现在大的软件公司比较流行的做法是：
注重产品设计文档，在这种方法里，产品文档非常详尽，并且没有歧义，开发人员基于设计文档开发，测试人员基于设计文档制定测试方案，任何新人都可以通过阅读产品设计文档来了解项目的概况

而web项目从概念到实现的时间是非常短的，而且越短越好，并且由于变化迅速，要想写出完整的产品和需求文档是几乎不可能的，大多数情况是等你写出 完备的文档，项目早就是另外一个样子，但是没有文档的问题是，如果团队发生变化，添加新成员怎样才能了解软件的结构和概念呢，一种是每个人都了解软件的整 个结构，除非你的团队整体消失，否则任何一个人都能够担当培养新人的责任，这种face2face交流比文档有效率很多。

于是就有了前office开发者，现任yahoo中国某产品开发负责人的刘振飞所感觉到的落差，他说，我们的项目是吵出来的，我听完会心一笑

八，团队：team

不要专家团队，而要外科手术式的团队,你的团队里一定要有清道夫，需要有弓箭手，让他们和项目一起成长，才是项目负责人的最大成就

总结：

架构是一种权衡

web开发的特点是是：没有太复杂的技术难点，一切在于迅速的把握需求，其实这正式敏捷开发的要旨所在，一切都可以非常快速的建立，非常快速的重构，我们的开发工具，底层库和框架，包括搜索引擎和web文档提供的帮助，都提我们供给了敏捷的能力。

此外，相应的，最有效率的交流方式必须留给web开发，那就是face2face（面对面），不要太担心你的设计不能被完备的文档所保留下来，他们会以交流，代码和小卡片的方式保存下来

人的因素会更加重要，无论是对用户的需求，还是开发人员的素质。

1.SQL需求，统计当天的数据量。

2.查看其索引，以gmt_create开头。

3.查看awr报表的性能，逻辑读很高，达到9700个。

因为是只通过索引扫描，当看到返回结果集在2万左右，我们很容易估算出这个sql需要的逻辑读，(gmt_date字段7个字节+win_type字段1个字节+rowid+…）*2万，小于100个，现在很明显是偏高的。
4.调整前我们先去看数据分布。

5.调整索引,改为以win_type开头，为什么要以win_type开头呢？

6.查看其执行计划，逻辑读变成了89。

都在说建索引一定要看数据分布，从数据分布来看，一天的的数据(gmt_create)量在22万左右，而win_type的数据量非常 大，win_type为1有300万左右，为什么还要把win_type放在索引的前面呢？抛块砖，希望大家能对联合索引有更深入的理解，希望一起讨论。

--EOF--

帖子下的几个评论也很有意思：

什么是接口 (interface) ?

接口是方法的抽象，如果不同的类有同样的方法，那么就应该考虑使用接口。
（1）接口是一个行为的规范、协议。其实就是类和类之间的一种协定,一种约束
（2）C#不支持多继承，但是他把这个功能交给接口来实现。
（3）类与类之间的系统资源调用方式不一样，导致他们之间的通信很困难，而接口可以屏蔽掉它们之间的差异，能使他们顺利通信。

什么是抽象类（abstract class）？

1． 抽 象类仅提供一个类型的部分实现。抽象类可以有实例变量，以及一个或多个构造函数。抽象类可以同时有抽象方法和具体方法。一个抽象类不会有实例，这些构造函 数不能被客户端调用来创建实例。一个抽象类的构造函数可以被其子类调用，从而使一个抽象类的所有子类都可以有一些共同的实现，而不同的子类可以在此基础上 有其自己的实现。

2．  抽象类的用途1）  具体类不是用来继承的。 Scott Meyers曾指出，只要有可能，不要丛具体类继承。2）  假设有2个具体类，类A和类B，类B是类A 的子类，那么一个最简单的修改方案是应当建立一个抽象类（或java接口）C，然后让类A和类B成为抽象类C的子类。3）  抽象类应当拥有尽可能多的共同代码。以提高代码的复用率。4）  抽象类应当拥有尽可能少的数据。

 3．  基于抽象类的模式和原则1）  针对抽象编程，不要针对具体编程。2）  尽量使用合成(Composition)，而不要使用继承来达到复用的目的。3）  使用摸板方法模式

4．  什么时候应当使用继承复用1）  子类是超类的一个特殊种类，而不是超类的一个角色，也就是要区分”is – a” 和“has-a”两种关系。2）  永远不会出现需要将子类换成另一个子类的情况。如果设计师不是很肯定一个类回不会在将来变成另一个类的子类的话，就不应当把这个类设计成这个超类的子类。 3）  子类具有扩展超类的责任，而不是具有置换掉（Override）或注销掉（Nullify）超类的责任。4）  只有在分类学上有意义时，才可以使用继承，不要丛工具类继承。

抽象方法是必须实现的方法。且只能在抽象类中。

接口与抽象类

一个类可以继承多个接口。。。
一个类只能继承一个抽象类。。。

抽象方法是必须实现的方法。就象动物都要呼吸。但是鱼用鳃呼吸，猪用肺呼吸。
动物类要有呼吸方法。怎么呼吸就是子类的事了。

现在有很多讨论和建议提倡用interface代替abstract类，两者从理论上可以做一般性的混用，但是在实际应用中，他们还是有一定区别的。抽象类一般作为公共的父类为子类的扩展提供基础，这里的扩展包括了属性上和行为上的。而接口一般来说不考虑属性，只考虑方法，使得子类可以自由的填补或者扩展接口所定义的方法，就像JAVA王子所说的事件中的适配器就是一个很好的应用。
用一个简单的例子，比如说一个教师，我们把它作为一个抽象类，有自己的属性，比如说年龄，教育程度，教师编号等等，而教师也是分很多种类的，我们就可以继承教师类而扩展特有的种类属性，而普遍属性已经直接继承了下来。
而接口呢~还是拿教师做例子，教师的行为很多，除了和普通人相同的以外，还有职业相关的行为，比如改考卷，讲课等等，我们把这些行为定义成无body的方 法，作为一个集合，它是一个interface。而教师张三李四的各自行为特点又有不同，那么他们就可以扩展自己的行为body。从这点意义上来说，interface偏重于行为。
总之，在许多情况下，接口确实可以代替抽象类，如果你不需要刻意表达属性上的继承的话。

原文：http://www.cnblogs.com/cyc09156/archive/2009/01/09/1372330.html

由CAPCOM负责开发的格斗游戏《街头霸王4》（Street Fighter 4）最新试玩截图公布，本作将承袭系列作传统2D玩法，并采用最新的3D绘图技术，以更华丽的方式重现原作独特的2D绘图风格。PC版发售日期未 定，XBOX360/PS3即将2月17日发售。

另外，CAPCOM透露将推出内含限量非卖版人偶模型（PS3 版为隆，Xbox 360 版为深红毒蛇）、Studio 4C 制作之65分钟高分辨率动画影片（PS3版为BD蓝光影片，Xbox 360 版为专用高分辨率DVD影片，非一般 DVD 影片）、原声配乐 CD、攻略指引手册与独家下载内容的典藏版，定价 79.99美元。

以上内容来自于：http://www.lingaoyi.com/screens/new-street-fighter-4-screenshots/，同时以下图片也来自于该站（我只取了两张与我有关的图片）

更多图片请去该网站查看。。。

从TP1.5开始，对于其他的模版引擎有了原生支持（不再是以前那种插件机制了）。
本文以使用smarty模版为例作点简单介绍，其他的，可以参考一下View.class.php中的fetch方法可知。

TP的SVN中已经含有smarty模版库，因此当你要使用的时候，只需要在项目的config.php里作一点简单的配置：

从2009-01-07下午的SVN版本里，流年为又增加了一个TMPL_ENGINE_CONFIG这个数组，即：

备注：如果按照我这样的写法，请到cache目录里手动创建tplCompile和tplCache两个目录，否则程序会报错。
报错信息大致为：

如果出现这样的报错信息，请先检查这两个目录是否存在

在项目开发的时候，caching 最好设为false，否则你根本看不到效果。

如此设定完毕后，你就可以直接在项目中使用了，下面以Index模块的index方法进行举例：在IndexAction.class.php的index的方法里

然后到模版里：

就可以看到输出了。不过，这里需要注意的是，如果你$this->display()没有指定文件名，那么默认的模版文件就是default/Index/index.html，这点和原先使用TP默认的模版引擎没有什么区别。
出现问题最大的应该是在include方法里，include的使用方法是：{include file="Public/header.html"}，就象我前面所说，smarty的模版路径只指到了tpl目录，但实际上，我们是在默认的default目录下操作，因此正确的写法应该是{include file="default/Public/header.html"}
如果我们写的程序要对应多模版，那么，上面那种直接写死default的方法是不行的，还好，TP为我们留了一个常量：TEMPLATE_NAME，于是我们的写法就可以是现在这样：

现在试一下，是否公用目录里的header.html被加载了？

最后再报一个warning。如果是在WINDOWS下面开发并且开启了DEBUG_MODE，那么你在读取模版的时候，页面的Trace信息里，偶尔会出现一个注意：

这些信息，可以被忽略掉。模版文件还是会正常的生成和编译的。它只会在第一次生成模版编译文件的时候出现