Distributed Systems Concepts and Design:System Models系统模型

admin管理员组

文章数量:1623567

系统模型在分布式系统概念和设计中是一个关键部分，主要分为三类：物理模型、体系结构模型和基本模型。
物理模型用机器、网络、硬件等语言描述整个系统。
体系结构模型用计算、计算任务、计算单元等语言描述整个系统，这是一个比物理模型更抽象的层级。体系结构模型考察四个方面：实体间的通信方式、各个实体的在分布式系统中的角色、各个实体在物理层面对应的是什么设施。
基本模型是垂直视图或切片，表示分布式系统的一些关键方面。每个基本模型都代表了分布式系统设计中必须解决的一组问题。这些基本模型并不包含分布式系统的所有设计问题，相反，它们代表了关键领域，并提供了一种设计方法的示例。基本模型主要包括三个方面：interaction models（系统间的通信）、failure models（描述故障）、security models（安全模型）。
请注意，这只是分布式系统概念和设计中的一部分内容，如需了解更多，建议阅读分布式系统相关书籍或请教专业人士。在分布式系统中，系统间的通信是一个重要的方面。通信模型描述了系统中的实体如何交换信息。这包括消息传递、远程过程调用（RPC）、发布/订阅模型等。理解通信模型有助于设计者更好地理解系统中的数据流和信息交换，从而更好地设计系统的通信机制。
故障模型描述了分布式系统中的故障情况以及如何处理这些故障。由于分布式系统的特性，故障是不可避免的，因此设计者需要了解如何检测和处理故障，以保证系统的可靠性和可用性。这包括故障检测、故障恢复、容错技术等。
安全模型关注分布式系统中的安全性问题，如数据保护、身份验证、访问控制等。在设计分布式系统时，安全性是一个重要考虑因素，因为它涉及到系统的机密性、完整性和可用性。安全模型提供了一种设计安全机制的方法，以保护系统免受攻击和未经授权的访问。
除了以上三个基本模型外，分布式系统设计还涉及到其他方面，如数据一致性、负载均衡、容错性等。这些方面在不同的应用场景和需求中具有不同的重要性，因此设计者需要根据实际情况进行权衡和选择。
总之，系统模型是分布式系统概念和设计中的重要部分，它为设计者提供了一种组织和理解分布式系统复杂性的方法。通过深入理解这些基本模型，设计者可以更好地设计出高效、可靠和安全的分布式系统。分布式系统的设计和实施是一项复杂且挑战性的任务。除了上述的基本模型外，还需要考虑其他一些关键因素。
首先，数据一致性是分布式系统中的核心问题之一。由于系统中存在多个节点，如何保证数据在各个节点之间的一致性是一个关键问题。一致性模型描述了系统如何处理数据冲突和如何保证数据的一致性。这涉及到各种算法和技术，如分布式事务、共识算法等。
其次，负载均衡也是分布式系统设计中需要考虑的重要方面。负载均衡旨在确保系统中各个节点之间的负载分布均衡，避免某些节点过载而其他节点空闲的情况。负载均衡模型描述了如何分配任务和数据，以保证系统的性能和可靠性。
此外，容错性也是分布式系统设计中的重要方面。由于分布式系统的节点可能发生故障，因此系统需要具备一定的容错能力，以应对节点故障的情况。容错模型描述了如何检测和恢复节点故障，以保证系统的可用性和可靠性。
最后，可扩展性是分布式系统设计的重要考虑因素之一。随着系统的增长，可能需要增加更多的节点来扩展系统的容量和性能。可扩展模型描述了系统如何随着节点的增加而保持其性能和可靠性。
综上所述，分布式系统的设计和实施需要综合考虑多个方面，包括系统模型、数据一致性、负载均衡、容错性和可扩展性等。通过深入理解和掌握这些关键因素，设计者可以更好地设计出高效、可靠和安全的分布式系统。
Presentation Points Chapter 2

System Models

Objectives

This chapter aims to provide students with conceptual models to support their study of distributed systems. The models will motivate the study of many of the design problems and solutions described throughout the book. They are of two types:

Architectural models

These provide a high-level view of the distribution of functionality between components and the relationships between them. They will assist readers to organize their knowledge of system components and the patterns of communication (or interaction) between them. Architectural models determine the distribution of data and computational tasks amongst the physical nodes of the system and are helpful when evaluating the performance, reliability, scalability and other properties of distributed systems.
Fundamental models

These are vertical views or slices, representing some key aspects of distributed systems. Each fundamental model represents a set of issues that must be addressed in the design of distributed systems. Of course, the three fundamental models presented in this chapter do not encompass all of the design issues for distributed systems. Rather, they represent key areas and provide examples af a design approach by which related sets of design issues are extracted and reasoned about independently of the rest.

Points to emphasize

Middleware, as represented for example by CORBA and Java/Jini, provides essential support for distributed application development and is likely to offer greater support in the future. But the end-to-end argument implies that some aspects of communication support cannot always be abstracted away from applications.

The client-server architecture is predominant, but there are many variations, some of which differ markedly from the client-server model. All of those mentioned in Section 2.2 are important.

In an asynchronous system, for example, the Internet, no bounds can be set on process execution speeds, message delays or clock drift rates. In these conditions, it is impossible to synchronize computer clocks. Synchronous systems can be built, by supplying processors with clocks with bounded drift rates and providing sufficient processor and network capacity to satisfy known resource requirements.

