开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 2 天，点击查看活动详情
分布式系统是其硬件和软件组件分布在连网的计算机上，组件之间通过传递消息进行通信和动作协调的系统。 可见其组成基本要素因素：计算机、网络（互联网、移动电话网、协作网、企业内网、校园网、家庭网、车内网，可这些网络可以单独使用，也可以相互结合使用，均实现互联网协议，所以区别可以被屏蔽）；由一个网络连接的计算机可能在空间上距离不等，即它可能分布在地球上不同的洲（如国内、东南亚、欧洲、北美等），也可能在同一栋楼里或同一个房间里，如各公司自建机房、云厂商分布广泛的机房。
它的挑战是处理组件的异构性（网络、计算机硬件、操作系统、编程语言、由不同开发者完成的软件实现）、开放性（组件可被添加和替换）、安全性、可伸缩性（用户负载和数量增加时能正常运行的能力）、故障处理、组件的并发性、透明性和提供服务质量的问题。
- 异构性：中间件是一个软件层，它提供一个编程抽象，同时屏蔽了底层网络、硬件、操作系统、变编程语言的异构性。中间件为服务器和分布式应用程序提供了一致的计算模型。这些模型包括远程对象调用、远程事件通知、远程SQL访问和分布式事务处理。
- 开放性：开放性是决定系统能否以不同方式被扩展和重新实现的特征，主要强调系统是可扩展的。包括可以通过在网络中增加计算机实现在硬件层次上的扩展，或者通过引入新的服务、重新实现旧的服务的软件层次上的扩展。
- 安全性：分布式系统中需要传递消息进行通信和动作协调，这些信息资源的维护和使用对用户具有很高的内在价值，所以安全相当重要。信息资源的安全性包括三个部分：机密性（防止泄漏给未授权的个人）、完整性（防止被改变或被破坏）、可用性（防止对访问资源的手段的干扰).比如如何识别远程用户身份？如何拒绝服务攻击？
- 可伸缩性：如果资源数量和用户数量激增，分布式系统仍能保持其有效性，那么该系统就是可伸缩的。可伸缩设计面临如下挑战：
- 控制物理资源的开销：通常要使有n个用户的系统成为可伸缩的，那么所需的物理资源的数量应该至多为O(n)，即正比于n。如一个文件服务器能支持20个用户，那么两台这样的服务器能支持40个用户。听起来是理所当然目标，但实际上未必容易达到。
- 控制性能损失：当数据集大小与系统中的用户或资源量成正比时，这些数据管理的数据结构和算法要特别注意。如记录计算机域名和对应的有域名系统持有的互联网地址的表（用户查找如www.baidu.com这样的DNS名字）。 采用层次化结构的算法其伸缩性要好于使用线性结构的算法。即使使用层次结构，数量增加仍导致性能损失，即访问层次数据的时间是O(log n)，当n是数据集的大小时，对一个伸缩性系统，最大性能损失莫过于此。
- 避免性能瓶颈：通常，算法应该是分散型，以避免性能瓶颈，如上域名系统前身被爆存在一个主文件中，可被任何计算机下载，当最初只有几百个计算机时时可以的，但量级上来后会有严重性能和管理瓶颈。所以现在域名系统将名字表分区，分散到互联网中的服务器上并采用本地访问的方式来解决这个瓶颈。
理性情况下，系统规模增加时系统和应用程序应该不需要随之改变，但规模问题是分布式系统开发中面临的主要问题。比如规模增加了会间接导致有些共享资源被非常频繁的访问，这会引起网络性能下降，此时可以利用缓存、复制技术提高频繁使用的资源的性能。
- 故障处理：计算机软件或硬件发生故障时，会导致系统进程或网络故障，从而程序可能会产生不正确的结果或者在它们完成应该进行的计算之前就停止了。分布式故障是部分的，有些组件出了故障而有些组件运行正常，此时故障处理相当困难。
- 检测故障：有些故障可以被检测到，但有些故障很难甚至不可能被检测到（如服务器的崩溃）。面临的挑战时如何在有故障出现的情况下进行管理，这些故障不能被检测到但可以被猜到。
- 掩盖故障：有些检测到的故障能被隐藏起来或降低它的严重程度。如：
- 重试：消息在不能到达时可以进行重传
- 备份：数据写入两个磁盘，一个磁盘损坏，另一个磁盘的数据仍是正确的
- 容错：试图检测和隐藏所有互联网上故障是不切实际的。所以服务应该设计成容错的，即用户要容忍错误。如当Web浏览器不能与Web服务器连接时，它不会让用户一直等待，而是超时通知给用户这个问题，让用户自由选择是否稍后尝试。
- 故障恢复：服务器崩溃后，永久数据的状态能被恢复或”回滚“。通常，出现故障时，程序完成的计算是不完整的，被更新的永久数据可能存在不一致的状态。
- 冗余：利用冗余组件，服务可以实现容错
- 在互联网的任何两个路由器之间，至少应该存在两个不同的路由
- 在域名系统中，每个名字表至少被复制到两个不同的服务器上
- 数据库可以被复制到几个服务器上，以保证在任何一个服务器出现故障后数据仍是可访问的。服务器要被设计成能检测到其他对等服务器的错误，当检测到一个服务上有错误时，客户就被重定向到剩下的服务器上。设计有效的技术来保证服务器上数据的副本时最新的，而且不过度损失网络的性能是个挑战。
- 冗余：利用冗余组件，服务可以实现容错
面对硬件故障，分布式系统提供高可用性。如果用户正在使用的计算机出现故障，用户可以转移到另一台计算机上。
-
并发性：分布式系统服务和应用均提供可被客户共享的资源。所以，可能有几个用户同时试图访问一个共享资源的情况。如拍卖时，记录拍卖竞价的数据结构可能会被非常频繁的访问。分布式系统中，代表共享资源的任何一个对象负责确保它在并发环境中操作正确，为了在并发环境中安全使用，它的操作必须在数据保持一致的基础上同步。常见技术如操作系统使用的信号量，程序中使用的并发锁等。
-
透明性：透明性被定义成对用户和应用程序员屏蔽分布式系统组件的分离型，使系统被认为是一个整体，而不是独立组件的集合。
- 访问透明性：用相同的操作访问本地资源和远程资源，解释起来就是用户用一个操作就可访问到资源，用户不用关心资源在本地还是远程
- 位置透明性：不需要知道资源的物理或网络位置（如哪个建筑物或IP地址）就能够访问资源。如Web资源名或URL具有位置透明性，因为URL中识别Web服务器域名的部分指的是域中的计算机名字，而不是互联网地址。然而，URL不是移动透明的，因为某人的Web页面不能移动到另一个域中新的工作位置，因为其他页面上的所有链接仍将指向原来的页面
- 并发透明性：几个进程能并发地使用共享资源进行操作且互不干扰。
- 复制透明性：使用资源的多个实例提升可靠性和性能，而用户和应用程序员无须知道副本的相关信息。
- 故障透明性：屏蔽错误，不论是硬件组件故障还是软件组件故障，用户和应用程序都能够完成它们的任务。
- 移动透明性：资源和客户能够在系统内移动而不会影响用户或程序的操作。
- 性能透明性：当负载变化时，系统能被重新配置以提高性能。
- 伸缩透明性：系统和应用能够进行扩展而不改变系统结构或应用算法。
最重要的两个透明性是访问透明性和位置透明性，它们的有无对分布式资源的利用有很大影响。有时它们统一称为网络透明性。 透明性对用户和应用程序员隐藏了与手头任务无直接关系的资源，并使这些资源能被匿名使用。例如为完成任务，对相似资源的分配是可互换的-用于执行一个进程的处理器通常对用户隐藏身份并一直处于匿名状态。
-
服务质量：系统的主要的非功能特性，但影响客户和用户体验的服务质量是可靠性、安全性和性能。满足变化的系统配置和资源可用性的适应性已被公认为服务质量的一个重要方面。 其中包含涉及概念：QoS（Quality of Service，技术服务质量指标）和主观体验QoE（Quality of Experience，用户体验指标）。 可靠性和安全性问题在设计大多数计算机系统时是关键的。服务质量的性能方面源于及时性和计算吞吐量，但它已被重定义成满足及时性保证的能力。
一些应用，包括多媒体应用，处理时间关键性数据——这些数据是要求以固定速度处理或从一个进程传送到另一个进程的数据流。例如，一个电影服务可能由一个客户程序组成，该程序从一个视频服务器中检索电影并把它呈现到用户的屏幕上。该视频的连续帧在指定的时间限制内显示给用户，才算是一个满意的结果。
事实上，缩写QoS用于指系统满足这样的截止时间的能力，它的实现取决于所需要的计算和网络资源在相应时刻的可用性。这蕴含着对系统的一个需求，即系统要提供有保障的计算和通信资源，这些资源要足以使得应用能按时完成每个任务（例如，显示视频一帧的任务）。 通常今天使用的网络具有高性能——但当网络负载很重时，它们的性能会恶化，不能提供任何保障。除了网络之外，QoS可以应用到操作系统。每个关键性资源必须被需要QoS的应用保留，并且必须有一个提供保障的资源管理器。
