大型网站架构

 http://xiaogui9317170.javaeye.com/blog/317478

大型网站架构不得不考虑的10个问题

来自CSDN：http://news.csdn.net/n/20090115/122497.html

 

这里的大型网站架构只包括高互动性高交互性的数据型大型网站，基于大家众所周知的原因，我们就不谈新闻类和一些依靠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到海内校内，都在考虑这个问题，它可以更有效的留住用户并激发用户的更多的兴趣以及让更多的人帮助你做最有效的开发。这个时候一个有效的数据共享平台，数据开放平台就成为必不可少的途径了，而在开放的接口的情况保证数据的安全性和性能，又是一个我们必须要认真思考的问题了。

 

http://xiaogui9317170.javaeye.com/blog/311602

规划 SOA 参考架构

2007-12-03 09:14 作者：萧百龄 出处：比特网 责任编辑：方舟
         SOA  参考架构 （Reference Architecture）是一个框架，使各个项目都有一个遵从的依据，借以促进一致性、最佳实践典范，和标准化。参考架构并不受限于目前的 IT 现况，而应该针对一个经过深思熟虑的愿景目标，可以说是 IT 指导未来所有的新开发工作，借以实现该目标的参考依据。一般来说，2-3 年的规划，是一个比较合适的涵盖范围，既能提供足够的时间来达成面向服务的转型，而又不至于过于长远而虚幻。因此，参考架构提供了一个沟通目标愿景的方法，协助部门和角色各异的 IT 人员，逐渐朝向该目标会合。

　　高效的 SOA 需要采用新的方法来对待 IT 基础设施，并且根据个别企业的需求来量身定做，并将服务基础架构、共享的技术服务、安全服务，以及信息/数据、和遗留系统访问服务等，全部定义在内。

　　为了满足 SOA 的要求，所有公司都需要 SOA 参考架构和路线图，来指导部署一套能随时间演进、而逐渐丰富的工业级服务基础设施，同时指导对面向服务应用的开发和管理。

　　此外，企业也需要对参与 SOA 架构的各个个别系统的设计，进行监管，并在适当的地方，建立通用服务，透过协作来发挥更高的效率。对于这些举措，连接端点的标准化（通过建立定义清晰的契约和接口），是达成 IT 系统一致性的先决条件。

　　SOA 参考架构指导所有实施 SOA 的各个项目，能共同朝向企业级服务，和 SOA 基础架构标准方向的集中发展，尽早使企业从中获益。换句话说，参考架构规划的重点，在于开发一个特定于某个企业需要、切实可行的路线图，以填补当前和愿景目标之间的鸿沟;评估用于开发、部署和管理、监控的现有系统和技术，定义目标状态愿景，目标参考架构模型。

SOA 参考架构可说是指导 SOA 成功的蓝图 ，其作用包括：

　　促进 IT 与业务的紧密配合：参考架构的制定，以业务驱动力和 IT 目标为出发点，分析 SOA 解决方案能对这些驱动力带来多大的正面影响，进而为从目前 IT 现况演化到愿景架构，定出实现架构、相关规范及路线图。参考架构因此提供了从业务和 IT 目标，到实现架构间的可跟踪性，是业务与 IT 之间进行沟通的重要媒介，是企业实现业务灵活性、可管理性和变更规划的基础。

　　协助企业向重用、团队协作和资源共享的文化迁移：参考架构确立了 SOA 架构标准和技术部署的最佳实践，为日后各个 SOA 的实施项目，订立架构遵从性的度量标准和指标。

　　参考架构并非一成不变。在一个新的 SOA 策略与规划迭代中，SOA 的参考架构和规范标准，可能需要针对新的业务、IT 情况，和已实施的 SOA 项目中得到的反馈，进行调整，因此，SOA 参考架构不仅是 IT 模板，也是也描述 SOA 原则和标准的活文档。

我们可以将参考架构的内容，粗分为两大部分 ：

　　对服务建立一套共同的词汇和做法，包括：

• 　　服务的正式定义 – 例如服务必须由契约 （contract）、接口 （interface），和实现 （implementation） 所组成
• 　　服务的分类（核心业务功能服务，数据服务，展现服务等），以及各类服务的设计原则和建议
• 　　接口标准 （JMS, RMI, HTTP 等），建议的接口样式（例如：尽量采用粗粒度、异步的服务调用模式），可靠性要求等
• 　　需要遵从的 WS-* 标准
• 　　安全策略
• 　　服务版本控制策略
• 　　服务和数据模型采用规范
• 　　服务生命周期定义

　　与服务基础设施，例如企业服务总线 （ESB）、业务流程管理 （BPM）、注册库 （Registry）、资产库 （Repository） 等相关的规范，包括：

• 　　必须支持什么样的部署配置
• 　　必须具备什么样的能力

各个部件的责任

　　部件之间的耦合关系和原则，应避免的事项，例如，展现服务和业务流程服务不可直接调用数据服务，而必须通过核心业务服务;换句话说，数据服务不可直接与展现服务和业务流程服务有耦合关系

　　各个部件应支持那些科技和标准（例如：SCA, SDO…）

　　有哪些安全顾虑需要考虑，如何管理权限

要采用哪些产品

　　由于在规划服务基础设施参考架构时，需要涵盖几类 SOA 参与者和干系人 （stakeholders）各自不同的顾虑，包括架构师、程序员、和负责部署、运营、监控的 IT 人员，我们可以采用一个针对服务基础设施参考架构调整过的 4+1 视图（如下），来协助我们分离顾虑，来将不同层面的规范和目标架构一一制定，通过逻辑、实现、部署，和进程等四个视图，配合最佳实践典范和模式，来对参考架构的各个层面，进行描述和规范，如附图。

　　图说：为 SOA 参考架构调整过的 4+1 视图，源于 Kruchten 在 1997 年发表的《Architectural Blueprints – the 4+1 view model of software architecture》

　　图说：服务基础设施参考架构的逻辑视图 （Logical View）

各个部件的责任

　　部件之间的耦合关系和原则，应避免的事项，例如，展现服务和业务流程服务不可直接调用数据服务，而必须通过核心业务服务;换句话说，数据服务不可直接与展现服务和业务流程服务有耦合关系

　　各个部件应支持那些科技和标准（例如：SCA, SDO…）

　　有哪些安全顾虑需要考虑，如何管理权限

要采用哪些产品

　　由于在规划服务基础设施参考架构时，需要涵盖几类 SOA 参与者和干系人 （stakeholders）各自不同的顾虑，包括架构师、程序员、和负责部署、运营、监控的 IT 人员，我们可以采用一个针对服务基础设施参考架构调整过的 4+1 视图（如下），来协助我们分离顾虑，来将不同层面的规范和目标架构一一制定，通过逻辑、实现、部署，和进程等四个视图，配合最佳实践典范和模式，来对参考架构的各个层面，进行描述和规范，如附图。

　　图说：为 SOA 参考架构调整过的 4+1 视图，源于 Kruchten 在 1997 年发表的《Architectural Blueprints – the 4+1 view model of software architecture》

　　图说：服务基础设施参考架构的逻辑视图 （Logical View）

　　图说：服务基础设施逻辑视图下的功能视图 （Functional View）

　　图说：服务基础设施参考架构的实现视图实例（场景为某电信客户的 provisioning service），描绘所计划采用的产品，以及如何通过这些产品间的交互，来实现解决方案。

http://xiaogui9317170.javaeye.com/blog/276135

系统构架设计应考虑的因素

 

厦门巨龙软件工程有限公司 卢琳生
2004-10-19