Processes and communication channels can fail. The classificaton of their failures is useful for the analysis of failures of protocols. Components that exhibit byzantine or arbitrary failures may do anything at any time. Timing failures occur only in synchronous systems. Most failures in distributed systems are benign (e.g. omission but not byzantine failures). A service may mask the failures of the components from which it is constructed, for example, reliable one-to-one communication may be built by masking omission failures.

The security model discusses the possible threats to processes and communication channels. It introduces the concept of a secure channel, which is secure against those threats.

Possible difficulties

The end-to-end argument (p. 33) may seem counter-intuitive for those who take a bottom-up approach to As Dave Reed points out in [ www.reed ], it was the subject of much debate between experienced designers and engineers during the early development of the Internet; the outcome was firmly based on end-to-end primciples (e.g. for TCP, DNS and the Web) and the current scale of the Internet would have been inconceivable had it not been so.

Teaching hints

The system architectures of Section 2.2.2 can be related to the Internet. For example, Figure 2.2 could be an illustration of browsers and a web server which uses a local file server. Or Figure 2.3 could illustrate a replicated web service. Figures 2.4 and 2.6 already refer to web examples.

In discussing the synchronous/asynchronous models of distributed systems, try to bring out what is really needed for the former. Exercise 2.11-12 address some of the issues.

Before embarking on the failure model, try asking students to suggest all the possible things that can go wrong in a distributed system. Exercise 2.10 could be used to relate failures to Section 2.2.5 on the use of caching and replication.

When discussing the classification of their failures, mention that the classes will be used again in the discussion of the characteristics of the Internet protocols (UDP and TCP in Chapter 4). Use Exercise 2.14-15 to illustrate theuse of the classification.

To help with the idea of a service masking the failures of the components from which it is constructed, see Exercise 2.16, or discuss the use of checksums in network protocols to mask wrong values (byzantine failures) and replace them with omission failures.

In discussing the integrity property of reliable communication, point out that integrity can be broken both by failures and by security breaches.
介绍要点第2章
系统模型
目标
本章旨在为学生提供概念模型，以支持他们对分布式系统的研究。这些模型将推动对本书中描述的许多设计问题和解决方案的研究。它们有两种类型：
建筑模型
它们提供了组件之间功能分布以及组件之间关系的高级视图。它们将帮助读者组织他们对系统组件以及它们之间的通信（或交互）模式的知识。体系结构模型确定数据和计算任务在系统物理节点之间的分布，在评估分布式系统的性能、可靠性、可伸缩性和其他属性时很有帮助。
基本模型
这些是垂直视图或切片，表示分布式系统的一些关键方面。每个基本模型都代表了分布式系统设计中必须解决的一组问题。当然，本章介绍的三个基本模型并不包含分布式系统的所有设计问题。相反，它们代表了关键领域，并提供了一种设计方法的示例，通过这种方法，可以独立于其他问题提取和推理相关的设计问题集。
重点
以CORBA和Java/Jini为代表的中间件为分布式应用程序开发提供了必要的支持，并可能在未来提供更大的支持。但是端到端的争论意味着通信支持的某些方面不能总是从应用程序中抽象出来。
客户机-服务器体系结构占主导地位，但也有许多变体，其中一些与客户机-服务器模型有显著差异。第2.2节中提到的所有这些都很重要。
在异步系统中，例如Internet，进程执行速度、消息延迟或时钟漂移率不能设置界限。在这种情况下，不可能同步计算机时钟。通过向处理器提供具有有界漂移率的时钟，并提供足够的处理器和网络容量以满足已知资源需求，可以构建同步系统。
进程和通信通道可能会失败。它们的故障分类对于分析协议的故障非常有用。表现出拜占庭式或任意故障的组件可能会在任何时候执行任何操作。定时故障只发生在同步系统中。分布式系统中的大多数故障都是良性的（例如遗漏，但不是拜占庭式故障）。服务可以屏蔽其构建所依据的组件的故障，例如，可以通过屏蔽遗漏故障来构建可靠的一对一通信。
安全模型讨论了进程和通信通道可能面临的威胁。它引入了安全通道的概念，可以安全地抵御这些威胁。
可能的困难
对于那些采取自下而上方法的人来说，端到端的争论（第33页）似乎有悖常理，正如戴夫·里德（Dave Reed）在[www.Reed]中指出的那样，在互联网的早期发展过程中，这是经验丰富的设计师和工程师之间争论的主题；结果是基于端到端的原则（例如TCP、DNS和Web），如果不是这样的话，互联网目前的规模是不可想象的。
教学提示
第2.2.2节中的系统架构可与互联网相关。例如，图2.2可以是浏览器和使用本地文件服务器的web服务器的示例。或者，图2.3可以说明一个复制的web服务。图2.4和2.6已经提到了web示例。
在讨论分布式系统的同步/异步模型时，试着找出前者真正需要的东西。练习2.11-12解决一些问题。
在开始建立故障模型之前，试着让学生提出分布式系统中可能出现的所有问题。练习2.10可用于将故障与第2.2.5节有关缓存和复制的使用联系起来。
在讨论其故障分类时，请注意这些类将在讨论互联网协议的特征时再次使用（第4章中的UDP和TCP）。使用练习2.14-15说明分类的使用。
要帮助理解服务屏蔽其构建组件故障的思想，请参阅练习2.16，或讨论在网络协议中使用校验和来屏蔽错误值（拜占庭式故障），并用遗漏故障替换它们。
在讨论可靠通信的完整性属性时，指出完整性可以被故障和安全漏洞破坏。

本文标签： 模型系统conceptsSystemsDistributed