模拟项目2007

序章

本故事纯属虚构，如有雷同，纯属巧合。

传说中人闲得无聊的时候总会下意识地找点什么事情做，而恰巧这段时间我正因为种种缘由处在这种状态之中。于是乎我便打算随便模拟个什么项目来练练手，让自己有聊些…再于是乎，故事由此开始。

Web2.0 仍作为一个囫囵吞枣的概念被国内的网络圈狂热地追捧着，所以项目俺就挑选了一个显得比较典型的视频网，也跟着赶赶时髦。而在人员配置上，为了让这么一个项目看起来更显得真实可信一些，我偷偷地拽上跟我同住的一个室友 —— 那是一个自诩而同时典型的设计师，请允许我这样称呼他 —— Y 。

于是乎我们两人组成了一个有着完整结构的团队，共同攻克这个如珠穆朗玛一般存在的视频网项目。需求分析、系统架构、主程序员和系统优化由我一并承担，同样 Y 也不得不肩负着用户体验设计、用户界面设计并实现、前台实现、黑白盒测试和客户沟通等同责。与客户沟通是一项涉及到民生的大事，毕竟客户才是我们的衣食父母。而对于更注重逻辑的我而言，要与客户华丽而优雅地交流，在体现出我们的专业的同时还要有艺术的热情，实在不是一件轻松的工作。

“ 食君之禄，忠君之事 ” ，让客户以更低廉的成本实现更高能的需求，是我们应该达成的准则。因此，我们应该尽可能地减少服务器数量和网络带宽的占用，同时尽可能地保持项目的可发展性。但是，用我们超人的智慧去帮客户扩展需求就大可不必了，这并不是一个明智的选择 —— 当然，尽可能地从安全和实用性角度去帮助客户精炼需求同时也优化用户体验，还是一个好员工所应该做的。不过过分地重视流量一直是中国网络圈的顽疾，哪怕是在 Web2.0 的华丽外表之下。所以如果客户对于优化用户体验并不热心的话，还是就此作罢得好。

在本章结束之前，顺便扯扯题外话。中国网络沉浮十余载，高脚达人无数。晚生年少轻狂，如若写得差错，欢迎给杂志投稿纠正，俺也顺带着更上层楼 ;-) 起始 一个项目的研发周期中，前一半应该都留给设计，后四分之一为测试和修补保留，真正留给开发的时间寥寥无几。因此，在动手之前，于设计时就尽可能地弄清楚所有潜在的问题是必须的。同时，为了让团队运转得更加高效一些，程序和美工两方面应该尽可能地并行，仅仅在开发时间的最后，做拼装时才会产生些许交集。当然了，要达成这样的一个目标并不是一件轻松的事情。不过幸而俺们才冒了一泡的 Y 有着一身不俗的前台能力，使本次模拟中的这个小小梦想有机会变成现实。

而视频网需要实现的基本功能不外乎以下几点：多媒体播放、包含了评论的扩展社区、好友、圈子和刺激用户的一系列榜单，即便是有所变化才只是客户的创意让这些点更亲密地联系起来。而在这次模拟中，需求自然是最为中规中矩的了。于是我们这个团队的两大巨头开始频繁碰头，商定数据取舍，同时在客户规定的关键用户体验基础上完善。

在商定结束后兵分两路，我拿着罗列的数据开始尝试设计程序结构。因为是视频网，大量的视频下载会是程序性能的最大瓶颈，所以必须在程序设计之初便需要考虑清楚视频的分布、命名和下载规则，而非在程序基本完成之后整体优化时才做这个工作。

预先使用多服务器分布视频，可以分解大量用户访问时的压力 —— 即便最初因为成本问题只允 许一台服务器存放视频，也可以在此服务器临近负载峰值时添加镜像。而不会因为最初设计上的短视，导致运转正常地网站被迫关闭以整修的方式再开发升级。当然，视频下载并非一时半会就能结束的事情，因此多台服务器提供下载服务也在情理之中。这样的规划只是让现有服务器群不再满足用户需要时，能及时地无缝扩展服务器。

使用特殊规则重命名上传的规则，让恶意用户和爬虫无规律可循，则是为了保障客户的利益。毕竟谁也不想自己辛辛苦苦整出来的成果被人剽窃。而俺们这个团队虽然小巧但同样精悍，也不希望被郁闷的客户大肆批评，使得一世英名毁于一旦。

