架構師學習思考

　　最近幾天一直在思考是否要成爲架構師，如何成爲一個架構師的問題。因而上網蒐集了一些關於架構師的文章，細細讀了以後，裏面的內容不只廣闊了個人視野，有些之前知道的知識又有了更深一層的感悟，感受大有所獲，至少對於我目前思考的問題是有很大幫助的，在此謝謝各位網上的前輩們。讀完他們的文章以後，須要本身再思考一下，最近2天寫一下關於架構師的一些思考。 

1.爲何要成爲架構師

這篇談談第一部分，爲何要成爲架構師。首先「架構」這個詞就顯得很高端，架子、結構、頂層設計，這些事在工程領域來講，好比對一幢大樓、一套系統來講是很是重要，骨架很差，雖能湊合着用，可是經不起大風的考驗。能作這件事的人是頂着「光環」的，是使人嚮往的角色。架構師是公司的「金領」，有着很是高的收入，不多須要考慮生存的問題，從而有更多的精力思考關鍵技術問題，沉澱一些基礎技術解決方案，造成「強者愈強」的良性循環。

而對於大多數程序員來講，工做到必定時間，coding到必定程度，ctrl-c 和ctrl-v也更加純熟，這時會到達一個瓶頸，畢竟不少年輕的後輩們過一段時間就能夠達到這個地方，你若是想突破瓶頸，就要開始考慮本身的將來到底向哪一個方向發展。在中國，程序員的最終的歸途無外乎兩條：一是轉向技術管理 
，它的終點是CTO；二是繼續深刻，它的終點是首席架構師。若是程序員的溝通能力強過技術能力，在補充必定的項目管理知識後，能夠向技術管理的方向轉型；若是其對技術很感興趣，而溝通能力也不弱，則能夠試着進一步增強技術修養，以期向架構師的方向發展，最終「修成正果」。

 

2.架構師的技能

架構師須要普遍的知識，是一個「雜家」，「博學家」，可是我以爲架構師必須有1，2個本身特別精通的領域，不少架構師就是從專家過來的。架構師須要什麼技能呢，咱們須要先看看架構師的職責。

2.1 架構師的職責

我以爲《架構師之路》（王澤賓）之中的有一段描述很好，直接拿過來分享一下。

」架構師這個稱呼不是拍腦殼想出來的，是有國際標準（ISO/IEC 42010）可查的。架構師是軟件開發活動中的衆多角色之一，它多是一我的、一個小組，也多是一個團隊。微軟對架構師有一個分類參考，咱們參考一下，他們把架構師分爲4種：企業架構師EA(Enterprise Architect)、基礎結構架構師IA(Infrastructure Architect)、 
特定技術架構TSA(Technology-Specific Architect)和解決方案架構師SA (Solution Architect)。微軟的這個分類是按照架構師專一的領域不一樣而劃分的。

EA的職責是決定整個公司的技術路線和技術發展方向；IA的工做是提煉和優化技術方面積累和沉澱造成的基礎性的、公共的、可複用的框架和組件，這些都是一個技術型公司傳承下來的最寶貴的財富之一；特定技術架構師TSA，他們主要從事相似安全架構、存儲架構等專項技術的規劃和設計工做；SA的工做則專於解決方案的規劃和設計，把產品、技術或理論，不斷地進行組合，來創造出知足用戶需求的選擇。

大公司會把各類類型的架構師分得很清楚，小公司通常就不那麼講究了，架構師多數是是IA+TSA+SA，一人包打天下，因此說大公司出專才，小公司出全才。

實際工做中，咱們也常常會見到另外一種比較簡單的分類方式，把架構師分爲軟件架構師和系統架構師。軟件架構師基本上是TSA+IA，這也是程序員最容易突破，最可能走上的一條道路，好比JAVA架構師、DotNet架構師、LAPM架構師等等，我後面所講的內容都是與軟件架構師的相關的話題。系統架構師其實是SA+TSA，更着力於綜合運用已有的產品和技術，來實現客戶指望的需求。系統架構師要求通曉軟、硬件兩方面的知識，因此它的知識體系相對龐雜。「

架構師須要參與到軟件項目開發的整個過程，需求分析，架構設計，開發實現，測試聯調和發佈部署。負責對整個項目的技術指導和協調。

一、需求分析

架構師須要和產品經理常常溝通，把需求明確下來，而且對需求可否實現進行評估，反覆進行，確保需求的完整性和需求的可實現性，以及實現的難度。

2.系統分解

