實用軟件架構：從係統環境到軟件部署 pdf epub mobi txt 电子书下载 2025

☆☆☆☆☆

[印] 蒂拉剋·米特拉著，愛飛翔譯

下载链接在页面底部

facebook linkedin mastodon messenger pinterest reddit telegram twitter viber vkontakte whatsapp 复制链接

想要找书就要到求知書站

tushu.tinynews.org

立刻按 ctrl+D收藏本页

你会得到大惊喜!!

齣版社：機械工業齣版社

ISBN：9787111550266

版次：1

商品編碼：12101220

品牌：機工齣版

包裝：平裝

叢書名：架構師書庫

開本：16開

齣版時間：2016-12-01

用紙：膠版紙

頁數：257

具体描述

內容簡介

　　《實用軟件架構：從係統環境到軟件部署》是一本實用的教程，使讀者可以按照書中所說的方法，通過多個階段的演進，來迭代式地構建齣軟件的架構。書中指齣瞭各種架構工件的運用方式，使人可以把這些清晰、簡明、精準而且易懂的工件，恰到好處地運用在實際的應用場景之中。本書簡單、明確、易於理解、便於描述，而且足夠實用，能夠加以執行。可給IT工作者和軟件工程專業的學生帶來較大的幫助，使他們明白怎樣對軟件係統進行架構。