下载规则的制定包括三个部分，一是多用缓存减少用户重复访问次数，这点主要是 RFC 中的一些 HTTP 头定义在起作用；二是尽量避免用户使用多线程下载，这点也还是由 HTTP 头定义操控；三是对视频的下载进行监控，需要的时候手动维护。

如何监控？又如何维护？在用户所能看到的活力 Top10 榜单基础上再扩展，让运营工作人员通过管理程序中的这份榜单，能够发现原来最火的十份视频中居然有三份在一台服务器 A 上！这还了得，赶紧勾选住其中一份视频，选择一台没有任何活力视频的服务器 B ，一个按钮点下去… OK ，这份视频被转移到使用率不高的服务器 B 中，而可怜的服务器 A 终于有点空可以擦擦汗喝口水了。

这些视频规则想清楚之后，就该设计数据库了。先遵循第三范式（ 3NF ）来上一遍，然后根据视频网的实际需要小小地逆反一下，目的在于让程序消耗在数据库上的时间和资源最小。如果客户告知了后继可能发展的话，在设计时也应该尽可能为后继发展留下空间。不过需要注意的是，如果涉及到比较冗杂地计算或排序时，最好在此时便将镜像表（无论物理表还是内存表）都设计好。具体到 MySQL 上，自然是大数据尽可能不入库，字符串类型字段尽可能使用 CHAR 而非 VARCHAR ，同时表类型尽可能为 FIXED 。

这些都做完了就去看看 Y 的进度咯…太好了！根据用户体验制作的用户界面范稿已经出来了，并且客户也认可了 =.= 这种情况如无意外限出现于本模拟及相关类似幻想中，如果你真碰到了…恭喜了，你该马上去烧柱香拜拜保佑你的财神老爷。

根据设计出来的数据字典建立对应的模型，当然还有为了效率而已破坏掉的部分，三下五除二罗列出来了扔给 Y ，让他拼出一份雍容华贵的设计文档交送客户过目 —— 自然也得在文档的排版布局上体现出本项目的风格特色出来 —— 虽然实际项目中这样做实在功夫深效果小，但本于精益求精的精神，其消耗的时间就忽略不计了。理所当然地，客户看到了这样一份在表现上堪称精典的设计文档，除了满意肯定不会有什么别的想法了。

前期设计工作至此就告一段落了，接下来就是重复劳动造代码的时间了。

高潮 在很久以前，俺因为想多多尝试多多锻炼而养成了什么都想自己写的偏执。后于猴年马月龙日虎时突然顿悟，尝试归尝试，做事时大可不必如此 —— 总不能哪天我自己买车再改时，拿张图纸自己做发动机吧…

所以除了 Smarty 和 Adodb （或 Creole ），像 Zend Framework 、 Prado 、 Cake 、 FleaPHP 等等，只要熟悉且无法律上的纠葛，大可以拿来做自己开发的基石。

考虑到只有自己这么一个苦力写代码，所以工作分解和排期就大可不必了，扎扎实实埋下脑袋狂敲键盘就是了。数据和逻辑模型、注释缺少的规则判断、单元测试、逻辑拼装，遵循这样一个过程即可。

幸而在俺的无赖加胁迫之下， Y 达人对 Smarty 颇为了解。因此白板测试页和正式用户界面模板的制作任务，就当仁不让地交给他老人家了。而无须天天在程序和美工之间展开殊死搏斗，讨论究竟谁才是模板的救世主。也是能者多劳嘛！

每完成一个部分的逻辑拼装，就由 Y 使用白板测试页做白盒测试。即这个部分我们需要达成什么目标，是否能够如预期实现。如果有问题，就在纸上列出问题和具体情况 —— 可怜兮兮的两个人，项目管理和错误管理自然是用不到了。而我自然是两耳不闻窗外事，一心只做苦力工了。

全部业务逻辑完成之后，额头上的 “ 奋 ” 字带尚未摘下的我如同杨白劳，对着错误列表一个一个的纠正。而新一代杰出黄世仁 —— Y 达人自然是每纠正一个就测试一个，通过了便换上正式的用户界面模板。当这些工作全部完成之后，程序员的噩梦时刻 —— 黑盒测试便来了。

