系統架構師（雲時代架構文章讀後感12）

一架構師職責

架構師是一個既須要掌控總體又要洞悉局部瓶頸，並依據具體的業務場景給出解決方案的團隊領導型人物，他須要參與項目開發的所有過程，包括需求分析、架構設計、系統實現、集成、測試和部署各個階段，負責在整個項目中對技術活動和技術說明進行指導和協調。

架構師主要職責有4條：

01確認需求

在項目開發過程當中，架構師是在需求規格說明書完成後介入的，需求規格說明書必須獲得架構師的承認。架構師須要和分析人員反覆交流，以保證本身完整並準確地理解用戶需求。

02系統分解

依據用戶需求，架構師將系統總體分解爲更小的子系統和組件，從而造成不一樣的邏輯層或服務。隨後，架構師會肯定各層的接口，層與層相互之間的關係。架構師不只要對整個系統分層，進行「縱向」分解，還要對同一邏輯層分塊，進行「橫向」分解。

      架構師的功力基本體現於此，這是一項相對複雜的工做。

03技術選型

架構師經過對系統的一系列的分解，最終造成了軟件的總體架構。技術選擇主要取決於軟件架構。Web Server運行在Windows上仍是Linux上？數據庫採用MSSql、Oracle仍是Mysql？須要不須要採用MVC或者Spring等輕量級的框架？前端採用富客戶端仍是瘦客戶端方式？相似的工做，都須要在這個階段提出，並進行評估。

架構師對產品和技術的選型僅僅限於評估，沒有決定權，最終的決定權歸項目經理。架構師提出的技術方案爲項目經理提供了重要的參考信息，項目經理會從項目預算、人力資源、時間進度等實際狀況進行權衡，最終進行確認。

04制定技術規格說明

架構師在項目開發過程當中，是技術權威。他須要協調全部的開發人員，與開發人員一直保持溝通，始終保證開發者依照它的架構意圖去實現各項功能。

架構師與開發者溝通的最重要的形式是技術規格說明書，它能夠是UML視圖、Word文檔，Visio文件等各類表現形式。經過架構師提供的技術規格說明書，保證開發者能夠從不一樣角度去觀察、理解各自承擔的子系統或者模塊。

架構師不只要保持與開發者的溝通，也須要與項目經理、需求分析員，甚至與最終用戶保持溝通。因此，對於架構師來說，不只有技術方面的要求，還有人際交流方面的要求。

二架構師綜合能力

做爲架構師，必須成爲所在開發團隊的技術路線引導者，具備很強的系統思惟的能力；須要從大量互相沖突的系統方法和工具中區分出哪些是有效的，哪些是無效的。架構師應當是一個成熟的、豐富的、有經驗的、學習快捷、善溝通和決策能力強的人。他必須普遍瞭解各類技術並精通一種特定技術，至少了解計算機通用技術以便肯定哪一種技術最優，或組織團隊開展技術評估。優秀的架構師能考慮並評估全部可用來解決問題的整體技術方案。須要良好的書面和口頭溝通技巧，通常經過可視化模型和小組討論來溝通指導團隊確保開發人員按照架構建造系統。

因此做爲架構師須要以下的綜合能力：

01溝通能力

爲了提升效率，架構師必須贏得團隊成員、項目經理、客戶或用戶認同，這就須要架構師具備較強的溝通能力。溝通能力是人類最廣泛性的素質要求，技術人員好像容易忽略，想成爲架構師就不能忽略。千萬不要抱着這樣的觀念：懷纔跟懷孕似的，時間久了總會被人發現的。仍是天橋上賣大力丸的哥們說得對：光說不練假把式，光練不說傻把式。看看你周圍的頭頭腦腦們，哪個不是此中高手，咱們千萬不要鄙視，認爲這是阿諛奉承、投機鑽營，凡事都要看到積極的一面，「溝通」的確是一種能力。我認爲本身是一個略內向的人，由於我是農村出來的孩子，普通話都說很差，之前或多或少帶有點自卑感，幻想着是金子總會發光，因此在職業生涯中吃了很多虧。如今，我深深懂得了溝通的重要性，我會很主動地跟同事們，跟老大們不定時地溝通，感受工做起來順暢多了。

這一條我認爲最爲重要，因此排在首位。我甚至認爲下面幾條均可以忽略，惟一這一條得牢記，並且要經常提醒本身

02技術能力

架構師最好精通1-2個技術，具有這種技術能力能夠更加深刻的理解有關架構的工做原理，也能夠拉近和開發人員的距離，並造成團隊中的影響力。

