前言：系 統 架 構 設 計 師 (System Architecture Designer)是項目開發活動中的眾多角色之 一 ，它可 以是 一個人或 一個小組，也可以是一個團隊。架構師 (Architect) 包含建筑師、設計師、創造 者、締造者等含義，可以說，架構師是社會各領域的創造者和締造者。 從組織上劃分 ， 架構師 通 常可分為 ： 業 務 架 構 師 (Business Architect) 、主 題 領 域 架 構 師 (Domain Architect)、技 術 架 構 師 (Technology Architect)、項 目 架 構 師 (Project Architect) 和 系 統 架 構 師 (System Architecture)等 5 類 。 如 果 參 考 微 軟 公 司 對 架 構 設 計 師 的 分 類 ， 這 里 根 據 架 構 師 關 注 的 領 域 不 同 ，可 將 系 統 架 構 設 計 師 分 為 4 種 ： 企 業 架 構 師 EA(Enterprise Architect) 、 基 礎 結 構 架 構 師IA(Infrastructure Architect)、特 定 技 術 架 構 師 TSA(Technology Architect) 和 解 決 方 案 架 構 師SA(Solution Architect)。

原文來源：《系統架構設計師教程》第一章? 部分摘抄

一、架構設計師概述

1.1、架構設計師的定義

????????架構設計師是系統開發的主體角色，他們通過執行一系列活動來實施架構設計。架構設計通過生成過程形成最 架構 終的產品架構，架構設計師的成果是創建架構。系統開發中架構設計師是整個系統的核心。 架構設計師是負責系統架構的人、團隊或組織 (IEEE 1471-2000)。架構設計師是系統或產品線的設計責任人，是一個負責理解和管理并最終確認和 評估非功能性系統需求(如軟件的可維護性、性能、復用性、可靠性、有效性和可測試性等), 給出開發規范，搭建系統實現的核心構架，對整個軟件架構、關鍵構件和接口進行總體設計并澄清關鍵技術細節的高級技術人員。

1.2、架構設計師的職責

????????架構設計師的職責應該是技術領導，這意味著架構設計師除了擁有專門技能外，還必須擁有領導能力。首先，領導能力既體現在組織中的職位上，也體現在架構設計師展現的品質上。?在組織中的職位方面，架構設計師是項目中的技術領導，應該擁有進行技術決策的權威。項目經理更關注管理資源、進度和成本方面的項目計劃，架構設計師和項目經理代表了這個項目的公共角色。在架構設計師展現的品質方面，領導力也可以在與其他團隊成員的交流中展現出來，?架構設計師應該為他人樹立榜樣并在制定方向方面表現出自信。成功的架構設計師是以人為導向的，都應在指導并培養他們團隊的成員上花時間，以保證團隊成員能夠在后續項目的開發中能夠完整地理解架構設計師的設計思路。其次，擁有專門技能主要體現在除了必須非常清楚項目的總體目標和實施方法外，還應是特定的開發平臺、語言、工具的大師，對常見應用場景能及時給出最恰當的解決方案，同時要對所屬的開發團隊有足夠的了解，能夠評估該開發團隊實現特定的功能需求目標的資源代價。架構設計師必須非常關注交付的實際結果，并必須賦予項目在技術方面的驅動力，還必須能夠進行決策并確保這些決策被傳達、理解并始終被執行。

1.3、架構設計師的任務與組成

????????架構設計師在項目中的主要任務可概述如下。

????????(1)領導與協調整個項目中的技術活動(分析、設計和實施等)。

????????(2)推動主要的技術決策并最終表達為系統架構。

????????(3)確定系統架構，并促使其架構設計的文檔化，這里的文檔化應包括需求、設計、實施

和部署等“視圖”。

????????從技術角度看，架構設計師的職責就是抽象設計、非功能設計和關鍵技術設計等三大任務。

架構設計師角色可以由一個人或一個團隊來履行。在角色和人之間是存在差異的，如一個?人可能會履行多個角色。由于架構設計師需要非常廣泛的技能，所以架構設計師角色通常由多個人履行。這種方式允許技能分布于多個人，每個人都能充分運用他自己的經驗。特別是在理解業務領域和掌握各個方面技術所必須的技能上，往往由幾個人才能很好地覆蓋。

