分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
object提供接口供外部訪問，具體的訪問方法通過IDL（Interface Defination Language）來描述 => 第5&8章有更詳細的描述
Component
從發展的角度，基於Component爲基礎而構建的分佈式系統是爲了解決上面“object爲基礎的系統”的問題而產生的（什麼問題？）
建立在問題域基礎上，把一些相關的object組合形成Component，同樣提供接口供外部訪問 => 與object-based的系統不同的是，Component-based的系統中，對外部依賴的描述比較嚴格 => 顯式的描述了自己component正常工作時需要的外部依賴，從結構化系統設計的角度講，這是有利於例如第三方開發獨立的Component；
第8章有更詳細的描述
Webservice
邏輯和上面的一樣，封裝之後通過接口提供功能
區別或者說優點在於，通過web技術提供更加“公共”的接口，例如URL和XML-based msg exchange
在實際應用中，webservice 經常和“通過object or component-based的”其他App結合起來，提供value-added service => 不同business之間的集成 => chapter9有更多的描述
上面是從“構成實體”角度的描述，下面，從各實體之間“交互、通信”角度
三大類：interprocess（進程間通信）；remote invoke（遠程調用）；indirect communication（pub-sub？）
interprocess
主要指的是提供send/rec 原語API進行消息的收發，或者更加common Internet API （socket） => 第四章有更詳細介紹
remote invocation
遠程調用，首先分兩大類（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下載的思想，第十章就詳細介紹這種結構如何設計工作
上面介紹了分佈式系統中的“邏輯實體”“實體之間的通信方式”“實體之間的角色和職責”，
下面說說如何map這些邏輯實體到具體的物理機器
這個問題沒有具體的通用性指導原則，只有幾個比較宏觀的策略性原則可供考慮，結合實際情況做相應的設計
（爲什麼不能有統一原則？需要考慮實體之間的通信方式，當前物理機的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.
下面，再換個角度分析 => 傳統的“架構”層面 （例如分層） => 書上叫Architectural Pattern
叫“架構模式”也許更加合適（類比與“設計模式”）
=> 在解決特定問題的時候，值得參考的架構設計模式。
Layering Arch
常說的“分層”，底層給上層提供service => 換句話說，隱藏下層的實現細節，抽象出簡單的service 接口提供給上層
簡單圖示如上，其中提一下Middleware的定義：
- 屏蔽底層多樣性，向App的編程人員提供“簡單編程模型”
（mask heterogeneity and to provide a convenient programming model to application programmers）
- 上面的“簡單編程模型”通常包括
- 遠程過程、方法調用（RPC、RMI）
- 進程間通信
- 共享數據管理等等，後面會細表
Tiered Arch （居然和Layering說的不是一回事 => 同一件事情的不同方面）
相對於Layering，Layering更多的是邏輯層面對整個軟件的分層
而當提到“Tier”的時候，更多的是指，如何把上面的logic layer放到具體的物理機器上面
例如下圖所示的3-layers SW （表示層、商業邏輯層、持久化層），落實到Tier的時候，可以有2 tiers or 3 tiers兩種方案
沒什麼可多說的，書上提到了AJAX的例子，Google Map就是AJAX實現的一個典型
整個屏幕被分割爲256x256的tiles，每一塊的刷新實際都是瀏覽器端AJAX往後臺請求新數據的過程
Thin Client
見名識意
除了BS架構，另外一種常用技術是通過VNC提供遠程桌面訪問的方式實現thin client
其他常見的模式（other commnly occuring pattern）
- 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，可能的安全問題，以及如何應對設計
Interaction Model
從分佈式系統各“進程間交互”的角度分析模型，主要從下面幾方面考量
1. 通信通道的特徵 （latency、bandwidth、Jitter）
Communication Channel 的特點
Latency- 從發出到收到的時間間隔
實際分析中包括比如
“實際信道傳輸時間”
“因爲網絡阻塞的等待時間 - 例如以太網原理中的衝突檢測等待重發機制”
“OS的消息收發程序的處理時間 - 和CPU load有關”
Bandwidth
沒啥好說的
Jitter
the variation in the time taken to deliver a series of messages.
確保一系列消息連貫發送 => 主要在video、audio領域用到
2. 缺乏統一的時間
沒啥好說的，上次十四章裏面都說了
3. 關於Interaction Model的兩種類型 - 同步model和異步model
同步模型
基本假設：程序的每步執行都在有限的時間內完成；所有消息的傳送也都在有限時間內完成；每個進程都有local clock並且漂移速度可控
在實際應用中，定義這些上下限很容易，但是真的控制在這上下限之內卻是很困難；通常做法是需要確保有足夠的CPU資源和網絡帶寬來保證；
（同步模型中，通常可以用timeout來判斷是否執行失敗）
異步模型
異步模型，完全相反於同步模型，上面的三個限制在異步模型中都不存在
4. 事件排序
就是十四章提到的logical clock概念
Failure Model
簡單講，分佈式系統中，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，然後再重傳之類的
Security Model
這塊主要從下面兩方面考慮
1. 保護分佈式系統中的進程和通信通道，例如金融系統
2. 包括對象（object）不受非法訪問，例如存放用戶信息的object
會出什麼問題呢，通常都是下面這種方式
連在網絡上的其他server，截獲消息，然後僞造消息發給下家等等
第十一章有詳細介紹
應對方法，簡單講，就是加密、完整性、公鑰私鑰的方式的認證，以及SSL、***這樣的secure channel
Weighted Voting for Replicated Data, David K.Gifford 多機副本可以提高分佈式系統的性能（比如可以支持多個節點的併發訪問）， 但是會產生新的問題：多個副本之間可能因爲修改操作導致副本內容不一致。 論文提出一個新的算法來維持副本間的數據一致性。算法通過給副本賦以投票數來實現，每個讀操作需要收集事先規定的r個投票，每個寫操作需要收集事先規定的w個投票，才能執行讀寫請求； 並且 r + w > n (n爲賦給副本的總的投票數）。這樣使得任何讀寫操作都會具有交集。使用版本號來跟蹤副本內容的修改。這樣任何讀， 寫操作都可以發現最新的更新版本。 通過對應用場景的理解（比如讀多，寫少）來挑戰r，w，n的數值。 例子：GFS有3個副本，假設每個副本的投票爲1， 即共有3個副本，則r和w可以設置爲： （1）r=1， w=3 讀性能高，寫性能低， 適合頻繁讀，少量寫的應用場景（大多數website) （2）r=3, w=1 讀性能低，寫性能高，適合頻繁寫，少量讀的應用場景 （寫log？？） （3）r=2, w=2 讀寫性能相當，但是比讀取或者寫入單一副本的性能要差而可靠性和一致性具有保證。 通過對 文件 指定 版本號來解決上面讀寫多個副本，發現不一致適合的衝突處理。在讀寫進程數已知的情況下可以使用logical time vector來排序讀寫操作。 |
Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency, Cary G.Gray.. 論文提出基於短時間租約的方式來控制副本的讀寫。系統保證在某一客戶端持有租約期間整個系統不能對其進行寫操作，從而保證副本數據一致性。當租約超時，比如說10s，客戶端才能對primary data進行寫/更新操作。其他客戶端在超時後，重新從服務器取新的副本和租約時間。 通過這樣的方式來保證讀寫一致性，以及通過在租約期間的讀本地緩存而非服務器數據來提高讀性能。 之後論文對這一模型進行了分析和評估（還沒看） 聯想到GFS中的鏈式更新，採用了類似的操作而非是一個全局鎖的方式來保證更新的原子性。 即對某一具有三個副本的數就集，若客戶端對其進行寫操作，則目錄服務器將會選擇三個副本所在的服務器之一作爲master，並賦予一個租約，此master會將寫請求攜帶的數據以鏈的方式轉給另外兩個服務器, client <=> master <=> replica A <=> replica B。 在都寫完以後，才返回成功狀態給client和目錄服務器。 當然這裏另外一個保證機制是允許有中斷的或者寫了部分的數據存在，客戶端在讀取數據時，會進行校驗和忽略只有部分正確或內容corrupted的記錄存在而繼續讀下一條。 |