这三份文档主要阐述了一个系统的设计和实现过程，从系统分解为层次、层次内的模块以及相互的接口、模块分解为对象以及对象的接口、实现这些对象接口的方法。

XXX架构设计说明书

(架构设计重点在于将系统分层并产生层次内的模块、阐明模块之间的关系)

一.  概述

描述本文的参考依据、资料以及大概内容。

二.  目的

描述本文编写的目的。

三.  架构设计

阐明进行架构设计的总体原则，如对问题域的分析方法。

3.1.       架构分析

对场景以及问题域进行分析，构成系统的架构级设计，阐明对于系统的分层思想。

3.2.       设计思想

阐明进行架构设计的思想，可参考一些架构设计的模式，需结合当前系统的实际情况而定。

3.3.       架构体系

根据架构分析和设计思想产生系统的架构图，并对架构图进行描述，说明分层的原因、层次的职责，并根据架构图绘制系统的物理部署图，描述系统的部署体系。

3.4.       模块划分

根据架构图进行模块的划分并阐明模块划分的理由，绘制模块物理图以及模块依赖图。

3.4.1.       模块描述

根据模块物理图描述各模块的职责，并声明其对其他模块的接口要求。。

3.4.2.       模块接口设计

对模块接口进行设计，并提供一定的伪代码。

XXX概要设计说明书

(概要设计重点在于将模块分解为对象并阐明对象之间的关系)

一.  概述

描述本文的参考依据、资料以及大概内容。

二.  目的

描述本文的编写目的。

三.  模块概要设计

引用架构设计说明书中的模块图，并阐述对于模块进行设计的大致思路。

3.1.       设计思想

阐明概要设计的思想，概要设计的思想通常是涉及设计模式的。

3.2.       模块A

3.2.1.       概要设计

根据该模块的职责对模块进行概要设计(分解模块为对象、描述对象的职责以及声明对象之间的接口)，绘制模块的对象图、对象间的依赖图以及模块主要功能的序列图，分别加以描述并相应的描述模块异常的处理方法。

3.2.2.       模块接口实现

阐明对于架构设计中定义的模块接口的实现的设计。

XXX详细设计说明书

(详细设计重点在于对模块进行实现，将模块的对象分解为属性和方法，并阐述如何实现)

一.  概述

阐述本文的参考依据、资料以及大概内容。

二.  目的

阐述本文的编写目的。

三.  模块详细设计

3.1.       设计思想

阐述对模块进行详细设计的思想。

3.2.       模块A

3.2.1.       详细设计

根据模块概要设计详细描述对于模块内对象的实现，包括对象的职责、属性、方法、对象内功能的流程图、对象关联的类、对象的异常。(需要绘制的主要为类图)

Hadoop and Hive

Hadoop的是一个开源的map-reduce实现，使得它可以在进行大数据上进行运算。 Facebook的使用这个进行数据分析（而我们都知道，Facebook已经大量的数据）。 Hive就是发源于Facebook，使得对于Hadoop使用的SQL查询成为可能，从而是其更容易对非程序员使用。

Hadoop和Hive是开源的（Apache项目），有为数众多的追随者，例如雅虎和Twitter。

Thrift

Facebook使用的几种不同的语言和不同的services。 PHP是最终用于前端，Erlang是用于聊天，Java和C ++也使用于多种场所，也许还有其他语言。Thrift是一个内部开发的跨语言的框架，联系语言，使他们可以在一起合作，从而使他们之间可以交互。 这使得Facebook可以更容易为继续保持其跨语言的发展。

Facebook已经让Thrift开源。更多的语言支持已被添加到Thrift。

Varnish

Varnish是一个HTTP加速器，可以作为一个负载平衡器，并缓存的内容，然后可以以闪电般的速度送达。

Facebook使用的arnish来处理照片和个人资料图片，处理每天数十亿的要求。 和其他的东西一样，Varnish是开源的。

保持Facebook 顺畅运行的其他东西

我们已经提到的软件，组成了Facebook的系统，并帮助运行在大规模上。 但是，处理这么大的系统是一个复杂的任务，因此我们将列出一些其他的东西，他们保持了Facebook的平稳运行。

渐进发布和暗启动

Facebook有一个他们所谓的守门人制度（Gatekeeper），允许他们可以给不同的用户运行两套不同的系统。 这让Facebook渐进的发布新的功能，A / B测试，只为Facebook雇员发布等的某些特性。