软件工程专家网

   本文从程序的运行时结构和源代码的组织结构两个方面探讨了系统构架设计应考虑的各种因素，列举了系统构架设计文档应考虑的一些问题。

    一、与构架有关的几个基本概念：
 
    1、模块（module）：一组完成指定功能的语句，包括：输入、输出、逻辑处理功能、内部信息、运行环境（与功能对应但不是一对一关系）。
 
    2、组件（component）：系统中相当重要的、几乎是独立的可替换部分，它在明确定义的构架环境中实现确切的功能。
 
    3、模式（pattern）：指经过验证，至少适用于一种实用环境（更多时候是好几种环境）的解决方案模板（用于结构和行为。在 UML 中：模式由参数化的协作来表示，但 UML 不直接对模式的其他方面（如使用结果列表、使用示例等，它们可由文本来表示）进行建模。存在各种范围和抽象程度的模式，例如，构架模式、分析模式、设计模式和代码模式或实施模式。模式将可以帮助我们抓住重点。构架也是存在模式的。比如，对于系统结构设计，我们使用层模式；对于分布式系统，我们使用代理模式（通过使用代理来替代实际的对象，使程序能够控制对该对象的访问）；对于交互系统，我们使用MVC（M模型(对象)／V视图(输出管理)／C控制器(输入处理)）模式。模式是针对特定问题的解，因此，我们也可以针对需求的特点采用相应的模式来设计构架。
 
    4、构架模式（architectural pattern）：表示软件系统的基本结构组织方案。它提供了一组预定义的子系统、指定它们的职责，并且包括用于组织其间关系的规则和指导。
 
    5、层（layer）：对模型中同一抽象层次上的包进行分组的一种特定方式。通过分层，从逻辑上将子系统划分成许多集合，而层间关系的形成要遵循一定的规则。通过分层，可以限制子系统间的依赖关系，使系统以更松散的方式耦合，从而更易于维护。（层是对构架的横向划分，分区是对构架的纵向划分）。
 
    6、系统分层的几种常用方法：
    1） 常用三层服务：用户层、业务逻辑层、数据层；
    2） 多层结构的技术组成模型：表现层、中间层、数据层；
    3） 网络系统常用三层结构：核心层、汇聚层和接入层；
    4） RUP典型分层方法：应用层、专业业务层、中间件层、系统软件层；
    5） 基于Java的B/S模式系统结构：浏览器端、服务器端、请求接收层、请求处理层；
    6） 某六层结构：功能层（用户界面）、模块层、组装层（软件总线）、服务层（数据处理）、数据层、核心层；
 
    7、构架（Architecture，愿意为建筑学设计和建筑物建造的艺术与科学）: 在RUP中的定义：软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互；《软件构架实践》中的定义：某个软件或者计算系统的软件构架即组成该系统的一个或者多个结构，他们组成软件的各个部分，形成这些组件的外部可见属性及相互间的联系；IEEE 1471-2000中的定义：the fundamental organization of a system emboided in its components,their relationships to each other,and to the enviroment and the principles guiding its design and evolution，构架是系统在其所处环境中的最高层次的概念。软件系统的构架是通过接口交互的重要构件（在特定时间点）的组织或结构，这些构件又由一些更小的构件和接口组成。（“构架”可以作为名词，也可作为动词，作为动词的“构架”相当于“构架设计”）
 
    8、构架的描述方式：“4＋1”视图（用例视图、设计视图、实现视图、过程视图、配置视图）是一个被广为使用的构架描述的模型；RUP过程的构架描述模板在“4＋1”视图的基础上增加了可选的数据视图（从永久性数据存储方面来对系统进行说明）；HP公司的软件描述模板也是基于“4＋1”视图。
 
    9、结构：软件构架是多种结构的体现，结构是系统构架从不同角度观察所产生的视图。就像建筑物的结构会随着观察动机和出发点的不同而有多种含义一样，软件构架也表现为多种结构。常见的软件结构有：模块结构、逻辑或概念结构、进程或协调结构、物理结构、使用结构、调用结构、数据流、控制流、类结构等等。
 
    二、构架设计应考虑的因素概揽：
 
    模块构架设计可以从程序的运行时结构和源代码的组织结构方面考虑。
 
    1、程序的运行时结构方面的考虑：
    1） 需求的符合性：正确性、完整性；功能性需求、非功能性需求；
    2） 总体性能（内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响）；
    3） 运行可管理性：便于控制系统运行、监视系统状态、错误处理；模块间通信的简单性；与可维护性不同；
    4） 与其他系统接口兼容性；
    5） 与网络、硬件接口兼容性及性能；
    6） 系统安全性；
    7） 系统可靠性；
    8） 业务流程的可调整性；
    9） 业务信息的可调整性
    10） 使用方便性
    11） 构架样式的一致性
    注：运行时负载均衡可以从系统性能、系统可靠性方面考虑。
 
    2、源代码的组织结构方面的考虑：
    1） 开发可管理性：便于人员分工（模块独立性、开发工作的负载均衡、进度安排优化、预防人员流动对开发的影响）、利于配置管理、大小的合理性与适度复杂性；
    2） 可维护性：与运行可管理性不同；
    3） 可扩充性：系统方案的升级、扩容、扩充性能；
    4） 可移植性：不同客户端、应用服务器、数据库管理系统；
    5） 需求的符合性（源代码的组织结构方面的考虑）。

    三、程序的运行时结构方面的考虑：
 
    1、 需求的符合性：正确性、完整性；功能性需求、非功能性需求
  
    软件项目最主要的目标是满足客户需求。在进行构架设计的时候，大家考虑更多的是使用哪个运行平台、编成语言、开发环境、数据库管理系统等问题，对于和客户需求相关的问题考虑不足、不够系统。如果无论怎么好的构架都无法满足客户明确的某个功能性需求或非功能性需求，就应该与客户协调在项目范围和需求规格说明书中删除这一需求。否则，架构设计应以满足客户所有明确需求为最基本目标，尽量满足其隐含的需求。（客户的非功能性需求可能包括接口、系统安全性、可靠性、移植性、扩展性等等，在其他小节中细述）
 
    一般来说，功能需求决定业务构架、非功能需求决定技术构架，变化案例决定构架的范围。需求方面的知识告诉我们，功能需求定义了软件能够做些什么。我们需要根据业务上的需求来设计业务构架，以使得未来的软件能够满足客户的需要。非功能需求定义了一些性能、效率上的一些约束、规则。而我们的技术构架要能够满足这些约束和规则。变化案例是对未来可能发生的变化的一个估计，结合功能需求和非功能需求，我们就可以确定一个需求的范围，进而确定一个构架的范围。（此段 From林星）
 
    这里讲一个前几年因客户某些需求错误造成构架设计问题而引起系统性能和可靠性问题的小小的例子：此系统的需求本身是比较简单的，就是将某城市的某业务的全部历史档案卡片扫描存储起来，以便可以按照姓名进行查询。需求阶段客户说卡片大约有20万张，需求调研者出于对客户的信任没有对数据的总量进行查证。由于是中小型数据量，并且今后数据不会增加，经过计算20万张卡片总体容量之后，决定使用一种可以单机使用也可以联网的中小型数据库管理系统。等到系统完成开始录入数据时，才发现数据至少有60万，这样使用那种中小型数据库管理系统不但会造成系统性能的问题，而且其可靠性是非常脆弱的，不得不对系统进行重新设计。从这个小小的教训可以看出，需求阶段不仅对客户的功能需求要调查清楚，对于一些隐含非功能需求的一些数据也应当调查清楚，并作为构架设计的依据。
 
    对于功能需求的正确性，在构架设计文档中可能不好验证（需要人工、费力）。对于功能需求完整性，就应当使用需求功能与对应模块对照表来跟踪追溯。对于非功能需求正确性和完整性，可以使用需求非功能与对应设计策略对照表来跟踪追溯评估。
 
    “软件设计工作只有基于用户需求，立足于可行的技术才有可能成功。”
 
    2、 总体性能
 
    性能其实也是客户需求的一部分，当然可能是明确的，也有很多是隐含的，这里把它单独列出来在说明一次。性能是设计方案的重要标准，性能应考虑的不是单台客户端的性能，而是应该考虑系统总的综合性能；
 
    性能设计应从以下几个方面考虑：内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响；

    几点提示：算法优化及负载均衡是性能优化的方向。经常要调用的模块要特别注意优化。占用内存较多的变量在不用时要及时清理掉。需要下载的网页主题文件过大时应当分解为若干部分，让用户先把主要部分显示出来。
 
    3、 运行可管理性
 
    系统的构架设计应当为了使系统可以预测系统故障，防患于未然。现在的系统正逐步向复杂化、大型化发展，单靠一个人或几个人来管理已显得力不从心，况且对于某些突发事件的响应，人的反应明显不够。因此通过合理的系统构架规划系统运行资源，便于控制系统运行、监视系统状态、进行有效的错误处理；为了实现上述目标，模块间通信应当尽可能简单，同时建立合理详尽的系统运行日志，系统通过自动审计运行日志，了解系统运行状态、进行有效的错误处理；（运行可管理性与可维护性不同）
 
    4、 与其他系统接口兼容性（解释略）
 
    5、 与网络、硬件接口兼容性及性能（解释略）
 
    6、 系统安全性
 
    随着计算机应用的不断深入和扩大，涉及的部门和信息也越来越多，其中有大量保密信息在网络上传输，所以对系统安全性的考虑已经成为系统设计的关键，需要从各个方面和角度加以考虑，来保证数据资料的绝对安全。
 
    7、 系统可靠性
 
    系统的可靠性是现代信息系统应具有的重要特征，由于人们日常的工作对系统依赖程度越来越多，因此系统的必须可靠。系统构架设计可考虑系统的冗余度，尽可能地避免单点故障。系统可靠性是系统在给定的时间间隔及给定的环境条件下，按设计要求，成功地运行程序的概率。成功地运行不仅要保证系统能正确地运行，满足功能需求，还要求当系统出现意外故障时能够尽快恢复正常运行，数据不受破坏。
 
    8、 业务流程的可调整性
 
    应当考虑客户业务流程可能出现的变化，所以在系统构架设计时要尽量排除业务流程的制约，即把流程中的各项业务结点工作作为独立的对象，设计成独立的模块或组件，充分考虑他们与其他各种业务对象模块或组件的接口，在流程之间通过业务对象模块的相互调用实现各种业务，这样，在业务流程发生有限的变化时（每个业务模块本身的业务逻辑没有变的情况下），就能够比较方便地修改系统程序模块或组件间的调用关系而实现新的需求。如果这种调用关系被设计成存储在配置库的数据字典里，则连程序代码都不用修改，只需修改数据字典里的模块或组件调用规则即可。
 
    9、 业务信息的可调整性
 
    应当考虑客户业务信息可能出现的变化，所以在系统构架设计时必须尽可能减少因为业务信息的调整对于代码模块的影响范围。
 
    10、 使用方便性
 
    使用方便性是不须提及的必然的需求，而使用方便性与系统构架是密切相关的。WinCE（1.0）的失败和后来改进版本的成功就说明了这个问题。 WinCE（1.0）有太多层次的视窗和菜单，而用户则更喜欢简单的界面和快捷的操作。失败了应当及时纠正，但最好不要等到失败了再来纠正，这样会浪费巨大的财力物力，所以在系统构架阶段最好能将需要考虑的因素都考虑到。当然使用方便性必须与系统安全性协调平衡统一，使用方便性也必须与业务流程的可调整性和业务信息的可调整性协调平衡统一。“满足用户的需求，便于用户使用，同时又使得操作流程尽可能简单。这就是设计之本。”
 
    11、构架样式的一致性
 
    软件系统的构架样式有些类似于建筑样式（如中国式、哥特式、希腊复古式）。软件构架样式可分为数据流构架样式、调用返回构架样式、独立组件构架样式、以数据为中心的构架样式和虚拟机构架样式，每一种样式还可以分为若干子样式。构架样式的一致性并不是要求一个软件系统只能采用一种样式，就像建筑样式可以是中西结合的，软件系统也可以有异质构架样式（分为局部异质、层次异质、并行异质），即多种样式的综合，但这样的综合应该考虑其某些方面的一致性和协调性。每一种样式都有其使用的时机，应当根据系统最强调的质量属性来选择。
 
    四、源代码的组织结构方面的考虑：
 
    1、 开发可管理性
  
    便于人员分工（模块独立性、开发工作的负载均衡、进度安排优化、预防人员流动对开发的影响：一个好的构架同时应有助于减少项目组的压力和紧张，提高软件开发效率）、利于配置管理、大小的合理性、适度复杂性；
    1）便于人员分工－模块独立性、层次性
    模块独立性、层次性是为了保证项目开发成员工作之间的相对独立性，模块联结方式应该是纵向而不是横向, 模块之间应该是树状结构而不是网状结构或交叉结构，这样就可以把开发人员之间的通信、模块开发制约关系减到最少。同时模块独立性也比较利于配置管理工作的进行。现在有越来越多的的软件开发是在异地进行，一个开发组的成员可能在不同城市甚至在不同国家，因此便于异地开发的人员分工与配置管理的源代码组织结构是非常必要的。
 
    2）便于人员分工－开发工作的负载均衡
    不仅仅是开发出来的软件系统需要负载均衡，在开发过程中开发小组各成员之间工作任务的负载均衡也是非重要的。所谓工作任务的负载均衡就是通过合理的任务划分按照开发人员特点进行分配任务，尽量让项目组中的每个人每段时间都有用武之地。这就需要在构架设计时应当充分考虑项目组手头的人力资源，在实现客户需求的基础上实现开发工作的负载均衡，以提高整体开发效率。
 
    3）便于人员分工－进度安排优化；
    进度安排优化的前提是模块独立性并搞清楚模块开发的先后制约关系。利用工作分解结构对所有程序编码工作进行分解，得到每一项工作的输入、输出、所需资源、持续时间、前期应完成的工作、完成后可以进行的工作。然后预估各模块需要时间，分析各模块的并行与串行（顺序制约），绘制出网络图，找出影响整体进度的关键模块，算出关键路径，最后对网络图进行调整，以使进度安排最优化。
 
    有个家喻户晓的智力题叫烤肉片策略：约翰逊家户外有一个可以同时烤两块肉片的烤肉架，烤每块肉片的每一面需要10分钟，现要烤三块肉片给饥肠辘辘急不可耐的一家三口。问题是怎样才能在最短的时间内烤完三片肉。一般的做法花20分钟先烤完前两片，再花20分钟烤完第三片。有一种更好的方法可以节省10分钟，大家想想。
   
    4）便于人员分工－预防员工人员流动对开发的影响
    人员流动在软件行业是司空见惯的事情，已经是一个常见的风险。作为对这一风险的有效的防范对策之一，可以在构架设计中考虑到并预防员工人员流动对开发的影响。主要的思路还是在模块的独立性上（追求高内聚低耦合），组件化是目前流行的趋势。
 
    5）利于配置管理（独立性、层次性）
    利于配置管理与利于人员分工有一定的联系。除了逻辑上的模块组件要利于人员分工外，物理上的源代码层次结构、目录结构、各模块所处源代码文件的部署也应当利于人员分工和配置管理。（尽管现在配置管理工具有较强大的功能，但一个清楚的源码分割和模块分割是非常有好处的）。
 
    6）大小的合理性与适度复杂性
    大小的合理性与适度复杂性可以使开发工作的负载均衡，便于进度的安排，也可以使系统在运行时减少不必要的内存资源浪费。对于代码的可阅读性和系统的可维护性也有一定的好处。另外，过大的模块常常是系统分解不充分，而过小的模块有可能降低模块的独立性，造成系统接口的复杂。
 
    2、 可维护性
 
    便于在系统出现故障时及时方便地找到产生故障的原因和源代码位置，并能方便地进行局部修改、切割；（可维护性与运行可管理性不同）
 
    3、 可扩充性：系统方案的升级、扩容、扩充性能
 
    系统在建成后会有一段很长的运行周期，在该周期内，应用在不断增加，应用的层次在不断升级，因此采用的构架设计等方案因充分考虑升级、扩容、扩充的可行性和便利
 
    4、 可移植性
   
    不同客户端、应用服务器、数据库管理系统：如果潜在的客户使用的客户端可能使用不同的操作系统或浏览器，其可移植性必须考虑客户端程序的可移植性，或尽量不使业务逻辑放在客户端；数据处理的业务逻辑放在数据库管理系统中会有较好的性能，但如果客户群中不能确定使用的是同一种数据库管理系统，则业务逻辑就不能数据库管理系统中；

    达到可移植性一定要注重标准化和开放性：只有广泛采用遵循国际标准，开发出开放性强的产品，才可以保证各种类型的系统的充分互联，从而使产品更具有市场竞争力，也为未来的系统移植和升级扩展提供了基础。
 
    5、 需求的符合性
 
    从源代码的组织结构看需求的符合型主要考虑针对用户需求可能的变化的软件代码及构架的最小冗余（同时又要使得系统具有一定的可扩展性）。
 
    五、写系统构架设计文档应考虑的问题
 
    构架工作应该在需求开发完成约80％的时候开始进行，不必等到需求开发全部完成，需要项目经理以具体的判断来评估此时是否足以开始构建软件构架。
 
    给出一致的轮廓：系统概述。一个系统构架需要现有概括的描述，开发人员才能从上千个细节甚至数十个模块或对象类中建立一致的轮廓。
 
    构架的目标应该能够清楚说明系统概念，构架应尽可能简化，最好的构架文件应该简单、简短，清晰而不杂乱，解决方案自然。
 
    构架应单先定义上层的主要子系统，应该描述各子系统的任务，并提供每个子系统中各模块或对象类的的初步列表。
 
    构架应该描述不同子系统间相互通信的方式，而一个良好的构架应该将子系统间的通信关系降到最低。
 
    成功构架的一个重要特色，在于标明最可能变更的领域，应当列出程序中最可能变更的部分，说明构架的其他部分如何应变。
 
    复用分析、外购：缩短软件开发周期、降低成本的有效方案未必是自行开发软件，可以对现有软件进行复用或进行外购。应考虑其对构架的影响。
 
    除了系统组织的问题，构架应重点考虑对于细节全面影响的设计决策，深入这些决策领域：外部软件接口（兼容性、通信方式、传递数据结构）、用户接口（用户接口和系统层次划分）、数据库组织和内容、非数据库信息、关键算法、内存管理（配置策略）、并行性、安全性、可移植性、网络多人操作、错误处理。
 
    要保证需求的可追踪性，即保证每个需求功能都有相应模块去实现。
 
    构架不能只依据静态的系统目标来设计，也应当考虑动态的开发过程，如人力资源的情况，进度要求的情况，开发环境的满足情况。构架必须支持阶段性规划，应该能够提供阶段性规划中如何开发与完成的方式。不应该依赖无法独立运行的子系统构架。将系统各部分的、依赖关系找出来，形成一套开发计划。
 
    六、结语
 
    系统构架设计和千差万别的具体的开发平台密切相关，因此在此无法给出通用的解决方案，主要是为了说明哪些因素是需要考虑的。对于每个因素的设计策略和本文未提到的因素需要软件构架设计师在具体开发实践中灵活把握。不同因素之间有时是矛盾的，构架设计时需要根据具体情况进行平衡。
 
    参考文献
    《软件构架实践》SEI软件工程译丛，林·巴斯著
    《微软项目：求生法则》Steve McConnell著，余孟学译
    《实用软件工程》第二版，郑人杰、殷人昆、陶永雷等著
    《软件工程：实践者的研究方法》（第5版）Roger S.Pressman著
    《软件开发的科学与艺术》陈宏刚等著

 