????????這個團隊是擁有共同目標和執行目標，擁有使他們可以相互負責的方法，同時技能相互補?充的一小部分人。

????????如果架構設計師角色由一個團隊履行，擁有一個首席架構設計師角色非常重要，他不僅具有先知先明的能力、還是架構團隊的單點協調人。沒有這個協調人，架構團隊的成員要創造出內聚的架構或做出決策是困難的。

????????優秀的架構設計師應知道他的優勢和弱勢。無論架構設計師的角色是否由一個團隊來履行，?架構設計師都應有好幾個可信顧問的支持，這樣架構設計師不僅可以了解其弱點，還可以通過??獲取必要的技能或與他人一起合作來彌補其知識的缺陷，進而彌補這些弱點。最優秀的架構通??常由一個團隊而不是個人創建，這僅僅因為當有多人參與進來時，使見識更廣和更深。

二、?架構設計師應具備的專業素質

架構設計師作為項目的技術領導，他應熟悉業務領域知識并熟練掌握軟件開發知識。?一個優秀的架構設計師通常可以做到在軟件開發知識和業務領域知識之間的平衡。因此，架構設計師應該具備以下專業知識。

2.1、掌握業務領域的知識

領域是從事于某一行業的人理解并歸納的一組概念和術語知識或者活動范疇?(UML),當架構設計師理解軟件開發但不理解業務模型時，可能會開發出一個不能滿足用戶需求而只能反映該架構設計師所熟悉內容的解決方案，因此，熟悉業務也使得架構設計師能夠預見可能發生的改變。由于架構受其部署環境(包括業務領域)影響很大，對業務領域的正確認識可使架構設計師能夠在可能改變的區域和穩定性方面做出更全面的決策。

2.2、掌握技術知識

由于架構設計的某些方面明確需要技術知識，所以一個架構設計師應該擁有一定程度的技術水平。然而架構設計師不必是一個技術專家，它必須關注技術的重要因素，而不是細節。架構設計師需要理解像Java???EE?或 .NET?這類平臺上的可用關鍵框架，但是不必理解訪問這些平臺?可用的每個應用程序接口(API) ???的細節。由于技術的發展相當快速，架構設計師必須跟得上這?些技術的發展。

2.3、掌握設計技能

設計過程是架構設計的核心內容，架構是關鍵設計決策的具體化，因此，架構設計師應該擁有很強的設計技能。關鍵設計決策指關鍵結構設計決策、特定模型的選擇和指導規格說明書等。?為了保證系統的結構完整性，這些元素被代表性的廣泛應用并對系統取得成功產生深遠的影響。?因此，這樣的元素應該由擁有相當技能的人識別出來。設計能力不可能在短時間內獲得，而是多年經驗積累的結果，因此，?一個優秀的架勢設計師是要經過多年工作實踐才能成為技術領導。

2.4、具備編程技能

項目中的開發人員是架構設計師必須與之打交道的最重要的團隊成員，而項目的最終產品?是可執行代碼，只有架構設計師承認開發人員的工作價值時，在架構設計師和開發人員之間的?溝通才是有效的，尤其是在項目開發后期的缺陷更改時，雙方的溝通尤為重要。因此，架構設 計師應該具有一定的編程技能，即使他們在項目中不必編寫代碼，也必須跟上技術的更新。優 秀的架構設計師通常會有組織地參與開發并應該編寫一定量的代碼，如果架構設計師參與代碼 實現，開發組織會從架構設計師那兒獲得見識，這些見識可以直接有益于架構的專業知識本身。?架構設計師還可以通過查看他們決策和設計的第一手結果，對開發流程給出反饋。

2.5、具備溝通能力

與架構設計師相關的所有軟技能中，溝通最重要。架構設計師應該具備有效的口頭和書面表達能力。有效的溝通可使開發組織能夠充分理解架構設計師的思想，同時開發組織也能夠及時將架構設計實現中遇到的問題及時反饋給架構設計師。有效的溝通是項目成功的基礎，架構設計師能夠有效地與利益相關方溝通，對于理解他們的需求及與他們就架構達成并保持一致是非常重要的。架構設計師不是簡單地將信息傳達給團隊，還要激勵團隊，架構設計師負責傳達系統愿望，以便這個愿望為大家共享，而不是只有架構設計師理解并相信。