Gatekeeper也可以让Facebook实现“暗启动”，这是在用户使用一些功能之前，就激活某些功能（因为用户没有察觉，所以称之为暗 启动）。 这将作为一个现实世界的压力测试，在正式启动前，帮助揭露一些功能障碍和其他问题。 暗启动通常是在正式启动前两个星期。

Profiling的直播系统

Facebook的仔细监控其系统，有趣的是它也负责监察每一个PHP函数在生产环境的性能。 检测各个PHP的环境的配置运行情况。使用开源工具，XHProf 。

渐进的利用关闭功能来提升性能

如果Facebook运行时出现性能问题，有一个办法，就是逐步禁用不太重要的功能，以增强Facebook的大量核心功能表现。

我们没有提及的事情

我们没有提到硬件相关的事情，但这也是提高可伸缩性的重要一环。例如，就像其他大型站点，Facebook利用CDN来处理静态内容。 Facebook还有一个the huge data center，可以帮助他扩展更多的服务。

Facebook的开源情节

不仅是Facebook使用（和帮助），如Linux，Memcached的，MySQL和Hadoop的开源软件，以及许多其他情况下， 也贡献许多了其内部开发的软件。

Facebook亦开源了Tornado，一个高性能的网络服务器框 架，由FriendFeed团队开发。关于开放源码软件清单，可以在Facebook’s Open Source page.找到。

在了解过世界最大的PHP站点，Facebook的后台技术后，今天我们来了解一个百万级PHP站点的网站架构：Poppen.de。Poppen.de 是德国的一个社交网站，相对Facebook、Flickr来说是一个很小的网站，但它有一个很好的架构，融合了很多技术，如 Nigix、MySql、CouchDB、Erlang、Memcached、RabbitMQ、PHP、Graphite、Red5以及Tsung。

目前有200万注册用户数、2万并发用户数、每天20万条私有消息、每天25万登录次数。而项目团队有11个开发人员，两个设计，两个系统管理员。该站点的商业模式采用免费增值模式，用户可以使用搜索用户、给好友发送消息、上载图片和视频等功能。

如果用户想享受不受限制发送消息和上载图片，那么就得根据需要支付不同类型的会员服务，视频聊天及网站其他服务也采用同样的策略。

Nginx

Poppen.de 所有的服务都是基于Nginx服务上的。前端有两台Nginx服务器在高峰期提供每分钟15万次请求的负载，每个机器已经有四年寿命，并且只有一个CPU 和3GB RAM。Poppen.de拥有三台独立的图像服务器，由三台Nginx服务器为*.bilder.poppen.de提供每分钟8万次请求服务。

Nginx 架构中一个很酷的设计就是有很多请求是由Memcached处理的，因此请求从缓存中获取内容而不需要直接访问PHP机器。比如，用户信息页(user profile)是网站需要密集处理的内容，如果把用户信息页全部缓存到Memcached上，那么请求直接从Memcached上获取内容。 Poppen.de的Memcached每分钟可以处理8000次请求。

架构中有三个Nginx图像服务器提供本地图像缓存，用户上载图 像到一个中央文件服务器。当向这三个Nginx之一中请求图像时，如果服务器本地中没有存在该图像，则从中央文件服务器下载到该服务器上作缓存并提供服 务。这种负载均衡的分布式图像服务器架构设计可以减轻主要存储设备的负载。

PHP-FPM

该网站运行在PHP- FPM上。共有28台双CPU、6GB内存的PHP机器，每个机器上运行100个PHP-FPM的工作线程。使用启用了APC的PHP5.3.x。 PHP5.3可以降低CPU和内存使用率的30%以上。

程序代码是基于Symfony1.2框架之上开发的。一是可以使用外部资源，二是 能够提高项目开发进度，同时在一个著名的框架上可以让新开发人员更容易加入到团队中来。虽然没有任何事情都是十全十美的，但可以从Symfony框架中得 到很多好处，让团队可以更多的精力放在Poppen.de的业务开发上去。

网站性能优化使用XHProf，这是Facebook开源出来的一个类库。这个框架非常容易个性化和配置，能够可以缓存大部分高代价的服务器计算。

MySQL

MySQL是网站主要的RDBMS。网站又几个MySql服务器：一台4CPU、32GB的服务器存储用户相关信息，如基本信息、照片描述信息 等。这台机器已经使用了4 年，下一步计划会使用共享集群来替换它。目前仍基于这个系统上进行设计，以简化数据访问代码。根据用户ID进行数据分区，因为网站中大部分信息都是以用户 为中心的，如照片、视频、消息等。