http://xiaogui9317170.javaeye.com/blog/276130

 负载均衡－－大型在线系统实现的关键（服务器集群架构的设计与选择）

 

作者：sodme

网站：http://blog.csdn.net/sodme/archive/2005/06/12/393165.aspx

 

要了解此篇文章中引用的本人写的另一篇文章，请到以下地址：
　　http://blog.csdn.net/sodme/archive/2004/12/12/213995.aspx
　　以上的这篇文章是早在去年的时候写的了，当时正在作休闲平台，一直在想着如何实现一个可扩充的支持百万人在线的游戏平台，后来思路有了，就写了那篇总结。文章的意思，重点在于阐述一个百万级在线的系统是如何实施的，倒没真正认真地考察过QQ游戏到底是不是那样实现的。

　　近日在与业内人士讨论时，提到QQ游戏的实现方式并不是我原来所想的那样，于是，今天又认真抓了一下QQ游戏的包，结果确如这位兄弟所言，QQ游戏的架构与我当初所设想的那个架构相差确实不小。下面，我重新给出QQ百万级在线的技术实现方案，并以此展开，谈谈大型在线系统中的负载均衡机制的设计。

　　从QQ游戏的登录及游戏过程来看，QQ游戏中，也至少分为三类服务器。它们是：
　　第一层：登陆/账号服务器(Login Server)，负责验证用户身份、向客户端传送初始信息，从QQ聊天软件的封包常识来看，这些初始信息可能包括“会话密钥”此类的信息，以后客户端与后续服务器的通信就使用此会话密钥进行身份验证和信息加密；
　　第二层：大厅服务器(估且这么叫吧, Game Hall Server)，负责向客户端传递当前游戏中的所有房间信息，这些房间信息包括：各房间的连接IP，PORT，各房间的当前在线人数，房间名称等等。
　　第三层：游戏逻辑服务器(Game Logic Server)，负责处理房间逻辑及房间内的桌子逻辑。

