大型系统架构简介.pdf

===================================================================== WEB 程序的架构基本上可以分成以下三类： (一) 基于“WEB页面/文件”，例如CGI 和PHP/ASP 程序。程序的文件分别存储在不同的目录里， 与URL 相对应。当HTTP 请求提交至服务器时，URL 直接指向某个文件，然后由该文件来处理请求，并 返回响应结果。 比如http://www.website.conm/news/readnews.php?id=1234 可以想像，我们在站点根目录的news 目录下放置一个readnews.php 文件。 这种开发方式最自然，最易理解，也是PHP 最常用的方式。要注意产生的URL 对搜索引擎不友好，不过 你可以用服务器提供的URL 重写方案来处理，例如Apache 的mod_rewrite。 (二) 基于“动作”(Action)。这是MVC 架构的WEB 程序所采用的最常见的方式。目前主流的WEB 框架像Struts、Webwork(Java) ，Ruby on Rails(Ruby),Zend Framework(PHP)等都采用这种设计。URL 映射到控制器(controller)和控制器中的动作(action)，由action 来处理请求并输出响应结果。这种设计和上 面的基于文件的方式一样，都是请求/响应驱动的方案，离不开HTTP。 比如/news/read/id/1234 可以想像在实际代码中，我们会有一个控制器newsController，其中有一个readAction。不同框架可能默 认实现方式稍有不同，有的是一个Controller 一个文件，其中有多个Action ，有的是每个Action 一个文件。 当然这些你都可以自己控制，题外话。 这种方式的URL 通常都很漂亮，对搜索引擎友好，因为很多框架都自带有URL 重写功能。可以自由规定 URL 中controller、action 及参数出现的位置。 另外，还有更直接的基于URL 的设计方案，那就是REST。通过人为规定URL 的构成形式（比如Action 限制成只有几种）来促进网站之间的互相访问，降低开发的复杂性，提高系统的可伸缩性。REST 对于Web Services 来说是一个创新。 虽然本文讨论的是单个项目所采用的架构，而REST 是为了解决网站之间的通讯问题，但REST 的出现， 会对单个项目的架构造成影响（很显然你在开发时就要构造规范的URL）。将来混用REST 和MVC 应该 也是一种趋势。RoR 提供很好的REST 支持，Zend Framework 也提供了Zend_Rest 来支持REST，包括 Server 和Client。 (三) 基于“组件” （Component ，GUI 设计也常称控件）、事件驱动的架构，最常 见的是微软的.NET。基本思想是把程序分成很多组件，每个组件都可以触发事件，调用特定的事件处理器 来处理（比如在一个HTML 按钮上设置onClick 事件链接到一个PHP 函数）。这种设计远离HTTP，HTTP 请求完全抽象，映射到一个事件。 事实上这种设计原本最常应用于传统桌面GUI 程序的开发，例如Delphi，Java Swing 等。所有表现层的 组件比如窗口，或者HTML 表单都可以由IDE 来提供，我们只需要在IDE 里点击或拖动鼠标就能够自动添 加一个组件，并且添加一个相应的事件处理器。 这种开发方式有几个优点： 复用性 -代码高度可重用。 易于使用 -通常只需要配置控件的属性，编写相关的事件处理函数。 我个人也挺喜欢这种方式，PEAR 就提供了相当强大的HTML_QuickForm，用于在页面添加表单元素及其 事件处理函数，还可以与Smarty 等模板引擎相结合。这对于项目开发来说是一个补充性的功能，在项目 中的某些部份使用QuickForm，有时可以大大加快开发。 而完全基于组件和事件驱动的开发框架对于PHP 来说也已经不新鲜，PRADO 就是一个这样的框架，曾经 得过Zend 编程大赛的头奖。但目前来说很显然Prado 所提倡的这种开发方式仍然没有被大部份PHP 程序 员所接受。为什么呢？ ============================================================================ 大型WEB 系统架构设计的总结 博客分类：  Java 相关 总结一下自己对大型WEB 系统架构设计的想法： 1. 一般大型W