Y 按照用户体验设计在已现雏形的网站上挖空心思搞破坏；而我则在出现规则判断缺失情况的时候，再埋头苦干填充之前注释但并未实现的判断规则。所以就出现了这样一幅场景 ——

我头戴 “ 奋 ” 字鬓插笔，眼睛透过空无一物的眼镜框死死地盯着俺心爱的 SyncMaster 940BW ，十指劈劈啪啪在 Zend Studio 里敲个不停，偶尔切换到单元测试页按按 F5 试试能否通过。而 Y 达人头戴耳机手端咖啡，身子还无规律地演示羊癫风症状，间或中断陶醉睁开双眼，小眼睛透过眼镜框给我深情一眼，直到我汗毛全体起立表示感谢再继续陶醉。

上苍保佑我！我还有权利在每部分单元测试完全通过后打断他的陶醉来释放俺胃中堆积的妒意。如此再三，到所有的单元测试通过，黑盒测试也通过时，俺终于平静下来了。

尾章 至此，项目程序终于搬到了正式服务器上，剩下的工作只是小小的调整和优化而已。苦难的日子终于要过去了，风雨过后见彩虹啊。

Y 疲于应付客户在界面和用户体验上的小修正和小要求；不过考虑到项目结束即将到来的钞票，我坚信他现在是幸福而快乐的。而我则舒舒服服地躺在靠椅里，悠闲着计算着可能会出现的压力和运算瓶颈，检查是否有需要缓存而并未设置缓存的地方。

一台服务器的运算能力是有限的，为了让服务器增强负载的能力，我们所能做的就是尽可能减少服务器的运算。而减少服务器运算的最佳方式，就是缓存。而生成静态页，也可以理解为暴露给最终用户的缓存。

至于搜索引擎优化 (SEO) ，如果搜索爬虫不抓 php 文件，俺把静态文件命名为 html ，而 php 文件命名为 htm 还不成么。独立的服务器，这样的设置并不是什么很困难的事情。不希望搜索爬虫抓到的文件在网站根目录下设置一个 robots.txt 就搞定了，也不怕误抓。

将运算量感觉颇大、运算频率并不算太高的公共内容统一缓存，将用户频繁访问的私有数据也统一缓存。用一定的延时换取数倍的效果还是很划算的，而且很多时候不是非常敏锐地用户也不会发现或者不会在乎这点延时。

怕服务器空间不够？没事，给客户解释清楚了不会小气的，硬盘总比服务器便宜吧…

或许网站访问量太高了以后用缓存也无济于事？还是没关系，设计的时候俺就考虑清楚了，缓存的读写都使用 UNC 路径，服务器不够使了加网站服务器就够了。

都缓存都静态文件了有变更如何？缓存本身只是概念上的思维，没钱的像俺这样写文件，有钱有条件的可以用独立的服务器做内存缓存。而且数据变更时可以创建缓存，用户访问时也可以生成缓存 —— 前者类似于推，后者类似于拉。合理的机制足以满足数据变更时页面表现的及时性要求。

而且还可以使用 AJAX 、 JSON 这样的理念将变化快的数据与页面分离开来，在用户端显示时再组装页面。

这些都做完了，最后再给客户打个电话 —— 买份 Zend Platform 给网站服务器装上吧，效果很显著的哦！虽然粗糙理解为免费的 Zend Optimizer 的收费威力加强版，但人家好歹是官方出品，类似于 .Net 运行时的思路，让程序可以在内存中停留时重组优化。

说 Zend Platform 有 10 倍加速之功效也不算夸张。一来这是真实有效的数据（俺偷偷问得啊，一般人我不告诉他），二来 PHP 中也确实存在一些使用上的陷阱，最典型的就是 foreach 了。

虽然俺自信自己对 PHP 还确实蛮了解的，但毕竟没接触过底层代码，不看 PHP 的 CHANGELOG 也很少知道居然还有这么些 bug 不是。所以程序中难免会出现低效的情况，如果是在访问频率很高的地方，大不就大大降低了程序能力。总体来说， Zend Platform 应该还是物有所值地。万一客户能耐，以打折的价格买到不是更赚！当然，如果能送我一份，这个世界就更美好了…残念啊，仅限于本文的 YY 。

终于这个项目结束啦，俺的模拟事业也暂告一段落，有机会松口气了。文末再点点题，小子狂妄，说得错了还往诸位多多海涵啊！汗一个，还往各位前辈斧正。