　　从静态的表述来看，以上的三层结构似乎与我以前写的那篇文章相比并没有太大的区别，事实上，重点是它的工作流程，QQ游戏的通信流程与我以前的设想可谓大相径庭，其设计思想和技术水平确实非常优秀。具体来说，QQ游戏的通信过程是这样的：

　　1.由Client向Login Server发送账号及密码等登录消息，Login Server根据校验结果返回相应信息。可以设想的是，如果Login Server通过了Client的验证，那么它会通知其它Game Hall Server或将通过验证的消息以及会话密钥放在Game Hall Server也可以取到的地方。总之，Login Server与Game Hall Server之间是可以共享这个校验成功消息的。一旦Client收到了Login Server返回成功校验的消息后，Login Server会主动断开与Client的连接，以腾出socket资源。Login Server的IP信息，是存放在QQGame/config/QQSvrInfo.ini里的。

　　2.Client收到Login Server的校验成功等消息后，开始根据事先选定的游戏大厅入口登录游戏大厅，各个游戏大厅Game Hall Server的IP及Port信息，是存放在QQGame/Dirconfig.ini里的。Game Hall Server收到客户端Client的登录消息后，会根据一定的策略决定是否接受Client的登录，如果当前的Game Hall Server已经到了上限或暂时不能处理当前玩家登录消息，则由Game Hall Server发消息给Client，以让Client重定向到另外的Game Hall Server登录。重定向的IP及端口信息，本地没有保存，是通过数据包或一定的算法得到的。如果当前的Game Hall Server接受了该玩家的登录消息后，会向该Client发送房间目录信息，这些信息的内容我上面已经提到。目录等消息发送完毕后，Game Hall Server即断开与Client的连接，以腾出socket资源。在此后的时间里，Client每隔30分钟会重新连接Game Hall Server并向其索要最新的房间目录信息及在线人数信息。

　　3.Client根据列出的房间列表，选择某个房间进入游戏。根据我的抓包结果分析，QQ游戏，并不是给每一个游戏房间都分配了一个单独的端口进行处理。在QQ游戏里，有很多房间是共用的同一个IP和同一个端口。比如，在斗地主一区，前50个房间，用的都是同一个IP和Port信息。这意味着，这些房间，在QQ游戏的服务器上，事实上，可能是同一个程序在处理！！！QQ游戏房间的人数上限是400人，不难推算，QQ游戏单个服务器程序的用户承载量是2万，即QQ的一个游戏逻辑服务器程序最多可同时与2万个玩家保持TCP连接并保证游戏效率和品质，更重要的是，这样可以为腾讯省多少money呀！！！哇哦！QQ确实很牛。以2万的在线数还能保持这么好的游戏品质，确实不容易！QQ游戏的单个服务器程序，管理的不再只是逻辑意义上的单个房间，而可能是许多逻辑意义上的房间。其实，对于服务器而言，它就是一个大区服务器或大区服务器的一部分，我们可以把它理解为一个庞大的游戏地图，它实现的也是分块处理。而对于每一张桌子上的打牌逻辑，则是有一个统一的处理流程，50个房间的 50＊100张桌子全由这一个服务器程序进行处理(我不知道QQ游戏的具体打牌逻辑是如何设计的，我想很有可能也是分区域的，分块的)。当然，以上这些只是服务器作的事，针对于客户端而言，客户端只是在表现上，将一个个房间单独罗列了出来，这样作，是为便于玩家进行游戏以及减少服务器的开销，把这个大区中的每400人放在一个集合内进行处理（比如聊天信息，“向400人广播”和“向2万人广播”，这是完全不同的两个概念）。

　　4.需要特别说明的一点。进入QQ游戏房间后，直到点击某个位置坐下打开另一个程序界面，客户端的程序，没有再创建新的socket，而仍然使用原来大厅房间客户端跟游戏逻辑服务器交互用的socket。也就是说，这是两个进程共用的同一个socket！不要小看这一点。如果你在创建桌子客户端程序后又新建了一个新的socket与游戏逻辑服务器进行通信，那么由此带来的玩家进入、退出、逃跑等消息会带来非常麻烦的数据同步问题，俺在刚开始的时候就深受其害。而一旦共用了同一个socket后，你如果退出桌子，服务器不涉及释放socket的问题，所以，这里就少了很多的数据同步问题。关于多个进程如何共享同一个 socket的问题，请去google以下内容：WSADuplicateSocket。

　　以上便是我根据最新的QQ游戏抓包结果分析得到的QQ游戏的通信流程，当然，这个流程更多的是客户端如何与服务器之间交互的，却没有涉及到服务器彼此之间是如何通信和作数据同步的。关于服务器之间的通信流程，我们只能基于自己的经验和猜想，得出以下想法：

　　1.Login Server与Game Hall Server之前的通信问题。Login Server是负责用户验证的，一旦验证通过之后，它要设法让Game Hall Server知道这个消息。它们之前实现信息交流的途径，我想可能有这样几条：a. Login Server将通过验证的用户存放到临时数据库中；b.　Login Server将验证通过的用户存放在内存中，当然，这个信息，应该是全局可访问的，就是说所有QQ的Game Hall Server都可以通过服务器之间的数据包通信去获得这样的信息。

　　2.Game Hall Server的最新房间目录信息的取得。这个信息，是全局的，也就是整个游戏中，只保留一个目录。它的信息来源，可以由底层的房间服务器逐级报上来，报给谁？我认为就如保存的全局登录列表一样，它报给保存全局登录列表的那个服务器或数据库。

　　3.在QQ游戏中，同一类型的游戏，无法打开两上以上的游戏房间。这个信息的判定，可以根据全局信息来判定。

　　以上关于服务器之间如何通信的内容，均属于个人猜想，QQ到底怎么作的，恐怕只有等大家中的某一位进了腾讯之后才知道了。呵呵。不过，有一点是可以肯定的，在整个服务器架构中，应该有一个地方是专门保存了全局的登录玩家列表，只有这样才能保证玩家不会重复登录以及进入多个相同类型的房间。

　　在前面的描述中，我曾经提到过一个问题：当登录当前Game Hall Server不成功时，QQ游戏服务器会选择让客户端重定向到另位的服务器去登录，事实上，QQ聊天服务器和MSN服务器的登录也是类似的，它也存在登录重定向问题。

　　那么，这就引出了另外的问题，由谁来作这个策略选择？以及由谁来提供这样的选择资源？这样的处理，便是负责负载均衡的服务器的处理范围了。由QQ游戏的通信过程分析派生出来的针对负责均衡及百万级在线系统的更进一步讨论，将在下篇文章中继续。

　　在此，特别感谢网友tilly及某位不便透露姓名的网友的讨论，是你们让我决定认真再抓一次包探个究竟。

 

      在网络应用中，“负载均衡”已经不能算是什么新鲜话题了，从硬件到软件，也都有了很多的方法来实现负载均衡。我们这里讨论的负载均衡，并不是指依靠DNS转向或其它硬件设备等所作的负载均衡，而是指在应用层所作的负载均衡。

