軟件架構實踐, Len Bass

第一部分 入門介紹

第1章 什么是軟件架構 1

1.1 什么是軟件架構，什么不是軟件架構 2

1.架構是一組軟件結構
架構結構可以分為三個有用的類別，
1)組件及連接器結構
2)模塊結構
3)分配結構

架構結構的集合既不是固定的，也不是有限的。什么是架構取決于在系統上下文的推理中什么是有用的。

2.架構是一種抽象
架構關注的是公共部分;元素的私有部分(僅與內部實現有關的細節)與架構無關我們希望且需要的是，理解系統的架構要比理解系統的每個細節容易很多個數量級。
3.架構與設計
架構是設計，但并不是所有的設計都是架構。也就是說，許多設計決策不受架構的約束，
6.架構包括行為
架構師不必關注元素的所有行為。然而，當個元素 的行為影響 了整個系統的可接受性時，這個行為必須被認為是系統架構設計的一部分， 并被記錄下來。

系統架構和企業架構
企業架構
企業架構是對組織的過程、信息流、人員、組織單元的結構和行為的描述。

1.2 架構結構與視圖 5

架構結構本質上要有對應的東西。例如，神經科醫生、骨科醫生、血液科醫生和皮膚
科醫生對人體的不同結構都有不同的看法。

1.三種結構
1)組件及連接器( Component-and-Connector, C&C)結構:
2)模塊結構: 模塊結構中的模塊之間的關系包括使用( use)、泛化“is-a”)和“是一部分”(is partof)。
3)分配結構:
每個軟件元素在哪些處理器上執行?
在開發、測試和系統構建期間，每個元素存儲在哪個目錄或文件中?
每個軟件元素分配給開發團隊的任務是什么?

層結構。這種結構中的模塊稱為層。層是一個抽象的“虛擬機”。 層以可管理的方式使用其他層;在嚴格分層的系統中，一層只允許使用其他層中的一個。

3.一些有用的C&C結構
所有的C&C結構與基于模塊的結構是正交的，

C&C結構中的關系都是依附( atachment),顯示了組件和連接器是如何勾連在一起的。(連接器本身可以是“調用”這種常用的結構。)有用的C&C結構包括:

• 服務結構。這里的單元是指通過服務協同機制(比如消息)進行互操作的服務。
• 并發結構。

4.一些有用的分配結構
分配結構定了來自C&C或模塊結構的元素如何映射到非軟件——通常是硬件(可能是虛擬化的)、團隊和文件系統。有用的分配結構包括:

• 部署結構。部署結構顯示了如何將軟件分配給處理器和通信器件等硬件。
• 實現結構。該結構顯示軟件元素 (通常是模塊)如何映射到系統的開發、集成、測試或配置管理環境中的文件結構。
• 工作分配結構。這種結構用于將實現和集成模塊的任務分配給相關團隊。例如，亞馬遜的工作分配結構是為每項微服務配備一個團隊。 在大型開發項目中，識別公共功能單元并將其分配給單個團隊，而不是讓每個需要它們的人來實現它們，這是很有用的。這種結構也將決定團隊之間的主要溝通途徑:定期的網絡會議、wiki、 電子郵件列表等。

表1.1 有用的架構結構

	軟件結構	元素類型	關系	用于	影響的質量屬性
模塊結構	分解結構	模塊	是...的子模塊	資源分配以及項目構建和規劃;封裝	可修改性
	使用結構	模塊	使用(即請求正確存在..... )	設計子集和擴展	可分解性、可擴展性
	層結構	層	允許使用....服務;為..提供抽象	增量式開發;在“虛擬機” 上實現系統	可移植性、可修改性
	類結構	類、對象	是....的實例;是對....的泛化	在面向對象的系統中，分解出共性:規劃功能擴展性	可修改性、可擴展性
	數據模型結構	數據實體	{1，多}對{1，多};泛化:具體化	為一致性和性能設計全局數據結構	可修改性、性能
C&C結構	服務結構	服務、服務注冊	依附(通過消息傳遞)	調度分析;性能分析;魯棒性分析	互操作性、可用性、可修改性
	并發結構	進程、線程	依附(通過通信和同步機制)	確定存在資源爭搶的位置，實現并行的時機	性能

1.3 什么是“好的”架構 19

我們把觀察分成兩組:過程建議和產品(或結構)建議。我們的過程建議如下:
1)軟件（或系統）架構應該是單個架構師或技術領導帶領的一小組架構師的產品。架構師和開發團隊之間應該有很強的聯系，以避免不切實際的“象牙塔”設計。
2)架構師(或架構團隊)應該在持續的基礎上，將架構建立在明確的質量屬性需求的優先級列表上，這意味著要經常進行權衡。功能需求沒那么重要。
3)應該使用視圖來記錄架構。
5)架構應該增量實現。一種方法是通過創建一個“骨架"系統，在這個“骨架”系統中，通信路徑可用，但最初只有最小的功能。

1.4 總結 21
1.5 進一步閱讀 21
1.6 問題討論 22

第2章 軟件架構的重要性 25

2.1 抑制或支持系統的質量屬性 26

系統滿足其期望的(或要求的)質量屬性的能力實質上是由架構決定的。

• 高性能。你需要關注管理元素基于時間的行為，它們對共享資源的使用以及元素間通信的頻率和數量。
• 可修改性。你需要關注將責任分配給元素，并限制這些元素的交互(耦合)。理想情況下，每個變更將只影響單個元素。
• 高度防護。你需要管理和保護組件間的通信，并控制哪些組件可以訪問哪些信息。授權機制來設置一個強大的“邊界”以防止入侵。
• 安全可靠，你需要保障措施和恢復機制。
• 性能的可伸縮性。你需要將資源的使用本地化，以便引人更高容量資源來替換。
• 交付系統增量子集，你必須管理組件間的使用。
• 可重用。你需要限制元素間的耦合，這樣當你提取一個元素時，它不會帶出太多與當前環境相關的內容。

糟糕的下游設計或實現決策總是會破壞合理的架構設計。就像我們常說的那樣(多半是開玩笑):架構給予什么，實現就拿走什么。軟件生命周期的所有階段(從架構設計到編碼、實現和測試)的決策都會影響系統質量。因此，質量并不完全是架構設計的一個功能， 但它是起點。

2.2 關于變更的推理和管理 27

軟件開發社區開始認識到這樣一個事實:一個典型的軟件系統大約80%的總成本發生在初始部署之后。

2.3 預測系統質量 28

