对于大流量、大并发量的网站系统架构来说，除 了硬件上使用高性能的服务器、负载均衡、CDN等之外，在软件架构上需要重点关注下面几个环节：使用高性能的操作系统（OS）、高性能的网页服务器 （Web Server）、高性能的数据库（Databse）、高效率的编程语言等。下面我将从这几点对其一一讨论。

　　操作系统

　 　Linux操作系统有很多个不同的发行版，如Red Hat Enterprise Linux、SUSE Linux Enterprice、Debian、Ubuntu、CentOS等，每一个发行版都有自己的特色，比如RHEL的稳定，Ubuntu的易用，基于稳定性 和性能的考虑，操作系统选择CentOS（Community ENTerprise Operating System）是一个理想的方案。

　 　CentOS（Community ENTerprise Operating System）是Linux发行版之一，是RHEL/Red Hat Enterprise Linux的精简免费版，和RHEL为同样的源代码，不过，RHEL和SUSE LE等企业版，提供的升级服务均是收费升级，无法免费在线升级，因此要求免费的高度稳定性的服务器可以用CentOS替代Red Hat Enterprise Linux使用。

LAMP网站架构图

　　Web服务器、缓存和PHP加速

　 　Apache是LAMP架构最核心的Web Server，开源、稳定、模块丰富是Apache的优势。但Apache的缺点是有些臃肿，内存和CPU开销大，性能上有损耗，不如一些轻量级的Web 服务器（例如nginx）高效，轻量级的Web服务器对于静态文件的响应能力来说远高于Apache服务器。

　　Apache做为Web Server是负载PHP的最佳选择，如果流量很大的话，可以采用nginx来负载非PHP的Web请求。nginx是一个高性能的HTTP和反向代理服 务器，Nginx以它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。Nginx不支持PHP和CGI等动态语言，但支持负载均衡和容 错，可和Apache配合使用，是轻量级的HTTP服务器的首选。

　　Web服务器的缓存也有多种方案，Apache提供了自己的缓存模 块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。Squid Cache是一个Web缓存服务器，支持高效的缓存，可以作为网页服务器的前置cache服务器缓存相关请求来提高Web服务器的速度，把Squid放在 Apache的前端来缓存Web服务器生成的动态内容，而Web应用程序只需要适当地设置页面实效时间即可。如访问量巨大则可考虑使用memcache作 为分布式缓存。

　　PHP的加速使用eAccelerator加速器，eAccelerator是一个自由开放源码PHP加速器，优化和动 态内容缓存，提高了性能PHP脚本的缓存性能，使得PHP脚本在编译的状态下，对服务器的开销几乎完全消除。它还有对脚本起优化作用，以加快其执行效率。 使PHP程序代码执效率能提高1-10倍。

　　具体的解决方案有以下几种：

　　1、squid + Apache + PHP + eAccelerator

　　使用Apache负载PHP，使用squid进行缓存，html或图片的请求可以直接由squid返回给用户。很多大型网站都采用这种架构。

　　2、nginx/Apache + PHP（fastcgi） + eAccelerator

　　使用nginx或Apache负载PHP，PHP使用fastcgi方式运行，效率较高。

　　3、nginx + Apache + PHP + eAccelerator

　　此方案综合了nginx和Apache的优点，使用Apache负载PHP，nginx负责解析其他Web请求，使用nginx的rewrite模块，Apache端口不对外开放。

　　数据库

　 　开源的数据库中，MySQL在性能、稳定性和功能上是首选，可以达到百万级别的数据存储，网站初期可以将MySQL和Web服务器放在一起，但是当访问 量达到一定规模后，应该将MySQL数据库从Web Server上独立出来，在单独的服务器上运行，同时保持Web Server和MySQL服务器的稳定连接。

　　当数据库访问量达到更大的级别，可以考虑使用MySQL Cluster等数据库集群或者库表散列等解决方案。

　　总的来说，LAMP架构的网站性能会远远优于Windows IIS + ASP + Access（例如月光博客）这样的网站，可以负载的访问量也非常大，国内的大量个人网站如果想要支撑大访问量，采用LAMP架构是一个不错的方案。

　　综上所述，基于LAMP架构设计具有成本低廉、部署灵活、快速开发、安全稳定等特点，是Web网络应用和环境的优秀组合。

    大型网站，比如门户网站。在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面，还没法根本解决大型网站面临的高负载和高并发问题。

    上面提供的几个解决思路在一定程度上也意味着更大的投入，并且这样的解决思路具备瓶颈，没有很好的扩展性，下面我从低成本、高性能和高扩张性的角度来说说我的一些经验 。

1、HTML静态化

    其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最 有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS ，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态 页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

    除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。

    同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中 论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储在数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部 分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。

2、图片服务器分离

    大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网 站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图 片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持，尽可能少的 LoadModule，保证更高的系统消耗和执行效率。

3、数据库集群和库表散列

    大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我 们需要使用数据库集群或者库表散列。在数据库集群方面，很多数据库都有自己的解决方案， Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决 方案来实施即可。

    上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且 最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功 能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架 构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统 随时增加一台低成本的数据库进来补充系统性能。

4、缓存

    缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。架 构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的 提高Apache的访问响应能力。

    网站程序开发方面的缓存，Linux上提供的Memory Cache是常用的缓存接口，可以在web开发中使 用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。另外，在使用web语言开 发的时候，各种语言基本都有自己的缓存模块和方法。

5、镜像

    镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和 EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现 成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具 。

6、负载均衡

    负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。

    负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。

硬件四层交换

    第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。第四层交换功能就象是虚 IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的 载量平衡算法。在IP世界，业务类型由终端TCP或UDP 端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。

    在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。

软件四层交换

    大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。

    软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满 足多种应用需求，这对于分布式的系统来说必不可少。

    一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成 本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。这样的架构我准备空了专门详细整理一下和大家探讨。

    对于大型网站来说，前面提到的每个方法可能都会被同时使用到，我这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会，有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大，希望大家一起讨论，达到抛砖引玉之效。

讨论大型高并发负载网站的系统架构问题，作者提出了几点建议：

1. HTML静态化，这可以通过CMS 自动实现；

2. 图片服务器分离（类似的，在视频网站中，视频文件也应独立出来）；

3. 数据库集群和库表散列，Oracle、MySQL等DBMS都有完美的支持；

4. 缓存，比如使用 Apache的Squid模块，或者是开发语言的缓存模块，；

5. 网站镜像；

6. 负载均衡。

    作者将负载均衡称为“是大型网站解决高负荷访问和大量并发请求采用的终极解决办法”，并提出“一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换 的基础上搭建squid集群”。在实践时可以考虑建立应用服务器集群和Web服务器集群，应用服务器集群可以采用Apache+Tomcat集群和 WebLogic集群等，Web服务器集群可以用反向代理，也可以用NAT的方式，或者多域名解析均可。

    从提升网站性能的角度出发，静态资源不应和应用服务器放在一起，数据库服务器也应尽 量独立开来。在典型的MVC模式中，由谁来完成数据逻辑处理的，对系统性能有着至关重要的影响。以Java EE为例，在OO的设计思想中，我们强调系统的抽象、重用、可维护性，强调下层的更改不会扩散到上层逻辑，强调系统移植的便捷性， 因而往往存在一种过分抽象的问题，比如在Hibernate的基础上再加入一层DAO的设计。另外一方面，却会忽视利用DBMS本身的优秀特性（存储过 程、触发器）来完成高效的数据处理。诚然，如果客户要求将数据从Oracle移植到MySQL，那么DBMS特性的东西越少，移植便越容易。但事实上，在 实践中，提出类似移植要求的情况非常少见，因此在做架构设计时，不一定为了这种潜在的需求而大幅牺牲系统的性能与稳定性。此外，我不建议采用分布式数据库 管理结构，这样带来的开销太大，数据维护也是个头痛的问题，尽可能采用集中式的数据管理。

    在商业系统中，算法逻辑本身并不复杂，在这种情况下，程序设计本身的好坏不会对系统的性能造成致命的影响。重要的影响因素反而变为软件系统架构本身。在传 统的CORBA、J2EE、DCOM等对象模 型中，我们看到专家们对分布式对象计算的理论偏好，但实践证明，对象的分布带来的恶劣影响远远胜过其积极意义。这也 是现在轻量级的开发框架受推崇的一个重要原因。如果能用简单的，就不要用复杂的，例如能够用Python、RoR完成的任务，是否一定要用Java来做？ 我看未必。对于用户来说，他们关心的不是采用什么先进的技术，而是我们提供的产品能否满足他的需求。而且，Python、RoR这些开发工具已经强大到足 以应对大部分网站应用，在各种缓存系统的帮助下，在其他技术的协调配合下，完全能够胜任高负载高并发的网站访问任务。

    在HTML静态化方面，如果是对于更新相对较少的页面，可以这样处理，例如新闻、社区通告、或者类似与淘宝网的产品分类信息。但若数据更新频繁，这样做的意义便不大。

    网站镜像是个传统的技术，更高级的应用来自流媒体领域的CDN(Content Delivery Network)，CDN的概念可以由流媒体数据扩展到图片、视频文件等静态资源的传输。不过，在电子商务领域，很少有这样的应用。

开源平台的高并发集群思考目前碰到的高并发应用，需要高性能需求的主要是两个方面:

1。网络

2。数据库

这两个方面的解决方式其实还是一致的

1。充分接近单机的性能瓶颈，自我优化

2。单机搞不定的时候(数据传输瓶颈:单位时间内磁盘读写/网络数据包的收发cpu计算瓶颈)，把负荷分担给多台机器，就是所谓的负载均衡

网络方面单机的处理

1。底层包收发处理的模式变化(从select 模式到epoll / kevent)