2.6、具備決策能力

決策是架構設計師必須具備的能力，尤其是在很多不很明確的情況下，而且沒有充足的時間研究所有可能性時，架構設計師不能果斷決策會延誤項目，失去信任。優秀的架構設計師應承認這種情況，即使在決策時咨詢其他人并營造共同參與決策的環境，進行適當的決策仍然是架構設計師的職責，而這些決策并不總是正確的，但是架構設計師必須學會糾正這些錯誤決策。

2.7、知道組織策略

成功的架構設計師并不僅僅關心技術，他們還應對政治敏感并知道其在組織中的權利，他?們利用這些知識與恰當的人進行溝通，并確保項目在適當的周期中獲得支持。

2.8、應是談判專家

架構設計師需要與許多利益相關者進行交流，其中的一些交流需要談判技巧。架構設計師應特別關注的一點是在項目中盡可能早地把風險降到最低，這對穩定架構所花費的時間有直接?影響。因為風險與需求有關，消除風險的一個途徑是通過精煉需求以使這種風險不再出現，因?此，必須回退需求以便利益相關者和架構設計師達成一致。這種情形要求架構設計師是一位有?效的談判專家，能夠清晰明白地表明各種折中方案的后果。

三、架構設計師的知識結構

架構設計師綜合的知識能力結構主要包括10個方面：

(1)戰略規劃能力。

(2)業務流程建模能力。

(3)信息數據架構能力。

(4)技術架構設計和實現能力。

(5)應用系統架構的解決和實現能力。

(6)基礎IT?知識及基礎設施、資源調配的能力。

(7)信息安全技術支持與管理保障能力。

(8)IT審計、治理與基本需求的分析和獲取能力。

(9)面向軟件系統可靠性與系統生命周期的質量保障服務能力。

(10)對新技術與新概念的理解、掌握和分析能力。

系統架構設計師必須是開發團隊的技術引導者。他們應具有很強的系統思維能力，在項目中需要能夠從大量互相沖突的系統方法和工具中，判斷出哪些是有效的或者是無效的，并在關鍵時刻能夠做出科學的決策。這樣，就要求架構設計師應當是一個思維敏捷、經驗豐富、技術水平高超、受過良好教育的善于學習與溝通且決策能力強的人。他必須廣泛了解各種技術并精?通一種特定技術，至少了解計算機通用技術以便確定哪種技術最優，或組織團隊開展技術評估。?優秀的架構設計師能考慮并評估所有可用來解決問題的總體技術方案。架構設計師需要擁有良好的書面和口頭溝通技巧，?一般通過可視化模型和小組討論進行溝通并指導團隊，從而確保開發人員按照架構建造系統。

因此，系統架構設計師應該是一種綜合性特強的人才，其知識維度可以滿足多層次、多方面的能力。多層次是指架構設計師應在技術領域的深度上掌握更多的基礎知識，即必須在體系結構、計算機軟硬件與網絡基礎知識、系統工程、信息系統、嵌入式系統、軟件安全與可靠性?等知識層面上受過良好教育并擁有自學習能力；還須在架構設計方法、架構模式、開發流程以及各種模型等方面有豐富的經驗，廣泛了解各種產品和技術并精通一種特定領域的架構設計方?法。多方面是指架構設計師應在業務領域以及管理、商務、財務和法律等方面具備一定背景知識并熟悉相關政策，這與系統架構設計師的多角色特點是緊密相關的。

四、如何成為一名好的系統架構設計師

4.1?、如何衡量一名優秀架構設計師

對于系統架構設計師而言，其優劣無法用統一?的標準去衡量，優秀與否實際上是相對的，但是，根據架構設計師的能力可以進行評價。架構設計師是一個充滿挑戰的職?業，需要關注很多維度和技術。Pat???Kua( 原?ThoughWorks?咨詢師)提出：?一個好的架構設計師是技術全面的，并給出了成為一個技術全?面的架構設計師必須具備的6個角色特質(見圖1)。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖1?系統架構設計師的6種角色特質

●作為開發者；

●?作為系統綜合者；

●?具備企業家思維；

●具備戰略技術專家的權衡思維與戰術思維；

●具備良好的溝通能力。