有三台服务器按主-从-从配置架构提供用户论坛服务。一台从服务器负责网站自定义消息存储，到现在有 2.5亿条消息。另外四台机器为主-从配置关系。另外由4台机器配置成NDB族群专门服务于密集型写操作数据，如用户访问统计信息。

数据表设计尽量避免关联操作，尽可能缓存最多的数据。当然，数据库的结构化规范已经完全被破坏掉了。因此，为了更容易搜索，数据库设计创建了数 据挖掘表。大部分表是MyISAM型表，可以提供快速查找。现在的问题是越来越多的表已经全表锁住了。Poppen.de正考虑往XtraDB存储引擎上 迁移。

Memcached

网站架构中Memcached应用相当多，超过45GB的高速缓存和51个节点。缓存了Session会话、视图缓存以及函数执行缓存等。架构 中有一个系统 当记录被修改时可以自动地把数据更新到缓存中去。未来改善缓存更新的可能方案是使用新的Redis Hash API或者MongoDB。

RabbitMQ

在 2009年中开始在架构中使用RabbitMQ。这是一个很好的消息解决方案，便于部署和集中到这个架构中去，在LVS后运行了两台RabbitMQ服务 器。在上个月，已经把更多的东西集成到该队列中，意味着同一时刻有28台PHP服务器每天要处理50万次请求。发送日志、邮件通知、系统消息、图像上载等 更多的东西到这个队列中。

应用PHP-FPM中的fastcgi_finish_request()函数集成队列消息，可以把消息异步发 送到队列中。当系统需要给用户发送HTML或JSON格式响应时，就调用这个函数，这样用户就没有必要等到PHP脚本清理。

这个系统可以改善架构资源管理。例如，在高峰期服务每分钟可以处理1000次登录请求。这表示有1000并发更新用户表保存用户的登录时间。由 于使用了队列机制，可以 按相反的顺序来运行这些查询。如果需要提高处理速度，只需要增加更多的队列处理者即可，甚至可以增加更多的服务器到这集群中去，而不需要修改任何配置和部 署新节点。

CouchDB

日志存储CouchDB运行在一台机器上。在这台机器上可以根据模块/行为进行日志查询 /分组，或者根据错误类型等等。这对定位问题非常有用。在使用日志聚合服务CouchDB之前，不得不逐台登录到PHP服务器上设法日志分析定位问题，这 是非常麻烦的。而现在把所有的日志集中到队列中保存到CouchDB中，可以集中进行问题检查和分析。

Graphite

网站使用Graphite采集网站实时信息并统计。从请求每个模块/行为到Memcached的命中和未命中、RabbitMQ状态监控以及 Unix负载等等。Graphite服务平均每分钟有4800次更新操作。实践已经证实要监测网站发发生什么是非常有用的，它的简单文本协议和绘图功能可 以方便地即插即 用的方式用于任何需要监控的系统上。

一件很酷的事情是使用Graphite同时监控了网站的两个版本。一月份部署了Symfony框架新 版本，以前代码作为一个备份部署。这就意味着网站可能会面临性能问题。因此可以使用Graphite来对两个版本在线进行对比。

发现新版本上的Unix负载表较高，于是使用XHProf对两个版本进行性能分析，找出问题所在。

Red5

网站为用户也提供了两种类型的视频服务，一种是用户自己上载的视频，另外一种是视频聊天，用户视频互动和分享。到2009年年中，每月为用户提供17TB的流量服务。

Tsung

Tsung 是一个Erlang编写的分布式基准分析工具。在Poppen.de网站中主要用于HTTP基准分析、MySQL与其他存储系统(XtraDB)的对比分 析。用一个系统记录了主要的MySQL服务器的流量，再转换成Tsung的基准会话。然后对该流量进行回放，由Tsung产生数以千计的并发用户访问实验 室的服务器。这样就可以在实验环境中与真实场景非常接近。

收集性能计数器注释，以备使用!

1  % Processor Time (Processor _Total)
指处理器用来执行非闲置线程时间的百分比。计算方法是，度量处理器用来执行空闲线程的时间，然后用 100% 减去该值。
如果该参数值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。

2  Processor\% User Time\_Total
   表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。

3  Memory\Pages/sec
   Hard Paging-Memory:Pages/sec > 0 或 Memory:Page Reads/sec > 5
Memory:Pages/sec > 0 或 Memory:Page Reads/sec > 5 表示 Windows 将通过磁盘解决内存引用（强制分页错误）。这需要消耗磁盘 I/O 和 CPU 资源。Memory:Pages/sec 是一个指示 Windows 正在执行的分页数量和数据库服务器当前的 RAM 配置是否充足的有效指示器。Performance Monitor 中的强制分页信息的子集是 Windows 每秒钟必须读取分页文件以解决内存引用的次数，它用“Memory:Pages Reads/sec”表示。如果“Memory:Pages Reads/sec > 5，那么这对于性能是不利的。
 
    每秒磁盘读写页数
