copy过来有些图没了，见这里
第二章 - 系统模型
分3大块
physical mode（只考虑物理连接方面的模型）；
architechture mode（主要是“计算”方面的体系结构模型，例如peer to peer、client to server）
fundunmental mode（抽象层面，主要用于分析某些特定问题 => 针对下面3个问题）
同时，由于分布式系统没有统一的时钟，所以一切交互基本都是以消息来进行的，针对这种通信方式，提出三种mode应对常见问题
interaction mode
failure mode
security mode
回顾一下第一章提到的一些分布式系统主要难点和威胁
- 多样性，例如整个系统中，有些comp会有很高的access load，有些又很低，甚至断开（e.g. mobile computer)，有些又对带宽要求很高
- 分布式系统中各个节点的系统环境多样，例如不同的OS，甚至Mobile
- 内部问题，例如内部各node时钟不一致，某些mode的SW、HW failure，数据同步冲突等等
- 外部问题，各种安全领域的攻击等等
Physical Mode
1. 最基本模型（baseline physical mode）
最基本最经典的模型，可扩展的一组计算机，链接在一个网络上面，靠消息通信
（an extensible set of computer nodes interconnected by a computer network for the required passing of messages）
基于此，有以下的扩充
2. Early distributed systems
80年代初，随着局域网，特别是以太网的兴起而产生，主要特点为local网络上连了10-100台机器，有限的互联网访问同时内部提供有限的服务例如共享打印机，文件服务器等等，而对于server QoS的关注还处于非常早期的阶段；
3. Internet-scale distributed systems
这一波，是随着90年代互联网的兴起，借助互联网的把分布式系统彻底的在global范围之内分布式起来，例如Google的服务
在这个阶段，“多样性”（heterogeneity）的问题变得突出起来，也产生了一些例如CORBA之类的中间件技术来应对这些多样性问题
4. 当代分布式系统（Contemporary distributed systems）
在3的基础上，结合了例如mobile，物联网，云计算等新兴技术
Architechtual Mode （分布式系统体系结构）
最简单的模型中，构成分布式系统的实体就是Node（Server）；如果再细看一层，实际是Node中的Thread；
但是从实现的角度，这种分类还是太粗，于是有下面的不同形式
在基于object为基础构建的分布式系统中，首先是用“面向对象”思维把整个系统抽象成不同的object
object提供接口供外部访问，具体的访问方法通过IDL（Interface Defination Language）来描述 => 第5&8章有更详细的描述
从发展的角度，基于Component为基础而构建的分布式系统是为了解决上面“object为基础的系统”的问题而产生的（什么问题？）
建立在问题域基础上，把一些相关的object组合形成Component，同样提供接口供外部访问 => 与object-based的系统不同的是，Component-based的系统中，对外部依赖的描述比较严格 => 显式的描述了自己component正常工作时需要的外部依赖，从结构化系统设计的角度讲，这是有利于例如第三方开发独立的Component；
第8章有更详细的描述
逻辑和上面的一样，封装之后通过接口提供功能
区别或者说优点在于，通过web技术提供更加“公共”的接口，例如URL和XML-based msg exchange
在实际应用中，webservice 经常和“通过object or component-based的”其他App结合起来，提供value-added service => 不同business之间的集成 => chapter9有更多的描述
三大类：interprocess（进程间通信）；remote invoke（远程调用）；indirect communication（pub-sub？）
主要指的是提供send/rec 原语API进行消息的收发，或者更加common Internet API （socket） => 第四章有更详细介绍
远程调用，首先分两大类（1）direct communication -> 交互双发同时存在 （2） indirect -> 双发不一定同时存在
第一类direct communication，包括以下几种方式（第五章有更详细的介绍）
- Request-reply protocols
这个，是最原始的方式，也是下面两种的基础
曾经（也许是曾经）主要用在client-server模式中，client发消息给server让server做些事情并返回结果
通常消息里面会带上encode成二进制的operation，以及相应的参数；通常返回结果的消息也是encode成二进制 byte
=>通常在对性能要求很高的嵌入式系统中会采用这种方式；而其他的系统，则通常采用下面的两种方式
（注意HTTP其实也是用的这种方式）
- Remote procedure calls （so called RPC）
提供一个底层的RPC系统，使得本(client)程序调用远程(server)上面的procedure，就像调用本地的一样
RPC系统负责屏蔽中间的复杂性，包括encoding/decoding 参数和返回结果，传输消息等等
（具体技术再看一下）
- Remote method invocation （RMI）
based on RPC，但是拓展到OO领域，使得local的object可以调用远程object的methods => 第五章又更详细介绍
第二类，indirect communication
两种典型场景（1）sender不知道要发给谁 - space uncoupling （2）sender和receiver不同时存在 - time Uncoupling
下列几种方式应对这两种场景
- Group communication
简单的群发群收
- Publish-subscribe systems
pub sub不用多说，避免简单粗暴的群发，提高效率
- Message queues
相对于pub sub的1-N 模式，msg queue是1-1的
sender把消息放到receiver的queue里面去，receiver慢慢搞（避免了暂时不available的问题）
- Tuple spaces
提供一块持久化的存储空间，各process可以放任意数据结构的数据在那里进行indirect communication
具体的实现需要根据实际情况处理，似乎用的不多
- Distributed shared memory
拓展share memory的思想到分布式环境中，提供这种机制的底层架构需要很好的处理同步以及数据一致性问题，在第六章会有更具体介绍
放到表格里面总结上面的内容，如下
两种
client-server
没什么可多说的，处理略微提一下，对一个“server”来说，可以同时是“server”& “client”
举得例子是web search engine，同时“作为server，给web browser提供服务的同时，也作为client -> 爬虫，去抓web上面的网页信息”
peer-peer
最初出现的一个原因是为了解决client server结构中扩展性差的问题 => server会成为scaling过程中的瓶颈
=> 一个典型的例子就是BT下载的思想，第十章就详细介绍这种结构如何设计工作
这个问题没有具体的通用性指导原则，只有几个比较宏观的策略性原则可供考虑，结合实际情况做相应的设计
（为什么不能有统一原则？需要考虑实体之间的通信方式，当前物理机的load以及可靠性等等一系列和现场环境相关的问题）
- mapping of services to multiple servers;
如字面意思所述
- caching;
一个例子例如通过web proxy 来cache远端server的内容
- mobile code;
另一个典型的名字叫Applet
简单流程如下
解决什么问题呢？ => 在某些应用场景下，server希望client端能够实时的得到更新的信息（例如股票软件希望client端及时得到更新的价格）
在这种场景下，传统的CS架构肯定没问题，但如果希望轻量的BS也能support，单靠一个浏览器就不够了，于是有了Applet这种东西
同时，也带来安全问题，通常浏览器会限制applet访问local的任何资源。
- mobile agents.
感觉和Applet类似，提到的一种应用例如“installation agent”
Mobile agents might be used to install and maintain software on the computers within an organization or to compare the prices of products from a number of vendors by visiting each vendor’s site and performing a series of database operations.
=> 在解决特定问题的时候，值得参考的架构设计模式。
常说的“分层”，底层给上层提供service => 换句话说，隐藏下层的实现细节，抽象出简单的service 接口提供给上层
简单图示如上，其中提一下Middleware的定义：
- 屏蔽底层多样性，向App的编程人员提供“简单编程模型”
（mask heterogeneity and to provide a convenient programming model to application programmers）
- 上面的“简单编程模型”通常包括
- 远程过程、方法调用（RPC、RMI）
- 进程间通信
- 共享数据管理等等，后面会细表
相对于Layering，Layering更多的是逻辑层面对整个软件的分层
而当提到“Tier”的时候，更多的是指，如何把上面的logic layer放到具体的物理机器上面
例如下图所示的3-layers SW （表示层、商业逻辑层、持久化层），落实到Tier的时候，可以有2 tiers or 3 tiers两种方案
没什么可多说的，书上提到了AJAX的例子，Google Map就是AJAX实现的一个典型
整个屏幕被分割为256x256的tiles，每一块的刷新实际都是浏览器端AJAX往后台请求新数据的过程
见名识意
除了BS架构，另外一种常用技术是通过VNC提供远程桌面访问的方式实现thin client
- proxy
主要用在RPC或者RMI中，做一个local的proxy，提供和远程过程/方法一样的接口
这样local程序对proxy的操作就如同对远端object的操作一样 => 第五章详细介绍
- brokerage
- reflection
反射？
关于Middleware的分类
后面章节会有更多介绍，这里提到的一点就是，APP通常不能完全依赖middleware来完成所有的事情，例如可靠的通信机制，经常需要在middleware提供的功能之外，APP需要做额外的事情。
Fundamental Models （基础设施模型）
说的是什么呢？
上面在Architectural Model中提到的任何一种模型，在具体实施的时候都不可避免的会碰到一些问题，例如performance、reliability、security等等
我们称之fundamental properties，本节谈谈这方面的设计。换个说法：阐述清楚在设计一个分布式系统的时候，所有需要考虑到的assumption，以及如何考虑这些assumption。
具体说，本节从3个角度考虑这些fundamental properties
1. interaction， 例如考虑interaction model的时候，需要考虑消息传输的延时，同步等
2. failure，分布式系统中任何一个节点出现错误咋办
3. security，可能的安全问题，以及如何应对设计
从分布式系统各“进程间交互”的角度分析模型，主要从下面几方面考量
Communication Channel 的特点
Latency- 从发出到收到的时间间隔
实际分析中包括比如
“实际信道传输时间”
“因为网络阻塞的等待时间 - 例如以太网原理中的冲突检测等待重发机制”
“OS的消息收发程序的处理时间 - 和CPU load有关”
Bandwidth
没啥好说的
Jitter
the variation in the time taken to deliver a series of messages.
确保一系列消息连贯发送 => 主要在video、audio领域用到
没啥好说的，上次十四章里面都说了
同步模型
基本假设：程序的每步执行都在有限的时间内完成；所有消息的传送也都在有限时间内完成；每个进程都有local clock并且漂移速度可控
在实际应用中，定义这些上下限很容易，但是真的控制在这上下限之内却是很困难；通常做法是需要确保有足够的CPU资源和网络带宽来保证；
（同步模型中，通常可以用timeout来判断是否执行失败）
异步模型
异步模型，完全相反于同步模型，上面的三个限制在异步模型中都不存在
就是十四章提到的logical clock概念
简单讲，分布式系统中，process和communication channel都可能出错
抽象归类之后，有下面三种failure model
Omission Failure
这一类，简单讲，该做的没做。
同样，分成process & communication channel 两种
先说process omission Failure => 典型的场景是process crash了 => 官方名称“fail-stop”
别的进程通常只能通过“发给它的消息没回应”来判断这个进程是否crash
=> 在异步式的设计中，这其实不是充分条件，因为那个进程可能反应慢了或者设置没收到
而同步式的设计中，timeout可以用来判断，当对方进程在规定的时间内没有反应，认为对方crash
再说 communication omission failure
简单讲就是“消息丢了”
从原因角度讲，一般有几种可能
- send方这边的buffer满了，所以新消息没能放到发送队列里面去
- receive方buffer满了。。。。
- 网络传输问题，收到之后checksum坏了
Arbitrary Failure
“随机”错误，感觉上这种定义的错误就是通常说的“灵异事件”
例如程序莫名其妙走到了其他地方；跳过某些步骤，或者发的消息有问题，自动重发等等
Timing Failure
简单如下定义，特别是“同步式设计”的系统，或者“video、audio”等app里面
Masking Failure
这不是一种错误类型定义，这个词说的是“针对上面描述的三种常见错误model”，我们在设计service的时候，要能够预见到并mask这些错误
例如用checksum检查Arbitrary failure转化成Omission failure，然后再重传之类的
这块主要从下面两方面考虑
1. 保护分布式系统中的进程和通信通道，例如金融系统
2. 包括对象（object）不受非法访问，例如存放用户信息的object
会出什么问题呢，通常都是下面这种方式
连在网络上的其他server，截获消息，然后伪造消息发给下家等等
第十一章有详细介绍
应对方法，简单讲，就是加密、完整性、公钥私钥的方式的认证，以及SSL、VPN这样的secure channel
分布式系统概念与设计-第二章笔记,布布扣,bubuko.com
分布式系统概念与设计-第二章笔记
原文：http://usdaydayup.blog.51cto.com/8723085/1392473