1.作為技術領導者

一名好的軟件架構設計師需要明白，作為領導者并不一定要告訴開發人員做什么。相反，?好的架構設計師就像一個導師，能夠帶領開發團隊向同一個技術愿景前進。好的架構設計師會借助講故事、影響力、引導沖突和構建信任等領導技能，將他們的架構愿景變成現實。?一個好的領導者，同時也是一個好的架構設計師。他/她會仔細聽取每個參與者的意見，通過與團隊?的互動調整他們的愿景。

2.作為開發人員

一個架構設計師同時又是一個好的開發人員。通常，做出一個良好的架構選擇需要權衡理想的架構狀態與軟件系統的當前狀態。例如，如果一個問題更適合采用關系型數據庫來解決，?那么將文檔數據庫引入到系統中的做法是毫無道理的。?一個架構設計師如果不考慮技術選型與?問題域之間的匹配度，會很容易受到各種技術的誘惑——這也就是常見的“象牙塔式架構設計?師”行為模式。

緩解這種情況的最佳方法是讓架構設計師多與開發人員待在一起，花一些時間在核心代碼上。?了解系統的構建方式及系統的約束，這將幫助架構設計師在當下環境中做出正確的選擇。

3.聚焦系統

經驗豐富的開發人員明白代碼只是軟件的一部分。為了讓代碼可運行，他們還需要了解代碼在生產環境中運行良好所需的其他重要質量屬性。他們需要考慮部署過程、自動化測試、性能、安全和可支持性等多個方面。開發人員可能以臨時的方式來實現這些質量屬性，而架構設計師不僅需要專注于了解代碼，還要了解并滿足不同利益相關者(如支持、安全和運營人員)?的需求。?一個好的架構設計師需要專注于尋找那些能夠滿足不同利益相關者需求的解決方案，?而不是選擇針對某一個參與者的偏好或風格進行優化的工具或方法。

4.?具備企業家思維

所有技術選型都有相關的成本和收益，?一個好的架構設計師需要從這兩個角度考慮新的技術選型，就如成功的企業家是愿意承擔風險的，他不但會尋求快速學習的機會和方法，也要學會做好接受失敗的心理準備。架構設計師可以用類似的方式做出技術選型，收集真實世界中有?短期和長期成本的信息，以及他們可能意識到的好處。

這方面一個很好的例子是，架構設計師避免承諾立即使用一個在閱讀新文章時看到或在某?一會議上聽到過的工具。相反，他們試圖通過架構調研來了解工具在其環境中的相關性，以收集更多信息。他們對于工具的選擇不是基于銷售量，而是考慮他們需要什么以及這個工具所提?供的價值。他們還會尋找這些工具背后的隱性成本，例如工具的支持情況(如文檔化程度、社?區使用情況),工具可能帶來的約束或長期來看可能帶來的額外風險。

5.權衡策略思維與戰術思維

許多團隊由一些獨立的開發人員一起構建軟件，而每個人都傾向于選擇自己最舒適或最有經驗的工具和技術。好的架構設計師會持續關注可能有用的新技術、工具或方法，但不一定立即采用它們。技術采用往往需要長期的考量。架構設計師將在團隊和組織層面尋求敏捷度(允許團隊快速采取行動)和一致性(保持足夠的一致性)之間的良好平衡。建立自己的技術雷達?進行練習是用戰略思維探索技術的一個有用工具。

6.良好的溝通

架構設計師需要知道，有效的溝通是建立信任和影響團隊以外成員的關鍵技能。他們知道??不同群體使用不同的術語，而使用技術術語的描述語言與業務人員溝通將會變得比較困難。與 其談論模式、工具和編程概念，架構設計師需要使用聽眾熟悉的術語與之交流，諸如風險回報、?成本和收益等。這比單純使用技術詞匯進行溝通來得更好。架構設計師還需要認識到團隊內部??溝通與外部溝通同樣重要，可以使用圖表和小組討論的方式來建立和完善技術愿景，并進行書??面記錄(如架構決策日志或?Wiki?等),從而為將來留下可追溯的歷史。