2.4 利益相關者之間的溝通 28

軟件系統的每一個利益相關者(客戶、用戶、項目經理、編碼人員、測試人員等)都與受架構影響的不同系統特征有關。例如:

• 用戶關心系統是否快速、可靠且在需要時可用。
• 客戶(為系統付費的人)關心架構可以按計劃和預算實施。
• 管理者關心架構(除了成本和進度方面之外)是否最大限度允許團隊獨立工作，以有紀律和受控的方式進行交互。
• 架構師關心實現所有這些目標的策略。

2.5 早期設計決策 31
2.6 實現約束 31
2.7 對組織結構的影響 32
2.8 賦能增量開發 33
2.9 成本和進度估算 33
2.10 可轉移、可重用模型 34
2.11 架構允許合并獨立開發的元素 34
2.12 限制設計方案的術語 35
2.13 培訓的基礎 36
2.14 總結 36
2.15 進一步閱讀 37
2.16 問題討論 37

第二部分 質量屬性

第3章 理解質量屬性 39

3.1 功能性 40
3.2 質量屬性注意事項 41

3.3 明確質量屬性需求：質量屬性場景 42

質量屬性場景由六個部分組成：

• 刺激。我們使用術語“刺激”來描述到達系統或項目的事件。刺激可以是性能社區的事件、易用性社區的用戶操作或防護性社區的攻擊，等等。
• 來源。刺激必須有源頭，它必須來自某個地方。
• 響應。響應是刺激到達后發生的活動，是架構師承諾要滿足的內容。
• 響應度。當響應發生時。它應該是可度量的。
• 環境。環境是場景發生時所處的狀況，通常是指系統運行時狀態。
• 制品。刺激到達的某個目標。這通常是指系統或項目本身，但如果可能的話，更精確一些是有幫助的。

3.4 通過架構模式和戰術實現質量屬性 45
3.5 用戰術設計 46
3.6 分析質量屬性的設計決策：基于戰術的調查問卷 48
3.7 總結 49

3.8 進一步閱讀 49

在Frank Buschmann等人的五卷集《面向模式的軟件體系結構》(Pattern-Oriented Sofware Architecture)中可以找到內容充實的架構模式目錄。

3.9 問題討論 50

第4章 可用性 51

系統與其規格之間的偏差稱為失效，這種偏差在外部是可見的，而且有明確的外部觀察者。
失效的原因叫作故障。

系統的可用性可以通過在指定的時間間隔內提供服務的概率來街量。一個眾所周知的用來推導穩態可用性(來自硬件領域)的表達式為:
$$MTBF/(MTBF+MTTR)$$
其中，MTBF ( Mean Time Between Failures)指系統平均失效間隔，MTTR ( Mean Time To Repair)指平均修復時間。
依據公式，我們可以計算概率，并做出類似“系統表現出99.999%的可用性”或“系統無法正常操作的概率為0.001%”這樣的聲明。在計算可用性時，不應考慮計劃停機時間(提前安排好的停機)，因為那時系統被認為“無須運行”;當然，這取決于系統的特定需求，這些需求通常約定在服務水平協議( Service Level Agreement, SLA)中。

4.1 可用性通用場景 53

4.2 可用性戰術 55

可用性戰術的目標是使系統能夠防止或忍受系統故障，從而使系統交付的服務仍然符合其規格。
因此作為架構師，你的工作可能是選擇和評估(而不是實現)正確的可用性戰術和戰術的正確組合。

1.故障檢測
在任何系統對故障采取行動之前，必須檢測到故障的存在或預測到故障的存在。

• pingeho在這種戰術中，節點之間交換異步請求/響應消息對，用于確定通過相關網絡路徑的可達性和往返延遲。
• 心跳。這種故障檢測機制在系統監視器和被監視的進程之間進行周期性的消息交換。心跳和ping/echo之間的區別在于誰負責啟動檢查——是監視器還是組件本身。
• 異常檢測。參數圍欄戰術使用一個已知的數據樣本(例如0xDEADBEEF),將該樣本放置在對象任何可變長參數之后，用于在運行時檢測訪問是否覆蓋了對象可變長參數分配的內存。

2.故障恢復

• 冗余備份。這種戰術指的是一種配置， 在這種配置中，如果主組件發生故障，一個或多個備份組件可以介人并接管工作。這種戰術是熱備、溫備和冷備模式的核心，它們的主要區別在于接管時備份組件的更新程度。
• 回滾
• 重試。常被用于網絡和服務器集群中。
• 事務。事務戰術最常見的實現是“兩階段提交(two-Phase Commit, 2PC)協議這種戰術可以防止兩個進程同時更新相同數據導致的競爭情況。

4.3 基于戰術的可用性調查問卷 62

4.4 可用性模式 66

• 活動冗余(熱備)。因為冗余備份組件擁有與活動組件相同的狀態，所以它可以在大約幾毫秒的時間內接管故障組件。
• 備份(冷備)。在冷備的配置中，冗余備份在故障轉移發生之前一直處于停止服務狀態，此時，在冗余備份投人服務之前，需要啟動開機復位過程。

4.5 進一步閱讀 68
4.6 問題討論 69

第5章 可部署性 71

5.1 持續部署 72
5.2 可部署性 75
5.3 可部署性通用場景 76

5.4 可部署性戰術 78

2.完全替代服務的模式
基于規模遞增部署戰術。
1)藍/綠部署。
2)滾動升級。實踐中，一次可以替換多個實例， 但每步只能替換一小部分。
3.部分替代服務的模式
(1)金絲雀測試
(2) A/B測試
在金絲雀測試中，DNS 服務器和服務發現配置被設置為向不同的版本發送客戶端請求。在A/B測試中， 要對不同的版本進行監視， 以便從業務角度選出哪 個版本提供了最佳響應。

5.5 基于戰術的可部署性調查問卷 80
5.6 可部署性模式 81
5.7 進一步閱讀 87
5.8 問題討論 87

第6章 能源效率 89

6.1 能源效率通用場景 90
6.2 能源效率戰術 92
6.3 基于戰術的能源效率調查問卷 95
6.4 模式 97
6.5 進一步閱讀 98
6.6 問題討論 99

第7章 可集成性 101

7.1 評估架構的可集成性 102
7.2 可集成性通用場景 104

7.3 可集成性戰術 105

1. 限制依賴關系
   1. 封裝
   2. 使用中介
   3. 限定通信路徑
   4. 遵守標準
   5. 抽象公共服務