架構師的技術知識廣度也很重要，須要瞭解儘量多的技術，所謂見多識廣，只有這樣，纔可能綜合各類技術，選擇更加適合項目的解決方案。有的人說，架構師技術廣度的要求高於技術深度的要求，這是頗有道理的。總而言之，一句話：架構師是項目團隊中的技術權威。

03架構能力

架構是架構師洞察內在結構、原則、規律與邏輯的過程，架構師要作到清晰理解系統、簡潔描述，除此以外，一個架構師還必須具有極強的分析能力，要作到根據產品宗旨和目標，分析清楚產品定位、產品業務，再整合利用現有的技術領域，找出最佳方案，實現產品概念。

04抽象分析

架構師必須具有抽象思惟和分析的能力，這是你進行系統分析和系統分解的基本素質。只有具有這樣的能力，架構師才能看清系統的總體，掌控全局，這也是架構師大局觀的造成基礎。你如何具有這種能力呢？一是來自於經驗，二是來自於學習。架構師不只要具有在問題領域上的經驗，也須要具有在軟件工程領域內的經驗。也就是說，架構師必須可以準確得理解需求，而後用軟件工程的思想，把需求轉化和分解成可用計算機語言實現的程度。經驗的積累是須要一個時間過程的，這個過程誰也幫不了你，是須要你去經歷的。可是，若是你有意識地去培養，不斷吸收前人的經驗的話，仍是能夠縮短這個週期的。

05決策能力

決策能力是一個架構師最重要的職責。

1. 技術方案決策原則

一般一個問題都會有多種可解決的技術方案，怎麼來決策就相當重要了，而決策一般又和全面相關，大的來講一般決策的原則就是性價比和可持續發展。性價比簡單來講是方案的實現成本，這個成本要包括很是多的方面，例若有些場景可能會是用硬件解決看起來是花錢，但最終折算成本是最划算的，不少系統設計在決策性價比時都過於隨意，例如一個另外常見的場景就是建設一套新系統替代舊系統，這個時候可能徹底沒考慮舊系統的遷移代價甚至超過了改造舊系統的代價；

可持續發展簡單來講就是所選擇的技術方案在公司是否可持續，例如簡單的案例是公司主體的研發人員都是php，卻搞一個其餘語言，且只有極少人懂的（固然，這仍是要看性價比，若是搞一個其餘語言帶來的效益超過了語言/人才體系的更換成本），又例如引入一個開源產品，有無專業團隊維護這都是要考慮的關鍵因素。

2. 優先級和節奏控制

常常我會問作系統設計的同窗一個問題：對於這個業務場景而言，在系統設計上最須要把握的一個點是什麼；這是一個關鍵問題，全面意味着考慮到了不少地方的問題，但一般業務需求實現都是有很強的時間要求的，所以在這個時候必須考慮清楚不一樣點的優先級，同時也包括技術方案在決策時也要作出取捨，有可能選了一個不是那麼好的技術方案，但經過留下一些可改造的空間，爲之後的重構作好鋪墊，那就是很不錯的，尤爲技術同窗有些時候比較容易陷入解決技術問題的場景去，但那個問題其實有可能不是現階段最重要的。

優先級和節奏控制是我認爲一個優秀的架構師的最佳體現，優先級意味着把握住了重點，能夠確保在所設計的架構指導下業務實現不會出現大問題，節奏控制則意味着全面，知道隨着業務發展該在什麼時間點作什麼事，爲未來作好鋪墊。

架構優化一方面是優化系統交易鏈上的每一個環節進行分析並優化，另外一方面是對單一架構進行瓶頸點分析和調優。可是優化的目標大體相同，最終目的是提升系統的響應速度、吞吐量、下降各個模塊之間的耦合。

優化原則

1. 在應用系統的設計、開發過程用中，應始終把性能放在考慮的範圍內。

2. 肯定清晰明確的性能目標是關鍵。

3. 性能調優是伴隨整個項目週期的，最好進行分階段設定目標開展，在達到預期性能目標以後便可對本階段工做進行總結和知識轉移進入下一階段調優工做。

4. 必須保證調優後的程序運行正確。

5. 性能更大程度是取決於良好的設計，調優技巧只是一個輔助手段。

6. 調優過程是疊代漸進的過程，每次調優的結果要反饋到後續的代碼開發中去。

7. 性能調優不能以犧牲代碼的可讀性和維護性爲代價。