作爲公司的互聯網系統架構師承擔了系統架構升級與優化的責任，很多互聯網系統架構師也是隨着公司架構升級與優化成長起來的。那麼系統架構師必須具備哪些能力呢？
1、軟件架構的定義：
軟件架構(Software Architecture)也稱之爲軟件體系結構，它是一組有關如下要素的重要決策：軟件系統的組織，構成系統的結構化元素，接口和它們相互協作的行爲的選擇，結構化元素和行爲元素組合成粒度更大的子系統方式的選擇，以及指導這一組織(元素及其接口、協作和組合方式)的架構風格的選擇。換句話說，軟件架構實際上是對系統整體結構設計的刻劃，系統架構師是做全局的、整體的把握工作。架構的組成與決策是架構設計的兩個基本概念。架構=>藍圖+規則+解決方案
軟件架構是一個認識事物的過程：原型、發現、改進、再發現、再改進，這是軟件開發的必由螺旋。
2、架構師成長路線圖：
系統架構師已經不僅僅是技術精湛的技術專家，他需要與業務團隊緊密合作，並且精通市場、業務與管理。從上升趨勢來說，可以有三個層面的路線圖：第一個層面，要關注系統思考。在這個層面，重要的不僅僅是掌握設計的知識點，而是更重視分析能力、創新思維能力的提升，需要更廣闊的思路，這方面的空間相當非常大。這是第一層面的能力基礎。第二個層面，要關注總結和指導，思維空間要轉向羣體。如何把已有的經驗總結出來，並讓這種智力資產真正發揮作用?成爲架構師上升第二層面的能力基礎。第三個層面，要提升自身的全面修養。我們必須引發自己思維方式的變革，要培養組織力、領導力、創新力以及擁有激情，這是架構師上升第三層面的能力基礎。
要看到自身的弱點，思路要寬，多思考
架構師並不是一個普通的技術人員，他對設計站的角度更高，需要的知識和能力結構更復雜，他需要具有其他人所沒有的思想、眼光和感知世界的方法，必須突破已有的思維模式和行爲模式，突破長期束縛自己的思維瓶頸，纔可能達到自己從未達到過的高度。
架構師要養成每項工作都記錄並分析的好習慣，以形成更紮實的工作風格。在每個項目完成都需要進行總結。
3、架構師要保持自己的競爭力：
架構師必須關注今天的IT技術、商業模式變革以及由此引發的軟件產業變革的重大趨勢，勤于思考並迎接新的挑戰。一個人最核心的競爭優勢是學習能力。架構師作爲技術層面資深的一羣，爲了保持競爭力需要注意以下幾個問題：(1)、保持激情：關鍵是信念。激情源自於信念，有了信念纔會主動挑戰自我，迎接挑戰纔會有激情，有了激情工作纔會更有意思。(2)、創新思考：在工作中多嘗試一些新方法，是維持自我能力的重要手段。(3)、逆向思維：逆向思維指的是使用與正常思路相反的思維方式去分析同一個問題，使思路多樣化。逆向思維能夠幫助人們衝破傳統思維的束縛，克服慣性思維方式。從反方向考慮問題往往會取得出人意料的結果。
4、架構師要關注軟件的新趨勢：
目前傳統軟件危機暴露出的問題還未真正解決，新的挑戰卻已擺在眼前。在人們不斷思考面臨的挑戰以及對策中，形成了一些新的趨勢，包括：(1)、軟件質量以服務質量形式展現，對質量的投資可獲得更高的投資回報。(2)、軟件過程擴展到用戶，希望更多的`用戶深入參與到軟件全生命週期。(3)、功能至上遠遠不夠，用戶體驗得到空前重視。(4)、系統集成模式面臨變革，軟件、服務、終端、IT基礎設施將形成更緊密的價值體系。(5)、研發要更多關注非功能性需求，如安全性質量、性能、可靠性、可擴充性、可伸縮性、可用性等，從而不斷提高軟件的價值。 知識就是力量==>資訊就是力量
架構並不完全是概要設計。概要設計還是停留在圖紙上，而架構必須證明這個技術路線可行，並且能夠證明大多數質量風險已經得到了解決。
5、所謂設計就是解決問題的過程：
軟件設計是一種思維活動，設計的魅力在於破解難題，透過直面問題的挑戰，以及對相應解決方案的仔細推敲，纔可能設計出真正有靈性的產品。(1)、設計不具普遍性：軟件設計很少具有普通性，不同的目標需要不同的設計來支援。(2)、做出權衡：所謂軟件設計，本質上就是在質量、成本、時間以及其它各種因素之間做出權衡。(3)、記錄設計的理由(設計文檔)。多關注各種方面的架構設計
6、質量屬性決定了架構風格：
一種架構的風格，很大程度上與設計者如何滿足質量要求的對策有關。需求的功能和非功能兩方面都可能有質量要求。具體歸納如下：(1)、與功能性有關的質量屬性主要包括：A、正確性：是指軟件按照需求正確執行任務的能力。B、健壯性：指的是在異常情況下，軟件能夠正常執行的能力。正確性與健壯性的區別在於，前者是在功能需求之內描述問題，後者是在功能需求之外描述問題。健壯性一般有兩層含義：首先是容錯能力，其次是恢復能力。容錯指的是發生異常情況不出錯誤的能力，而恢復指的是軟件發生錯誤以後能恢復到沒有發生錯誤錢的狀態的能力。C、可靠性：是一個與時間相關的屬性，指的是在一定的環境下，在一定的時間段，系統不出現故障的概率。通常用平均無故障時間來衡量。(2)、與非功能性有關的質量屬性主要包括：A、性能：是指軟件的“時間-空間”效率，而不僅僅是指軟件執行速度。換句話說是速度要快而佔用資源要少。性能=速度/資源。B、易用性：指的是用戶使用軟件的容易程度。C、清晰性：意味着工作成果易讀、易理解。D、安全性：它的目的是系統應該具備防止非法入侵的能力，這既屬於技術問題也屬於管理問題。E、可擴展性：這反映軟件適應“變化”的能力，包括需求、設計的變化、算法的改進和變化。F、可移植性：指的是軟件不經修改(或者稍加修改)就可以在不同軟硬件環境中使用的能力。
7、抵制前期進行龐大設計的誘惑：
(1)、架構應該具備易演化特徵;(2)、項目開發週期不要超過6個月;(3)、分而治之：抓住真正的需求、分而治之(把大項目分成小項目)、設定優先級、儘快交付;(4)、增量式開發與交付：如果前期需求比較清楚，可以把一個大項目分成若干相對獨立能夠持續交付的部分，這樣就可以把大問題分成若干小問題;(5)、迭代式開發與交付：如果前期需求不是太清楚，項目帶有強烈的創新成分，可以使用具有強迭代的逐步求精的模型。
8、重構：
在不影響整體外部行爲的前提下，不斷地對軟件進行細微的設計改進，這種漸進式的實踐叫做重構。透過重構不僅能夠降低維護成本，而且也爲我們提供了改進代碼質量的通用標準，並使我們能迅速添加新功能。從本質上說，重構根本上就是一個態度問題，而不全是技術問題。
在集中精力完成了代碼邏輯以後，就需要集中精力做第二件事情，那就是重構。在對代碼進行重構時，我們不會增加新功能，甚至也不會去修復bug。相反，我們會透過將代碼變得更易於理解來提升代碼的可讀性。
重構要堅持不懈：(1)重構可以加快進度;(2)、重構應該是小步驟地進行;(3)、技術債務積累越多，重構的難度就越大。
9、對結構進行優化的基本原則：
在完成了功能邏輯之後，除了代碼重構以外，很多情況下還需要重新審視一下軟件結構，對結構進行重構。良好的結構設計需要遵循一些原則，而原則本身就是經驗的總結。依據這些原則，我們就可以在設計中有良好的設計指向。如需求不變則不需結構。
結構的4條設計原則：(1)單一職責原則(SRP)：也被稱之爲內聚性原則;SRP原則的描述爲：就一個類而言，應該僅有一個引起它變化的原因;(2)、開放--封閉原則(OCP)：OCP的關鍵是依賴於抽象。OCP原則的目的，是要求我們設計的軟件實體(類、組件、函數等等)應該是可以擴展的，但是不可修改的。A、對於擴展是開放的：這意味着組件的行爲是可以擴展的，當應用的需求改變時，我們可以對組件進行擴展，使其具有滿足那些改變的新行爲。換句話說我們可以改變組件的功能。B、對於更改是封閉的：對組件行爲進行擴展時，不必改動組件的原始碼，無論是動態連結庫、DLL或者是Java的jar檔案都無需改動。(3)、依賴倒置原則(DIP)：使用傳統的結構化設計所創建出來的依賴關係結構，策略是依賴於細節的，這是糟糕的，因爲這樣會使策略受到細節改變的影響。面向對象的程序設計倒置了依賴關係結構，使得細節和策略都依賴於抽象，並且常常是客戶擁有服務接口。事實上，這種依賴關係的倒置正是好的面向對象設計的標誌所在。DIP的原則是：A、高層組件不應該依賴於低層組件。二者都應該依賴於抽象;B、抽象不應該依賴於細節，細節應該依賴於抽象。(4)、接口隔離原則(ISP)：這個原則用來處理“胖(fat)”接口所具有的缺點。類的“胖”(不內聚)接口可以分解成多組方法。每一組方法都服務於一組不同的客戶程序。這樣，一些客戶程序可以使用一組成員函數，而其它客戶程序可以使用其它組的成員函數。實際中當然也存在有一些對象，它們確實不需要內聚的接口，但是ISP建議客戶程序不應該看到它們作爲單一的類存在。相反，客戶程序看到的應該是多個具有內聚接口的抽象基類。
10、關注變化、關注特徵：
擁抱着變化而設計。讓變化成爲一個重要的設計要素，需求總是會發生變化。面向對象是個思維方式。基於接口進行設計。
軟件複用(SoftwareReuse)：是將已有軟件的各種有關知識用於建立新的軟件，以縮減軟件開發和維護的花費。軟件複用是提高軟件生產力和質量的一種重要技術。早期的軟件複用主要是代碼級複用，被複用的知識專指程序，後來擴大到包括領域知識、開發經驗、設計決定、體系結構、需求、設計、代碼和文檔等一切有關方面。
軟件重用，是指在兩次或多次不同的軟件開發過程中重複使用相同或相似軟件元素的過程。軟件元素包括程序代碼、測試用例、設計文檔、設計過程、需要分析文檔甚至領域知識。通常，可重用的元素也稱作軟構件，可重用的軟構件越大，重用的粒度越大。
11、面向服務的架構(Service-OrientedArchitecture, SOA)：
面向服務的架構成功的要點是服務識別。服務識別的基本過程：(1)、瞭解項目的性質;(2)、業務牽頭，一定不是技術牽頭;(3)、明確產品的戰略目標;(4)、研究企業業務流程;(5)、重用行業製品;(6)、建立契約基線;(7)、完善服務屬性等級矩陣(ARMS);(8)、使用業務敏捷場景仿真(BASS)進行測試;(9)、擁抱變更。
12、架構與框架的區別：
框架是一個軟件，但架構不是軟件，而是關於軟件如何設計的重要決策。但是在引入軟件框架以後，軟件架構決策往往會體現在框架設計之中。不論是架構技術還是框架技術，都是爲了解決軟件日益複雜所帶來的困難，而採取的“分而治之”的結果。架構的思維是先大局後局部，這是一種問題在抽象層面地解決方案，首先考慮大局而忽略細節。框架的思維是先通用後專用，這是一種半成品，還需要透過後期的定製才能成爲具體的軟件。
框架和架構的關係可以總結爲兩個方面：(1)、爲了儘早驗證架構設計，或者出於支援產品線開發的目的，可以把通用機制甚至整個架構以框架方式實現;(2)、企業可能存在大量可重用框架，這些框架可能已經實現了架構所需的重要機制，或者對某個子系統提供了可擴展的半成品，最終軟件架構可以藉助這些框架來構造。
框架設計最重要的部分，其實並不在於採用何種技術方案來實現，而是對已經存在的業務過程進行深入思考，尋找它們的共性，探究其中的規律，建立恰當的模式，然後選擇恰當的技術實現方案。
帶團隊關鍵因素：決心、手段(方法)、激情、信心，技術不是關鍵因素。
13、把經驗歸納總結成理論：
總結是兩方面的，(1)總結過程：歸納出良好設計必須遵循的步驟，以及每一步驟的目標、解決什麼問題、應該有什麼樣的思考點和思考方向。(2)總結模式(設計模式)：模式是一種實踐經驗的總結，透過總結每個思考點的各種解決方案，並且和過程的節點裝配在一起，形成能夠指導他人的模式語言。