这会导致硬页故障，从而导致SQL Server依赖页文件而不是依赖内存。如果这个计数器的平均值为20，你可能需要添加额外的RAM来停止内存分页。
 
4   Memory\Available Mbytes
     它测量可用于运行进程的物理内存量（单位为兆字节）。如果此值低于总物理 RAM 的 5%，则意味着内存不足，分页活动可能会增加。要解决此问题，应增加更多的内存。

5  Memory: Page Faults / sec
  如果该值偶尔走 高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈

6  PhysicalDisk\Avg. Disk Queue Length\_Total
该值应不超过磁盘数的1.5~2倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘。

7  PhysicalDisk\Avg. Disk sec/Read\_Total
   它测量从磁盘读取数据的平均时间（以秒为单位）。如果此数字大于 25 毫秒 (ms)，则意味着从磁盘读取数据时磁盘系统发生了延迟。对于托管 SQL Server(R) 和 Exchange Server 的关键任务服务器，可接受的阈值要低得多，约为 10 ms。

8  PhysicalDisk\Avg. Disk sec/Write\_Total
   它测量将数据写入磁盘所需的平均时间（以秒为单位）。如果此数字大于 25 ms，则意味着写入磁盘时磁盘系统发生了延迟。对于托管 SQL Server 和 Exchange Server 的关键任务服务器，可接受的阈值要低得多，约为 10 ms

9  PhysicalDisk\Disk Reads/sec\_Total
取决于制造商检查磁盘的指定传送速度，以验证此速度没有超出规格。通常，Ultra Wide SCSI 磁盘
每秒可以处理 50 到 70 次 I/O 操作。

10 PhysicalDisk\Disk Writes/sec\_Total
取决于制造商检查磁盘的指定传送速度，以验证此速度没有超出规格。通常，Ultra Wide SCSI 磁盘
每秒可以处理 50 到 70 次 I/O 操作。 

9b  PhysicalDisk\Disk sec /Reads\_Total   <8ms
10b PhysicalDisk\Disk sec /Writes \_Total   < 8ms (non cached) < 1ms (cached)

11 SQLServer:Access Methods\Full Scans/sec
 a每秒不受限制的完全扫描数。这些扫描可以是基表扫描，也可以是全文索引扫描。合理范围：<5
 b如果该指标的值比1或2高，应该分析设计的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化
12 SQLServer:Access Methods\page Splits/sec
  每秒由于索引页溢出而发生的页拆分数。合理范围：越小越好，可降低填满因子的设定值或重建索引还减少每秒的页分割数量。
13 SQLServer:Access Methods\Worktables Created/sec
   每秒创建的工作表数。例如，工作表可用于存储查询假脱机、LOB 变量、XML 变量和游标的临时结果。
 
14 SQLServer:Buffer Manager\Buffer cache hit ratio
 比率最好为90% 或更高。表示90% 以上的数据请求可以从数据缓冲区中获得所需数据。

15 SQLServer : Catalog Metadata: Cache Hit Ratio
  该值越高越好。如果持续低于80%，应考虑增加内存。 注意该参数值是从SQL Server启动后，就一直累加记数，所以运行经过一段时间后，该值将不能反映系统当前值。

16 SQLServer:Buffer Manager\Checkpoint pages/sec
  由要求刷新所有脏页的检查点或其他操作每秒刷新到磁盘的页数。

17 SQLServer:Buffer Manager\Lazy writes/sec
  每秒被缓冲区管理器的惰性编写器写入的缓冲区数。惰性编写器是一个系统进程，用于成批刷新脏的老化的缓冲区（包含更改的缓冲区，必须将这些更改写回磁盘，才能将缓冲区重用于其他页），并使它们可用于用户进程。惰性编写器不需要为创建可用缓冲区而频繁执行检查点。
合理范围：0

