作為公司的網際網路系統架構師承擔了系統架構升級與優化的責任，很多網際網路系統架構師也是隨著公司架構升級與優化成長起來的。那麼系統架構師必須具備哪些能力呢？
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)總結模式(設計模式)：模式是一種實踐經驗的總結，通過總結每個思考點的各種解決方案，並且和過程的節點裝配在一起，形成能夠指導他人的模式語言。