2。应用模式的变化

2.1 应用层包的构造方式

2.2 应用协议的实现

2.3 包的缓冲模式

2.4 单线程到多线程

网络负载均衡的几个办法

1。代理模式：代理服务器只管收发包，收到包以后转给后面的应用服务器群（服务器群后可能还会有一堆堆的数据库服务器等等），并且把返回的结果再返回给请求端

2。虚拟代理ip：代理服务器收发包还负载太高，那就增加多台代理服务器，都来管包的转发。这些代理服务器可以用统一的虚拟ip，也可以单独的ip

3。p2p：一些广播的数据可以p2p的模式来减轻服务器的网络压力

数据库(指mysql)单 机的处理

1。数据库本身结构的设计优化（分表，分记录，目的在于保证每个表的记录数在可定的范围内）

2。sql语句的优化

3。master + slave模式

数据库集群的处理

1。master + slave模式 （可有效地处理 并发查询）

2。mysql cluster 模式 （可有效地处理并发数据变化）

我们知道，对于一个大型网站来说，可伸缩性是非常重要的，怎么样在纵向和横向有良好的可伸缩性，就需要在做架构设计的时候考虑到一个分的原则，我想在多个方面说一下怎么分：

   首先是横向的分：

   1. 大的网站化解为多个小网站：当我们一个网站有多个功能的时候，可以考虑把这个网站拆分成几个小模块，每一个模块可以是一个网站，这样的话我们到时候就可以很灵活地去把这些网站部署到不同的服务器上。

   2. 静态动态分离：静态文件和动态文件最好分离开成2个网站，我们知道静态网站和动态网站对服务器来说压力的侧重不同，前者可能重IO后者重CPU，那么我们 在选择硬件的时候也可以有侧重，而且静态和动态内容的缓存策略也不一样。典型的应用，我们一般会有独立的文件或图片服务器。而且，使用不用的域名还可以提 高浏览器并行加载的能力。

   3. 按照功能来分：比如有一个模块是负责上传的，上传操作很消耗时间，如果和其它应用混在一起的话很可能，一点点访问就会使服务器瘫痪，这种特殊的模块应该分开。安全的不安全的也要分开，还需要考虑到以后SSL的购买。

   4. 我们不一定要全部用自己的服务器，搜索、报表可以依靠别人的服务，比如google的搜索和报表服务，自己做的不一定比得过别人，服务器带宽都省了。

   其次是纵向的分：

   1. 文件也相当于数据库，IO的流量可能比数据库还大，这也算是纵向级别的访问，上传的文件图片一定要和WEB服务器分开。当然，数据库和网站都放在一个服务器上的很少了，这是最基本的。

   2. 对于涉及到数据库访问的动态程序来说，我们可以使用一个中间层（所谓的应用层或逻辑层）来访问数据库（部署在独立的服务器上），最大的好处就是缓存和灵活 性。缓存的内存占用比较大，我们要把它和网站进程分开，而且这样做我们可以很方便的去改变一些数据访问的策略，即使到时候数据库有分布的话在这里可以做一 个调配工作，这样灵活性就很大了。还有好处是中间层可以做电线网通桥梁，可能网通访问双线再访问电信会比网通直接访问电信服务器快。

   有人说我不分，我可以做负载均衡，对，是可以的，但是如果分的话，同样的10台机器肯定比不分10台机器可以承受更多的访问量，而且对硬件的需求可能不 会很高，因为知道需要哪个硬件特别好。争取让每一个服务期都不空闲，又都不是太忙，合理进行组合调整和扩充，这样的系统伸缩性就高了，能根据访问量来调整 的前提就是之前有考虑到分，分的好处是灵活性、伸缩性、隔离性以及安全性。

   对服务器来说，我们有几点是要长期观察的，任何一点都可能是瓶颈：

   1. CPU：动态文件的解析需要比较多的CPU，CPU出现瓶颈就要看是不是哪个功能过长时间占用线程，如果是就分出去。或者就是每一个请求处理时间不长，但是访问量很高，那么就加服务器。CPU是好东西，不能让他干等，不做事情。

   2. 内存：缓存从IIS进程独立出去，一般对WEB服务器来说内存不够的情况不是很多。内存比磁盘快，要合理利用。

  3. 磁盘IO：用性能监视器找到哪些文件IO特别大，找到了就分到独立的一组文件服务器上去，或者直接做CDN。磁盘慢，大规模读取数据的应用靠缓存，大规模写入数据的应用可以靠队列来降低突发的并发。

   4. 网络：我们知道，网络的通讯是比较慢的，比磁盘还慢，如果是做分布式缓存，分布式计算的话，要考虑到物理服务器之间网络通讯的时间，当然，在流量大了以 后，这可以提高系统的接纳能力一个等级。静态内容可以借助CSD分担一部分，在做服务器假设的时候还要考虑中国特色的电信网通情况以及防火墙。

  对SQL SERVER数据库服务器来说：

   其实还是水平分割和纵向分割，一个二维表，水平分割就是横过来切一刀，纵向分割就是竖直切一刀：

   1、纵向分割就是，我们不同的应用可以分到不同的DB中，不同的实例中，或者说把某个拥有很多字段的表拆分成小表。

   2、横向分割就是，某些应用可能不负载，比如用户注册，但是用户表会非常大，可以把大表分开。可以采用表分区，数据存储在不同文件上，然后再部署到独立 物理服务器增加IO吞吐以改善读写性能，土一点的做法就是自己定期把老的数据存档。表分区的另外一个优势可以增加数据查询速度，因为我们的页索引可以有多 层了，就像一个文件夹中的文件不要太多，多分几层文件夹一样。

   3、还可以通过数据库镜像、复制订阅、事物日志，把读写分开到不同的镜像物理数据库上，一般来说够用，如果还不行可以用硬件来实现数据库的负载均衡。当然，对于BI，我们可能还会有数据仓库。

     架构上考虑到了这些之后，流量大了，就可以在这个的基础上再去调整或者做WEB服务器或者应用服务器的负载均衡。很多时候我们都是在重复发现问题-》找到瓶颈-》解决这个过程。

   典型的架构如下：

   动态WEB服务器配好点的CPU，静态WEB服务器和文件服务器磁盘好点
   应用服务器内存大点，缓存服务器也是，数据库服务器当然内存和CPU都要好

上次说的“分”是一个比较大的原则也是一个比较高层的原则，这次我想说一下其它两个原则：并与换。

并

    为什么要分？是因为我们希望通过分来提高系统的承载能力，那并又是并什么呢？我想了一下有几个方面可以并：

    1. 合并用户请求，最基本的就是合并CSS/图片/脚本，还可以合并页面。不过合并就可能产生流量的浪费，需要有一个平衡点。

   2. 合并接口的粒度，如果做分布式应用的话，我们可能不会直接访问数据库而是调用应用层提供的接口，由于是网络调用，代价比较大，因此在设计的时候尽量提供粒度比较粗的接口，一次调用返回比较多的数据，而不是细化到添加删除修改的层次。

   3. 合并接口的部署，对于频繁的跨机器调用可以考虑有一些数据冗余，把跨网络的服务编程进程间通讯，甚至转到客户端来做。比如论坛发贴时候脏词的过滤，直接调用应用层提供的接口（跨机器）是可以的，但是可能代价比较大，可以把这个接口使用IPC方式部署在本机。

换

    时间换空间，空间换时间是常见的做法，具体一点说：

    1. 缓存。缓存的重要性早计算机的硬件中就有重要的体现。对于网站，有很多种缓存，可以是客户端资源的缓存，可以是页面输出缓存，也可以是应用层的数据缓存， 目的都是一样的，或是减少了服务器请求次数，或是减少了请求的处理过程，或是减少了数据库的访问次数。当然，生成静态文件也可以算是一种缓存。不访问磁盘 固然不可能，但是我们要极大限度降低磁盘访问的机会。

   2. 有的时候为了获取极快的响应，我们还会不惜代价采用重复计算。比如，我们的某个操作很可能会由于网络问题等原因响应比较慢，在设计的时候可以有一个统一的 处理接口，由这个接口分发到不同的服务器去异步实现这个操作，哪个服务器先返回了结果我们就用这个结果，然后杀死其他服务器的冗余操作。

   3. 网站一般追求比较快的响应，一般不太会在比较高的层次用时间来换取空间，但是在一些用户独有数据的处理算法上可能还是会考虑到空间的节省问题。

   4. 有的时候我们会用一些聚合表来存放聚合数据，也就是进行一些预计算提高复杂计算（比如报表）的性能。当然，对于数据分析，构建多维数据库也是一种不错的选择。

    有很多网友留言说说的比较粗，没有什么具体的东西。我觉得架构这个东西很难去说具体怎么做，因为具体实施的时候要看情况去应用的，由于没有完美的东西，所 以做架构通常是去做一个平衡，很可能某一个侧重不同会影响到架构的实施。希望我的这些文章能给大家一个提示的作用，看了之后如果你觉得“这点我倒没有考虑 到，以后要注意”那或许就是最大的帮助了，下面我想说一些其它方面的问题，每一条都很零散，算是一个补充吧：

    1. 到底是采用已有的东西还是自己去做需要详细考虑的，采用别人的东西可能比较稳定，但是自己的控制少了一点，采用自己做的东西可以很灵活，但是可能会问题比 较多。不管怎么样，我们在采用一个第三方框架的时候务必要进行缜密的调查，看到他的不足，否则项目很可能在后期被这个框架制约，反之，决定自己去做一个框 架的时候也要看到自己需要什么其他框架不能提供的东西。

   2. 数据传输的时候可以做压缩，但要考虑到压缩解压缩需要CPU资源，在IO（磁盘，带宽，传输能力）和CPU之间有一个平衡的考虑。

   3. 理想的可伸缩性架构是可以自由增加或替换服务器，无需去停机维护或做很大的调整。在使用一个统一的调度中心来调度这些服务器，分配请求的时候，我们要考虑一下调度服务器能承受多少流量。

  4. 使用大量的廉价服务器还是少量的高配服务器？如何根据需求来组合服务器发挥最大作用。

   5. 对于分布式构架，我们尽量让每一个节点保持简单的逻辑，尽量减少同一层次节点之间的依赖，另外。需要有统一的地方来管理所有的节点。

   6. 功能分解、使用异步进行整合、故障转移、失效保护。

  7. 软件的架构升级和计算机硬件的架构升级很像，可能有一段时期，我们是在慢慢提高整体能力，2年也才提高了几倍，之后发现只有通过某种彻底的架构改变才能提高数十倍的能力，升级之后，我们或许又会遇到其他问题。就像CPU，是简单提高主频还是彻底更换架构。

   8. 数据方面，读写分离、数据库分隔、功能划分、缓存、镜像。

  9. 硬件网络上的架构很重要，但软件开发中的一些细节不可忽略，好的架构不意味着不需要代码审阅。

