三位著名的軟件架構師的新版著作,闡述了軟件架構師如何管理和優化現有體系結構,轉換它們以解決新問題,并構建可重用的體系結構,使之成為戰略業務資產。更新了移動,云,能源管理,DevOps,量子計算等新內容
當開始編寫本書第4版時,我們遇到的個問題是:架構還重要嗎?隨著云基礎設施、微服務、框架和每個可能想象的領域以及質量屬性參考架構的興起,人們可能會認為不再需要架構知識了。今天的架構師需要做的就是從豐富的工具和基礎設施備選方案中選一個,再將它們實例化并加以配置,一個架構就完成了。
我們過去(以及現在)非常肯定架構仍然重要。為此,我們采訪了一些架構師(他們在醫療保健、汽車、社交媒體、航空、國防、金融、電子商務等領域工作),他們誰也沒有被教條的偏見所左右。他們的回答證實了我們的信念,即架構在今天和20多年前我們編寫第1版時一樣重要。
讓我們來研究一下架構仍然重要的原因。,新需求的增長速度多年來一直在加快,甚至現在還在繼續加快。在客戶和業務需求以及競爭壓力的驅動下,今天的架構師面臨著不斷增加的特性需求和永無休止的待修復bug。如果架構師不注意系統的模塊化(而且請記住微服務不是的),系統很快就將拋錨—難以理解、變更、調試和修改,并拖累業務。
第二,當系統的抽象級別在增加時(我們可以并且確實經常使用許多復雜巧妙的服務,而不用關心它們是如何實現的),我們創建的系統的復雜性也在以同樣快的速度增加。這像一場軍備競賽,而架構師并沒有獲勝!架構一直致力于馴服復雜性,而這一點在短期內是不會消失的。
說到提高抽象級別,基于模型的系統工程(Model-Based Systems Engineering,MBSE)在過去10年的時間里已經成為工程領域的一股強大力量。MBSE是一種形式化的支持系統設計的建模應用。國際系統工程理事會(International Council on Systems Engineering,INCOSE)將MBSE列為“轉型賦能者”之一,它是整個系統工程學科的基礎。模型是對一個可以被推理的概念或結構進行圖形化、數學化或物理化表示。INCOSE正試圖將工程領域從基于文檔的思維轉向基于模型的思維,其中結構模型、行為模型、性能模型等都被持續用于更好、更快、更便宜地構建系統。MBSE本身已經超出了本書的范圍,但是我們不得不注意到正在被建模的是架構。那誰建立模型呢?回答是:架構師。
第三,信息系統世界的飛速增長(以及前所未有的員工流動率)意味著,在任何現實世界的系統中,沒有人了解一切。僅僅聰明和努力是不夠的。
第四,盡管工具可以自動完成我們過去人工做的許多事情(例如Kubernetes中所有的編排、部署和管理功能),但我們仍然需要理解所依賴的這些系統的質量屬性,并在把系統組合到一起時理解突現的質量屬性。大多數質量屬性(如性能、防護性、可用性、安全性等)都容易受到“短板”問題的影響,而這些短板只有在聯調系統時才會出現并影響我們。如果沒有指路之手來避免災難,聯調很可能會失敗。那只指路之手屬于架構師,不論他們的頭銜是什么。
考慮到這些因素,我們覺得確實需要這本書。
但有必要推出第4版嗎?當然有必要!這應該是非常明顯的。自上一版出版以來,計算機領域發生了很大變化。一些之前沒有被考慮的質量屬性在許多架構師的日常實踐中變得重要。隨著軟件繼續滲透到社會的各個方面,對許多系統來說,安全性考慮已經變得至關重要,如軟件控制駕駛的汽車。同樣,十年前,能源效率是少數架構師考慮的質量屬性,但現在必須注意它,從對能源有強烈需求的大型數據中心到我們周圍的小型(甚至很小的)電池驅動的移動和物聯網設備。此外,考慮到我們比以往任何時候都更多地利用現有的組件來構建系統,可集成性的質量屬性正在消耗我們越來越多的注意力。
后,我們正在構建不同種類的系統,并且以不同于10年前的方式構建它們。現在的系統通常構建在云中的虛擬化資源之上,它們需要提供并依賴顯式接口。此外,它們的移動性越來越強,移動性帶來的機遇和挑戰也越來越多。因此,在這個版本中,我們增加了關于虛擬化、接口、移動性和云的章節。
如你所見,我們說服了自己。希望我們同樣說服了你,你會發現第4版對你的書架是一個有用的補充。
部分 入門介紹
第1章 什么是軟件架構1
1.1 什么是軟件架構,什么不是軟件架構2
1.2 架構結構與視圖5
1.3 什么是“好的”架構19
1.4 總結21
1.5 進一步閱讀21
1.6 問題討論22
第2章 軟件架構的重要性25
2.1 抑制或支持系統的質量屬性26
2.2 關于變更的推理和管理27
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
3.9 問題討論50
第4章 可用性51
4.1 可用性通用場景53
4.2 可用性戰術55
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
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
7.4 基于戰術的可集成性調查問卷110
7.5 模式112
7.6 進一步閱讀114
7.7 問題討論115
第8章 可修改性117
8.1 可修改性通用場景120
8.2 可修改性戰術121
8.3 基于戰術的可修改性調查問卷125
8.4 模式126
8.5 進一步閱讀130
8.6 問題討論131
第9章 性能133
9.1 性能通用場景134
9.2 性能戰術137
9.3 基于戰術的性能調查問卷145
9.4 性能模式146
9.5 進一步閱讀149
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
11.1 防護性通用場景170
11.2 防護性戰術172
11.3 基于戰術的防護性調查問卷176
11.4 防護性模式179
11.5 進一步閱讀180
11.6 問題討論180
第12章 可測試性183
12.1 可測試性通用場景186
12.2 可測試性戰術187
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
13.5 進一步閱讀205
13.6 問題討論205
第14章 使用其他質量屬性207
14.1 其他質量屬性207
14.2 是否使用標準質量屬性清單209
14.3 處理“X能力”:引入新的QA212
14.4 進一步閱讀215
14.5 問題討論215
第三部分 架構解決方案
第15章 軟件接口217
15.1 接口的概念218
15.2 設計一個接口222
15.3 接口文檔編制228
15.4 總結230
15.5 進一步閱讀230
15.6 問題討論231
第16章 虛擬化233
16.1 共享資源234
16.2 虛擬機235
16.3 虛擬機映像238
16.4 容器239
16.5 容器和虛擬機241
16.6 容器可移植性242
16.7 Pod242
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
18.3 傳感器和執行器267
18.4 資源268
18.5 生命周期270
18.6 總結273
18.7 進一步閱讀274
18.8 問題討論275
第四部分 可擴展架構實踐
第19章 架構上的重要需求277
19.1 從需求文檔中收集ASR278
19.2 通過訪