优点
相比较而言的优点
系统倾向于分布式发展潮流的真正驱动力是经济。25年前，计算机权威和评论家HerbGrosch指出CPU的计算能力与它的价格的平方成正比，后来成为Grosch定理。也就是说如果你付出两倍的价钱，就能获得四倍的性能。这一论断与当时的大型机技术非常吻合，因而使得许多机构都尽其所能购买最大的单个大型机。以分布式系统在数据库方面应用的优势和在网络方面的漏洞及其对应措施为中心,深入探讨了分布式系统的工作原理,研究对比了分布式系统和其它系统的性能差异,同时在理论上分析了分布式系统受到攻击的危害性。
随着微处理机技术的发展，Grosch定理不再适用了。到了二十一世纪初期，人们只需花几百美元就能买到一个CPU芯片，这个芯片每秒钟执行的指令比80年代最大的大型机的处理机每秒钟所执行的指令还多。如果你愿意付出两倍的价钱，将得到同样的CPU，但它却以更高的时钟速率运行。因此，最节约成本的办法通常是在一个系统中使用集中在一起的大量的廉价CPU。所以，倾向于分布式系统的主要原因是它可以潜在地得到比单个的大型集中式系统好得多的性价比。实际上，分布式系统是通过较低廉的价格来实现相似的性能的。
另一方面，一些作者对分布式系统和并行系统进行了区分。他们认为分布式系统是设计用来允许众多用户一起工作的，而并行系统的唯一目标就是以最快的速度完成一个任务，就像我们的速度为500,000MIPS的计算机那样。我们认为，上述的区别是难以成立的，因为实际上这两个设计领域是统一的。我们更愿意在最广泛的意义上使用“分布式系统”一词来表示任何一个有多个互连的CPU协同工作的系统。
同集中式系统相比较，分布式系统的另一个潜在的优势在于它的高可靠性。通过把工作负载分散到众多的机器上，单个芯片故障最多只会使一台机器停机，而其它机器不会受任何影响。理想条件下，某一时刻如果有5%的计算机出现故障，系统将仍能继续工作，只不过损失5%的性能。对于关键性的应用，如核反应堆或飞机的控制系统，采用分布式系统来实现主要是考虑到它可以获得高可靠性。
最后，渐增式的增长方式也是分布式系统优于集中式系统的一个潜在的重要的原因。通常，一个公司会买一台大型主机来完成所有的工作。而当公司繁荣扩充、工作量就会增大，当其增大到某一程度时，这个主机就不能再胜任了。仅有的解决办法是要么用更大型的机器（如果有的话）代替现有的大型主机，要么再增加一台大型主机。这两种作法都会引起公司运转混乱。相比较之下，如果采用分布式系统，仅给系统增加一些处理机就可能解决这个问题，而且这也允许系统在需求增长的时候逐渐进行扩充。表1-1中总结了以上这些优点。
从长远的角度来看，主要的驱动力将是大量个人计算机的存在和人们共同工作与信息共享的需要，这种信息共享必需是以一种方便的形式进行的，而不受地理或人员、数据，机器的物理分布的影响。
与独立PC机相比较的优点
既然使用微处理机是一种节省开支的办法，那么为什么不给每个人一台个人计算机，让他们各自独立地工作呢？一则，许多用户需要共享数据。例如，机票预订处的工作人员需要访问存储航班以及现有座位信息的主数据库。假如给每个工作人员都备份整个数据库，那么在实际中这是无法工作的，因为没有人知道其他工作人员已经卖出了哪些座位。共享的数据是上例和许多其它应用的基础，所以计算机间必须互连。而计算机互连就产生了分布式系统。
共享并不只是仅仅涉及数据。昂贵的外设，例如彩色激光打印机，照相排版机以及大型存储设备（如自动光盘点唱机）都是共享资源。
把一组孤立的计算机连成一个分布式系统的第三个原因是它可以增强人与人之间的沟通，电子邮件比信件、电话和传真有更多的诱人之处。它比信件快的多，不像电话需要两人同时都在，也不像传真，它所产生的文件可在计算机中进行编辑、重排和存储，也可以由文本处理程序来处理。
最后，分布式系统可能比给每个用户一个独立的计算机更灵活。尽管一种可能的模式是给每个人一台个人计算机并把它们通过LAN联在一起，但这种方式并不是唯一的。另外还存在一种模式是将个人计算机和共享计算机混合连接在一起（这些机器的型号可能并不完全相同），使工作能够在最合适的计算机上完成，而并不总是在自己的计算机上完成。这种方式可以使工作负荷能更有效地在计算机系统中进行分配。系统中某些计算机的失效也可以通过使其工作在其它计算机上进行而得到补偿。表1-2总结了以上所介绍的各点。
测试
在测试执行过程中，对测试结果的分析是一个需要进行深入思考的重点问题。分布式系统测试的重点在于对后端服务器集群的测试，而判定系统中是否存在Bug则是我们需要解决的重要问题。那么应该如何确定是否存在Bug呢？
对于测试结果的分析，我们通常观察下面几种情况。
观察前端应用的返回结果。这里需要分两种情况来考虑：第一，按照前端应用业务功能点及流程进行操作，观察返回结果是否符合业务方的需求预期；第二，操作后端的服务器（通常是重启、宕机、断网等操作），观察前端应用的返回结果是否符合系统的设计需求。
分析服务器日志。在功能测试过程中，当我们在启动服务器的时候，需要将日志级别定义为Debug级别（最低级别）。这样做的主要目的是为了能便于测试工程师来分析日志和定位问题。为了能更好地定位问题，常常需要在服务器程序代码中进行日志打桩，把程序中的一些重要数据通过日志的方式展现出来。通常情况下，我们需要对日志的格式进行约定，在日志行中增加一些关键字来进行分类，这将便于测试工程师进行日志分析，也有利于开展分布式系统的自动化测试。另外，值得注意的是，我们尽可能地将打桩代码放在Debug代码中，避免影响系统代码，引入新问题。
分析操作系统的一些重要信息。我们测试的分布式系统绝大多数是基于Linux操作系统开发的，在测试的过程中，除了详细分析程序日志以外，还需要对操作系统的一些重要数据信息进行分析，从而来诊断服务器程序是否存在异常。以Linux操作系统为例，我们常常会使用top命令、netstat命令及sar命令来查看操作系统的一些数据信息。例如，可以通过netstat命令检查服务器程序是否正确地监听了指定的端口等。
借助其他分析工具。例如，如何判断服务器程序是否产生了内存泄漏？通常需要借助于内存检测工具来进行分析。在Linux环境下，我们常用Valgrind来进行内存检测。这是一款非常好用、功能强大的分析工具，可以帮助测试或者开发工程师快速发现很多隐藏的程序Bug，尤其是在内存检测方面（同时它还具有很多其他优秀的功能，读者可以自己查看官网中的使用手册）。
压力测试与性能测试
对于分布式系统而言，压力测试和性能测试非常重要。在进行压力测试和性能测试的时候，可能会碰到下面一些难点。
自动化测试
自动化测试是测试行业发展的必然趋势，对于分布式系统测试而言也不例外。在实施分布式系统自动化测试的过程中，我们可能会碰到下面两个难点问题。
涉及平台多且硬件杂，测试流程控制困难。在实施自动化测试的过程中，测试脚本需要控制的操作系统和应用程序很多，而且存在跨平台的特性，同时还有可能需要控制一些网络设备。因此，选择一个优秀的自动化测试框架成为了非常重要的工作之一。以我们的实践经验来看，STAF是一个不错的选择，它的平台（Windows及Linux各版本）支持及开发语言的支持都很全面。
测试结果验证复杂。对于分布式系统的自动化测试来说，我们需要通过测试脚本来收集各种测试结果数据以验证测试结果的正确性。在实施自动化测试的过程中，我们可以将测试结果数据收集部分模块化，通过各子模块来检测各项数据是否正确。例如，我们会设计一个日志分析模块，主要负责从服务器应用程序的日志中收集相应数据进行对比验证（本文前面提到的在打桩日志中增加关键字部分就显得格外重要）。
随着互联网的发展，大型分布式系统也越来越多、越来越复杂、越来越重要。如何有效地保证大型分布式系统7×24小时全天候持续稳定地运行也就成为了一个重要课题。