　　一般而言，只有在大型在线系统当中才有必要引入负载均衡，那么，多大的系统才能被称为大型系统呢？比如动辄同时在线数十万的网络游戏，比如同时在线数在10万以上的WEB应用，这些我们都可以理解为大型系统，这本身就是一个宽泛的概念。

　　设计再好的服务器程序，其单个程序所能承载的同时访问量也是有限的，面对一个庞大且日益增长的网络用户群，如何让我们的架构能适应未来海量用户访问，这自然就牵涉到了负载均衡问题。支持百万级以上的大型在线系统，它的架构核心就是如何将“百万”这么大的一个同时在线量分摊到每个单独的服务器程序上去。真正的逻辑处理应该是在这最终的底层的服务器程序（如QQ游戏平台的游戏房间服务器）上的，而在此之前所存在的那些服务器，都可以被称为“引路者”，它们的作用就是将客户端一步步引导到这最终的负责真正逻辑的底层服务器上去，我们计算“百万级在线”所需要的服务器数量，也是首先考虑这底层的逻辑服务器单个可承载的客户端连接量。

　　比如：按上篇我们所分析QQ游戏架构而言，假设每个服务器程序最高支持2W的用户在线（假设一台机子只运行一个服务器程序），那么实现150万的在线量至少需要多少台服务器呢？如果算得简单一点的话，就应该是：150/2=75台。当然，这样算起来，可能并不能代表真正的服务器数量，因为除了这底层的服务器外，还要包括登录/账号服务器以及大厅服务器。但是，由于登录/账号服务器和大厅服务器，它们与客户端的连接都属于短连接（即：取得所需要信息后，客户端与服务器即断开连接），所以，客户端给这两类服务器带来的压力相比于长连接（即：客户端与服务器始终保持连接）而言就要轻得多，它们的压力主要在处理瞬间的并发访问上。

　　“短连接”，是实现应用层负载均衡的基本手段！！！如果客户端要始终与登录/账号服务器以及大厅服务器保持连接，那么这样作的分层架构将是无意义的，这也没有办法从根本上解决用户量不断增长与服务器数量有限之间的矛盾。

　　当然，短连接之所以可以被使用并能维护正常的游戏逻辑，是因为在玩家看不到的地方，服务器与服务器之间进行了大量的数据同步操作。如果一个玩家没有登录到登录服务器上去而是直接连接进了游戏房间服务器并试图进行游戏，那么，由于游戏房间服务器与大厅服务器和登录/账号服务器之间都会有针对于玩家登录的逻辑维护，游戏房间服务器会检测出来该玩家之前并没有到登录服务器进行必要的账号验证工作，它便会将玩家踢下线。由此看来，各服务器之间的数据同步，又是实现负载均衡的又一必要条件了。

　　服务器之间的数据同步问题，依据应用的不同，也会呈现不同的实现方案。比如，我们在处理玩家登录这个问题上。我们首先可以向玩家开放一些默认的登录服务器（服务器的IP及PORT信息），当玩家连接到当前的登录服务器后，由该服务器首先判断自己同时连接的玩家是不是超过了自定义的上限，如果是，由向与该服务器连接着的“登录服务器管理者”（一般是一个内部的服务器，不直接向玩家开放）申请仲裁，由“登录服务器管理者”根据当前各登录服务器的负载情况选择一个新的服务器IP和PORT信息传给客户端，客户端收到这个IP和PORT信息之后重定向连接到这个新的登录服务器上去，完成后续的登录验证过程。

　　这种方案的一个特点是，在面向玩家的一侧，会提供一个外部访问接口，而在服务器集群的内部，会提供一个“服务器管理者”及时记录各登录服务器的负载情况以便客户端需要重定向时根据策略选择一个新的登录接口给客户端。

　　采用分布式结构的好处是可以有效分摊整个系统的压力，但是，不足点就是对于全局信息的索引将会变得比较困难，因为每个单独的底层逻辑服务器上都只是存放了自己这一个服务器上的用户数据，它没有办法查找到其它服务器上的用户数据。解决这个问题，简单一点的作法，就是在集群内部，由一个中介者，提供一个全局的玩家列表。这个全局列表，根据需要，可以直接放在“服务器管理者”上，也可以存放在数据库中。

　　对于逻辑相对独立的应用，全局列表的使用机会其实并不多，最主要的作用就是用来检测玩家是不是重复登录了。但如果有其它的某些应用，要使用这样的全局列表，就会使数据同步显得比较复杂。比如，我们在超大无缝地图的MMORPG里，如果允许跨服操作(如跨服战斗、跨服交易等)的话，这时的数据同步将会变得异常复杂，也容易使处理逻辑出现不可预测性。

　　我认为，对于休闲平台而言，QQ游戏的架构已经是比较合理的，也可以称之为休闲平台的标准架构了。那么，MMORPG一般的架构是什么样的呢？

　　MMORPG一般是把整个游戏分成若干个游戏世界组，每个组内其实就是一个单独的游戏世界。而不同的组之间，其数据皆是相互独立的，并不象QQ休闲平台一样所有的用户都会有一个集中的数据存放点，MMORPG的游戏数据是按服务器组的不同而各自存放的。玩家在登录QQ游戏时，QQ游戏相关的服务器会自动为玩家的登录进行负载均衡，选择相对不忙的服务器为其执行用户验证并最终让用户选择进入哪一个游戏房间。但是，玩家在登录MMORPG时，却没有这样的自动负载均衡，一般是由玩家人为地去选择要进入哪一个服务器组，之所以这样，是因为各服务器组之间的数据是不相通的。其实，细致想来，MMORPG的服务器架构思想与休闲平台的架构思想有异曲同工之妙，MMORPG的思想是：可以为玩家无限地开独立的游戏世界（即服务器组），以满足大型玩家在线；而休闲平台的思想则是：可以为玩家无限地开游戏房间以满足大量玩家在线。这两种应用，可以无限开的都是“具有完整游戏性的游戏世界”，对于MMORPG而言，它的一个完整的游戏地图就是一个整体的“游戏世界”，而对于休闲平台，它的一个游戏房间就可以描述为一个“游戏世界”。如果MMORPG作成了休闲平台那样的全服皆通，也不是不可以，但随之而来的，就是要解决众多跨服问题，比如：好友、组队、帮派等等的问题，所有在传统MMORPG里所定义的这些玩家组织形式的规则可能都会因为“全服皆通”而改变。

　　架构的选择是多样性的，确实没有一种可以称得上是最好的所谓的架构，适合于当前项目的，不一定就适合于另一个项目。针对于特定的应用，会灵活选用不同的架构。但有一点，是可以说的：不管你如何架构，你所要作的就是－－要以尽可能简单的方案实现尽可能的稳定、高效！

 

http://xiaogui9317170.javaeye.com/blog/275576

Web站点数据库分布存储浅谈

作者：heiyeluren
网址：http://blog.csdn.net/heiyeshuwu/archive/2007/11/18/1891639.aspx

【 前言 】

网 站在Web 2.0时代，时常面临迅速增加的访问量（这是好事情），但是我们的应用如何满足用户的访问需求，而且基本上我们看到的情况都是性能瓶颈都是在数据库上，这个不怪数据库，毕竟要满足很大访问量确实对于任何一款数据库都是很大的压力，不论是商业数据库Oracle、MS SQL Server、DB2之类，还是开源的MySQL、PostgreSQL，都是很大的挑战，解决的方法很简单，就是把数据分散在不同的数据库上（可以是硬件上的，也可以是逻辑上的），本文就是主要讨论如何数据库分散存储的的问题。
目前主要分布存储的方式都是按照一定的方式进行切分，主要是垂直切分（纵向）和水平切分（横向）两种方式，当然，也有两种结合的方式，达到更到的切分粒度。

1. 垂直切分 （纵向）数据是数据库切分按照网站业务、产品进行切分，比如用户数据、博客文章数据、照片数据、标签数据、群组数据等等每个业务一个独立的数据库或者数据库服务器。
2. 水平切分 （横向）数据是把所有数据当作一个大产品，但是把所有的平面数据按照某些Key（比如用户名）分散在不同数据库或者数据库服务器上，分散对数据访问的压力，这种方式也是本文主要要探讨的。

本 文主要针对的的 MySQL/PostgreSQL 类的开源数据库，同时平台是在 Linux/FreeBSD，使用 PHP/Perl/Ruby/Python 等脚本语言，搭配 Apache/Lighttpd 等Web服务器的平台下面的Web应用，不讨论静态文件的存储，比如视频、图片、CSS、JS，那是另外一个话题。

说明：下面将会反复提到的一个名次“节点”（Node），指的是一个数据库节点，可能是物理的一台数据库服务器，也可能是一个数据库，一般情况是指一台数据库服务器，并且是具有 Master/Slave 结构的数据库服务器，我们查看一下图片，了解这样节点的架构：


(图1)



【 一、基于散列的分布方式 】