總之，做一個技術全面的架構設計師并不容易，因為有很多方面需要關注，而每個方面都?有很多作為開發人員經常不會專注并練習的技能。其實最重要的不一定是一個架構設計師的能?力，而是他們在每個不同的領域都有足夠的專業知識。有價值的架構設計師需要在上述6個方?面都具備良好的專業知識。

4.2、從工程師到系統架構設計師的演化

人們通常把系統架構設計師類比為建筑師，其共同點都是做好頂層設計，充當需求方和?實施者的橋梁。但是系統架構設計師和建筑師存在許多不同，?對于建筑師而言，在成為建筑設計師之前，是不會成為建筑工人或工程師的；而系統架構設計師一定是從工程師成長起來的。?

工程師和架構設計師的本質區別主要體現在技術、組織和個人成長上。

在技術上，架構設計師的首要工作是抽象建模，而比首要工作更重要的是要了解自己所處的業務領域。只有對業務足夠了解，才能更好地抽象和建模，也更能沉淀通用的設計方法論。?另一方面，架構設計師需要了解甚至精通業務領域所涉及的技術領域，譬如對于互聯網行業的?架構設計師，小到語言、算法、數據庫，大到網絡協議、分布式系統、服務器、中間件、IDC???等等都需要涉獵。?一句話，架構設計師是技術團隊的對外接口人，也應該是外部團隊技術問題的終結者。除廣度之外還要有深度，對于關鍵技術模塊的設計，架構設計師需要有技術的權威 性。而工程師則屬于開發團隊成員，主要負責項目的具體實現工作，在架構設計師的指導和幫助下，要熟悉相關業務流程，懂得建模方法，使用已確定的開發方法進行設計、編碼和測試等 工作，從掌握專用技術知識層面來講，工程師必須熟練掌握詳細的設計方法、編程語言、工具和環境。

架構設計師要成為業務和技術的橋梁，因此需要精通業務和技術的語言，要鍛煉溝通能力，?不只是口頭溝通能力，也包括用標準化的圖表表達設計思路的能力。架構設計師需要一種學會?掌握“中庸之道”的方法。不管是技術的選型，團隊的協作、培養和分工，商業訴求和成本控?制，產品需求和技術訴求的匹配，很多時候都是在做權衡。可以說，架構的工作主題就是權衡，?這可能也是工程師成長為架構設計師的最大挑戰。工程師經常是完美主義的，程序也總是精準?而精確的，但是架構設計師要習慣于不完美和一定條件下的不精確。工程師主要是追求產品的?完美形態，通過自己設計出的漂亮程序以充分展示自我能力，很少考慮團隊與協同，開發團隊?相互間為了提升，往往存在相互競爭。

系統架構設計師一般都具備計算機科學或軟件工程的知識，由工程師做起，然后再慢慢成長為架構設計師。

成為系統架構設計師的關鍵是要培養自己的判斷力、執行力和創新力。判斷力是能夠準確判斷系統的復雜度在哪里，能準確地看出系統的脆弱點；執行力是能夠使用合適的方案解決復?雜度問題；創新力是能夠創造新的解決方案解決復雜度問題。因此，要成為一個系統架構設計?師，就需要不斷地鍛煉自己的內功，這些內功來源于經驗、視野和思考。因此，要從工程師成長為架構設計師，應遵循積累經驗，拓寬視野和深度思考的原則。下面說明從工程師到架構設?計師的成長過程。

1.工程師階段

要從一名技術員(助理工程師)成為一個合格的工程師需要參加相關工作1～3年時間，其?典型特征是“在別人的指導下完成開發”,這里的“別人”主要是“高級工程師”或者“技術專?家”。通常情況下，高級工程師或者技術專家負責需求分析、討論和方案設計，工程師負責編碼?實現，高級工程師或者技術專家會指導工程師進行編碼實現。工程師階段應該是原始的“基礎?技能積累階段”,主要積累基礎知識，包括編程語言、基本數據結構、開發環境、操作系統、數?據庫以及相關軟件開發流程等。

2.高級工程師階段

從工程師成長為高級工程師需要3～5年時間，其典型特征是“獨立完成開發”,包括需求?分析、方案設計和編碼實現，其中需求分析和方案設計已經包含了“判斷”和“選擇”,只是?范圍相對來說小一些，更多是在已有架構下進行設計。高級工程師主要需要“積累方案設計經?驗”,簡單來說就是業務當前用到的相關技術的設計經驗。