这里的大型网站架构只包括高互动性高交互性的数据型大型网站，基于大家众所周知的原因，我们就不谈新闻类和一些依靠HTML静态化就可以实现的架构 了，我们以高负载高数据交换高数据流动性的网站为例，比如海内，开心网等类似的web2.0系列架构。我们这里不讨论是PHP还是JSP或者.NET环 境，我们从架构的方面去看问题，实现语言方面并不是问题，语言的优势在于实现而不是好坏，不论你选择任何语言，架构都是必须要面对的。

这里讨论一下大型网站需要注意和考虑的问题

1、海量数据的处理

众所周知，对于一些相对小的站点来说，数据量并不是很大，select和update就可以解决我们面对的问题，本身负载量不是很大，最多再加几个 索引就可以搞定。对于大型网站，每天的数据量可能就上百万，如果一个设计不好的多对多关系，在前期是没有任何问题的，但是随着用户的增长，数据量会是几何 级的增长的。在这个时候我们对于一个表的select和update的时候(还不说多表联合查询)的成本的非常高的。

2、数据并发的处理

在一些时候，2.0的CTO都有个尚方宝剑，就是缓存。对于缓存，在高并发高处理的时候也是个大问题。在整个应用程序下，缓存是全局共享的，然而在 我们进行修改的时候就，如果两个或者多个请求同时对缓存有更新的要求的情况下，应用程序会直接的死掉。这个时候，就需要一个好的数据并发处理策略以及缓存 策略。

另外，就是数据库的死锁问题，也许平时我们感觉不到，死锁在高并发的情况下的出现的概率是非常高的，磁盘缓存就是一个大问题。

3、文件存贮的问题

对于一些支持文件上传的2.0的站点，在庆幸硬盘容量越来越大的时候我们更多的应该考虑的是文件应该如何被存储并且被有效的索引。常见的方案是对文 件按照日期和类型进行存贮。但是当文件量是海量的数据的情况下，如果一块硬盘存贮了500个G的琐碎文件，那么维护的时候和使用的时候磁盘的Io就是一个 巨大的问题，哪怕你的带宽足够，但是你的磁盘也未必响应过来。如果这个时候还涉及上传，磁盘很容易就over了。

也许用raid和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者新疆的访问速度如何解决?如果做分布式，那么我们的文件索引以及架构该如何规划。

所以我们不得不承认，文件存贮是个很不容易的问题

4、数据关系的处理

我们可以很容易的规划出一个符合第三范式的数据库，里面布满了多对多关系，还能用GUID来替换INDENTIFY COLUMN 但是，多对多关系充斥的2.0时代，第三范式是第一个应该被抛弃的。必须有效的把多表联合查询降到最低。

5、数据索引的问题

众所周知，索引是提高数据库效率查询的最方面最廉价最容易实现的方案。但是，在高UPDATE的情况下，update和delete付出的成本会高的无法想想，笔者遇到过一个情况，在更新一个聚焦索引的时候需要10分钟来完成，那么对于站点来说，这些基本上是不可忍受的。

索引和更新是一对天生的冤家，问题A，D，E这些是我们在做架构的时候不得不考虑的问题，并且也可能是花费时间最多的问题，

6、分布式处理

对于2.0网站由于其高互动性，CDN实现的效果基本上为0，内容是实时更新的，我们常规的处理。为了保证各地的访问速度，我们就需要面对一个绝大的问题，就是如何有效的实现数据同步和更新，实现各地服务器的实时通讯有是一个不得不需要考虑的问题。

7、Ajax的利弊分析

成也AJAX，败也AJAX，AJAX成为了主流趋势，突然发现基于XMLHTTP的post和get是如此的容易。客户端get或者post 到服务器数据，服务器接到数据请求之后返回来，这是一个很正常的AJAX请求。但是在AJAX处理的时候，如果我们使用一个抓包工具的话，对数据返回和处 理是一目了然。对于一些计算量大的AJAX请求的话，我们可以构造一个发包机，很容易就可以把一个webserver干掉。

8、数据安全性的分析

对于HTTP协议来说，数据包都是明文传输的，也许我们可以说我们可以用加密啊，但是对于G问题来说的话，加密的过程就可能是明文了(比如我们知道 的QQ，可以很容易的判断他的加密，并有效的写一个跟他一样的加密和解密方法出来的)。当你站点流量不是很大的时候没有人会在乎你，但是当你流量上来之 后，那么所谓的外挂，所谓的群发就会接踵而来(从qq一开始的群发可见端倪)。也许我们可以很的意的说，我们可以采用更高级别的判断甚至HTTPS来实 现，注意，当你做这些处理的时候付出的将是海量的database，io以及CPU的成本。对于一些群发，基本上是不可能的。笔者已经可以实现对于百度空 间和qq空间的群发了。大家愿意试试，实际上并不是很难。

9、数据同步和集群的处理的问题

当我们的一台databaseserver不堪重负的时候，这个时候我们就需要做基于数据库的负载和集群了。而这个时候可能是最让人困扰的的问题 了，数据基于网络传输根据数据库的设计的不同，数据延迟是很可怕的问题，也是不可避免的问题，这样的话，我们就需要通过另外的手段来保证在这延迟的几秒或 者更长的几分钟时间内，实现有效的交互。比如数据散列，分割，内容处理等等问题

10、数据共享的渠道以及OPENAPI趋势

Openapi已经成为一个不可避免的趋势，从google，facebook，myspace到海内校内，都在考虑这个问题，它可以更有效的留住 用户并激发用户的更多的兴趣以及让更多的人帮助你做最有效的开发。这个时候一个有效的数据共享平台，数据开放平台就成为必不可少的途径了，而在开放的接口 的情况保证数据的安全性和性能，又是一个我们必须要认真思考的问题了。

　　那么，这些人的问题和弱点体现在什么地方呢？从上面软件生产过程来看，每个阶段都对前面有所依赖， 在编程阶段出问题，追根溯源，问题无疑出在分析和设计阶段，分析设计作为一个软件产生的龙头，有着映射实际需求世界 到计算机世界这样一个拷贝任务，如何做到拷贝不走样，是衡量映射方法好坏与否的主要判断标准。

简单的mvc结构如下：

view层：显示层。

control层：业务层，集合了各种action。

model层：模型层，一般和数据打交道。简单的sample：一个表对应一个model类。

其中control层调用model层的方法，实现对数据的访问。

采用这样的结构在一定程度上，可以做到代码清晰，较容易扩展，代码的管理复杂度较低。

但是如果是业务很多，逻辑又很复杂的网站，如果再加上开发人员的水平参差不齐，那必然会导致下面的情况：

1 action中的代码越来越长，逻辑越来越复杂，不同action之间看起来有很多可以重用的代码， 但是真要进行重构的话，又非常困难。

2 model层中包含的方法越来越多，有些方法也过于复杂。甚至在不少方法中还包含了业务逻辑。

3 代码的修改，还是牵一发而动全身。

4 代码难以进行自动化测试。

本来以为引入了mvc，程序的管理复杂度问题就高枕无忧了，但现在又面临了相同的问题了。

以我最近的所学看，在mvc中再引入service层，可以在很大程度上避免或者缓解上述问题。

原有的mvc结构改成如下：

1 view层：显示层。

2 control层：业务层，集合了各种action。

3 service层。

4 DAO层。

原来的model层不见了，增加了service层和DAO层。DAO，即Data Access Object，数据访问接口，数据访问：顾名思义就是与数据库打交道。

在这个结构中，control不直接和DAO联系，

需要操作数据的时候，通过service层访问DAO层来实现。

service层做的事情，不仅仅是调用DAO操作数据，还会包含了一定的业务逻辑。整个程序的设计，也变成了针对服务进行设计。

这样做的好处是：

1 control层中的action得以精简，因为action中的一些逻辑，被重构成一个个的服务。而不同的action也可以重用服务了。

2 只负责和数据打交道的DAO层，相比之前的model层，也得以精简（DAO层尽量只做最原子的数据操作，不同数据操作之间的联系，这边不考虑，那是service层的事情）。

3 service层可以实现很大程度上的代码复用，程序的功能封装更清晰了。

4 由于service层更加清晰的定义了应用程序的边界，那么对于各个service函数（对应某个服务/应用），要做到自动化测试就方便多了。WEB程序如何做到能方便的进行单元测试，这是一直困扰我的难题，这样的设计似乎真的可行了~

5 开发人员的工作分配，理论上真的可以按层次划分了。只是理论上~

同时，这样的设计模式也是存在一定的缺点的：