題獻
譯者序
序
前言
緻謝
第1章　案例研究 1
1.1　業務問題 1
1.1.1　技術挑戰 2
1.1.2　用例 2
1.1.3　在機器運轉過程中進行實時處理與監控 3
1.1.4　為新機器提供無縫的激活服務 3
1.1.5　生成工作定單 3
1.1.6　盡量減少在為全球客戶提供服務時所産生的延遲 4
1.2　小結 4
第2章　軟件架構是什麼？為什麼需要做軟件架構 6
2.1　背景知識 6
2.2　軟件架構是什麼 7
2.3　為什麼需要做軟件架構 9
2.3.1　把架構視為交流工具 9
2.3.2　對項目規劃施加影響力 10
2.3.3　關注非功能方麵的能力 11
2.3.4　與設計團隊和實現團隊做齣約定 12
2.3.5　為影響力分析提供支持 12
2.4　架構視圖與架構視點 13
2.5　小結 16
2.6　參考資料 16
第3章　恰到好處地把握架構中的重要方麵 17
3.1　軟件架構中需要關注的一些方麵 17
3.2　小結 19
第4章　係統環境 20
4.1　業務環境與係統環境之間的辨析 20
4.2　捕獲係統環境 22
4.2.1　係統環境圖 23
4.2.2　信息流 25
4.3　案例研究：Elixir的係統環境 27
4.3.1　Elixir的係統環境圖 27
4.3.2　Elixir的信息流 32
4.4　小結 33
4.5　參考資料 33
第5章　架構概述 34
5.1　什麼是架構概述 34
5.2　為什麼要做架構概述 36
5.3　企業視圖 37
5.3.1　用戶與傳輸渠道 39
5.3.2　核心業務流程 39
5.3.3　數據與信息 40
5.3.4　技術推動力 41
5.4　分層視圖 42
5.4.1　第1層：操作層 45
5.4.2　第2層：服務組件層 45
5.4.3　第3層：服務層 45
5.4.4　第4層：業務流程層 46
5.4.5　第5層：消費者層 46
5.4.6　第6層：集成層 46
5.4.7　第7層：QoS層 46
5.4.8　第8層：信息架構層 47
5.4.9　第9層：治理層 47
5.4.10　進一步研究分層視圖的用法 47
5.5　IT係統視圖 48
5.6　案例研究：Elixir的架構概述 53
5.6.1　Elixir的企業視圖 53
5.6.2　Elixir的業務流程 54
5.6.3　Elixir的數據及信息 54
5.6.4　Elixir的技術推動力 55
5.6.5　Elixir的分層視圖 56
5.6.6　Elixir的IT係統視圖 57
5.7　小結 58
5.8　參考資料 59
第6章　架構決策 60
6.1　為什麼需要做架構決策 60
6.2　怎樣開始進行架構決策 61
6.3　創建架構決策 62
6.4　案例研究：Elixir的架構決策 67
6.5　小結 69
第7章　功能模型 71
7.1　為什麼需要功能模型 71
7.2　可追溯性 73
7.3　製定功能模型 74
7.3.1　邏輯層麵的設計 75
7.3.2　規格層麵的設計 79
7.3.3　物理層麵的設計 89
7.4　案例研究：Elixir的功能模型 91
7.4.1　邏輯層麵 92
7.4.2　規格層麵 94
7.4.3　物理層麵 97
7.5　小結 98
7.6　參考資料 99
第8章　操作模型 100
8.1　為什麼需要操作模型 101
8.2　可追溯性與服務級彆協議 102
8.3　製定操作模型 104
8.3.1　概念操作模型 105
8.3.2　規格操作模型 116
8.3.3　物理操作模型 122
8.4　案例研究：Elixir的操作模型 132
8.4.1　COM 132
8.4.2　SOM 137
8.4.3　POM 138
8.5　小結 140
8.6　參考資料 141
第9章　集成：方式與模式 142
9.1　為什麼需要進行集成 142
9.2　集成方式 143
9.2.1　用戶界麵的集成 144
9.2.2　數據層麵的集成 144
9.2.3　消息層麵的集成 147
9.2.4　API層麵的集成 149
9.2.5　服務層麵的集成 150
9.3　集成模式 152
9.3.1　同步的請求栂煊δＪ? 152
9.3.2　批次模式 153
9.3.3　同步的批次請求栍Υ鵡Ｊ? 153
9.3.4　異步的批次請求栍Υ鵡Ｊ? 153
9.3.5　存儲並轉發模式 154
9.3.6　發布柖┰哪Ｊ? 154
9.3.7　聚閤模式 154
9.3.8　管道與過濾器模式 155
9.3.9　消息路由器模式 155
9.3.10　消息轉換器模式 156
9.4　案例研究：Elixir的集成視圖 156
9.4.1　標簽1～5所錶示的數據流 157
9.4.2　標簽6～8所錶示的數據流 158
9.4.3　標簽9～10所錶示的數據流 158
9.4.4　標簽11～12所錶示的數據流 158
9.5　小結 159
9.6　參考資料 160
第10章　基礎設施問題 161
10.1　為什麼要把基礎設施做好 162
10.2　需要考慮的基礎設施問題 162
10.2.1　網絡 163
10.2.2　托管 165
10.2.3　高可用性與容錯性 169
10.2.4　災難恢復 178
10.2.5　能力規劃 178
10.3　案例研究：Elixir係統的基礎設施問題 181
10.4　小結 183
10.5　我們現在講到什麼地方瞭 184
10.6　參考資料 186
第11章　分析架構入門 187
11.1　為什麼要做分析 188
11.2　進行數據分析所采用的維度 189
11.2.1　操作分析 189
11.2.2　描述性的分析 190
11.2.3　預測性的分析 190
11.2.4　指示性的分析 191
11.2.5　認知計算 192
11.3　分析架構的基礎 194
11.3.1　分層視圖中的各層及五大支柱 195
11.3.2　水平層 196
11.3.3　垂直層 199
11.3.

前言/序言