2. 適配
   1. 發現
   2. 裁剪接口
   3. 配置行為
3. 協調
   1. 編排
   2. 管理資源

7.4 基于戰術的可集成性調查問卷 110

7.5 可集成性模式 112

• 包裝器。包裝器是一種封裝形式。

1.面向服務的架構模式
服務之間的通信通常使用如Web服務描述語言( Web Services Description Language, WSDL)或簡單對象訪問協議( Simple Object Access Protocol, SOAP) 等Web服務協議來執行。

2.動態發現
動態發現的注冊和注銷必須是自動化的，因此要開發相應的工具。

7.6 進一步閱讀 114
7.7 問題討論 115

第8章 可修改性 117

一個簡化的變更機制判斷公式是:
N × 不采用該機制的變更成本≤ 創建機制的成本+ (N × 使用機制進行變更的成本)
這里，N是使用可修改性機制進行修改的預期數量——但它也是一個預測。 如果出現的變更比預期的少，可能不會引入昂貴的修改機制。此外，創建可修改性機制的成本可以
應用到其他地方(機會成本)——添加新功能， 改進性能，甚至是非軟件投資，如招聘或培訓。

特定的可修改性賦予了特殊的名稱：

• 可擴展性用于容納更多內容。水平可擴展性(向外擴展)指的是向邏輯單元添加更多資源，例如向服務器集群添加新服務器。垂直可擴展性(向上擴展)是指向物理單元添加更多資源，例如向單個計算機添加更多內存。
• 可變性是指系統及其支撐制品(如代碼、需求、測試計劃和文檔)以預先計劃的方式生成一組彼此不同的變體的能力。軟件產品線中的可變性目標是在一段時間內讓構建和維護系列產品變得容易。
• 可移植性是指在一個平臺上運行的軟件可以改為在另一個平臺上運行的難易程度。

8.1 可修改性通用場景 120

8.2 可修改性戰術 121

可修改性戰術的控制目標是控制變更的復雜性以及進行變更的時間和成本。
我們可以通過測量一個模塊的變更傳播到另一個模塊的概率來量化這種重疊。這種關系稱為耦合。
內聚用于度量-一個模塊的職責之間的關系有多緊密。內聚性越高，給定變更影響多個模塊的可能性就越低。

可修改性戰術：

• 增加內聚性
  • 拆分模塊
  • 重新分配職責
• 減少耦合性
  • 封裝
  • 使用中介
  • 抽象公共服務
  • 限制依賴關系
• 延遲綁定
  • 組件替換（例如，在構建腳本或makefile中）
  • 編譯參數
  • 方面
  • 配置時綁定
  • 資源文件
  • 發現
  • 解釋參數
  • 共享庫
  • 多態性

8.3 基于戰術的可修改性調查問卷 125

8.4 模式 126

1.客戶機-服務器模式
以大觀明型性(特別是機密性)并保持完整性。
2.插件(微核)模式
插件模式包含兩種類型的元素——提供核心功能集的元素和通過一組固定接口添加功能的專門變體(稱為插件)。
4.發布-訂閱模式
發布者不知道訂閱者，訂閱者只知道消息類型。使用發布-訂閱模式的系統依賴于隱式調用，也就是說，發布消息的組件不會直接調用任何其他組件。

8.5 進一步閱讀 130

在《軟件系統體系結構:使用視點和視角與利益相關者合作》( Software Systems Architecture: Working With Stakcholders Using Viewpoints and Perspectives) 中給出了更多的可修改性模式。

8.6 問題討論 131

第9章 性能 133

9.1 性能通用場景 134

性能場景從事件到達系統開始。正確響應事件需要消耗資源(包括時間)。需要注意這種場景下，系統可能同時為其他事件提供服務。

9.2 性能戰術 137

• 控制資源需求
  • 管理工作請求
  • 限制事件響應
  • 事件優先級
  • 減少計算開銷
  • 限定執行時間
  • 提高資源利用率
• 管理資源
  • 增加資源
  • 引人并發
  • 保持多個計算副本
  • 保持多個數據副本
  • 限定隊列大小
  • 調度資源

調度策略
調度策略在概念上有兩部分:優先級分配和分派。
常見的調度策略如下:

• 先進先出。
• 固定優先級調度。
• 動態優先級調度。
  • 輪詢。
  • 最早截止優先。
  • 最少空閑優先。

9.3 基于戰術的性能調查問卷 145

9.4 性能模式 146

1. 服務網格。網格模式已在微服務架構中采用。網格的主要特征是sidecar——一種伴隨每個微服務的代理，用于處理與應用功能無關的大量公共功能，如服務間通信、監視和防護性。
2. map-reduce。

map-reduce模式由三部分組成:

• map函數以一個鍵和一個數據集作為輸人。它使用該鍵將數據散列到一組bucket中。假設我們的數據集由撲克牌組成，那么鍵值就可能是花色。
• 所有繁重的分析都在reduce函數中進行。reduce實例的數量對應于map函數輸出的bucket的數量。reduce 階段執行一些程序員指定的分析，然后發出分析的結果。例如，我們可以計算梅花、方塊、紅桃和黑桃的數量。

9.5 進一步閱讀 149

• Foundations of software and system performance engineering: process, performance modeling, requirements, testing, scalability, and practice ISBN: 9780321833822這本書提供了性能工程的全面概述，從技術實踐到組織實踐。
• Software Performance and Scalability : A Quantitative Approach。這本書涵蓋了面向企業應用程序的性能，重點介紹了隊列理論和度量。
• 《軟件性能工程》(Peformance Solutions : A Pracical Guide to Creating Reponsive,Scalable Software)) 。這本書涵蓋了性能設計，重點是構建實用的預測性能模型(并使用真實數據)。

9.6 問題討論 150

第10章 安全性 151

10.1 安全性通用場景 154
10.2 安全性戰術 156
10.3 基于戰術的安全性調查問卷 160
10.4 安全性模式 163
10.5 進一步閱讀 165
10.6 問題討論 166

第11章 防護性 169

描述防護性最簡單的方法集中于CIA (CIA-Cofientiality, Integrity, Availability) 特征上，即機密性、完整性和可用性:

• 機密性是指保護數據或服務不受未經授權訪問的屬性。例如，防止黑客在政府系統上訪問你的納稅申報表。
• 完整性是指保護數據或服務不受未經授權篡改的屬性。例如，你的成績在老師判定后是不能被篡改的。
• 可用性是指系統被合法使用的屬性。例如，拒絕服務攻擊不會阻止你從在線書店訂購這本書。