层次太多，刚接触的开发人员理解起来比简单的mvc结构费时；

service层的设计需要一定的功力，因为action中和model层的逻辑在很大程度上转移到这里了。

但整体上看，service Layer的引入，更加清晰的定义了应用程序的边界，提供了一系列可以重用的操作集合。这对于网站的可扩展性和可维护性是非常有帮助的。

当然，如果网站的业务逻辑并不复杂，完全没必要用这样的设计。过度设计是万恶之源~

一、概述

类图（Class Diagram）是描述类、接口、协作以及它们之间关系的图，用来显示系统中各个类的静态结构。类图是定义其他图的基础，在类图基础上，可以使用状态图、协作图、组件图和配置图等进一步描述系统其他方面的特性。

类图包括7个元素：类（Class）、接口（Interface）、协作（collaboration）、依赖关系（Dependency）、泛化关系（Generalization）、关联关系（Association）以及实现关系（Realization）。

二、类

类定义了一组有着状态和行为的对象。其中，属性和关联用来描述状态。属性通常用没有身份的数据值表示，如数字和字符串。关联则用有身份的对象之间的关系表示。行为由操作来描述，方法是操作的实现。对象的生命期则由附加给类的状态机来描述。

1、 名称：类的名称是每个类中所必有的构成元素。

2、 属性（Attribute）

（1） 可见性：类中属性的可见性主要包括公有（public）、私有（Private）和受保护（Protected）。在UML中，公有类型的用“+”表达，私有类型用“-”表达，而受保护类型则用“#”表达。UML的类中不存在默认的可见性，如果没有显示任何一种符号，就表示没有定义该属性的可见性。

（2） 属性名：按照UML的约定，单字属性名小写。如果属性名包含多个单词，这些单词要合并，且除了第一个单词外其余单词的首字母要大写。

（3） 属性字符串。属性字符串用来指定关于属性的其他信息，例如某个属性应该是永久的。任何希望添加在属性定义字符串值但又没有合适地方可以加入的规则，都可以放在属性字符串里。

（4） 类属性。属性也可以作为一个类属属性来定义，这就意味着此属性被该类的所有对象共享。在类图中，类属性带有一条下划线。

3、 操作。类的操作是对类的对象所能做的事务的抽象，相当于一个服务的实现。

4、 职责：在操作部分下面的区域，可以用来说明类的职责。职责是类或其他元素的契约或义务。类的职责是是自由形式的文本，写一个短语，一个句子等。在UML中，把职责列在类图底部的分隔栏中。

5、 约束。说明类的职责是消除二义性的一种非形式化的方法，形式化的方法是使用约束。约束指定了该类所要满足的一个或多个规则。在UML中，约束是用一个花括号括起来的自由文本。

三、接口

接口包含操作但不包含属性，且它没有对外界可见的关联。

四、类之间的关系

类之间的关系最常见的有四种：依赖关系、泛化关系、管理关系、实现关系。

1、 依赖关系（Dependency）

依赖表示两个或多个模型元素之间语义上的关系。它表示了这样一种情形，对于一个元素（提供者）的某些改变可能会影响或提供消息给其他元素（客户），即客户以某种形式依赖于其他类元。根据这个定义，关联、实现和泛化都是依赖关系，但是它们有更特别的语义。在UML中，依赖用一个从客户指向提供者的虚箭头表示，用一个构造型的关键字来区分它的种类。

UML定义了4种基本依赖类型，分别是使用（Usage）依赖、抽象（Abstraction）依赖、授权（Permission）依赖和绑定（Binding）依赖。

（1）、使用依赖。使用依赖都是非常直接的，通常表示客户使用提供者提供的服务以实现它的行为。以下列出了5种使用依赖关系.

（2）、抽象依赖。抽象依赖用来表示客户与提供者之间的关系，依赖于在不同抽象层次上的事物。

（3）、授权依赖。授权依赖表示一个事物访问另一个事物的能力。提供者通过规定客户的权限，可以控制和限制对其内容访问的方法。

（4）、绑定依赖。绑定依赖是较高级的依赖类型，用于绑定模板以创建新的模型元素。

2、泛化关系（Generalization）

泛化关系是一种存在于一般元素和特殊元素之间的分类关系，它只使用在类型上，而不是实例上。在类中，一般元素被称为超类或父类，而特殊元素被称为子类。在UML中，泛化关系用一条从子类指向父类的空心三角箭头表示

3、关联关系（Association）

关联关系是一种结构关系，它指明一个事物的对象与另一个事物的对象之间的联系。也就是说，关联描述了系统中对象或实例之间的离散连接。在UML中，关联关系用一条连接两个类的实线表示

关联关系有6种对应的修饰，它们分别是：名称、角色、多重性、聚合、组合和导航性。

（1）、名称（Name）。名称用来描述关联的性质，通常使用一个动词或动词短语来命名关联。名称以前缀或后缀一个指引阅读的方向指示符以消除名称含义上可能存在的歧义，方向指示符用一个实心的三角形箭头表示。

（2）、角色（Role）。角色是关联关系中一个类对另一个类所表现出来的职责。角色名称是名词或名词短语，以解释对象是如何参与关联的。

（3）、多重性（Multiplicity）。约束是UML三大扩展机制之一，多重性是其中使用最广泛的一种约束。关联的多重性是指有多少对象可以参与该关联，多重性可以用来表达一个取值范围、特定值、无限定的范围或一组离散值。

（4）、聚合（Aggregation）。聚合关系表示整体和部分关系的关联。聚合关系描述了“has a”的关系。在UML中聚合关系用带空心的实线来表示，其中头部指向整体。

（5）、组合关系(Composition)。组合关系是聚合关系中的一种特殊情况，是更强形式的聚合，又被称为强聚合。在组合中，成员对象的生命周期取决于聚合的生命周期，聚合不仅控制着成员对象的行为，而且控制着成员对象的创建和析构。在UML中，组合关系用带实心菱头的实线来表示，其中头部指向整体。

（6）、导航性(Nevigation)。导航性描述的是一个对象通过链（关联的实例）进行导航访问另一个对象，即对一个关联端点设置导航属性意味着本端的对象可以被另一端的对象访问。可以在关联关系上加箭头表示导航方向。只在一个方向上可以导航的关联称为单向关联(Unidirection Association),用一条带箭头的实线来表示。在两个方向上都可以导航的关联称为双向关联(Bidirection Association),用一条没有箭头的实线来表示。另外使用导航性可以降低类之间的耦合度，在也是好的面向对象分析与设计的目标之一。

4、实现关系（Realization）

实现是规格说明和其实现之间的关系，它将一种模型元素与另一种模型元素连接起来，比如类和接口。

泛化和实现关系都可以将一般描述与具体描述联系起来。泛化将同一语义层上的元素连接起来，并且通常在同一模型内。实现关系则将不同语义层内的元素连接起来，通常建立在不同的模型内。

实现关系通常在两种情况下被使用：在接口与实现该接口的类之间；在用例以及实现该用例的协作之间。

在UML中，实现关系的符号与泛化关系的符号类似，用一条带指向接口的空心三角箭头的虚线表示。下图所示的是实现关系的一个示例，描述的是Keyboard保证自己的部分行为可以实现Typewriter的行为

实现关系还有一种省略的表示方法，即接口表示为一个小圆圈，并和实现接口的类用一条线段连接，如图

类图建模技术

一、对简单协作建模

类不是单独存在的，而是要与其他类协同工作。协作是动态交互在静态视图上的映射，协作的静态结构通过类图来描述。

对协作建模要遵循如下策略

1、识别要建模的机制。一个机制描述了正在建模的部分系统的一些功能和行为，这些功能和行为是由类、接口和一些其他元素的相互作用产生的。

2、对每种机制，识别参与协作的类、接口和其他协作，并识别这些事物之间的关系。

3、用协作的脚本检测事物，通过这种方法可以发现模型中被遗漏的部分和有明显语义错误的部分。

4、把元素和它们的内容聚合在一起。对于类，首先平衡好职责，随着时间的推移，将它们转换成具有的属性和操作。

二、对逻辑数据库模式建模

通用的逻辑数据库建模工具是“实体-关系（E-R）”图，传统的E-R图只针对数据，而UML的类图还允许对行为建模。在物理数据库中，类图一般要把逻辑操作转化成触发器或存储过程。

对模式建模要遵循如下策略：

1、在模型中识别的类，其状态必须超过其应用系统的生命周期。

2、创建包含这些类的类图，并把它们标记为永久（persistent）。对于特定的数据库细节，可以定义自己的标记值集合。

3、展开这些类的结构性细节，即详细描述属性的细节，并注重于关联和构造类的基数。

4、观察系统中的公共模式（如循环关联、一对一关联和n元关联），它们常常造成物理数据库设计的复杂化。

5、考虑这些类的行为，扩展对数据库存储和数据完整性来说重要的操作。一般情况下，与对象集的操作相关的业务规则应该被封装在永久类的上一层。

三、正向工程和逆向工程

1、正向工程（Forward Engineering）

正向工程是通过实现语言的映射把模型转换为代码的过程。由于UML中描述的模型在语义上比当前的任何面向对象语言要丰富，所以正向工程会导致一定信息的损失，这也是需要模型的原因。

对类图进行正向工程，要遵循如下的策略

(1)、识别映射到所选择的实现语言的规则

(2)、根据所选择的语言的语义，可能会限定一些对UML特性的使用

(3)、用标记值详细描述目标语言，若需要精确的控制，该操作可以在单个类的层次上进行，也可以在较高的层次(如协作或包)上进行

(4)、使用工具对模型进行正向工程

2、逆向工程（Reverse Engineering）