1. 散列方式介绍
基于散列（Hash）的分布存储方式，主要是依赖主要Key和散列算法，比如以用户为主的应用主要的角色就是用户，那么做Key的就可以是用户ID或者是用户名、邮件地址之类（该值必须在站点中随处传递），使用这个唯一值作为Key，通过对这个Key进行散列算法，把不同的用户数据分散在不同的数据库节点（Node）上。

我们通过简单的实例来描述这个问题：比如有一个应用，Key是用户ID，拥有10个数据库节点，最简单的散列算法是我们用户ID数模以我们所有节点数，余数就是对应的节点机器，算法：所在节点 = 用户ID % 总节点数，那么，用户ID为125的用户所在节点：125 % 10 = 5，那么应该在名字为5的节点上。同样的，可以构造更为强大合理的Hash算法来更均匀的分配用户到不同的节点上。

我们查看一下采用散列分布方式的数据结构图：

    （图2）

2. 散列分布存储方式的扩容

我们知道既然定义了一个散列算法，那么这些Key就会按部就班的分散到指定节点上，但是如果目前的所有节点不够满足要求怎么办？这就存在一个扩容的问题，扩容首当其冲的就是要修改散列算法，同时数据也要根据散列算法进修迁移或者修改。

(1) 迁移方式扩容： 修改散列算法以后，比如之前是10个节点，现在增加到20个节点，那么Hash算法就是[模20]，相应的存在一个以前的节点被分配的数据会比较多，但是新加入的节点数据少的不平衡的状态，那么可以考虑使用把以前数据中的数据按照Key使用新的Hash算法进行运算出新节点，把数据迁移到新节点，缺点但是这个成本相应比较大，不稳定性增加；好处是数据比较均匀，并且能够充分利用新旧节点。

(2) 充分利用新节点： 增加新节点以后，Hash算法把新加入的数据全部Hash到新节点上，不再往旧节点上分配数据，这样不存在迁移数据的成本。优点是只需要修改Hash算法，无须迁移数据就能够简单的增加节点，但是在查询数据的时候，必须使用考虑到旧Key使用旧Hash算法，新增加的Key使用新的Hash算法，不然无法查找到数据所在节点。缺点很明显，一个是Hash算法复杂度增加，如果频繁的增加新节点，算法将非常复杂，无法维护，另外一个方面是旧节点无法充分利用资源了，因为旧节点只是单纯的保留旧Key数据，当然了，这个也有合适的解决方案。

总结来说，散列方式分布数据，要新增节点比较困难和繁琐，但是也有很多适合的场合，特别适合能够预计到未来数据量大小的应用，但是普遍 Web2.0 网站都无法预计到数据量。





【 二、基于全局节点分配方式 】

1. 全局节点分配方式介绍

就是把所有Key信息与数据库节点之间的映射关系记录下来，保存到全局表中，当需要访问某个节点的时候，首先去全局表中查找，找到以后再定位到相应节点。全局表的存储方式一般两种：

(1) 采用节点数据库本身（MySQL/PostgreSQL）存储节点信息，能够远程访问，为了保证性能，同时配合使用 Heap(MEMORY) 内存表，或者是使用 Memcached 缓存方式来缓存，加速节点查找

(2) 采用 BDB(BerkeleyDB)、DBM/GDBM/NDBM 这类本地文件数据库，基于 key=>value 哈希数据库，查找性能比较高，同时结合 APC、Memcached 之类的缓存加速。

第一种存储方式是容易查询（包括远程查询），缺点是性能不太好（这个是所有关系型数据库的通病）；第二种方式的有点是本地查询速度很快（特别是hash型数据库，时间复杂度是O(1)，比较快），缺点是无法远程使用，并且无法在多台机器中间同步共享数据，存在数据一致的情况。

我们来描述实施 大概结构：假如我们有10个数据库节点，一个全局数据库用于存储Key到节点的映射信息，假设全局数据库有一个表叫做 AllNode ，包含两个字段，Key 和 NodeID，假设我们继续按照上面的案例，用户ID是Key，并且有一个用户ID为125的用户，它对应的节点，我们查询表获得：

  Key NodeID 13         2 148 5 22 9 125 6

 

 

 

 

 

 

 

 

 

 

 

 

 

(图3)


2. 全局节点分布方式的扩容

全局节点分配方式同样存在扩容的问题，不过它早就考虑到这个问题，并且这么设计就是为了便于扩容，主要的扩容方式是两种：

(1) 通过节点自然增加来分配Key到节点的映射扩容
这种是最典型、最简单、最节约机器资源的扩容方式，大致就是按照每个节点分配指定的数据量，比如一个节点存储10万用户数据，第一个节点存储0-10w用户数据，第二个节点存储10w-20w用户数据，第三个节点存储20w-30w用户信息，依此类推，用户增加到一定数据量就增加节点服务器，同时把Key分配到新增加的节点上，映射关系记录到全局表中，这样可以无限的增加节点。存在的问题是，如果早期的节点用户访问频率比较低，而后期增加的节点用户访问频率比较高，则存在节点服务器负载不均衡的现象，这个也是可以想方案解决的。


(2) 通过概率算法来映射Key到节点的的扩容
这种方式是在既然有的节点基础上，给每个节点设定一个被分配到Key的概率，然后分配Key的时候，按照每个节点被指定的概率进行分配，如果每个节点平均的数据容量超过了指定的百分比，比如50%，那么这时候就考虑增加新节点，那么新节点增加Key的概率要大于旧节点。
一般情况下，对于节点的被分配的概率也是记录在数据库中的，比如我们把所有的概率为100，共有10个节点，那么设定每个节点被分配的数据的概率为10，我们查看数据表结构：

NodeIDWeight110210310

现在新加入了一个节点，新加入的节点，被分配Key的几率要大于旧节点，那么就必须对这个新加入的节点进行概率计算，计算公式：10х+у=100, у>х，得出：у{10...90}，х{1...9}，x是单个旧节点的概率，旧节点的每个节点的概率是一样的，y是新节点的概率，按照这个计算公式，推算出新节点y的概率的范围，具体按照具体不同应用的概率公式进行计算。



 
【 三、存在的问题 】

现在我们来分析和解决一下我们上面两种分布存储方式的存在的问题，便于在实际考虑架构的时候能够避免或者是融合一些问题和缺点。

1. 散列和全局分配方式都存在问题

(1) 散列方式扩容不是很方便，必须修改散列算法，同时可能还需要对数据进行迁移，它的优点是从Key定位一个节点非常快，O(1)的时间复杂度，而且基本不需要查询数据库，节约响应时间。
(2) 全局分配方式存在的问题最明显的是单点故障，全局数据库down掉将影响所有应用。另外一个问题是查询量大，对每个Key节点的操作都必须经过全局数据库，压力很大，优点是扩容方便，增加节点简单。


2. 分布存储带来的搜索和统计问题

(1) 一般搜索或统计都是对所有数据进行处理，但因为拆分以后，数据分散在不同节点机器上，无法进行全局查找和统计。解决方案一是对主要的基础数据存储在全局表中，便于查找和统计，但这类数据不宜太多，部分核心数据。
(2) 采用站内搜索引擎来索引和记录全部数据，比如采用 Lucene 等开源索引系统进行所有数据的索引，便于搜索。 对于统计操作可以采用后台非实时统计，可采用遍历所有节点的方式，但效率低下。


3. 性能优化问题

(1) 散列算法，节点概率和分配等为了提高性能都可以使用编译语言开发，做成lib或者是所有php扩展形式。
(2) 对于采用 MySQL 的情况，可以采用自定义的数据库连接池，采用 Apache Module 形式加载，能够自由定制的采用各种连接方式。
(3) 对于全局数据或都频繁访问的数据，可以采用APC、Memcache、DBM、BDB、共享内存、文件系统等各种方式进行缓存，减少数据库的访问压力。
(4) 采用数据本身的强大处理机制，比如 MySQL5 的表分区或者是 MySQL5 的Cluster 。另外建议在实际架构中采用InnoDB表引擎作为主要存储引擎，MyISAM作为一些日志、统计数据等场合，不论在安全、可靠性、速度都有保障。



【 总结 】

本文泛泛的分析了在网站项目（特别是Web2.0）中关于数据库分布存储的一些方式方法，基本上上面提到的两种分布方案笔者都经过实验或者是使用过类似成型的项目，所以在实践性方面是有保障的，至于在具体实施过程中，可以按照具体的应用和项目进行选择性处理，这样，让你的网站速度飞快，用户体验一流。同时本文有些概念和描述不一定准确，如果有不足之处，请谅解并且提出来，不胜感谢。另外，如果有更好的方案或者更完善的解决方式，非常希望能够分享一下，本文更希望起到抛砖引玉的作用。（转载本文，敬请注明出处为：http://blog.csdn.net/heiyeshuwu，谢谢！ :-) ）

 

http://xiaogui9317170.javaeye.com/blog/275575

大型Web2.0站点构建技术初探

作者：heiyeshuwu

网址：http://blog.csdn.net/heiyeshuwu/archive/2007/11/18/1890793.aspx

 

一、 web2.0网站常用可用性功能模块分析