11.1 防護性通用場景 170

11.2 防護性戰術 172

• 檢測攻擊
  • 檢測人侵
  • 檢測拒絕服務
  • 驗證消息完整性
  • 檢測消息傳遞異常
• 抵抗攻擊
  • 標識參與者
  • 驗證參與者。密碼、一次性密碼、數字證書。另一個例子是CAPTCHA （Completely Automated Public Turing test to tell Computers and Humans Apart,區分計算機和人類的完全自動化公共圖靈測試)。
  • 授權參與者
  • 限制訪問
  • 限制暴露
  • 加密數據
  • 隔離實體
  • 驗證輸人。數據驗證是防范SQL注人(惡意代碼被插人SQL語句中)和跨站腳本（XSS）等攻擊的主要形式，XSS是指來自服務器的惡意代碼在客戶機上運行。
  • 更改憑證設置
• 應對攻擊
  • 撒銷訪問
  • 限制登錄
  • 通知參與者
• 從攻擊中恢復
  • 審計。我們審計系統(即保存用戶和系統的活動及其影響的記錄)以幫助跟蹤攻擊者的行為并識別攻擊者。
  • 不可抵賴性。這種戰術保證了消息的發送者以后不能否認發送過消息，而接收者也不能否認收到過消息。

11.3 基于戰術的防護性調查問卷 176
11.4 防護性模式 179
11.5 進一步閱讀 180
11.6 問題討論 180

第12章 可測試性 183

12.1 可測試性通用場景 186

12.2 可測試性戰術 187

• 控制和觀察系統狀態
  • 專用接口
  • 記錄/回放。造成故障的狀態通常很難重現。記錄是指捕獲通過接口的信息，回放是指使用它作為進一步測試的輸人。
  • 本地化狀態存儲
  • 抽象數據源
  • 沙箱?！吧诚浠敝傅氖菍⑾到y實例從現實世界中隔離出來。特別是如果在現實世界中的進行模擬，在一且失敗可能導致嚴重后果的測試情況下，常常使用沙箱戰術。
  • 可執行斷言
• 限制復雜性
  • 限制結構復雜性
  • 限制不確定性

12.3 基于戰術的可測試性調查問卷 192
12.4 可測試性模式 192
12.5 進一步閱讀 194
12.6 問題討論 195

第13章 易用性 197

13.1 易用性通用場景 198
13.2 易用性戰術 200
13.3 基于戰術的易用性調查問卷 202

13.4 易用性模式 203

1.模型-視圖-控制器
用戶交互(按下按鍵、點擊按鈕、移動鼠標等)被傳送到控制器，控制器將它們解釋為對模型的操作，然后將這些操作發送給模型，模型會相應地改變狀態。反向路徑也是原始MVC模式的部分。也就是說，模型被更改，控制器向視圖發送更新。

13.5 進一步閱讀 205
13.6 問題討論 205

第14章 使用其他質量屬性 207

14.1 其他質量屬性 207
14.2 是否使用標準質量屬性清單 209
14.3 處理“X能力”：引入新的QA 212
14.4 進一步閱讀 215
14.5 問題討論 215

第三部分 架構解決方案

第15章 軟件接口 217

元素的參與者(actor) 是指與其交互的其他元素、用戶或系統。與元素交互的參與者集合稱為元素的環境( environment)。所謂“交互”，我們指的是一個元素所做的任何可能影響另一個元素處理的事情。
這些提供與元素直接交互的點的結構，稱為資源( resource)。

15.1 接口的概念 218

15.2 設計一個接口 222

2.交互方式
兩個最廣泛使用的交互方式: RPC和REST。

• 表現層狀態轉移( Representational State Transfer, REST)。REST是用于Web服務的協議。

最常見的獨立于編程語言的數據表示樣式可以分為文本(如XML或JSON)和二進制如協議緩區如(protocol buffer)兩類。

3.交換數據的表示和結構

15.3 接口文檔編制 228

“Hyrum定律" (www.hyrumslaw.com):“如果一個接口有足夠多的用戶，那么你在契約中承諾什么就不重要了:你的系統所有可觀察的行為都將被某人所依賴?！?/p>

15.4 總結 230

15.5 進一步閱讀 230

要了解采用XML、JSON和Protocol Buffers 表示郵政地址的區別，分別見https://schema.org/PostalAddress和https:/github.com/mgravell/protobuf-net/blob/master/src/protogen.site/wwwroot/protoc/googletype/postal_address.proto。
你可以在https://grpc.io上閱讀更多關于gRPC的信息。
REST是由Roy Fielding在他的博士論文( ics.uci.edu/ ~ fielding/pubs/dissertation/top.htm)中定義的。

15.6 問題討論 231

第16章 虛擬化 233

計算界因多個獨立應用程序無法共享一臺物理機資源(如內存、磁盤、I/O通道和用戶輸入設備)而感到沮喪。無法共享資源意味著一次只能運行一個應用程序。

16.1 共享資源 234

處理器共享是通過線程調度機制實現的。

隨著應用程序的增長，將所有的代碼和數據都裝人物理內存是不可能的。面對這一挑戰，虛擬內存技術應運而生。內存管理硬件將進程的地址空間劃分為頁，并根據需要在物理內存和輔助存儲之間交換頁。物理內存中的頁可以立即訪問，而其他頁則存儲在輔助內存中，直到需要它們的時候。硬件能支持個地址空間 與另一個地址空間的隔離。

磁盤的共享和隔離使用幾種機制來實現。首先，只能通過磁盤控制器訪問物理磁盤，該控制器確保每個線程的讀寫數據流按順序傳輸。此外，操作系統可以使用諸如用戶ID和組之類的信息來標記執行線程和磁盤內容(如文件和且錄)。

網絡隔離是通過識別消息來實現的。每個虛擬機( Virtual Machine, VM) 或容器都有一個Internet協議( Internet Protocol, IP)地址，用于標識虛擬機或容器收發的消息。本質上，IP地址用于將消息路由到正確的VM或容器。另一種發送和接收消息的網絡機制依賴于端口號的使用。每個請求服務的消息除了指定一個 IP地址，同時還要指定一個端口號。

16.2 虛擬機 235

虛擬機監控程序( hypervisor),它是虛擬機的操作系統。直接在物理計算機硬件上運行的hypervisor 通常稱為裸金屬或一型hypervisor。

托管hypervisor或二型hypervisor。在這種情況下，hypervisor 作為主機操作系統上的服務運行，而hypervisor又控制一個或多個VM。