逆向工程是通过从特定实现语言的映射，把代码转换为模型的过程。逆向工程会导致大量的冗余信息同时逆向工程又是不完整的。

对类图进行逆向工程，要遵循如下的策略

(1)、识别从实现语言或所选的语言进行映射的规则

(2)、使用工具，指向要进行逆向工程的代码，用工具生成新的模型或修改以前进行正向工程时已有的模型。

(3)、使用工具，通过查询模型创建类图。

对象图

一、概述

对象图(Object Diagram)描述的是参与交互的各个对象在交互过程中某一时刻的状态。对象图可以被看作是类图在某一时刻的实例。

在UML中，对象图使用的是与类图相同的符号和关系，因为对象就是类的实例。下图显示了对象图的模型。其中节点可以是对象也可以是类，连线表示对象之间的关系：

二、类图和对象图的区别

对象图建模技术

一、对对象结构建模

对系统的设计视图建模时，可以使用一组类图完整地描述抽象的语义以及它们之间的关系。但是使用对象图不能完整地描述系统的对象结构。对于一个个体类，可能存在多个实例，对于相互之间存在关系的一组类，对象间可有的配置可能是相当多的。所以，在使用对象图时，只能在一定意义上显示感兴趣的具体或原型对象集。这就是对对象结构建模，即一个对象图显示了某一时刻相互联系的一组对象。

对对象结构建模，要遵循以下策略：

(1)、识别将要使用的建模机制。该机制描述了一些正在建模的部分系统的功能和行为，它们由类、接口和其他元素的交互而产生。

(2)、对于各种机制，识别参与协作的类、接口和其他元素，同时也要识别这些事物之间的关系。

(3)、考虑贯穿这个机制的脚本。冻结某一时刻的脚本，并且汇报每个参与这个机制的对象。

(4)、按照需要显示出每个对象的状态和属性值，以便理解脚本。

(5)、显示出对象之间的链，以描述对象之间关联的实例。

二、正向工程和逆向工程

1、正向工程

对对象图工程进行正向工程在理论上是可行的，但是在实际上却是受限制的。

2、逆向工程

对对象图进行逆向工程是非常困难的。当对系统进行调试时，总要依靠开发人员或工具来进行。

这篇文章对那些还没有安装或使用过TFS的人将最有帮助。TFS有对复杂环境的良好支持。比如，报表，SharePoint的整合，支持跨多域，分布式数据库等等。不过我不打算在这里讲述其中的任何一个部分，我的目的是帮助你们了解为什么我们要选择TFS，以及如何使用它。如果你是VSS的用户， 在今后的文章中，我会讲述如何将VSS数据库迁移到TFS上。

在上图中，每个系统都有独立的存储空间，资源标识集，命令和工具集。要让整个系统工作起来，就像把一组自定义立体组件联接在一起：可以实现，但工作量巨大，而且可能在一些地方出现纰漏。

我更想要的就是这样一个系统，它可以将这些工作整合到一起并实现我默认的工作流程。

这个整合实现了一些非常常见的场景。例如每天我会编辑源代码，生成产品并测试它，报Bug并修复它，周而复始。当有一个整合的系统可以全部支持这些工作流程时，那么所有的工作就可以被关联起来。例如，当我签入Bug的修复时，我很想看到那些缺陷被解决时这个变更集能被纪录下来。（详见下面的例子）

TFS的基础配置可以让你精确地做到这些。这跟简单的源码管理相比是一个巨大的进步。TFS的完整版将会加入一些新的特性，包括自动化测试，虚拟实验室的部署和架构验证。下面是扩展后的工作流程：

当你使用Visual Studio 加强版和旗舰版的时候，你可以根据需要选择安装这些新组件。

有许多方法可以访问TFS。开发人员经常会通过Visual Studio来访问它。测试人员可以通过新的Test and Lab Manager来访问TFS（没有必要安装VS）。如果你是项目经理，你也可以通过web接口，Excel，Microsoft Project，或者dashboards的MOSS支持（VS2010的新功能）来访问TFS。更多相关内容以后介绍。

在这篇文章的其余部分，我会向你们逐步介绍如何使用基础配置来开始我们的第一个TFS工程。

入门指南

现在, 有了概念层次的了解，是时候把它们连接起来了。以Brian Harry的 TFS文章所列出的步骤为开端。所有必要的软件会以默认集合（创造性的称为DefaultCollection）的形式安装到你的机器上。

在这里我们能通过Visual Studio连接到TFS里。做到这一点最简单的方法是使用菜单“团队”（你也可以使用起始页上的链接）：

这里需要输入TFS的服务器名称。例如，我的Windows 7机器：JLZB2REL。通过添加按钮把服务器加入到列表里， 然后点击关闭：

在这里，你可以从组合框里选择服务器，接着选择DefaultCollection，然后点击连接：

现在团队资源管理器选项卡有了服务器连接和DefaultCollection，但我们还没有一个可以存储东西的TFS项目：

我为本教程创建了一个新的Windows窗体项目作为我们的解决方案样本（文件，新建项目，Windows窗体）。如果你试图添加新的代码项目到源代码管理，会出现错误。例如：

你选择“将解决方案添加到源代码管理”菜单项后，你会得到“没有可用的团队项目源代码管理文件夹”的错误信息：

该错误不是很直观（特别是所提供的词项目是用于TFS和你们代码解决方案里面，而它们是不同的概念）。此错误的意思是你必须创建一个真实的TFS项目去包含你工作中有用的资源。在团队资源管理器中，右键点击你的集合，选择新建团队项目：

在这里我将为应付帐款系统创建一个TFS项目。该项目将包含整个系统所有需要的解决方案，数据等。填写完资料，点击下一步:

默认的是Agile模板，但你也可以选择CMMI模板。关于模板类型你可以在MSDN上获取更详细的说明。如果你正在使用agile方法（比如TDD），这是个不错的选择。选择后，点击完成。

项目创建过程中，会有各种状态更新。

成功后，点击关闭按钮：

团队资源管理器显示了该项目，将包含工作项，生成和源代码管理：

此时可以更新项目集合。再增加一个解决方案到TFS中：右击解决方案资源管理器中的项目，选择“将解决方案添加到源代码管理”：

此时可以在TFS中为解决方案新建一个文件夹或者只是采用默认值。如果准备好了，请点击确定。

到此就可以在解决方案资源管理器中看到所有文件已经在源码管理下了。（查看文件前面的“+”号）

此时可以看到列出的源代码管理器可采取的公开解决方案的动作。添加注释然后点击签入：

点击是确认签入。

此时新的解决方案就在TFS中了，并且可以开始工作项了。

工作项

可以直接在Visual Studio里用团队资源管理器或者通过网页前端和Test and Lab Management工具 来创建工程项目。打开团队资源管理器，并展开工作项下的Team Queries项来浏览你的工程项目。也可以通过双击任意查询选项（例如Active Bugs）来浏览任意你所能看到的项目。

因为我们的TFS工程是空的，所以在列表中没有active Bug。

创建一个新的bug，选择菜单：团队，新建工程项。这里可以创建多种工作项来跟踪功能点，缺陷等等。选择Bug继续：

为这个新的Bug填入相关资料，然后点击保存工程项来提交到数据库中。

如果现在刷新Active Bug查询列表，你会看到这个新的Bug：

现在添加一个真正的Bug来修复我们的工程。在我的例子中，只是创建了一个默认的Windows Forms应用程序。如要更新标题：

现在我们需要修复这个Bug。重新回到解决方案资源管理器，选择Form1.cs，然后选择“签出以进行编辑”：

点击“签出”按钮来确定：

现在在文件的旁边会有一个打勾的标记，这样你就知道它已经可以编辑了：

当你更新主窗口的Text属性时，VS会自动签出任何依赖的文件：

这个例子虽然是一个Windows Forms应用程序，但它也支持其他所有的solution/project类型。现在我们对代码改动满意了，在VS的底部选择“挂起的更改”标签。

在这个例子中，我们修复了一个Bug，所以点击“工作项”图标按钮：

选择用来跟踪我们标题错误的Bug#6。我们想要通过这个签入来解决它：

添加注释并点击签入，然后点击“是”确认。

如果刷新Bug#6，你会看到现在状态已经变为Resolved，并且历史纪录已经更新了。

请注意“变更集”（源码管理改变的集合）已经被自动添加到历史纪录中。

这时候可以按你工程需要继续创建和修复Bug。

其他访问TFS的方法

我前面提到过没必要必须使用VS来访问TFS。我们已经将TFS与其它客户端作了许多深层次的整合，例如网页和Office。举个例子，我可以通过网页浏览器，很简单地用服务器的名字连接到我的服务器（8080是默认端口）：http://jlzb2rel:8080/tfs/

现在我可以浏览我的集合和工程了。如果你选择我们刚刚新建的AccountsPayable项目，然后点击“继续”按钮，会看到更多的信息。在这个例子中，通过导航到Work Items标签，可以找到这个系统中所有的Bug。

这确实是一个浏览你的工程的简单方法。可以在任何一台电脑上，并且不需要安装额外的东西。这些操作在Excel，Microsoft Project等其他软件中也有相关的支持。这种访问方式使该项目中的所有成员一起工作变得更加简单。

此时，你拥有了一套非常有用的工具来轻松完成工作。如果你在使用VSS，仅仅是这些内容就已经令人兴奋了。现在可以放下这个教程，休息会再回来，如果你想要尝试一些高级属性的话，例如测试场景。我会使用beta 1在这个教程中来演示。

生成支持

工作流程的下一个典型的环节就是自动生成产品。如果遵循Brian的安装说明，那么现在你的机器上就有了TFS基本的本地生成支持。第一步是要导航到团队资源管理器中，右键点击“所有生成定义”，选择“新建生成定义”：