二、 Flickr的幕后故事

三、 YouTube 的架构扩展

四、 mixi.jp：使用开源软件搭建的可扩展SNS网站

五、 Technorati的后台数据库架构

六、 通过了解MySpace的六次重构经历,来认识分布式系统到底该如何创建

七、 从LiveJournal后台发展看大规模网站性能优化方法

八、 说说大型高并发高负载网站的系统架构

一、 web2.0 网站常用可用性功能模块分析

Web 2.0网站是指将传统的网站构架（平台、内容源、用户、传播方式等）转化到以用户为核心的网站构架上来，包括一系列体现web2.0概念的元素、定位和创意。web2.0网站在构架上须体现两大宗旨，即强大的后台系统和简单的前台页面，也即提供良好的用户体验，体现以人为本，技术服务人类的宗旨。

web2.0网站常用功能块通常包括以下几大项：

1. Tag 标签功能块

Tag(中文叫做"标签") 是一种新的组织和管理在线信息的方式。它不同于传统的、针对文件本身的关键字检索，而是一种模糊化、智能化的分类。

　　网页使用Tag标签的好处：

为页面设置一个或者多个Tag标签可以引导读者阅读更多相关文章，为别人带去流量同理也为自己带来流量。

可以帮助读者及时了解一些未知的概念和知识点，提高用户体验。

Tag是人的意志和趋向的体现，Tag可以帮助你找到兴趣相投的人。

　　基于以上优势，Tag标签代替了传统的分类法，成为web2.0网站使用率最高的功能块（与其说是功能块倒不如说是一种内容导航和内容组织形式）。

　　一句话：Tag标签是一种更灵活的分类方法，功能在于引导，特点是无处不在，体现智能性、模糊性和趋向性。

2. RSS 订阅功能块

RSS是在线共享内容的一种简易方式（也叫聚合内容，Really Simple Syndication）。通常在时效性比较强的内容上使用RSS订阅能更快速获取信息，网站提供RSS输出，有利于让用户获取网站内容的最新更新。网络用户可以在客户端借助于支持RSS的聚合工具软件（例如SharpReader,NewzCrawler、FeedDemon），在不打开网站内容页面的情况下阅读支持RSS输出的网站内容。

RSS订阅的方式：

订阅到客户端软件如周伯通、遨游浏览器RSS阅读、Foxmail RSS阅读等，此方式使用者较多

订阅到在线阅读（聚合类）门户网站如Google Reader，Yahoo Reader，抓虾、Gougou等，省去了安装RSS阅读器的麻烦

订阅到在线单用户聚合器如Lilina等，比较灵活

RSS订阅功能的最大好处是定向投递，也就是说RSS机制更能体现用户的意愿和个性，获取信息的方式也最直接和简单，这是RSS订阅功能备受青睐的一大主要原因。

3. 推荐和收藏功能块

　　说到推荐功能，不仅web2.0网站在大量使用，传统的以cms平台为代表的内容模式的网站也在大量使用，推荐功能主要是指向一些网摘或者聚合类门户网站推荐自己所浏览到的网页。当然，一种变相的推荐就是阅读者的自我收藏行为，在共享的模式下也能起到推荐的作用。

　　比较有名的推荐目标有以del.icio.us为代表的网摘类网站包括国内比较有名气的365key、和讯网摘、新浪vivi、天极网摘等。这里值得一提的是前段时间曾涌现了大批网摘类网站，但他们坚持活下来的好像没有几个了，推荐使用前面提到的这几个网摘门户，人气基本上是使最旺的。

4. 评论和留言功能块

web2.0强调参与性，强调发挥用户的主导作用，这里的参与性除了所谓的订阅、推荐功能外更多地体现在用户对内容的评价和态度，这就要靠评论功能块来完成。一个典型的web2.0网站或者说一个能体现人气的web2.0网站都会花大量篇幅来体现用户的观点和视觉。这里尤其要提到web2.0中的带头老大web blog，评论功能已经成为博客主人与浏览者交流的主要阵地，是体现网站人气的最直观因素。

　　评论功能块应用在博客系统中实际上已经和博客内容相分离，而更好的应用恰恰是一些以点评为主的web2.0网站比如豆瓣、点评网等，这里的评论功能块直接制造了内容也极大地体现了网站的人气，所以说评论功能块是web2.0网站最有力的武器。

5. 站内搜索功能块

　　搜索是信息来源最直接的方式之一，无论你的网站是否打上web2.0的烙印，搜索对于一个体系庞大、内容丰富的大型网站都是非常必要的。Tag 标签在某种程度上起到搜索的作用，它能够有效聚合以此Tag为关键词的内容，但这种情况的前提是此Tag标签对浏览者是可见的，也就是说当Tag标签摆在浏览者的眼前时才成立，而对于那些浏览者想要的信息却没有Tag标签来引导时搜索就是达到此目的的最好方法。

　　对于web2.0网站，站内搜索以标题或者Tag为搜索域都能起到好的效果，但本人不建议使用内容搜索域，因为这不符合搜索的高效性原则。同时，具有突出关键词的内容往往都可以用Tag标签来引导，因此使用内容域来搜索实际上是一种浪费服务器资源的行为，而且搜索结果的准确性将大打折扣。

6. 群组功能块

　　我为什么要把群组作为web2.0网站的功能块来分析呢，因为群组是web2.0网站的一大特点，也是web2.0所要体现的服务宗旨所在。一个web2.0网站，博客也好、播客也好、点评也好，抑或是网摘、聚合门户，他们都强调人的参与性。物以类聚、人以群分，每个参与者都有自己的兴趣趋向，web2.0网站的另一主要功能就是帮助这些人找到同样兴趣的人并形成一个活跃的群体，这是web2.0网站的根本。

总结：web2.0网站倡导的是集体创作、共享资源，靠的是人气，体现的是参与性，一个没有参与性的web2.0网站都不足以成为web2.0。以上提到的这几个功能块就是以吸引用户参与和引导用户参与为目的的，真正的web2.0不是什么深奥的东西，只有一点，那就是如何让浏览者沸腾起来。

 

http://xiaogui9317170.javaeye.com/blog/275568

闲谈 Web 图片服务器

作者: Fenng | 可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息及版权声明
网址: http://www.dbanotes.net/web/web_image_server.html

 

现在很多中小网站(尤其是 Web 2.0 站点) 都允许用户上传图片，如果前期没有很好的规划，那么随着图片文件的增多，无论是管理还是性能上都带来很多问题。就自己的一点理解，抛砖引玉，以期能引出更具价值的信息。

事关图片的存储

把图片存储到什么介质上? 如果有足够的资金购买专用的图片服务器硬件或者 NAS 设备，那么简单的很；如果有能力自己开发单独存储图片的文件系统，那么也不用接着往下看了。

如果上述条件不具备，只想在普通的硬盘上存储，首先还是要考虑一下物理硬盘的实际处理能力。是 7200 转的还是 15000 转的，实际表现差别就很大。是选择 ReiserFS 还是 Ext3 ，怎么也要测试一下吧? 创建文件系统的时候 Inode 问题也要加以考虑，选择合适大小的 inode size ，在空间和速度上做取舍，同时防患于未然，注意单个文件系统下文件个数别达到极限。

独立，独立的服务器

无论从管理上，还是从性能上看，只要有可能，尽量部署独立的图片服务器。这几乎成为常识了(不过在我做过面向 Web 的项目之前就这个问题也被人笑话过)。具备独立的图片服务器或者服务器集群后，在 Web 服务器上就可以有针对性的进行配置优化。比如采用传说中更有效率的 Lighttpd 。

如果不想在几台机器间同步所有图片，只用 NFS 模式共享一下即可。注意软、硬连接可能带来的问题，以及 NFS 特定的传输速度。

独立，独立的域名

如果大部分 Web 页面必须要载入很多图片，那么需要注意 IE 浏览器的连接数 问题(参见对该问题的测试 )。

前几天有个朋友在线上问我，"一些大网站，图片服务器为什么都用另外一个域名? 比如yahoo.com 图片服务器用了 yimg.com 的域名?" ，粗糙一点的答案：除了管理方便，便于CDN 同步处理，上面说的 IE 连接数限制也是个考虑因素吧(其他原因我也不知，有请 Yahoo！的同学发言) 【还有一个我没考虑到的是 Cookie 的因素，参加楼下高春辉 的留言】

雅虎 Web 优化 14 条

关于雅虎 YSlow 工具倡导的 优化 14 条规则 ，建议每个 Web 维护人员必须倒背如流，当然也应该辩证来看--介绍这 14 条规则的页面本身也只能得到 70 多分...其中的第九条和上面说的独立域名之间多少有些矛盾。实际情况要根据自己的 Benchmark 与具体需求而确定了。

有效利用客户端 Cache

很多网站的 UI 设计人员为了达到某些视觉效果，会在一些用户需要频繁访问的页面模块上应用大量的图片。这样的情况，研究表明 ，对于用户粘度比较高的站点， 在Web 服务器上对这一类对象设置 Expires Header 就是十分有必要的，大量带宽就这么节省下来，费用也节省了下来。顺便说一下，对于验证码这样的东西，要加个简单的规则过滤掉。

