概述
能夠識別與分散式系統的非功能性需求相關的指標和機制
能夠識別和解釋在對分散式系統進行建模時使用的各種視點。
能夠在設計分散式系統時對架構樣式進行適當的選擇。
能夠實現一個簡單的分散式系統，考慮函式外屬性。
能夠分析架構模型並評估從不同角度呈現的分散式系統模型，以評估它們對各種非功能性需求的滿足程度。
包含兩部分：架構和系統
分散式系統的三部分：processing elements、communication network和software。
在去中心化的系統裡，仍然有一部分“中心節點”
而在分散式系統中，完全不存在任何中心節點。
只要在去中心化系統中加一兩條邊，就可能使得整個系統變成分散式系統。
邏輯上中心化和物理上集中化的系統：
全域性上沒有時間、狀態的觀念（每個計算機不會去記錄其他計算機的情況）
異質結構——跨平臺
分散式系統的設計目標：
1. 資源共享
2. 分散式的透明性（注意定義，這裡是說的對使用者而言，看不出來系統實際上是分散式的）
Relocation是系統發起讓資源轉移的
Migration是指在使用過程中，使用者發起的轉移，比如使用手機
3. 可規模性（Scalability）
3.1 規模可規模性：可以向系統新增更多使用者和資源，但不會有明顯的效能損失。
3.2 地理可規模性：使用者和資源可能相距很遠，但通訊延遲可能很嚴重這一事實卻很難被注意到。
3.3 管理可擴充套件性：即使跨越多個獨立的管理機構，仍能輕鬆管理。
4. 公開性
網格計算（異質的計算機）、叢集計算（同質的計算機）
開發時的一些錯誤假設：
架構
所謂的中介軟體層將應用程式與底層平臺分離。
架構概念
概念、ISO/IEC/ICEE 42010/4+1模型
架構框架：用於描述在特定應用領域和/或利益相關者社群內建立的架構的約定、原則和實踐
環境：決定系統所有影響的設定和環境的上下文
利益相關者：對系統持有關注的個人、團隊、組織（或其類別）
對應關係：兩個或多個架構描述元素之間已識別或命名的關係
關注點：對與其一個或多個利益相關者相關的系統的興趣
方面：實體的特徵或本質的一部分
規範：以完整、精確和可驗證的方式識別實體的需求、設計、行為或其他預期特徵的資訊部分
利益相關者視角：思考利益實體的方式，尤其是與關注點相關的實體
架構檢視：從特定系統關注點的角度表達系統架構的工作產品
acquirers：負責採購系統時的事務
assessors：負責考慮系統是否合規合法
communicators：透過文件解釋系統
developers：構建開發系統
maintainers：維護系統（管理迭代）
suppliers：提供軟硬體條件
support staff：協助使用者在系統上運作
system administrators：部署後執行系統
testors：檢查系統是否符合預期的成果
users：定義系統的功能、成果並使用
view：看到的東西
viewpoint：從哪看的
Kruchten view：
邏輯view、過程view、開發view、部署view
使用者用、開發者開發、系統管理者管理、系統工程師部署
RW Viewpoint：
Context Viewpoint：
描述系統與其環境（人、系統、外部實體）之間的關係、依賴關係和互動。
解決問題：
1. 系統範圍
2. 責任
3. 使用的資料
Functional Viewpoint：
描述系統的執行時功能元素及其職責、介面和主要互動。
解決問題：
1. 功能能力
2. 外部介面
3. 內部結構
4. 設計理念
Information Viewpoint：
描述架構儲存、操作和分發資訊的方式。
解決問題：
1. 資訊結構
2. 內容和流程
3. 資料所有權、數量、有效性、生命週期和可訪問性；交易管理（交易到底是啥？）
4. 恢復
5. 內部規範
Concurrency Viewpoint：
描述系統的併發單元（如程序和執行緒）、其功能以及所需的協調。
解決問題：
1. 任務結構
2. 程序間通訊
3. 狀態管理
4. 同步與過載入
5. 程序的建立和銷燬
Development Viewpoint：
描述系統的開發和整合過程
解決問題：
1. 模組組織
2. 共同處理
3. 設計和測試標準化
4. 程式碼組織與檢測
Deployment Viewpoint：
描述系統的部署環境，例如節點數、鏈路數、軟體依賴關係等
解決問題：
1. 硬體
2. 第三方軟體
3. 技術相容性
Operational Viewpoint：
描述系統在生產環境中的操作方面，例如安裝過程
解決問題：
1. 安裝與升級
2. 監控執行情況
3. 配置管理
4. 資源管理
EFR：額外功能要求
非常希望可以使用該架構來檢視這些問題是否得到滿足
可訪問性、可理解性、可用性、通用性、可操作性、簡單性、移動性、遊牧性、可移植性、準確性、效率、佔用空間、響應性、可擴充套件性、可排程性、容錯性、及時性、CPU利用率、延遲、吞吐量、併發性、靈活性、可變性、可進化性、可擴充套件性、可修改性、可定製性、可升級性、可擴充套件性、一致性、適應性、開放性、可組合性、互操作性、可整合性、責任性、完整性、簡潔性、正確性、可測試性、可跟蹤性、連貫性、可分析性、模組化、可重用性、可配置性、可分發性、可用性、機密性
架構風格
服務：
合同指定的實體的整體功能。
協議
一組正式的規則，規定實體之間的資訊交換以及互動應如何進行。
規則規定
1. 訊息格式
2. 有限狀態機
3. 時間限制
4. 其他質量屬性
四個特別的風格：
Layered
分層架構：只有上層的東西能夠呼叫下層的東西
每層都應該有一定的功能，且有穩定的方式保證各相鄰層之間能夠穩定通訊。
問題：過於依賴通訊和下層
嚴格分層時只有n-1層
Client-server
客戶端-伺服器風格
動機：關注點分離、共享一些資源、保護和管理內容、延遲繫結、減少依賴
動態結構，伺服器可以分佈
伺服器是被動的
客戶端沒有限制
缺點：
單個伺服器可能成為效能瓶頸
伺服器可能出現單點故障
Publish-subscribe
伺服器主動，可能有中介，當資料可用且相關時傳送資料
缺點：由於額外的間接性，延遲時間更大且波動更大。不適合硬實時約束。
Peer-to-peer
點對點
動機：共享資源和內容、社群合作、角色對稱、併發性高
特徵：加入社群，被動向其他host提供服務、積極使用其他host的服務。
有Super peer，為社群提供更多資源。
弱點：安全性、缺乏管理
時間耦合是指分散式系統的不同元件必須與特定時間或截止日期同步執行的情況
引用耦合是指分散式系統中元件或模組之間基於共享資料或引用的依賴關係
雲端計算：硬體+軟體分層
服務Client-server
雖然後續有關於REST等架構的題，但考試不會考，這部分包括：
REST
Batch
Pipe & filters
Service-oriented
Model View Controller
Blackboard
Virtual machine
Interpreter
系統
互動風格
層疊式協議和中介軟體：
中介軟體權衡
互動模式：
1. 中介軟體僅提供通訊服務
2. 中介軟體提供網路介面
Remote procedure call（遠端過程呼叫）、訊息導向的中介軟體
命名
服務發現
名稱系統
分散式扁平化方案
分散式結構化方案
虛擬化
資源分配
資源整合（resource consolidation）
容器（container）
可擴充套件性
可擴充套件性的種類，以及如何評估他們
容錯
系統錯誤容錯及過程錯誤容錯
複製及一致性
一致性
副本（replica）管理
分散式伺服器（訪問叢集）
叢集的目的：
1. 提高效能
2. 提高可靠性
3. 提高可用性
請求處理：
讓第一層處理所有通訊可能遇到瓶頸
增加一個伺服器（交換機）來處理連線問題，不過響應可以直接返回給客戶端
請求排程：
對於Finger table，如果我們不能直接跳到這個數本身上，我們就跳到其後邊儲存其的點上（甚至於說，我們就應該跳到後面儲存其的點上）