有一系列的定义需要填，就像一个代码项目的属性页：

触发页面使我们能够决定生成何时开始。你可以从下列项中选择：

·默认情况下使用手动项。我们必须以这一项开始我们自己的生成。

·每一次签入后，当你想拥有一个新的生成的时候，持续集成是非常有用的。它允许你立刻验证新的签入而不用等很多的签入混合在一起后再验证。

·滚动生成提供了一种批处理改变的方法，当开始生成要花一点时间并且你无法去做每一项时，这种方法很便利。

·封闭签入让你确保所有的签入传入TFS前被生成。并确保你不会对你项目组的其它成员造成生成破坏。

·计划生成为整个团队做每日生成进行了有益的尝试

可以创建和使用多个不同的生成定义，允许您根据不同的目的来使用不同类型的生成。

你可以在空闲的时候查看所有标签(每一项在产品上都完整的文档说明). 但是我们需要提供给生成一个存储新生成的位置来解决默认生成中的黄色警告标志，在这里，我在我的机器上创建了一个公共的UNC：

现在可以保存生成定义到TFS。如果回到团队资源管理器，我们可以“使新的生成入队”：

在跳出的确认对话框中，选择排队：

这是我机器上状态页显示的已排队的一个生成：

如果双击队列中的生成，可以得到这个生成的详细状态：

从这里你可以看到警告和错误，日志文件，导航到Drop的目录等。例如，如果你选择“查看日志文件”，你能看到执行生成的脚本（子集）：

如果你选择打开Drop文件夹链接，你会被带到我们drop的位置：

现在任何人都可以选择生成来做他们日常测试，或发布给客户等。

此时您已经知道利用了TFS的基本配置所有东西。

将来我会做一个如何安装使用虚拟实验室系统的教程（Visual Studio 旗舰版的一部分），使您能够部署复杂的应用程序到Hyper - V的环境，做自动化测试。

创建一个新的TFS集合

 [注意：这部分是完全可选的] 如果你喜欢你可以在一个TFS中存储你所有的工作。如果你是一个Visual Source Safe用户，你可以跳过这一整部分。但是如果你想创建一个新的顶级集合，相当的简单。第一步是启动，然后是团队基础管理控制台：

控制台启动后，选择“团队项目集合项”， 点击“创建团队项目集合”链接：

为项目的收集填写一个你想要描述的名称后，点击“下一步”：

接受数据层的默认值，然后点击“下一步”：

TFS基本配置不支持实验室管理，因此直接下一步：

在这里所有需要的数据都被配置了，你可以选择“核实”：

验证这些信息主要是为了集合可以顺利的创建：

当核实结束后，点击创建：

这一步为TFS的每一个配置提供所有需要的东西。点击下一步就完成了：

你将会看到一个默认版本的新项目集：

   features目录存放特性，plugins目录存放插件。接下来介绍一下如何安装插件。 

一、直接安装法
    直接安装最简单，第一种就是将下载的plugin直接拷贝到eclipse的plugin目录下。第二种是在help->software updates->find and install中找到插件并安装。这类方法虽然简便，但是缺点也十分明显。两种方法的实质都是将插件拷贝到eclipse的安装目录中一旦copy过去，插件本身就不可能再复用，且各种插件混杂在一起，不利于插件的管理。

二、Manage Configuration法
    将插件存储在eclipse外部，可以使几个版本的Eclipse同时使用插件，也方便插件管理，所以我推荐这种插件安装方式。具体操作如下：
    首先，在插件所在的eclipse目录下创建名为.eclipseextension的文件。如，我要安装EMF的插件，以下是我建立的扩展文件：

 

三、Link法
    如果我们在插件的eclipse目录中创建了.eclipseextension文件（方法和位置同二），我们还可以在Eclipse的安装目录下建一个文件夹，名为links。在这个目录中，我们可以创建*.link（文件名任意）。扩展名为link的文件应该如下配置：

path=d:\\plugins\\emf

    在windows下，注意要双写反斜杠。指向的目录要是插件的根目录。（如上面：emf目录下应该有eclipse目录）在启动时，Eclipse会自动监测links目录。
    总结：Eclipse的插件安装方法大致可以分为三种，分别是直接安装，通过Manage Configuration安装，利用Links进行安装。其中，我推荐后两种插件安装方法，灵活且便于管理。

四、向导安装
      第四种方法也很简单，它主要借助于Eclipse的向导来安装插件。通过Help/Software Updates/Find and Install，在弹出的菜单中选择“Search for new features to install”，点“Next”，在下一菜单中选择“New Local Site”或“New Archived Site”，找到你下载的插件所在目录，选中安装即可。 这种方法安装插件比较安全，不易出错，缺点就是对于插件的要求也比较挑剔，所以能够支持这种方式安装的插件也比较少。一般要求插件目录下不光有plugins和features文件夹，还要有site.xml文件（site.xml是进行自动安装的配置文件，eclipse会根据文件的信息自动安装插件）。支持J2ME开发的EclipseME插件就是通过这种方式安装的。


注释：

eclipse3.5与以前的目录结构不一样，它没有links目录,代替links目录的是dropins目录。

一、建立一个link文件里面用path=插件安装位置.

二、把link文件放到dropins中.

三、把插件里面的stie.xml文件删除掉.

重新启动eclipse即可.

    参考文章：IBM中国《管理Eclipse环境》，《Managing plugins in eclipse》。

常言笑 2010-09-08 16:19 发表评论

]]>

不管是面向对象，还是面向过程，都需要分成许多的块，然后由这些部件协同工作完成任务
要协同工作就会产生依赖，一个方法调用另一个方法，一个对象包含另一个对象
如果对象A包含对象B的话，就需要在A里new一个B
依赖注入从具体类B里抽象出接口IB——IB的具体实现可能有很多B,B1,B2…很多种——这样A可以不用再new具体的B了，而是跟IoC容器说：我要一个IB（getBean("IB")）。然后，由容器根据配置文件来做具体的new的工作。具体new的是哪个，由配置文件从代码外部决定，要更换成B,B1,或是B2…修改配置文件就能做到，不用再改代码了

例：
假设你编写了两个类，一个是人(Person)，一个是手机(Mobile)。
人有时候需要用手机打电话，需要用到手机的dialUp方法。
传统的写法是这样:

//code
public class Person{ 
    public boolean makeCall(long number){ 
        Mobile mobile=new Mobile(); 
        return mobile.dialUp(number); 
    } 
}

//code
public Interface MobileInterface{ 
    public boolean dialUp(long number);
}

//code
public class Person{
    private MobileInterface mobileInterface;
    public boolean makeCall(long number){
        return this.mobileInterface.dialUp(number);
    }
    public void setMobileInterface(MobileInterface mobileInterface){
        this.mobileInterface=mobileInterface;
    }
}

//code
<bean class="Person" id="person">
     <property name="mobileInterface">
         <ref local="mobileInterface"></ref>
     </property>
</bean> 
<bean class="Mobile" id="mobileInterface"></bean>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

是的，这里有HTML和XHTML，也有Transitional和Strict之分。顾名思义，XHTML是指这个文档是按照XML的格式来书写的，而HTML则表示这个文档是按照HTML的格式来书写的。Transition则表示这个文档达到了Transitional.dtd或者loose.dtd的要求，Strict则表示这个文档达到了strict.dtd的要求。但事实上我们经常会存在以下的误解：
(1) 我的文档是声明为XHTML的，则我的文档肯定完全按照XML的格式。
(2) 我的文档是声明为Strict的，则我的文档肯定是按照Strict Mode的方式来Render的，反之，是以Quirks Mode的方式来Render的。

这两种理解都很直接，然而却是错误的，我们也经常会犯这种的错误。

首先，文档声明为XHTML和HTML，和文档的Parse(即浏览器对文档的分析)是没有直接关联的。事实上，浏览器如何Parse文档取决于服务器以什么格式来提供这个文档。通常情况下，有两种方式，"text/html"和"application/xhtml+xml"。只有以"application/html+xml"方式来提供的文档才能够被按照XML的方式来Parse。然而，因为浏览器的历史原因，并不是所有的浏览器都支持"application/xhtml+xml"格式的文档，IE7之前的版本(包括IE7)就不能够支持这种格式，如果IE7碰到这种格式的文档，它会提示用户另存为其它文件。考虑到IE使用的广泛性，目前绝大部分的文档都是以"text/html"的方式来提供的。以"text/html"方式来提供的文档是按照HTML的语义来Parse的，大家都知道HTML的容错性是非常强的，即使你的文档里面的TAG没有正确地关闭，这个HTML也能够被正确地显示出来。因此如果你的XHTML是以"text/html"的方式来提供的(绝大多数情况下都是)，那么你即使在DOCTYPE里面声明了XHTML，你的文档也不是以XML的格式来Parse的，因此也不能保证你的文档是严格按照XML的规范的。事实上，很多专家都建议如果你的文档不是以"application/xhtml+xml"的方式来提供的，那么你就应该声明为HTML。

其次，浏览器以什么样的方式来Render你的文档，并不以你声明的DTD来决定的。事实上，如果你声明了DOCTYPE和DTD，你的文档就是以Strict Mode(或者称为Standard Mode，很多浏览器还包括Almost Standard Mode的方式，这里不进行区分)方式来Render的。对于没有DOCTYPE的文档，才是以Quirks Mode方式来Render的。因此浏览器的Render模式和你声明的DTD并没有直接的关系。