服务器端的 Cache

在国内，CDN 也是有钱才能玩得起。而类似 Amazon S3 这样的一揽子存储服务，国内还没有出现。所以，充分利用服务器端的 Cache 也是有必要的。Squid 作为反向代理服务器，缓冲图片效果应该说尚可，新浪技术团队贡献的 Ncache 据评测，效果更佳。

高解析图片问题

如果网站存在大量高解析度的图片，那么有必要考虑部署 IIPImage 或者类似的软件。

运营问题

很多比较有规模的网站对于用户上传的图片不做任何处理，结果页面上还能看到很多 BMP 格式的图片(个人觉得任何网站出现 BMP 格式的图片都是可耻的)...这完全是运营上的策略之误了。找个程序员投入一点时间写个图片处理模块，对那些"截屏"得来的图片做个转换，投入成本可能远比存储上的开销小，而用户再访问该图片，质量未必能有什么损失，浏览速度无疑好多了。哪种处理方式更让人接受，不言而喻。

--EOF--

图片处理工具的选择

可能大多数网站都是选择 ImageMagick 做为基础库，不过这里也有一篇 GraphicsMagick 1.2 vs ImageMagick 6.3.6 Benchmark Report ，如果图片处理量巨大，性能问题又怎能不考虑?

 

http://xiaogui9317170.javaeye.com/blog/275561

性能扩展问题要趁早

作者: Fenng | 可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息及版权声明
网址: http://www.dbanotes.net/arch/scaling_an_early_stage_startup.html

 

与国内的 Web 2.0 Startup 技术人员相比，国外技术人员更乐于分享。分享也是一种更好的宣传手段，如果不是看到了这篇 Scaling an early stage startup ， 或许我就不会知道这位 Mark Maunder (他还有个中文名字：马孟德) 以及他的 FeedJet 。

一般来说，一个刚刚发布的 Web 应用，因为用户量并不多，性能问题可能并不是很明显。可一旦宣传展开，用户增长或许不是线性的而是暴增(从几十个到几万个，相比之下怎不是暴增?)，这时候如果遇到性能问题，毫无疑问会影响初期用户的信任。

Maunder 文档中列举了一个扩展过程，相信这些例子也是他实际遇到的。毕竟 Startup 都是一两个人打通关，不可能所有技术都面面俱到的精通。下面记录一点。

错误的设置

数据库服务器的参数配置问题：导致 MySQL 消耗了大量资源。Apache Keepalive 的设置为不合理，修改为 off。我想这个前提应该还是要选择自己最擅长的技术路线。如果错误的选择另一条不熟悉的技术路线，那么遇到技术时解决问题的速度怕是更让用户恼火。对于 Apache 还应该知道 Httpd.Worker 比 Prefork 消耗更多内存 (httperf 来进行 Benchmark) ，内存也是蛮贵的。

尽可能的缓存动态内容

尽可能的利用数据库的 Cache，利用其他 Cache 工具，如 MemCacheD ，来减轻对磁盘的 IO 压力。为了节省成本，很多站点都是用的低速大容量的磁盘，所以，充分利用 Cache 是一个网站成功的必然条件。这样的软件BerkeleyDB 的最高事务处理记录是 90000 事务/秒。

剥离图片与CSS 到单独的服务器

说白了，也是为了减轻磁盘的压力。现在很多 Web 2.0 站点都把图片放到 Amazon S3 上，省心了不少。当然，国内还没这样的服务。

阻止内容引用"窃贼"

现在连那些大站点都在阻止图片被第三方引用 ，小站点更要提防被大站引用，很容易耗光网站的容量。另外一个要注意的是网络爬虫的频率。

在线观看这篇 Scaling an early stage startup 。顺便说一下，最近在 Scribd 上看到了不少有意思的文档。

 

http://blog.yening.cn/2007/03/25/226.html#more-226

主题：大型、高负载网站架构和应用初探
时间：30-45分钟

开题：163,sina,sohu等网站他们有很多应用程序都是PHP写的，为什么他们究竟是如何能做出同时跑几千人甚至上万同时在线应用程序呢?

挑选性能更好web服务器
单台 Apache web server 性能的极限
选用性能更好的web server TUX,lighttpd,thttpd …
动，静文件分开，混合使用
应用程序优化,Cache的使用和共享
常见的缓存技术
生成静态文件
对象持久化 serialize & unserialize
Need for Speed ，在最快的地方做 cache
Linux 系统下的 /dev/shm
tmpfs/ramdisk
php内置的 shared memory function /IPC
memcached
MySQL的HEAP表
多台主机共享cache
NFS,memcached,MySQL 优点和缺点比较
MySQL数据库优化
配置 my.cnf，设置更大的 cache size
利用 phpMyAdmin 找出配置瓶颈，榨干机器的每一点油
集群(热同步,mysql cluster)
集群，提高网站可用性
最简单的集群，设置多条A记录，DNS轮询，可用性问题
确保高可用性和伸缩性能的成熟集群解决方案
通过硬件实现，如路由器,F5 network
通过软件或者操作系统实现
基于内核,通过修改TCP/IP数据报文负载均衡，并确保伸缩性的 LVS以及 确保可用性守护进程ldirectord
基于 layer 7，通过URL分发的 HAproxy
数据共享问题
NFS,Samba,NAS,SAN
案例
解决南北互通，电信和网通速度问题
双线服务器
CDN
根据用户IP转换到就近服务器的智能DNS,dnspod …
Squid 反向代理,(优点,缺点)
案例

--------------------------------------------------------------------------------
附记：

pea上海的负责人h058在3月1日就邀请我希望我在pea上能说点什么，虽然我觉得我还是算健谈，但是觉得需要在如此正规的场合做演讲我还是真没有经验的，就连ppt我都不会做。一开始h058叫我说说linux下svn的部署，但是我觉得这个题目太浅了，也没有什么花头可以说。于是就想说点其它的。正好这段时间自己对服务器部署方面和应用程序优化这方面非常感兴趣，也想认真归纳了一下，于是就敲定这个题目了。

写大纲非常快10号左右基本上要说的话题都定下来了，虽然要说的东西基本上都非常熟悉如MySQL,Apache，包括集群的两个应用LVS和Haproxy自己也亲自做过试验，但是还是考虑到演讲的过程中会有些朋友提出一些比较刁难的问题，自己不懂，于是还是做了认认真真地对每个细节做足了功课，并且在每天睡醒地时候自己默默地在脑子里面像电影那样过一片。
3月24日,交大惠谷创业中心,shopex 407 培训教室….. PEA Shanghai 第七次聚会开始，与会人数约30人，还是10多名php的培训学员.

一开始是无喱头同学演讲的”PHPCMS系统的设计”，可能是对与会人员参与的情况了解不足，在系统宏观讲解和一些程序处理细节上觉得重点没有突出，到处着墨，洋洋洒洒18页Word文档，近1小时的演讲我已经听得已经云里雾里了，环顾四周，身边来培训php的一位小mm已经在偷偷睡觉了…..

15:55 分，无喱头同学觉得自己说得实在有点深了，主动提出中止演讲，休息十分钟，到我上场。

演讲意外的顺利，35分钟，从开题到留homework，行云流水，一气呵成，连水都没有喝一口，其中加入了不少极兴发挥，那时候觉得情绪非常激昂，浑身充满力量，唯一不爽的就是喉咙有点痛，呵呵:)

当我宣布“好好学习 天天向上”演讲结束后，同学们爆出热烈地掌声，那时，我深深地吐了一口气，压在心里的多日的大石终于落下来了，演讲看起来非常成功。

在演讲的过程中，我发现刚才睡觉的小MM居然也在聚集汇神地听我说话，让我值得感动的是发现还有不少同学在记笔记，没有人打瞌睡，结束还是很多人问我拿ppt。我问马哥我说得如何，马哥评价说“条例清晰，思路明确，语速平稳，真的不错!”,h058也称赞道我把现场的气氛调动起来了。嗯，那基本上可以肯定这次演讲还是做得不错了，自己给自己打分的话，88分！

回想一下，其实还觉得有一些不足的，觉得语速还是偏快了，没有抑扬顿挫感觉。并且声音太大，弄得自己喉咙不舒服。情绪还不是太稳定，稍微有点激动了。还有不知道是大家全都熟悉我说的话题还是我说得很透彻，基本上没有人提出问题。而我觉得好一个好的讲师，应该能调动大家的积极性，让大家一起参与话题的讨论中来，这点看来还需要继续锻炼。

通过这次演讲，发现自己在做一些即兴发挥的话题还有演讲方面等还是有点天赋和潜力可挖，以后一定要多多参加锻炼。并总结出要将一个演讲做好，要准备以下几点：

1) 精心的准备(包括选题和对听众的了解)
2) 稳定的心态和平稳的情绪
3) 热诚，全付身心的投入
4) 平时语言和谈吐技巧的积累
5) 想办法让听众参与到你的话题中.

演讲使用的ppt：peash-2007-3-25.ppt