在肯定完需求以後，就要對完成需求的系統進行架構設計。把完整的系統分解爲多個子系統，各個子系統的功能職責；不只要進行橫向的分解，還要進行縱向的分解，系統分層，以及每一個層之間數據接口，層與層之間的關係。這時候就有不少設計思想體現出來，也有不少架構模型，領域模式、AOP等等。

3.技術選型

肯定完系統的架構以後，就要根據架構進行技術的選擇，架構過程其實也是一個個的決策過程，須要分析各個選擇的優劣。好比選擇服務器是選擇windows仍是unix？數據庫是ms sql server 仍是mysql？服務接口是採用 WCF仍是restfull api？網站是用asp.net form 仍是 asp.net mvc開發？ 緩存服務器選擇什麼？是否須要圖片服務器？還有更詳細的選擇，好比數據庫ORM框架使用哪一種？網站前端使用什麼JS框架，JQuery仍是zepto？這些都要看架構設計的詳細程度，若是這些方面開發團隊有較高的水平，可讓他們作出較爲合適的選擇。

同時這些技術的選擇，架構是沒有最終的選擇權，架構師提供建議並分析實現難度以及工做量，項目經理根據項目預算、人力資源、時間進度等進行評估，和架構師一塊兒作出較爲合適的選擇。

4. 制定技術規格說明

架構師須要和開發人員進行積極的溝通，在開發過程當中是否按照架構設計進行實現和一些新的狀況須要作出修改的地方，可是架構師沒有過多的時間精力時時關注。這時須要一個技術規格說明書，一方面對開發實現進行指導和規範，另外一方面也能夠節省溝通成本。

一個技術規格說明書，須要包括系統背景介紹、用例圖、時序圖、架構圖等，也能夠保證開發者可以從不一樣角度去觀察、理解各自承擔的子系統或者模塊。

 

2.2架構師須要的基本技能

　　從大的方面說，架構師須要有良好的軟件技術知識，包括深度和廣度；良好的溝通能力；抽象思惟分析能力；領導能力。

　　進行軟件架構設計，面向對象的思想和設計模式的知識是必須的。面向對象的思想OO，是通過漫長的軟件開發歷程和不少人的實際經驗總結，發展而來的軟件設計開發的一種指導思想。這種思想相對於面向過程(OP)的思想，有許多好處，好比說開發效率高，因爲其高內聚、低耦合的目標，使得軟件系統的個子系統、模塊能夠分解並行開發，也可使用之前開發的模塊快速開發；軟件系統的可維護性和可擴展性也在抽象和封裝下使得修改和擴展更加局部化。可是並非說面向過程的編程沒有優於OO的地方，在效率要求很高的系統級的應用或準實時系統中，依然採用面向過程的編程。

　　架構師在設計系統的時候，會綜合考慮系統的性能、可靠性、可維護性、可擴展性，作出均衡的選擇。

2.3 互聯網架構師必須掌握的知識

　　1. 網絡知識

　　　不只僅是互聯網系統，不少軟件也不僅是單機運行的，愈來愈多的須要網絡功能。網絡知識不只僅包括tcp/ip，http等經常使用的協議，也包括網絡規劃，好比解決不一樣用戶離服務器距離不一樣產生的訪問速度問題的CDN(Content Delivery Network內容分發網絡)，解決電信和網通網絡訪問速度問題的「雙線」機房方案。

　　2.硬件知識

　　  瞭解硬件的極限以及最新的硬件會對程序的運行形成的影響。

　　3.軟件知識

　　  軟件知識包括不少內容，這也是軟件架構師知識體系的很重要的一塊。像操做系統、數據庫、應用服務器等方面的知識。操做系統的兼容性、性能等；數據庫的分庫以及分表、日誌、性能優化等；虛擬主機和非虛擬主機對程序的影響等。

　　4.其餘知識

　　分佈式系統、負載均衡、網絡安全、運維監控等知識也要有所瞭解，包括最新的產品是什麼，運用更普遍的技術什麼，有什麼優缺點？

 

3.架構師之路

　　成爲架構師是一個慢慢積累的過程，所須要的知識體系比較龐大，可是若是你在coding了一段時間以後，多少會接觸到這些知識。而你若是在編程的過程當中，常常思考程序的可靠性、性能、可維護性、可擴展性，再學習下面向對象、設計模式的知識，並在編程的過程當中試着運用這些知識；當你試着考慮系統應該分紅幾個子系統，系統運用哪些框架更能提升性能和可維護性，系統應該有數據庫，數據庫表如何設計才能更優，如何分佈式部署這些系統的時候，你已經走上了架構師之路......