最后，你声明为Strict.dtd还是Transitional.dtd，在目前的浏览器看来是没有什么区别的。Strict.dtd比Transitional.dtd或者loose.dtd要严格多了，很多元素在strict.dtd里面都不能使用。然而因为浏览器的兼容性，即使你在DOCTYPE里面声明了Strict.dtd，浏览器遇到strict.dtd里面不允许的元素，也还能够正确地显示你的文档。我猜测浏览器并没有将DTD考虑进去。例如iframe这个TAG在strict.dtd里面并不存在，但即使你的DOCTYPE里面声明了strict.dtd，然后使用了iframe这个TAG，浏览器(包括IE7，IE8，FF3.0，Safari 3.0)都能够正确地显示你的文档。浏览器并没有按照你声明的DTD来Parse你的文档。目前能够保证你的文档是符合strict.dtd还是Transitional.dtd的，只能通过一些网上的Validator，如W3C Validator来分析，浏览器并不能够给你很好的支持。当然，实际上如果你能够严格按照你声明的DTD来书写你的文档，那是最好的，这样保证了以后浏览器对DTD严格遵守的时候，你的文档不会产生错误。

因此，

(1) 如果你的文档是以"text/html"的方式来提供的，那么你就应该声明为HTML。假如你想要让IE7能够正确地显示，那么你就更应该这么做了。
(2) 如果你的文档声明为XHTML，那么你应该以"application/html+xml"的方式来提供。
(3) 尽量在你的文档前面声明DOCTYPE和DTD，这样能够保证你不是以Quirks Mode的方式来Render文档的。
(4) 如果你声明了DTD，那么就要严格按照DTD的要求来书写你的文档。特别是如果你声明了Strict.dtd，那么你应该注意哪些元素是不能够使用的。

注意：本文发布于2008.5.20。随着时间的发展，浏览器对HTML和XHTML，Strict.dtd和Transitional.dtd的支持会更好。如果你的浏览器比IE7, IE8, FF 3.0和Safari 3.0要高很多很多的版本，那么你要注意本文的适用性。

    概要设计就是设计软件的结构，包括组成模块，模块的层次结构，模块的调用关系，每个模块的功能等等。同时，还要设计该项目的应用系统的总体数据结构和数据库结构，即应用系统要存储什么数据，这些数据是什么样的结构，它们之间有什么关系。 
    详细设计阶段就是为每个模块完成的功能进行具体的描述，要把功能描述转变为精确的、结构化的过程描述。

    概要设计阶段通常得到软件结构图
    详细设计阶段常用的描述方式有：流程图、N-S图、PAD图、伪代码等

概要设计和详细设计

    在软件设计中，大家经常问到的一个问题是：概要设计应该怎样一个概要法，详细设计应该怎样一个详细法？
这个问题在公司内部经常有人问。现在陈述一下。
    我们公司的研发流程是瀑布型的，这个模型中的分析、设计阶段是基于经典的结构化方法。 

    结构化设计方法的基本思路是：按照问题域，将软件逐级细化，分解为不必再分解的的模块，每个模块完成一定的功能，为一个或多个父模块服务（即接受调用），也接受一个或多个子模块的服务（即调用子模块）。模块的概念，和编程语言中的子程序或函数是对应的。
 
    这样一来，设计可以明显地划分成两个阶段： 

    概要（结构）设计阶段：把软件按照一定的原则分解为模块层次，赋予每个模块一定的任务，并确定模块间调用关系和接口。
    详细设计阶段：依据概要设计阶段的分解，设计每个模块内的算法、流程等。

概要设计阶段：
 
    在这个阶段，设计者会大致考虑并照顾模块的内部实现，但不过多纠缠于此。主要集中于划分模块、分配任务、定义调用关系。模块间的接口与传参在这个阶段要定得 十分细致明确，应编写严谨的数据字典，避免后续设计产生不解或误解。概要设计一般不是一次就能做到位，而是反复地进行结构调整。典型的调整是合并功能重复的模块，或者进一步分解出可以复用的模块。在概要设计阶段，应最大限度地提取可以重用的模块，建立合理的结构体系，节省后续环节的工作量。 

    概要设计文档最重要的部分是分层数据流图、结构图、数据字典以及相应的文字说明等。以概要设计文档为依据，各个模块的详细设计就可以并行展开了。

详细设计阶段:

    在这个阶段，各个模块可以分给不同的人去并行设计。在详细设计阶段，设计者的工作对象是一个模块，根据概要设计赋予的局部任务和对外接口，设计并表达出模块的算法、流程、状态转换等内容。这里要注意，如果发现有结构调整（如分解出子模块等）的必要，必须返回到概要设计阶段，将调整反应到概要设计文档中，而不 能就地解决，不打招呼。详细设计文档最重要的部分是模块的流程图、状态图、局部变量及相应的文字说明等。一个模块一篇详细设计文档。

    概要设计文档相当于机械设计中的装配图，而详细设计文档相当于机械设计中的零件图。文档的编排、装订方式也可以参考机械图纸的方法。
    我们公司对模块的认识和传统定义有所不同，认为是较大的软件功能单元才可以称作模块。这种认识使大家对概要设计和详细设计的分工产生了混乱的理解，降低了文档的可用性，应该予以纠正。
    概要设计中较顶层的部分便是所谓的方案。方案文档的作用是在宏观的角度上保持设计的合理性。

    有的项目采用面向对象的分析、设计方法。可能在概要设计、详细设计的分工上疑问更多。其实，面向对象的分析、设计方法并没有强调结构化方法那样的阶段性，因此一般不引入概要、详细设计的概念。如果按照公司的文档体系，非要有这种分工的话，可以将包的划分、类及对象间的关系、类的对外属性、方法及协作设计看做 概要设计；类属性、方法的内部实现看做详细设计。

   1.需求分析--产生软件功能规格说明书,需要确定用户对软件的需求,要作到明确、无歧义。不涉及具体实现方法。用户能看得明白，开发人员也可据此进行下面的工作（概要设计）。 
   2.概要设计--产生软件概要设计说明书，说明系统模块划分、选择的技术路线等，整体说明软件的实现思路。并且需要指出关键技术难点等。   
   3.详细设计--产生软件详细设计说明书，对概要设计的进一步细化，一般由各部分的担当人员依据概要设计分别完成，然后在集成，是具体的实现细节。理论上要求可以照此编码。

概要设计和详细设计的区别与联系

    软件设计采用自顶向下、逐次功能展开的设计方法，首先完成总体设计，然后完成各有机组成部分的设计。

    根据工作性质和内容的不同，软件设计分为概要设计和详细设计。概要设计实现软件的总体设计、模块划分、用户界面设计、数据库设计等等；详细设计则根据概要设计所做的模块划分，实现各模块的算法设计，实现用户界面设计、数据结构设计的细化，等等。

    概要设计是详细设计的基础，必须在详细设计之前完成，概要设计经复查确认后才可以开始详细设计。概要设计，必须完成概要设计文档，包括系统的总体设计文档、以及各个模块的概要设计文档。每个模块的设计文档都应该独立成册。

    详细设计必须遵循概要设计来进行。详细设计方案的更改，不得影响到概要设计方案；如果需要更改概要设计，必须经过项目经理的同意。详细设计，应该完成详细设计文档，主要是模块的详细设计方案说明。和概要设计一样，每个模块的详细设计文档都应该独立成册。

   概要设计里面的数据库设计应该重点在描述数据关系上，说明数据的来龙去脉，在这里应该结合我们的一下结果数据，说明这些结果数据的源点，我们这样设计的目的和原因。详细设计里的数据库设计就应该是一份完善的数据结构文档，就是一个包括类型、命名、精度、字段说明、表说明等内容的数据字典。

   概要设计里的功能应该是重点在功能描述，对需求的解释和整合，整体划分功能模块，并对各功能模块进行详细的图文描述，应该让读者大致了解系统作完后大体的结构和操作模式。详细设计则是重点在描述系统的实现方式，各模块详细说明实现功能所需的类及具体的方法函数，包括涉及到的sql语句等。

概要设计，详细设计之间的关系是什么？

Q:
我的看法：
    概要设计只说明系统有多少个模块，各模块之间的接口和个模块本身的功能
    详细设计说明某个具体模块如何实现，粒度应该比程序略高一些

    但是问题来了，各个模块之间是有层次关系的，也有先后逻辑关系。这就说明，在概要设计中，还必须考虑模块的实现细节，否则，你怎么知道这个模块下面要划分子模块？你怎么知道各子模块的调用顺序？
    这就说明，概要设计和详细设计是重叠进行的，而软件工程书上说的确是顺序进行的，不知道是不是我的理解有问题。

举个例子，例如排序程序，如果设计2个模块：
一个主模块用于排序子模块用于交换2个变量，主模块调用子模块，但是子模块是怎么设计出来的呢？肯定是你先想到了用冒泡等排序方式的时候需要交换数据，这已经考虑了主模块足够多的细节，似乎属于"详细设计"了，但是目前进行的是概要设计，这就产生了我所说的重叠的情况。

A:

看看上面的帖子，有意思的居多。

上面也有朋友说到用建筑的例子来比喻。

软件的概要设计，主要是建立软件系统的整体架构，也就是我们在盖房子时候，需要先将房子的整个架子构建起来。

软件的详细设计，主要是将软件系统的各个部分的具体设计方法、逻辑、功能采用文字方式进行表述。这样在实现过程中，Coding人员原则上严格按此进行代码实现即可。

这样的一个最为简单的例证：我们可以将代码交付第三方来做。验证与跟踪采取设计来。

我看上面还有一个朋友说：快速做代码。这个本身没有值得批评之处。但只要想一下，你写的代码没有任何设计思想、文档留下的情况，一旦你离开，如何维护？重新设计吗？还是花费几倍人力去研究你写的几千/万，甚至几十万行代码？如果是这样的，你没错，关键是你们老板太对了，钱算什么。