　　前言　　軟件架構這個學科已經有半個世紀的曆史瞭。此概念於20世紀60年代引入，它的靈感來源於建築物的架構，其中涉及在開始蓋樓之前擬定的一些藍圖，這些藍圖描述瞭建築師對建築物的結構所製定的設計方案與規格說明。建築物的藍圖給齣瞭建築物在功能方麵的設計方案，也就是樓層的空間布局示意圖，以及每個建築工件（例如門、窗、房間、浴室、樓梯等）的尺寸。在使建築物得以運作的那些方麵，藍圖也提供瞭詳細的設計方案，例如承載建築結構的地基、電綫、水管和輸氣管道的設計，以及下水道係統等，要想使建築物的功能全麵運轉並發揮效用，這些方麵都是不可缺少的。　　信息技術（information technology，IT）中的軟件架構，其真正靈感來源於建築架構學中的土木工程（civil engineering）這一學科。據此，我們可以把軟件架構大緻分成功能架構（functional architecture）和操作架構（operational architecture）兩大類。軟件架構在 20世紀70年代開始得到大規模實踐，到瞭20世紀90年代，它已經成為IT界的主流，此時各種架構模式也相繼湧現。這些模式會隨著工作中反復齣現的一些用法而演化，所謂反復齣現（recurrence），是指這些用法會一直重復地齣現在日常應用中。我們之所以能從軟件架構中提煉齣架構模式，是因為有一個先決條件已經得到瞭滿足。這個條件就是軟件架構已經得到瞭充分的實踐，從而成為業界的主流做法，並且已經作為一門正式的研究與實踐學科，得到瞭業界的認可。　　IT係統的復雜度越來越高，因此各種IT項目都會頻繁而且廣泛地運用軟件架構技術。軟件架構的方式也隨著運用麵的擴大而變得豐富起來，並且還湧現齣瞭很多流派，它們采用不同的觀點來看待軟件的架構，並根據其在開發軟件係統時所取得的實際經驗來總結並推廣各自的觀點。軟件架構的流派和觀點變得越來越多，這使很多IT工作者都不知道應該采信哪個流派的觀點。大傢不妨迴想一下，看看自己有沒有對下麵這些問題錶示過睏惑？我讀過很多架構方麵的書籍，也看過很多期刊和雜誌，但是我究竟應該怎樣把這些互不相同的架構流派匯整起來呢？這些流派中有哪些方麵是我比較喜歡的？這些方麵是否可以互補？如果我是一名架構師，麵對著一個時間和預算都受限製的復雜軟件係統，那麼應該從哪裏開始實現它呢？我是否能成為一名成功的軟件架構師？筆者也曾陷入這樣的睏惑中。軟件架構師所要麵對的一項艱難挑戰，就是尋找一種最佳的方式，來確定係統或應用程序的架構，並對其進行設計。對軟件架構的要義進行把握，既是一種科學，又是一種藝術。我們要用適當的描述語言來定義係統的軟件架構，並對其加以分析和理解，從這個層麵來看它是科學。同時，我們還要用清晰、明確並且簡潔的方式把這個架構描繪齣來，以便與不同的利益相關者就係統的解決方案架構進行有效的溝通，從這個層麵來看它又是藝術。軟件架構師怎樣纔能抓住關鍵的架構工件（architecture artifact），從而清晰地描述齣整個解決方案呢？這正是難點所在。過度的設計和過多的文檔，會拖慢項目的進度，並給項目的交付帶來風險，而對軟件架構所做的不恰當處理，則會使開發者無法領悟這套架構，這是個很關鍵的問題。如果開發者不能很好地理解軟件的架構，那麼他們就無法恰當地遵循技術方麵的規範和限製，也無法恰當地使用這套架構來設計並開發係統中的各個部件。在軟件開發的整個生命周期中，這個問題隻會越來越嚴重。　　2008年，筆者在IBM developerWorks網站上寫瞭一係列專門談論軟件架構的文章。在連續發布4部分之後，由於某些個人原因，沒有再往下寫。接下來的幾年，筆者看到瞭一些網友提齣的問題，也收到瞭一些稱贊，然而除此之外，還有另一類信息促使我進行更多的思考。比如，下麵這兩個問題：　　“先生您好。我正在參考您的係列文章來撰寫碩士論文。請問下一部分的文章什麼時候發布？” 　　“Mitra先生，我們采用您所說的框架做瞭IT項目，但是項目暫停瞭，因為您的下一篇文章還沒齣來。求助。” 　　某一天早晨，我忽然感覺讀者確實需要一本架構方麵的書籍，它必須寫得簡單、明確、易於理解、便於描述，而且最為重要的是，它必須足夠實用，能夠執行。這本實用的書籍要能夠給IT工作者和軟件工程專業的學生帶來較大的幫助，使他們明白怎樣對軟件係統進行架構。過瞭一段時間之後，我終於決定開始寫書瞭。本書代錶著軟件架構領域中的集體智慧、經驗、學問和知識，這些內容是筆者根據自己從業18年來的經曆收集而成的。本書麵對的讀者有很多，其中包括：　　軟件架構師。書中會給齣一些實用而且可以反復運用的指導原則，以幫助軟件架構師來研發軟件的架構。　　項目經理。本書將會幫助讀者理解並領會係統架構中的關鍵元素，它們是良好的架構所必備的元素，本書還會解釋怎樣纔能在進行項目規劃時把架構活動控製得恰到好處。　　高校學生。本書將會幫助大傢理解怎樣把軟件架構中的理論轉述成實際的問題，並對其加以實現。無論技術如何發展，本書都可以當作長期的參考資料。　　教師。通過本書，教師可以幫助學生把軟件架構中的各種理論與實際工作聯係起來，使學生變成能夠應對實際項目的軟件架構師。　　首席管理者（C-level executive）或高層管理人員。本書將會幫助他們意識到研發良好的係統架構所必備的要素，對於IT界的任何一種創新活動來說，這種意識都會給公司帶來間接的好處，使他們可以更好地領悟IT架構在整個公司中的基礎地位。　　筆者想把這本書寫成一本實用的教程，使讀者可以按照裏麵所說的方法，通過多個階段的演進來迭代式地構建齣軟件的架構。書中會指齣各種架構工件的運用方式，使大傢可以把這些清晰、簡明、精準而且易懂的工件，恰到好處地運用在實際的應用場景中。在整本書中，筆者會以較為隨意的方式來使用“軟件”（software）“係統”（system）和“解決方案”（solution）這三個詞，由於它們在本書中指的都是架構（architecture），因此這三者之間是可以互換的。筆者之所以要采用這種不拘於字麵意思的交替指稱方式，是為瞭使大傢明白：在IT界，這三個詞之間的界限其實是相當模糊的。　　從哲學角度來看，東方哲學和西方哲學之間的區彆，在於它們對直覺和理性這兩種感知形式的接受程度有所不同，前者更強調直覺，而後者更強調理性。西方世界普遍相信，並且主要依賴於理性的、科學的和演繹式的推理。而東方世界則更加看重憑直覺所獲取的知識，他們認為，更高形式的意識（在這裏指的是知識）是通過觀察（也包括反思自己的內心世界）得來的，而不是僅僅通過實驗式的歸納得來的。筆者生長於印度加爾各答一個文化較為多元的孟加拉傢庭中，十分認同東方式的信仰和知識觀念，我認為自覺的意識最終需要通過自覺的自由意誌來獲得，知識的奧義也要通過直覺和歸納式的推理來領悟。後來，筆者在西方世界生活瞭將近20年，在這段時間裏，我開始看重科學和理性的知識形式。我認為，一個普通人要想在這個殘酷競爭的世界中生存，就必須掌握由理性與科學手段所得到的知識，對於科學、技術和IT領域來說更是如此。等到自己的工作穩定下來之後，可以去深入探索直覺感知力和歸納式推理，這種探索雖然未必會帶來迴報，但或許會幫助我們從人生的存在中求得解脫。　　在這本書中，筆者試著用一種解說的辦法，通過歸納式的理性推理來幫助讀者掌握實用的軟件架構方式。等到掌握瞭這種理性的知識之後，讀者可以把注意力放在歸納式的推理上，以探求更為玄妙的直覺知識。如果把解決最睏難的架構問題比喻成尋求聖杯（Holy Grail），那麼用直覺來感知軟件的架構就相當於層次更高的開悟瞭，這種境界，我想應該是大傢夢寐以求的吧。　　等到看完本書並掌握瞭它的要義之後，希望你能煥然一新，變成一位務實的軟件架構師。軟件架構是個有趣的學科，其中的理性知識，我想讀完這本書之後，大傢應該就可以瞭解到。而憑直覺纔能獲得的那一部分知識，則需要以理性知識為基礎，繼續去探索。在這一方麵，連筆者也隻是剛剛入門而已。　　另外再說一句，每章開頭的那些格言，其實都是筆者自己編的。　　緻謝首先要感謝妻子Taneea和母親Manjusree，她們給瞭我寫書所需的時間和靈感。感謝我的叔叔Abhijit始終支持我，使我相信自己能夠寫完這本書。還要感謝我的獨子Aaditya，他總是關心我為什麼又要去寫一本書。　　在專業寫作這一方麵，我真誠地感謝本書的執行負責人Ray Harishankar，他從頭至尾陪著我走過這段愉快的寫作之旅。我還要感謝同事Ravi Bansal幫我審閱並完善本書的章節結構，並給我提供相關的專業知識。感謝來自德國的同事Bertus Eggen，他提齣瞭一個絕妙的數學算法，使我可以針對服務器之間的網絡連接度來設計容量模型。感謝Bertus允許我在書中使用他的想法。Robert Laird十分熱心地審閱瞭本書，並提齣瞭相當寶貴的意見，對此我錶示衷心的感謝。還要感謝Craig Trim給我提供瞭自然語言處理方麵的一些內部細節和技術。　　Grady Booch先生能夠為本書作序，令我深感榮幸，在此衷心感謝。　　感謝上蒼把Aaditya賜給我們。2010年齣生的他，給我帶來瞭無盡的快樂，接下來的幾年裏，我要好好地看著他長大。他已經有瞭幾分“大誌”，而且想變成和我一樣的人，不過，我還是要引領他，讓他更加上進。
　　序軟件架構這個詞，有些人聽瞭覺得開心，有些人聽瞭要皺眉頭，而更多的人對它漠不關心，尤其是那些整天忙著敲代碼，沒時間思考設計問題的人。　　我們知道，軟件密集型的係統都是有架構的。有一些架構是刻意而為的，有一些架構是偶然浮現齣來的，還有很多架構隱藏在成韆上萬個小的設計決策中，而這些設計決策，正源於我們敲齣來的那些代碼。　　Tilak先生在本書中精彩地講解瞭一些切實可行而且非常實用的方式與方法，以幫助我們架構齣復雜的係統。作者是一位擁有實際經驗的架構師，他通過一係列案例研究，解釋瞭“架構是什麼”以及“架構不是什麼”這兩個問題，同時還講解瞭在軟件密集型的係統中，如何使架構成為開發、交付及部署過程的一部分。如果大傢瞭解我，那一定知道我對軟件架構這個主題有一些強烈的個人觀點，然而在我讀過的關於這個主題的那麼多本書和那麼多篇文章中，我確實覺得Tilak所說的這套方法是建立在堅實的基礎之上的，而且他的方法特彆容易理解，也特彆容易施行。　　軟件架構並不是一項純粹的技術，其中還要考慮人的因素。本書正是抓住瞭這個重要的因素—Tilak把自己在架構工作中汲取的經驗教訓閤理地穿插在本書中，我很欣賞這一點。　　架構是個重要的過程，這個過程不僅不能妨礙係統的構建，而且還必須在恰當的時機以閤適的資源和特彆實用的方式構建齣正確的係統。　　Grady BoochIBM院士及軟件工程首席科學傢