hypervisor要求其客戶VM使用與底層物理CPU相同的指令集——hypervisor不轉換或模擬指令執行。例如，如果你有一個用于使用ARM處理器的移動或嵌人式設備VM，那么你就不能在使用x86處理器的hypervisor上運行該虛擬機。另一種與hypervisor類似的技術支持跨處理器執行。它被稱為仿真器（emulator）。例如，開源QEMU仿真器可以模擬一個完整的PC系統，包括BIOS、x86 處理器和內存、聲卡、顯卡，甚至軟盤驅動器。

16.3 虛擬機映像 238

我們把啟動VM時調用的磁盤存儲中的內容稱作VM鏡像。
有三種方法可以用于創建新的VM鏡像:

1. 你可以找到一臺已運行相關軟件的機器，然后對該機器的內存進行快照。
2. 你可以從已有鏡像開始并添加其他軟件。
3. 你可以從頭開始創建鏡像。首先獲取所選操作系統的安裝介質，之后從安裝介質啟動新機器，它會格式化機器的磁盤驅動器，將操作系統復制到驅動器上，并將boot loader添加到預定位置。

16.4 容器 239
16.5 容器和虛擬機 241

16.6 容器可移植性 242

容器運行引擎和容器之間的接口已經由Open Container Initiative標準化，允許某個供應商(比如Docker)創建的容器在另一個供應商(比如containerd)提供的容器運行引擎上執行。

16.7 Pod 242

同一Pod中的容器共享IP地址和端口空間，以接收來自其他服務的請求，它們可以使用進程間通信(IPC)機制(比如信號量或共享內存)彼此通信，它們還可以共享Pod生命周期內的臨時存儲容量，它們具有相同的生命周期——Pod 中的容器一起被分配和釋放。Pod的目的是減少緊密相關容器之間的通信成本。如果容器1和容器2頻繁通信，將它們部署為一個Pod并分配到同個VM上，實際上是一種比消息傳遞更快的通信機制。

16.8 無服務器架構 243
16.9 總結 244
16.10 進一步閱讀 245
16.11 問題討論 245
第17章 云和分布式計算 247
17.1 云基礎 248
17.2 云中失效 251
17.3 使用多個實例提高性能和可用性 253
17.4 總結 261
17.5 進一步閱讀 262
17.6 問題討論 262

第18章 移動系統 263

重點介紹其中的五個特性:

• 能源
• 網絡連接
• 傳感器和執行器
• 資源
• 生命周期

18.1 能源 264

18.2 網絡連通性 266

無線網絡是根據傳輸距離來分類的。

• 在4cm以內。近場通信(Near Feild Commnication，NFC)用于門卡和非接觸式支付系統。GSM聯盟正在制定這方面的標準。
• 10m以內。IEEE 802.15標準系列涵蓋了這距離。藍牙和Zigbee是這類協議中的常見協議。
• 100 m以內。在此距離內使用IEEE 802.11標準系列(Wi-Fi)。
• 幾公里之內。IEEE 802.16 標準涵蓋了這一距離。 WiMAX是IEEE 802.16標準的商業名稱。
• 幾公里以上。這是通過蜂窩或衛星通信實現的。

架構師關注點
通信和網絡連接的設計需要架構師權衡大量的關注點，包括:

• 需要支持的通信接口數量。移動系統的設計目標恰恰相反:只應該包含嚴格要求的網絡接口，以優化功耗、發熱和空間分配。
• 從一個協議切換到另一個協議。移動系統可能會從支持一個協議 的環境移動到支持另一個協議的環境。例如，視頻可能通過Wi-Fi進行流傳輸，但隨后系統可能會移動到沒有Wi-Fi的環境中并通過蜂窩網絡傳輸。這種切換對用戶來說應該是無縫銜接的。

18.3 傳感器和執行器 267
18.4 資源 268
18.5 生命周期 270
18.6 總結 273
18.7 進一步閱讀 274
18.8 問題討論 275

第四部分 可擴展架構實踐

第19章 架構上的重要需求 277

架構重要性需求( Architecturally Significant Requirement, ASR) 是一種對架構有深遠影響的需求，也就是說，如果沒有這種需求，架構可能會有很大的不同。

19.1 從需求文檔中收集ASR 278

19.2 通過訪談利益相關者收集ASR 279

• 業務/使命陳述。代表系統背后的業務關注點的利益相關者(通常是管理者或管理者代表)花費大約一個小時來解釋系統的業務背景、廣泛的功能需求、約束和已知的QA需求。
• 架構計劃陳述。雖然詳細的系統或軟件架構可能不存在，但可能已經創建了廣泛的系統描述、上下文示意圖或其他制品來描述系統的一些技術細節。
• 識別架構驅動因素。
• 場景頭腦風暴。通過指定明確的刺激和響應，確保每個場景都解決了一個QA問題。
• 場景整合。要求利益相關者識別內容非常相似的場景。
• 場景優先級。利益相關者可以將任意數量的選票投給任何場景或場景組合。
• 場景細化。

我不知道需求應該是什么

在這種情況下，引出這個“東西”要比簡單地自己編造需求好得多。例如，你可能會問，“系統應該以多快的速度響應這個事務請求?”如果答案是“我
不知道”，我的建議是裝糊涂。你可以說，“那么...24h可以嗎?”
通過裝糊涂，你通常可以讓人們至少給你一個可接受的值范圍，即使他們不確切地如道需求應該是什么。

19.3 通過理解業務目標收集ASR 282

PALM的核心由以下步驟組成:

• 業務目標的引出。詳細閘述業務目標并將其表示為業務目標場景。
• 從業務目標中識別潛在的QA。讓參與者描述有助于實現目標的QA和響應度值(如果需要架構實現)。

19.4 在工具樹中捕獲ASR 284

效用樹以單詞“效用”作為根節點開始。效用是系統整體“好處”的一種表達。
一旦ASR被記錄為場景并放在樹的葉節點上，你就可以根據兩個標準來評估這些場景:候選場景的業務價值和實現它的技術風險。你可以使用任何你喜歡的量表，但我們發現一個簡單的“H"(高)、“M"(中)和“L”(低)評分系統足以滿足每個標準。對于業務價值，“高”表示必須具備的需求，“中” 表示重要但不會導致項目失敗的需求，而“低”表示需要滿足但不值得付出太多努力的良好需求。對于技術風險，“高"表示風險會讓你夜不能寐，“中”表示滿足此ASR會讓你擔心，但不會帶來高風險，“低”表示你有信心有能力
滿足該ASR。