另外的一个问题是：中国人如此聪明，但中国为什么没有出现巨型软件产品呢？个人英雄主义依然很严重，老板的短视利益行为大行其道。

    根据工作性质和内容的不同，软件设计分为概要设计和详细设计。概要设计实现软件的总体设计、模块划分、用户界面设计、数据库设计等等；详细设计则根据概要设计所做的模块划分，实现各模块的算法设计，实现用户界面设计、数据结构设计的细化，等等。

    概要设计是详细设计的基础，必须在详细设计之前完成，概要设计经复查确认后才可以开始详细设计。概要设计，必须完成概要设计文档，包括系统的总体设计文档、以及各个模块的概要设计文档。每个模块的设计文档都应该独立成册。

    详细设计必须遵循概要设计来进行。详细设计方案的更改，不得影响到概要设计方案；如果需要更改概要设计，必须经过项目经理的同意。详细设计，应该完成详细设计文档，主要是模块的详细设计方案说明。和概要设计一样，每个模块的详细设计文档都应该独立成册。

    概要设计里面的数据库设计应该重点在描述数据关系上，说明数据的来龙去脉，在这里应该结合我们的一下结果数据，说明这些结果数据的源点，我们这样设计的目的和原因。详细设计里的数据库设计就应该是一份完善的数据结构文档，就是一个包括类型、命名、精度、字段说明、表说明等内容的数据字典。

    概要设计里的功能应该是重点在功能描述，对需求的解释和整合，整体划分功能模块，并对各功能模块进行详细的图文描述，应该让读者大致了解系统作完后大体的结构和操作模式。详细设计则是重点在描述系统的实现方式，各模块详细说明实现功能所需的类及具体的方法函数，包括涉及到的sql语句等。

1. 下载下websphere6.1安装,在安装的过程中要记住自己设置的node name和cell name.

2.   启动eclipse,在window->preperences->myeclipse->application servers->websphere6.1

       点Browse...选择你eclipse的安装目录.我是安装在D:\webshpere6.1,之后myeclipse会自动的将Profile Root       Directory,Node name,cell name设置好.你需要确认一下.Profile Root Directory就是你的安装目录下Profiles目录下的一个文件夹.我的是D:\webshpere6.0\profiles \AppSrv01.而node name和cell name它会设成以你的机器名命名的名字,应该将cell name改为Profiles RootDirectory下的installedApps目录(D:\webshpere6.0\profiles\AppSrv01 \installedApps)下的文件夹的名字我的是就是localhostNode01Cell,将node name改为cell name去掉后面的cell的名字.选中enable项.点Apple保存.

3. 展开websphere6.1,选JDK,将JDK设置为webshpere6.1安装目录下的JDK(D:\webshpere6.0\java).一定要设置成IBM的JDK要不websphere是不能运行的.

4. 启动websphere(不是用eclipse,而是用websphere的启动服务器),选管理控制台,点服务器->应用服务器,选一个服务,一 般为server1.在故障诊断中选记录和跟踪->JVM 日志,修改两个文件名为console.保存,注销,停止服务.

5. 在eclipse中新建自己的企业工程(一定要是企业工程)如果之前有web工程可以将该企业工程的web modle设置为该web project如没有就自己新建一个.

6 发布企业工程(不是web project)在第一次发布时要选Packaged Archive

7. 用eclipse或websphere工具启动websphere,进入控制台,应用程序->安装新的应用程序,点浏览 在\webshpere6.0\profiles\AppServ01\installableApps下选自己发布的工程名的ear文件(你可能不是 AppServ01)然后next下去就可以了,唯一要注意的就是要设置web模块上下文根和要选上class 类文件和jsp的修改自动装载.

8. 退到控制台首页,应用程序->企业应用程序,选择自己发布的工程,点启动.注销,停止websphere.

9. 在eclipse中再点发布,删除刚发布的工程,再点add...选择企业工程,Exploded Archive.选Delete Remote...项.然后发布.以后就可以实时调试了.

    简单的比较一下 Enterprise, Development 和 Express 等三个版本:以功能言，Enterprise 版和 Development 版的功能一模一样。两者的差别，除了授权不同外，最主要的差别是: 

    Enterprise版的数据库引擎只能安装在Win2003Server(或其他Server)。 

    如果你想安装在WindowsXP Pro系统上，你应该安装SQL2005Development版(开发版)。 

    什么是「数据库引擎」。数据库引擎是SQL2005的核心，是最主要的数据库管理功能模块。没有它，就不是数据库管理系统了。

    因此，如果你是初学者，如果你只是想要在家里学习学习，如果你的环境是 WindowsXP Pro，那么，你应该选择的是 SQL2005Development(开发版)，而不是SQL2005Enterprise(企业版)或SQL2005Express(简易版)。

SQL Server 2005 Enterprise Edition（32 位和 64 位）

Enterprise Edition 达到了支持超大型企业进行联机事务处理 (OLTP)、高度复杂的数据分析、数据仓库系统和网站所需的性能水平。Enterprise Edition 的全面商业智能和分析能力及其高可用性功能（如故障转移群集），使它可以处理大多数关键业务的企业工作负荷。Enterprise Edition 是最全面的 SQL Server 版本，是超大型企业的理想选择，能够满足最复杂的要求。

SQL Server 2005 Evaluation Edition（32 位和 64 位）

SQL Server 2005 还推出了适用于 32 位或 64 位平台的 180 天 Evaluation Edition。SQL Server Evaluation Edition 支持与 SQL Server 2005 Enterprise Edition 相同的功能集。可以根据生产需要升级 SQL Server Evaluation Edition。

SQL Server 2005 Standard Edition（32 位和 64 位）

SQL Server 2005 Standard Edition 是适合中小型企业的数据管理和分析平台。它包括电子商务、数据仓库和业务流解决方案所需的基本功能。Standard Edition 的集成商业智能和高可用性功能可以为企业提供支持其运营所需的基本功能。SQL Server 2005 Standard Edition 是需要全面的数据管理和分析平台的中小型企业的理想选择。

SQL Server 2005 Workgroup Edition（仅适用于 32 位）

对于那些需要在大小和用户数量上没有限制的数据库的小型企业，SQL Server 2005 Workgroup Edition 是理想的数据管理解决方案。SQL Server 2005 Workgroup Edition 可以用作前端 Web 服务器，也可以用于部门或分支机构的运营。它包括 SQL Server 产品系列的核心数据库功能，并且可以轻松地升级至 SQL Server 2005 Standard Edition 或 SQL Server 2005 Enterprise Edition。SQL Server 2005 Workgroup Edition 是理想的入门级数据库，具有可靠、功能强大且易于管理的特点。

SQL Server 2005 Developer Edition（32 位和 64 位）

SQL Server 2005 Developer Edition 允许开发人员在 SQL Server 顶部生成任何类型的应用程序。该应用程序包括 SQL Server 2005 Enterprise Edition 的所有功能，但许可用作开发和测试系统，而不用作生产服务器。SQL Server 2005 Developer Edition 是独立软件供应商 (ISV)、咨询人员、系统集成商、解决方案供应商以及生成和测试应用程序的企业开发人员的理想选择。可以根据生产需要升级 SQL Server 2005 Developer Edition。

SQL Server 2005 Express Edition（仅适用于 32 位）

SQL Server Express 数据库平台基于 Microsoft SQL Server 2005。它也可以替换 Microsoft Desktop Engine (MSDE)。通过与 Microsoft Visual Studio 2005 集成，SQL Server Express 简化了功能丰富、存储安全且部署快速的数据驱动应用程序的开发过程。

SQL Server Express 是免费的，可以再分发（受制于协议），还可以充当客户端数据库以及基本服务器数据库。SQL Server Express 是独立软件供应商 ISV、服务器用户、非专业开发人员、Web 应用程序开发人员、网站主机和创建客户端应用程序的编程爱好者的理想选择。如果需要更多的高级数据库功能，可将 SQL Server Express 无缝升级到更复杂的 SQL Server 版本。

SQL Server Express 还提供了一些附加组件，这些组件都作为具有高级服务的 Microsoft SQL Server 2005 Express Edition (SQL Server Express) 的一部分提供。除了 SQL Server Express 的功能外，具有高级服务的 SQL Server Express 还包括以下功能：

• SQL Server Management Studio Express (SSMSE)，SQL Server Management Studio 的子集。
  
• 支持全文目录。
  
• 支持通过 Reporting Services 查看报表。
  

SQL Server 2005 Mobile Edition（仅 32 位）

SQL Server Mobile 是简版数据库，将企业数据管理功能扩展到小型设备上。SQL Server Mobile 能够复制 Microsoft SQL Server 2005 和 Microsoft SQL Server 2000 的数据，并且允许用户维护与主数据库同步的移动数据存储。SQL Server Mobile 是唯一为智能设备提供关系数据库管理功能的 SQL Server 版本。

SQL Server 2005 Runtime Edition（32 位和 64 位）

SQL Server 2005 Runtime Edition 随 Microsoft ISV Royalty Program 提供。根据 SQL Server 2005 Runtime Edition 的最终用户许可协议，如果用户不使用 SQL Server 代码运行任何其他应用程序或者在任何其他上下文中使用 SQL Server 代码，独立软件供应商 (ISV) 可能将 SQL Server 代码嵌入到他们提供的解决方案中。关于 SQL Server Runtime Edition 的详细信息，请参阅 Microsoft 知识库中的文章如何获取 SQL Server Runtime 许可证 (http://support.microsoft.com/kb/917400)。

注意点：

 在XP上不能安装 Enterprise 版本，

 Express版本只能在本地访问，不能进行远程访问。

 Express版本连接时需要在连接字符串中写 ***\SQLExpress

 Developer版本可以进行远程访问，记住要启用TCP/IP连接，同时要设置好防火墙