高級工程師階段相比工程師階段有兩個典型的差異：其一是深度，如果說工程師是要求知??道?How, ??那高級工程師就要求知道Why??了。例如Java??的各種數據結構的實現原理，因為只有??深入掌握了這些實現原理，才能對其優缺點和使用場景有深刻理解，這樣在做具體方案設計的??時候才能選擇合適的數據結構。其二是理論，理論就是前人總結出來的成熟的設計經驗，例如??數據庫表設計的3個范式、面向對象的設計模式、SOLID??設計原則、緩存設計理論(緩存穿透、?緩存雪崩和緩存熱點)等。

3.技術專家階段

成長為技術專家需要4～8年時間，其典型的特征是“某個領域的專家”,通俗地講，只要 是這個領域的問題，技術專家都可以解決。例如：?Java??開發專家、嵌入式開發專家、操作系統?開發專家等。通常情況下，“領域”的范圍不能太小，例如我們可以說“Java????開發專家”,但不 會說?“Java??多線程專家”或?“Java???JDBC?專家”。技術專家與高級工程師的一個典型區別就是：?高級工程師主要是在已有的架構框架下完成設計，而技術專家會根據需要修改、擴展和優化架構。從高級工程師成長為技術專家，主要需要“拓展技術寬度”,因為一個“領域”必然會涉及 眾多的技術面，

需要注意的是，拓展技術寬度并不意味著僅僅只是知道一個技術名詞，而是要深入去理解每個技術的原理、優缺點以及應用場景。

4.系統架構設計師(初級)

成長為初級架構設計師需要5～8年時間，其典型特征就是能夠“獨立完成一個系統的架構設計”,可以是從0到1設計一個新系統，也可以是將架構從1.0重構到2.0。初級架構設計師負責的系統復雜度相對來說不高，例如后臺管理系統、某個業務下的子系統等。初級架構設計??師和技術專家的典型區別是：初級架構設計師是基于完善的架構設計方法論的指導來進行架構??設計，而技術專家更多的是基于經驗進行架構設計。簡單來說，即使是同樣一個方案，初級架構設計師能夠清晰地闡述架構設計的理由和原因，而技術專家可能就是因為自己曾經這樣做過，?或者看到別人這樣做過而選擇設計方案。但在實踐工作中，技術專家和初級架構設計師的區別 并不很明顯，事實上很多技術專家其實就承擔了初級架構設計師的角色，因為在系統復雜度相對不高的情況下，架構設計的難度不高，用不同的備選方案最終都能夠較好地完成系統設計。

從技術專家成長為初級架構設計師，最主要的是形成自己的“架構設計方法論”。形成自己的架構設計方法論的主要手段有：系統學習架構設計方法論，包括訂閱專欄或者閱讀書籍等；?深入研究成熟開源系統的架構設計；結合架構設計方法論，分析和總結自己團隊甚至公司的各種系統的架構設計的優缺點，嘗試思考架構的重構方案。

5.系統架構設計師(中級)

成長為中級架構設計師需要8~10年以上時間，其典型特征是“能夠完成復雜系統的架構設計”,包含高性能、高可用、可擴展、海量存儲等復雜系統，例如設計一個總共100人參與開發的業務系統等。中級架構設計師與初級架構設計師的典型區別在于系統復雜度的不同，中級架構設計師面對的系統復雜度要高于初級架構設計師。以開源項目為例，初級架構設計師可能引入某個開源項目就可以完成架構設計，而中級架構設計師可能發現其實沒有哪個開源項目是合適的，而需要自己開發一個全新的項目，事實上很多開源項目就是這樣誕生出來的。從初級架構設計師成長為中級架構設計師，最關鍵的是“技術深度和技術理論的積累”。

6.系統架構設計師(高級)

成長為高級架構設計師需要10年以上時間，其典型特征是“創造新的架構模式”,例如：?谷歌的分布式存儲架構、分布式計算MapReduce??架構和列式存儲架構等開創了大數據時代；在虛擬機很成熟的背景下，Docker?創造了容器化的技術潮流。高級架構設計師與中級架構設計師?相比，典型區別在于“創造性”,高級架構設計師能夠創造新的架構模式，開創新的技術潮流。