18 SQLServer:Buffer Manager\Page life expectancy
  页若不被引用将在缓冲池中停留的秒数。
  Page Life Expectancy (PLE) 计数器帮助确定是否内存不足。PLE 计数器显示数据页在缓冲区高速缓存中停留的时间。行业中该计数器的可接受阈值为 300 秒。如果在很长一段时间内显示的值平均小于 300 秒，则表明从内存中刷新数据页的频率过高。如果出现这种情况，将导致 Resource Monitor 负载加重，从而导致处理器的活动增多。应该将 PLE 计数器和 Checkpoints Pages/sec 计数器一起进行评估。在系统中出现检查点时，缓冲区高速缓存中的脏数据页被刷新到磁盘，从而导致 PLE 值下降。Resource Monitor 进程是真正将这些页刷新到磁盘的机制，所以在出现这些检查点期间，您应该还会看到 Lazy Writes/sec 值增加。如果完成检查点后 PLE 值立即增加，您可以忽略这种短暂现象。另一方面，如果发现经常低于 PLE 阈值，则此时非常适合使用多出的内存缓解您的问题，同时将一些资源释放回 CPU。

19 SQLServer:Databases\Data File(s) Size (KB)\sqlh2
  数据库中所有数据文件的累计大小 (KB)，包括任何自动增长。监视此计数器非常有用，例如可以确定 tempdb 的准确大小。

20 SQLServer:Databases\Log File(s) Size (KB)\sqlh2
   数据库中所有事务日志文件的累计大小 (KB)。

21 SQLServer:Databases\Log File(s) Used Size (KB)\sqlh2
  数据库中所有日志文件的累计已用大小。

22 SQLServer:Latches\Latch Waits/sec
  未能立即授予的闩锁请求数。
  合理范围：越小越好，值过大表明服务器可能存在对资源的竞争问题。

23 SQLServer:Latches\Average Latch Wait Time (ms)
   必须等待授予的闩锁请求的平均等待时间（毫秒）。如果该指标的值很高，则系统可能正经历严重的资源竞争问题。

24 SQLServer:Locks\Lock Waits/sec\_Total
  每秒要求调用者等待的锁请求数
25 SQLServer:Locks\Average Wait Time (ms)\_Total
   每个导致等待的锁请求的平均等待时间（毫秒）。

26 SQLServer:SQL Statistics\Batch Requests/sec
  每秒收到的 Transact-SQL 命令批数。 这一统计信息受所有约束（如 I/O、用户数、高速缓存大小、请求的复杂程度等）影响。 批处理请求数值高意味着吞吐量很好

27 SQLServer:SQL Statistics\SQL Compilations/sec
   每秒的 SQL 编译数。 表示编译代码路径被进入的次数。 包括 SQL Server 中语句级重新编译导致的编译。 当 SQL Server 用户活动稳定后，该值将达到稳定状态

28 SQLServer:SQL Statistics\SQL Re-Compilations/sec
   每秒语句重新编译的次数。 计算语句重新编译被触发的次数。 一般来说，这个数最好较小。 在更高版本的 SQL Server 中，重新编译发生在语句级别，而不是发生在 Microsoft SQL Server 2000 中的批处理级别。 因此，不能直接比较 SQL Server 和早期版本中该计数器的值。

29 SQLServer:Memory Manager\Memory Grants Pending
   等待工作空间内存授权的进程总数。

30 PhysicalDisk\% Idle Time
它测量磁盘在采样间隔期间的空闲时间百分比。如果此计数器低于 20%，则表示磁盘系统处于满负荷状态。可考虑将当前的磁盘系统更换为速度更快的磁盘系统。

当您怀疑计算机硬件是影响SQL Server运行性能的主要原因时，可以通过SQL Server Performance Monitor监视相应硬件的负载，以证实您的猜测并找出系统瓶颈。下文将介绍一些常用的分析对象及其参数。 

　　Memory: Page Faults / sec

　　如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。

　　Process: Working Set

　　SQL Server的该参数应该非常接近分配给SQL Server的内存值。在SQL Server设定中，如果将"set working set size"置为0, 则Windows NT会决定SQL Server的工作集的大小。如果将"set working set size"置为1，则强制工作集大小为SQLServer的分配内存大小。一般情况下，最好不要改变"set working set size"的缺省值。

　　Process:%Processor Time

　　如果该参数值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。

　　Processor:%Privileged Time

　　如果该参数值和"Physical Disk"参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。另外设置Tempdb in RAM，减低"max async IO"，"max lazy writer IO"等措施都会降低该值。 

　　Processor:%User Time

　　表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。

　　Physical Disk:Avg.Disk Queue Length

　　该值应不超过磁盘数的1.5~2倍。要提高性能，可增加磁盘。

　　注意:一个Raid Disk实际有多个磁盘。

　　SQLServer:Catalog Metadata:Cache Hit Ratio

　　该值越高越好。如果持续低于80%，应考虑增加内存。 注意该参数值是从SQL Server启动后，就一直累加记数，所以运行经过一段时间后，该值将不能反映系统当前值。