分布式系统

分布式系统和计算机网络系统的共同点是：多数分布式系统是建立在计算机网络之上的，所以分布式系统与计算机网络在物理结构上是基本相同的。
他们的区别在于：分布式操作系统的设计思想和网络操作系统是不同的，这决定了他们在结构、工作方式和功能上也不同。网络操作系统要求网络用户在使用网络资源时首先必须了解网络资源，网络用户必须知道网络中各个计算机的功能与配置、软件资源、网络文件结构等情况，在网络中如果用户要读一个共享文件时，用户必须知道这个文件放在哪一台计算机的哪一个目录下；分布式操作系统是以全局方式管理系统资源的，它可以为用户任意调度网络资源，并且调度过程是“透明”的。当用户提交一个作业时，分布式操作系统能够根据需要在系统中选择最合适的处理器，将用户的作业提交到该处理程序，在处理器完成作业后，将结果传给用户。在这个过程中，用户并不会意识到有多个处理器的存在，这个系统就像是一个处理器一样。


分布式系统的缺点


尽管分布式系统有许多优点，但也有缺点。本节就将指出其中的一些缺点。我们前面已经提到了最棘手的问题：软件。就目前的最新技术发展水平，我们在设计、实现及使用分布式系统上都没有太多的经验。什么样的操作系统、程序设计语言和应用适合这一系统呢？用户对分布式系统中分布式处理又应该了解多少呢？系统应当做多少而用户又应当做多少呢？专家们的观点不一（这并不是因为专家们与众不同，而是因为对于分布式系统他们也很少涉及）。随着更多的研究的进行，这些问题将会逐渐减少。但是我们不应该低估这个问题。
第二个潜在的问题是通信网络。由于它会损失信息，所以就需要专门的软件进行恢复。同时，网络还会产生过载。当网络负载趋于饱和时，必须对它进行改造替换或加入另外一个网络扩容。在这两种情况下，一个或多个建筑中的某些部分必须花费很高的费用进行重新布线，或者更换网络接口板（例如用光纤）。一旦系统依赖于网络，那么网络的信息丢失或饱和将会抵消我们通过建立分布式系统所获得的大部分优势。
最后，上面我们作为优点来描述的数据易于共享性也是具有两面性的。如果人们能够很方便地存取整个系统中的数据，那么他们同样也能很方便地存取与他们无关的数据。换句话说，我们经常要考虑系统的安全性问题。通常，对必须绝对保密的数据，使用一个专用的、不与其它任何机器相连的孤立的个人计算机进行存储的方法更可取。而且这个计算机被保存在一个上锁的十分安全的房间中，与这台计算相配套的所有软盘都存放在这个房间中的一个保险箱中.


分布式系统的测试