19.5 發生了變化 286
19.6 總結 286

19.7 進一步閱讀 287

可在https://www.opengroup.org/togaf/10thedition上獲得Open Group Architecture Framework,它提供的完整模板，用于記錄包含大量有用信息的業務場景。

19.8 問題討論 287

第20章 設計架構 289

屬性驅動設計( Atribute-Driven Desig, ADD)，它允許以系統的、可重復的、經濟高效的方式來設計架構。

20.1 屬性驅動的設計 289

20.2 ADD步驟 292

1.步驟1:復檢輸入
設計過程的輸人;

• 本輪設計的目標
• 主要功能需求
• 主要質量屬性(QA)場景
• 任何約束
• 任何關注點

2.步驟2:通過選擇驅動因素建立迭代目標
每次設計迭代都聚焦實現一個特定的目標。

3步驟3:選擇-一個或多個系統元素進行細化
更滿足驅動因素，你就要做出架構設計決策，然后在一- 個或多個架構結構中表現出來。

4.步驟4:選擇-一個或多個符合所選驅動因素的設計概念
選擇設計概念可能是你在設計過程中面臨的最困難的決策，因為它要求你識別各種可能用于實現迭代目標的設計概念，然后從這些備選方案中進行選擇。

5.步驟5:實例化架構元素，分配職責，定義接口
如何從你選擇的設計概念出發實例化元素。例如，如果你選擇層模式作為設計概念，就必須決定使用多少層，以及它們允許的關系，因為模式本身并沒有規定這些關系。

6.步驟6:素描視圖并記錄設計決策
如果你在一一個會議室執行步驟5， 你可你白板上完成一系列圖表。捕獲視圖可能就像給白板拍張照片一樣簡單。

7.步驟7:執行當前設計的分析，檢查迭代目標和設計目標的實現情況

8.必要時進行迭代
由于時間或資源的限制，這種重復通常是不可能的，因為這些限制迫使你停止設計活動并轉向實現。
是否需要更多的設計迭代，判斷的標準是什么?讓風險成為你的向導。

20.3 ADD步驟4的進一步說明：選擇一個或多個設計概念 295

1.識別設計概念
更槽糕的是，這些設計概念分散在許多不同的來源:幾十種博客和網站、研究文獻和書籍。

設計候選方案：

• 利用現有的最佳實踐。
• 利用自己的知識和經驗。缺點是，你可能最終會重復使用相同的思想，即使它們不是最適合你所面臨的設計問題。俗話說:如果你只有一把錘子，那么整個世界看起來就像一顆釘子。

2.設計概念的選擇
SWOT (優勢、劣勢、機會、威脅)分析等方法可以幫助你做出決策。

3.創建原型
創建原型還是不創建原型
一個團隊可以進行一系列的實驗(比如構建原型)，以減少選擇的不確定性。問題在于實驗可能會帶來巨大的成本，而得出的結論可能仍然不確定。

20.4 ADD步驟5的進一步說明：生成結構 298
20.5 ADD步驟6的進一步說明：在設計過程中創建初步文檔 301

20.6 ADD步驟7的進一步說明：對當前設計進行分析并審查迭代目標和設計目的實現情況 304

評估你是否完成了足夠的設計工作：

• 你需要做多少設計?
• 到目前為止，你做了多少設計?
• 你完成了嗎?

1.架構backlog的使用
架構backlog是架構設計過程中仍然需要執行的未決活動的待辦事項列表。

2.使用設計看板
一個可以用來跟蹤設計過程的工具是看板。 看板建立了三類backlog項：“未解決“部分解決”和“完全解決”。

20.7 總結 306
20.8 進一步閱讀 306
20.9 問題討論 307

第21章 架構評估 309

架構評估是確定架構符合其預期目標程度的過程。

21.1 評估作為一項降低風險的活動 309

21.2 關鍵的評估活動是什么 310

價每次評估都應包括(至少)以下步驟:
1)評審人員單獨確保自己了解架構的當前狀態。
2)評審人員確定指導評審的若干驅動因素。
3)對于每個場景，每個評審人員應確定該場景是否已滿足。
4)評審人員捕獲在上一步驟中暴露的潛在問題。

21.3 誰能執行評估 311
21.4 環境因素 312

21.5 架構權衡分析方法 313

架構權衡分析方法( Architecture Tradeoff Analysis Method, ATAM)是正式定義的執行架構評估的過程。ATAM的設計使評估者不需要事先熟悉架構或其業務目標，也不需要等到系統構建完成。

1.ATAM的參與者

• 評估團隊。這個團隊位于要進行架構評估的項目的外部。在任何情況下，他們都需要被認為是有能力的、無偏見的局外人，沒有隱含的議程或意圖。
• 項目決策者。這些人被授權為開發項目說話，或者有權對其進行變更。通常包括項目經理，如果能找到一個客戶為開發買單，那么該客戶的代表也可能會在里面。架構師總是被包括在內——架構評估的一個基本規則是架構師必須欣然參與。
• 架構利益相關者。利益相關者對所宣稱的架構具有既得利益。利益相關者包括開發人員、測試人員、集成商、維護人員、性能工程師、用戶，以及與系統交互的系統構建者。

角色	職責
團隊領導	建立評估:與客戶協調，確?？蛻粜枨蟮玫綕M足:創建評估合同:組建評估小組:確保生成并交付最終報告
評估領導	執行評估:推動場景獲取;管理場景優先級排序過程;推動根據架構評估場景
場景描述者	在場景獲取過程中以共享的、公開的形式編寫場景:捕獲每個場景的一致描述， 暫停討論，直到獲得準確的描述
電子抄寫員	以電子形式捕獲過程中的產出一原始場景、 激發每個場景的問題(通常在場景本身描述中找不到)和每個場景的分析結果;生成已采用方案的列表，分發給所有參與者
提問者	基于質量屬性提出問題
表 ATAM 評估團隊角色

2.ATAM的輸出
1)架構簡明介紹。
3 )以質量屬性場景表示的優先質量屬性需求。
4)一組風險點和無風險點。
6)將架構決策映射到質量需求。
7)一組識別出的敏感點和權衡點。敏感點是對質量屬性響應有顯著影響的架構決策。權衡點是當兩個或多個質量屬性響應對相同的架構決策敏感，但其中一個改善而另一個惡化時，就會出現矛盾，因此需要權衡。