在测试执行过程中，对测试结果的分析是一个需要进行深入思考的重点问题。分布式系统测试的重点在于对后端服务器集群的测试，而判定系统中是否存在Bug则是我们需要解决的重要问题。那么应该如何确定是否存在Bug呢？
对于测试结果的分析，我们通常观察下面几种情况。
观察前端应用的返回结果。这里需要分两种情况来考虑：第一，按照前端应用业务功能点及流程进行操作，观察返回结果是否符合业务方的需求预期；第二，操作后端的服务器（通常是重启、宕机、断网等操作），观察前端应用的返回结果是否符合系统的设计需求。
分析服务器日志。在功能测试过程中，当我们在启动服务器的时候，需要将日志级别定义为Debug级别（最低级别）。这样做的主要目的是为了能便于测试工程师来分析日志和定位问题。为了能更好地定位问题，常常需要在服务器程序代码中进行日志打桩，把程序中的一些重要数据通过日志的方式展现出来。通常情况下，我们需要对日志的格式进行约定，在日志行中增加一些关键字来进行分类，这将便于测试工程师进行日志分析，也有利于开展分布式系统的自动化测试。另外，值得注意的是，我们尽可能地将打桩代码放在Debug代码中，避免影响系统代码，引入新问题。
分析操作系统的一些重要信息。我们测试的分布式系统绝大多数是基于Linux操作系统开发的，在测试的过程中，除了详细分析程序日志以外，还需要对操作系统的一些重要数据信息进行分析，从而来诊断服务器程序是否存在异常。以Linux操作系统为例，我们常常会使用top命令、netstat命令及sar命令来查看操作系统的一些数据信息。例如，可以通过netstat命令检查服务器程序是否正确地监听了指定的端口等。
借助其他分析工具。例如，如何判断服务器程序是否产生了内存泄漏？通常需要借助于内存检测工具来进行分析。在Linux环境下，我们常用Valgrind来进行内存检测。这是一款非常好用、功能强大的分析工具，可以帮助测试或者开发工程师快速发现很多隐藏的程序Bug，尤其是在内存检测方面（同时它还具有很多其他优秀的功能，读者可以自己查看官网中的使用手册）。
分布式系统压力测试与性能测试
对于分布式系统而言，压力测试和性能测试非常重要。在进行压力测试和性能测试的时候，可能会碰到下面一些难点。
数据准备。如何准备海量的测试数据并保证模拟数据的真实性？以一个分布式的文件系统为例，预先存入100GB的数据还是存入100TB的数据、存入的文件是大小基本一致差别不大还是各不相同甚至差异很大（例如，从几十字节至几十兆字节不等），这些因素对于分布式系统的性能影响是有很大差异的。另外，如果需要预先存入100TB的数据，若按每秒写入100MB数据来计算，写入100TB数据需要100×1024×1024/100=1048576秒=291.27小时=12天。我们是否能忍受这么长时间的数据准备工作？为了解决这样的问题，我们需要对系统架构设计进行深入分析，设计好测试场景，并提前进行测试用例的设计，以尽早开始准备测试数据。
性能或压力测试工具。通常来说，分布式系统的测试需要开发一些测试工具来满足性能测试的需求。如果可以的话，建议这样的测试工具最好由测试工程师自己来实现，因为测试工程师更清楚自己的测试需求。当需要自己开发测试工具的时候，有两个关键问题需要重点关注：第一，一些关键数据的收集方式与计算将成为性能测试工具的关键，例如，TPS（每秒请求数）、Throughput（吞吐量）计算的准确性；第二，要保证性能测试工具的性能，如果工具本身的性能不好，将无法给予分布式系统足够强大的压力来进行测试。另外，当考虑到多并发（例如有10万客户端同时并发连接）时，如果性能测试工具在一台测试机器上只能运行50个或者更少的话，那么需要的测试机器数量也将会很庞大（例如2000台测试机），这个成本或许是许多公司不能承受的。因此，性能测试工具本身的性能必须要足够好才能满足需求、降低测试成本。
分布式系统自动化测试
自动化测试是测试行业发展的必然趋势，对于分布式系统测试而言也不例外。在实施分布式系统自动化测试的过程中，我们可能会碰到下面两个难点问题。
涉及平台多且硬件杂，测试流程控制困难。在实施自动化测试的过程中，测试脚本需要控制的操作系统和应用程序很多，而且存在跨平台的特性，同时还有可能需要控制一些网络设备。因此，选择一个优秀的自动化测试框架成为了非常重要的工作之一。以我们的实践经验来看，STAF是一个不错的选择，它的平台（Windows及Linux各版本）支持及开发语言的支持都很全面。
测试结果验证复杂。对于分布式系统的自动化测试来说，我们需要通过测试脚本来收集各种测试结果数据以验证测试结果的正确性。在实施自动化测试的过程中，我们可以将测试结果数据收集部分模块化，通过各子模块来检测各项数据是否正确。例如，我们会设计一个日志分析模块，主要负责从服务器应用程序的日志中收集相应数据进行对比验证.