3.ATAM的各個階段

階段	活動	參與者	典型累積時間
0	伙伴關系和準備	評估團隊領導和關鍵項目決策者	按要求非正式地進行，可能需要幾個星期
1	評估	評估團隊和項目決策者	1~2天
2	評估(繼續)	評估團隊、項目決策者和利益相關者	2天
3	跟進	評估團隊和評估客戶	1星期
表 ATAM階段及其特征

4.評估階段的步驟
ATAM分析階段(第1和第2階段)包括九個步驟。
1)步驟1:講解ATAM
2)步驟2::講解業務目標
3)步驟3:講解架構
4)步驟4:識別架構設計方法
5)步驟5:生成質量屬性效用樹
6)步驟6:分析架構設計方法
7)第2階段的間歇和開始
8)步驟7:頭腦風暴并確定場景優先級
9)步驟8:分析架構設計方法
10)步驟9:講解結果

21.6 輕量級架構評估 324
21.7 總結 326

21.8 進一步閱讀 327

有多個采用ATAM方法的案例研究?？梢酝ㄟ^訪問https://insights.sei.cmu.edu/library/并搜索“ ATAM case study"找到它們。

21.9 問題討論 327

第22章 記錄一個架構 329

22.1 架構文檔的用途和受眾 330
22.2 符號 331
22.3 視圖 332
22.4 合并視圖 339

22.5 記錄的行為 340

有兩種類型的表示法可用于記錄行為:面向軌跡的和綜合的。
軌跡描述了系統結系之間的一系列活動或交互。這里我們介紹記錄軌跡的四種表示法:用例、序列圖、通信圖和活動圖。

• 序列圖。對象(即元素實例)有一條生命線，沿時間軸以垂直虛線繪制。這個序列通常由最左邊的角色開始。實例通過發送消息進行交互，消息顯示為水平箭頭。消息可以是通過網絡發送的消息、函數調用或通過隊列發送的事件。消息通常映射到接收方實例接口中的資源(操作)。圖中的實線實心箭頭表示同步消息，而實線開放箭頭表示異步消息，虛線箭頭是返回消息。沿著生命線的執行條表示實例正在處理或被阻止等待返回。

綜合表示法顯示結構元素的完整行為。
狀態機是許多綜合表示法使用的一種形式。
UML狀態機允許你跟蹤系統的行為。這樣的圖表使用方框表示狀態，使用箭頭表示狀態之間的轉換。

22.6 不只是視圖 345

除了視圖和行為，關于架構的全面信息還包括以下內容:

• 視圖之間的映射。因為一個架構的所有視圖都描述同一個系統，所以任何兩個視圖都有很多共同之處。

22.7 記錄基本原理 346

22.8 架構利益相關者 347

架構的主要利益相關者包括:

• 項目經理關心進度計劃、 資源分配。

對以下視圖感興趣:

1. 模塊視圖。分解視圖、使用視圖和分層視圖。
2. 分配視圖。部署視圖和工作分配視圖。
3. 其他。顯示系統交互、系統概述和用途的頂層上下文關系圖。

• 開發團隊的成員
• 測試人員和集成人員
• 最終用戶不需要看到架構
• 分析人員對設計是否滿足系統的質量目標感興趣。架構作為架構評估方法的素材

22.9 實際問題 350
22.10 總結 353

22.11 進一步閱讀 353

AADL (addl.info) 是一種架構描述語言， 已成為SAE記錄架構的標準。SAE是航空航天、汽車和商用車輛行業工程專業人士的組織。

22.12 問題討論 354

第23章 管理架構債 355

隨著時間的推移，設計將變得難以維護和發展。我們將這種形式的熵稱為“架構債”。
一旦確定了架構債，并且足夠糟糕，就應該通過重構來消除它。如果沒有回報的定量證據，通常很難讓項目利益相關者同意這一點。
債務分析模型可以確定架構中出現異常高的錯誤率和代碼擾動率(churn)(根據提交的代碼行)的區域，并嘗試將這些癥狀與設計缺陷聯系起來。

23.1 確定是否存在架構債問題 356

在管理架構債的過程中，我們將聚焦架構元素的物理表現形式，即存儲源代碼的文件。我們如何確定一組文件在架構上是相關聯的呢? 一種方法是根據項目文件之間的靜態依賴關系，例如，一文件中的方法調用另文件中的方法。第二種方法是捕獲文件之間的進化依賴關系。 當兩個文件需要-起變更時， 即稱之存在進化依賴關系。
我們可以使用一種稱為設計結構矩陣( Design Structure Matrix, DSM)的特殊鄰接矩
陣來表示文件依賴關系。
二T定進化(取歷文)低積。
重復一下: DSM中的每一行表示一個文件。一 行中的條目表示該文件對系統中其他文件的依賴關系。如果系統耦合度低，則DSM矩陣是稀疏的;也就是說，任何給定的文件都依賴較少的其他文件。此外，你應希望DSM是下對角線的:也就是說，所有條目都出現在對角線下方。這意味著文件僅依賴于較低級別的文件，而不依賴于較高級別的文件，并且你的系統中沒有循環依賴項。

23.2 發現熱點 358

如果你懷疑你的代碼庫有架構債(也許錯誤率在上升而特性發布速度在下降),
常見反模式:

• 不穩定的接口
• 違反模塊化
• 不健康的繼承
• 循環依賴或派系依賴
• 包循環

23.3 示例 362

2.量化架構債
架構師可以很容易地根據熱點中的反模式估計每個重構所需的人月數。

23.4 自動化 363
23.5 總結 364
23.6 進一步閱讀 364
23.7 問題討論 365

第五部分 架構和組織

第24章 架構師在項目中的角色 367

24.1 架構師和項目經理 367

項目經理負責項目的整體績效——通常是保證項目在預算內、按計劃進行，并配備正確的人員做正確的工作。
項目經理應該知道，并向高層管理者反映項目中的進展和風險，而軟件架構師應該知道，并向開發人員反映外部利益相關者的關注點。

架構師在支持項目管理知識領域中的角色

項目管理知識體系領域	描述	架構師角色
項目集成管理	確保項目中各個元素彼此協作	創建設計團隊，圍繞設計組織團隊;管理依賴關系。獲取度量指標。協調變更請求
項目范圍管理	確保項目包括所有必需的工作，并且只包括必需的工作	獲取、協商和審查運行時需求，并生成開發需求。估算與滿足需求相關的成本、進度和風險
項目時間管理	確保項目按時完成	幫助定義工作分解結構。定義跟蹤措施。提出給軟件開發團隊分配資源的建議
項目成本管理	確保項目在所需預算內完成	從各個團隊收集成本數據;就構建/購買和資源分配提出建議
項目質量管理	確保項目滿足其承擔的需求	針對質量進行設計，并根據設計跟蹤系統。定義質量指標
項目人力資源管理	確保項目最有效地利用人力資源	定義所需的技能集。指導開發人員職業道路。推薦培訓。面試候選人
項目溝通管理	確保及時、適當地生成、收集、傳播、存儲和處置項目信息	確保開發人員之間的溝通和協作。征求有關進展、問題和風險的反饋。監督文檔
項目風險管理	識別、分析和應對項目風險	識別和量化風險;調整架構和流程以降低風險
項目采購管理	從組織外部獲取商品和服務	確定技術要求;推薦技術、培訓和工具

24.2 增量架構和利益相關者 369

24.3 架構和敏捷開發 370

敏捷原則和以架構為中心的觀點

敏捷原則	以架構為中心
我們的首要任務是通過盡早、持續地交付有價值的軟件來滿足客戶	對極了
歡迎不斷變化的需求，即使是在開發后期。敏捷流程利用變化實現客戶的競爭優勢	對極了，這一原則要求提供高度可修改性和可部署性的架構
圍繞有工作動力的個人建立項目。給他們環境和他們需要的支持，并相信他們能完成工作	雖然我們原則上同意，但許多開發人員缺乏經驗。因此，請確保包括一名技術熟練、 經驗豐富、積極主動的架構師來幫助指導這些人
在開發團隊中傳遞信息的最有效方法是面 對面交談	對于重要系統來說，這是胡說八道。人類發明寫作是因為我們大腦不能記住需要記住的一切。接口、協議、架構等都需要寫下來，重復指令的低效和無效，以及由于誤解而產生的錯誤，都不符合這一原則。根據這一觀點，任何人都不應該制作用戶手冊，而應該公開開發者的電話號碼，并邀請他們隨時通話。對于任何有維護階段(幾乎所有系統都有維護階段)的系統來說，這也是毫無意義的，因為在維護階段，根本找不到原始團隊。
最好的架構、需求和設計來自自組織團隊	不，他們沒有。正如我們在第20章中所描述的，最好的架構是由熟練、有才華、訓練有素和經驗豐富的架構師有意識設計的

24.4 架構和分布式開發 373

大多數實質性項目都是由分布式團隊開發的。
分布式開發既有好處也有挑戰:

• 成本。勞動力成本因地而異，然而，在低成本的開發人員具備足夠的領域專業知識之前，在克服分布式開發的困難之前，必須進行大量的返工，從而讓整個工作得不償失。
• 技能和勞動力。組織可能無法在一個地點雇用開發人員: 以分布式方式開發系統允許工作移動到員工所在的位置，而不是強迫員工移動到工作地點，盡管這是以額外的通信和協作為代價的。
• 本地市場知識。開發者對合適的功能和可能出現的文化問題更有發言權。

協作方法包括下列選項:

• 非正式接觸。只有團隊同地協作時，才能進行非正式接觸，如在咖啡間或走廊里開會。
• 文檔。
• 會議。
• 異步電子通信。各種形式的異步電子通信可以用作協作機制，如電子郵件、新聞組、博客和wiki。

這對架構和架構師意味著什么?這意味著在分布式開發中，架構師將責任分配給團隊比在同地協作(指所有開發人員都在一個辦公室內，或者至少在很近的距離內開發)中更為重要，這還意味著，與其他質量屬性(如可修改性和性能)相比，架構師給了模塊依賴關系更多的關注。

24.5 總結 376

24.6 進一步閱讀 376

Dan Paulish寫了一本介紹如何在以架構為中心的環境中進行管理的好書——《軟件項日管理實用指南——以體系結構為中心( Architecture-centric Software Project Management: A Pactical Guide)。
架構師在組織中占有獨特的地位。他們被期望熟練地掌握系統生命周期的所有階段。在項目的所有成員中，他們對項目和系統的所有利益相關者的需求最為敏感。他們之所以被選為架構師，部分原因是他們的溝通能力高于平均水平。The Software Architect Elevator : Redefining the Architect's Role in the Digital Enterprise 描述了架構師與組織內外各級人員互動的獨特能力。

24.7 問題討論 377

第25章 架構能力 379

25.1 個人能力：架構師的職責、技能和知識 379

3.知識

通用知識領域	特定知識領域	示例
計算機科學知識	架構概念知識	了解架構框架，架構模式、戰術、結構和視圖、參考架構、與系統和企業架構的關系、新興技術、架構評估模型和方法以及質量屬性
	軟件工程知識	軟件開發領域的知識，包括需求、設計、開發、維護、配置管理、工程管理和軟件工程過程。系統工程知識
	設計知識	熟悉工具、設計和分析技術。了解如何設計復雜的多產品系統。熟悉面向對象的分析和設計，以及UML和SysML圖表
	編程知識	熟悉編程語言和編程語言模型。具備安全性、實時、防護性等專業編程技術知識
技術和平臺知識	特定技術和平臺	熟悉硬件/軟件接口、基于Web的應用程序和互聯網技術。具備特定軟件/操作系統的知識
	對技術和平臺的通用知識	了解IT行業的未來發展方向以及基礎設施對應用程序的影響方式
組織環境和管理的知識	領域知識	了解最相關的領城和特定領域的技術
	行業知識	了解行業最佳實踐和行業標準。了解如何在國內1海外團隊環境中工作

25.2 軟件架構組織的能力 386
25.3 成為更好的架構師 387
25.4 總結 388

25.5 進一步閱讀 388

信息技術架構知識體系( Information Technology Architecture Body of Knowledge，ITABoK)是一個“免費的IT架構最佳實踐、技能和知識公共檔案庫，基于全球最大的IT架構專業組織lasa中的個人和公司成員的經驗開發而成”( https://itabok.iasaglobal.org/itabok/)。
Joseph Ingeno在Software Architect's Handbook中專門用了一章來介紹“軟件架構師的軟技能”。

25.6 問題討論 389
第六部分 結論
第26章 展望未來：量子計算 391
26.1 單量子位 392
26.2 量子隱形傳態 394
26.3 量子計算和加密 394
26.4 其他算法 395
26.5 潛在應用 396
26.6 最后的想法 397
26.7 進一步閱讀 398
參考資料 399