軟體架構師是軟體行業中一種新興職業，工作職責是在一個軟體專案開發過程中，將客戶的需求轉換為規範的開發計劃及文字，並制定這個專案的總體架構，指導整個開發團隊完成這個計劃。架構師的主要任務不是從事具體的軟體程式的編寫，而是從事更高層次的開發構架工作。他必須對開發技術非常瞭解，並且需要有良好的組織管理能力。可以這樣說，一個架構師工作的好壞決定了整個軟體開發專案的成敗。

架構師就是繼分析師分析出需求後根據需求整體規劃專案，然後由軟體工程師或者程式設計師去實現，在實現過程中和實現以後，有測試師（好比質監局的）不停的找茬，我們軟體工程師（程式設計師）和測試師就是矛和盾！當然，整個專案中，專案經理是帶頭大哥.

如果把程式設計師比作民工的話，架構師就是劃圖紙的人。

網站架構設計師，網上的解釋是準確定位網站目標群體，設定網站整體架構，規劃、設計網站欄目及其內容，制定網站開發流程及順序，以最大限度地進行高效資源分配與管理的人員。

任何一個機構都不需要一個全職的軟體架構師。一旦建模完成之後，真正需要全職工作的是編碼和測試。這個專案一旦開始實施，每個月100個小時的工作量就足以讓任何設計師滿足全部正在進行的專案的大多數需求。

　　在企業IT部門或者在商業軟體公司工作的人員可能非常熟悉建造軟體與建造樓房之間的區別。也就是說設計師設計樓房，軟體開發人員建造這個樓房。有時候有相當於結構工程師的人員，但是在大多數時間是有區別的。

　　最重要的區別仍然是前面沒有適當的架構。你的大樓可能存在垮塌的風險。然而，沒有人討論的這個區別是工程師在大樓建造的整個過程中都在現場，而設計師開始的時候有80%的時間在現場工作，然後在建設開始的時候提供不斷的評估。

　　一般的承包商如何處理這個問題呢?他們僱用建築公司執行設計和評估的功能。機構如何處理軟體功能方面的問題呢?他們僱用全職的軟體架構師。然而，軟體架構師的困境就是在不需要設計新樓房的時候他做什麼工作呢?

　　此外，大多數機構在危機發生之前都利用工程師製作軟體以及上述結構，從而產生這樣的答案：“讓我們在這裡僱傭一個設計師吧。”這裡的想法是設計師能夠節省時間，保證正在建設的全部樓房滿足編碼標準和消除未來的擔心。這樣就不會把這個漏洞毀掉和從頭開始。

　　設計師做出的“你需要重新開始並且把這個事情做正確”的回答經常會遭到拒絕並且使設計師面臨敵意。而且，工程師將提出一些修改意見讓建設工作繼續實施。這樣就使全職設計師成為為非常昂貴的資源。在遇到問題時，設計師不能提出任何簡單的答案。而工資僅是設計師一半的工程師卻能給出答案。

     軟體架構師實際上就是軟體的總體設計師。首席設計師就是總設計師，打個通俗的比方：鄧爺爺是中國改革開放的總設計師，我們用現在的說法可以講，鄧爺爺是中國改革開放的首席架構師。架構師的形成一定是在實踐中積累起來的，而並非上了幾次培訓班，讀了幾本書就可以成功的，架構師是在工程實踐中培養出來的！

首席架構師 企業一個最高的技術決策者。
崗位職責:
1. 負責公司軟體產品或實施專案的技術路線制訂和技術架構設計，並進行實施指導；
2. 負責公司軟體產品或實施專案的系統架構測試設計；
3. 剩下的就要看董事會如何安排其職權範圍了。

例如：現在，微軟公司的這個決策者就是比爾?蓋茨，微軟的“首席架構師”。設立這個特殊職位是因為，無論在微軟還是在其他公司，執行長根本沒有時間管技術，而很多所謂的“首席技術官”卻都是沒有實權的科學家，決定不了技術發展方向。但是，在一個技術主導的行業裡，一個企業沒有技術方向的最高決策者是不行的。

作為首席架構師，比爾?蓋茨的工作是制定公司的長期技術路線圖，並確認公司每一個行政部門的科研計劃是互補而不是重疊的。因此，他要求公司的每一個產品和技術部門都向他做技術彙報，這些彙報大多是“頭腦風暴”式的討論會議。做這樣的彙報，除了可以得到比爾?蓋茨的回饋之外，每個專案團隊還可以在準備過程中受益匪淺。因為，專案團隊為了準備回答比爾可能問到的各種問題，必須在報告前徹底調研市場、技術、競爭對手等資訊，也因此避免了閉門造車的風險。

      架構師也並非是萬能的。架構師是客戶需求和開發者之間的橋樑。在軟體行業中，一般提到的架構師是技術架構師，而忽略了領域架構師或者講是領域工程師的概念。一個好的領域專家一定是業務領域的架構師，他能夠給出某一個業務領域的架構，我們可以稱為業務架構，只有技術架構和業務架構緊密結合才有可能真正創造出一個好的系統！

      架構師，首先讓我想起的是高樓大廈的設計人員，通常一座大廈在建之前,都先由設計師將藍圖描繪出來，包括其形狀、結構、尺寸、材料等等，然後建築工程師帶領工人們按照藍圖將大廈一層一層地建起來。

      近年來，軟體領域也漸漸地流行起架構師的角色，特別是對一些大型軟體產品或專案的開發，這一角色顯得很關鍵，因為缺乏好的軟體架構師而導致專案失敗的例子不勝列舉，一個沒有經驗和能力的架構師也會使專案失敗的速度加快。

軟體架構師的重要作用

      軟體架構師在整個軟體開發過程中都起著重要的作用，並隨著開發程序的推進而其職責或關注點不斷地變化，在需求階段，軟體架構師主要負責理解和管理非功能性系統需求，比如軟體的可維護性、效能、複用性、可靠性、有效性和可測試性等等，此外，架構師還要經常審查和客戶及市場人員所提出的需求，確認開發團隊所提出的設計；在需求越來越明確後，架構師的關注點開始轉移到組織開發團隊成員和開發過程定義上；在軟體設計階段，架構師負責對整個軟體體系結構、關鍵構件、介面和開發政策的設計；在編碼階段，架構師則成為詳細設計者和程式碼編寫者的顧問，並且經常性地要舉行一些技術研討會、技術培訓班等；隨著軟體開始測試、整合和交付，整合和測試支援將成為軟體架構師的工作重點；在軟體維護開始時，軟體架構師就開始為下一版本的產品是否應該增加新的功能模組進行決策。

如何成為優秀的軟體架構師

      顯而易見，在軟體開發過程中，一個優秀軟體架構師的重要性是不應低估的。那麼如何成為優秀的軟體架構師呢？

      首先必須具有豐富的軟體設計與開發經驗，這有助於理解並解釋所進行的設計是如何對映到實現中去。

      其次要具有領導能力與團隊協作技能，軟體架構師必須是一個得到承認的技術領導，能在關鍵時候對技術的選擇作出及時、有效的決定。

      第三是具有很強的溝通能力，呵呵，其時這一點好象什麼鬼角色都最好具備，軟體架構師需要與各路人馬經常打交道，客戶、市場人員、開發人員、測試人員、專案經理、網路管理員、資料庫工程師等等，而且在很多角色之間還要起溝通者的作用。在技術能力方面，軟體架構師最重要也是最需求掌握的知識是構件通訊機制方面的知識，比如遠端過程呼叫、JAVARMI、CORBA、COM/DCOM、各種標準的通訊協議、網路服務、面對物件資料庫、關係資料庫等等，另外，架構師應時刻注意新軟體設計和開發方面的發展情況，並不斷探索更有效的新方法。開發語言、設計模式和開發平臺不斷很快地升級，軟體架構師需要吸收這些新技術新知識，並將它們用於軟體系統開發工作中。當然，行業的業務知識對軟體架構師也是很重要的，有助於設計

      出一個滿足客戶需求的體系結構，優秀的軟體架構師常常因為要儘快獲得對行業業務的理解而必須快速學習並且進行敏銳的觀察。

      上面的描述是枯燥乏味的，但作為一個軟體架構師，在整個軟體系統的開發過程中是樂趣無窮的，因為這個角色很具有挑戰性，有時需要左右逢源八面玲瓏，有時又需要果斷堅定不留情面。在國內，較少軟體企業擁有獨立的架構師，通常一個軟體高手身兼數職，既是專案經理，又是軟體架構師，還是軟體開發者，有時還要客串一個測試人員，這對軟體的開發週期和產品質量是不利的，有時一個人的觀點立場是很片面的，而且繁重的工作、沉重的壓力會影響一個人的情緒，情緒會影響決策，決策影響結果，所以值得我們三思而後行。

構架師自我培養過程

      構架師不是通過理論學習可以搞出來的，不過不學習相關知識那肯定是不行的。總結構架師自我培養過程大致如下，僅供參考。

      1、構架師胚胎（程式設計師）
      學習的知識是語言基礎、設計基礎、通訊基礎等，應該在大學完成，內容包括java、c、c++、uml、RUP、XML、socket通訊（通訊協議）——學習搭建應用系統所必須的原材料。

      2、構架師萌芽（高階程式設計師）
      學習分散式系統、組建等內容，可以在大學或第一年工作時間接觸，包括分散式系統原理、ejb、corba、com/com+、webservice（研究生可以研究網路計算機、高效能併發處理等內容）

      3、構架師幼苗（設計師）
      應該在掌握上述基礎之上，結合實際專案經驗，透徹領會應用設計模式，內容包括設計模式（c++版本、java版本）、ejb設計模式、J2EE構架、UDDI、軟體設計模式等。在此期間，最好能夠了解軟體工程在實際專案中的應用以及小組開發、團隊管理。

      4、軟體構架師的正是成型在於機遇、個人努力和天賦軟體構架師其實是一種職位，但一個程式設計師在充分掌握軟構架師所需的基本技能後，如何得到這樣的機會、如何利用所掌握的技能進行應用的合理構架、如何不斷的抽象和歸納自己的構架模式、如何深入行業成為能夠勝任分析、構架為一體的精英人才這可不是每個人都能夠遇上的餡餅……

軟體構架師職場概況

      如果您今天有幸同全球首富比爾·蓋茨交換名片，您會注意到他的頭銜是微軟公司首席軟體架構師。同樣假如您得到中國首富丁磊的名片，您也會看到他的頭銜是網易公司首席架構師。悄然間，架構師已經成為職場上最讓人羨慕的職位。

      在我國，隨著軟體業規模的不斷擴大，軟體人才結構性矛盾將更加突出。國家人事部門預計到2005年我國軟體產業的規模將達到2500億元，全國計算機應用專業人才的需求每年將增加百萬人左右。其中，架構師這樣的專業高階人才每年培養人數全國不過數百名，缺口非常之大，而其中尤其以Java架構師缺口最為明顯。

      眾所周知，Java是當前最熱門的軟體開發語言，它具有跨平臺、面向物件、強大的網路功能等特性。你不僅能在電腦上使用Java程式，還能在手機、PDA、家用電器上使用Java程式，甚至舉世矚目的火星車也全部採用Java技術。Java在不到10年時間內已經變成最流行的軟體開發平臺，最新的企業級Java 2.0版本（簡稱：J2EE）也成為企業應用系統上最受歡迎的開發標準。

      事實上，全世界範圍內的J2EE架構師都是緊缺的人才，只是中國更加明顯而已。在英國，有經驗的J2EE架構師，目前平均年薪已經飆漲到七萬至十萬英鎊。全球著名的電子商務平臺提供商SilverStream軟體公司的技術服務總監Mark Ashton對J2EE人才的短缺深有感受，他表示許多求職者的履歷表上都有把J2EE列進去，但是仔細檢視或是面試之後就會發現大多數人只是聽過J2EE，並沒有真正用過這些技術。資訊產業部電子資訊產品管理司副司長丁文武近期也表示，目前我國Java人才還遠遠不夠，至少短缺20萬。特別是隨著大量軟體外包業務進入中國，許多外資或中資軟體企業也開始面臨著高階Java人才奇缺的問題，尤其是熟悉J2EE又能掌握一門相應外語的人才成為了眾多大公司爭搶的物件。

      作為Java的發明者和Java開發標準的主要制定者——美國Sun公司對從事Java開發的技術人員提供了三級認證體系，即初級的程式設計師認證（SCJP）、中級的開發員認證（SCJD和SCWD）和高階的架構師認證（SCEA）。這也是軟體行業中最權威的國際認證之一。目前國內已經有針對美國Sun公司認證體系的培訓，但絕大多數主要針對初級的程式設計師認證，只有極少數專業培訓機構能夠提供三層完整培訓。國家資訊化教育示範基地——上海文華學院（www.wenhua.org）是上海僅有的一家擁有Java自上而下、由淺入深的完善的培訓及認證體系的學院。作為Sun華東區最佳培訓中心，上海文華學院的“對外J2EE國際軟體工程師就業班”課程除了由淺入深，完整地教授整個J2EE體系外，還詳盡地教授開發企業級應用軟體所必須掌握的知識體系，如：作業系統、UML、資料庫、專案管理、軟體測試等。因此，即使你沒有任何軟體開發知識，也能完成這門課程的學習。課程採用專案教學，並培訓計算機英語和第二外語。學員考試通過後，可以獲得美國Sun公司的最高級別國際認證：Sun認證企業級Java 2架構師（SCEA），還推薦就業。學員入學前還可參加免費的“軟體開發潛質測試”，評估自己是否適合開發軟體。

　　架構師不是通過理論學習可以搞出來的，不過不學習相關知識那肯定是不行的。參考軟體企業架構師需求、結合目前架構師所需知識，總結架構師自我培養過程大致如下僅供參考：

　　1、架構師胚胎(程式設計師)學習的知識是語言基礎、設計基礎、通訊基礎等，應該在大學完成，內容包括java、c、c++、uml、RUP、XML、socket通訊(通訊協議)——學習搭建應用系統所必須的原材料。

　　2、架構師萌芽(高階程式設計師)學習分散式系統、組建等內容，可以在大學或第一年工作時間接觸，包括分散式系統原理、ejb、corba、com/com+、webservice(研究生可以研究網路計算機、高效能併發處理等內容)

　　3、架構師幼苗(設計師)應該在掌握上述基礎之上，結合實際專案經驗，透徹領會應用設計模式，內容包括設計模式(c++版本、java版本)、ejb設計模式、J2EE架構、UDDI、軟體設計模式等。在此期間，最好能夠了解軟體工程在實際專案中的應用以及小組開發、團隊管理。

　　4、軟體架構師的正式成型在於機遇、個人努力和天賦，軟體架構師其實是一種職位，但一個程式設計師在充分掌握軟架構師所需的基本技能後，如何得到這樣的機會、如何利用所掌握的技能進行應用的合理架構、如何不斷的抽象和歸納自己的架構模式、如何深入行業成為能夠勝任分析、架構為一體的精英人才這可不是每個人都能夠遇上的餡餅……

　然而學海無涯，精力有限，個人如何能夠很快將這些所謂的架構師知識掌握?這是祕密，每個人都有自己的獨門家傳祕笈就不敢一一暴露了。不過有一點就是廣泛學習的基礎之上一定要根據個人興趣、從事領域確定一條自己的主線來努力。

　　如果說架構師是在模型圖紙上工作的，那麼模型元素必須是實實在在的，正如我們不可能期望抽象派畫家來設計高樓大廈，沒有實際意義的模型元素，是不可能構築出軟體系統的。迄今為止，絕大部分軟體架構師是依賴軟體程式設計師來實現他們的架構意圖的，這二者直接的鴻溝是顯而易見的。設計模式的出現是為縮短二者之間的鴻溝所做的努力，目的是讓架構師和程式設計師之間有更多的共同語言和規範。儘管設計模式讓軟體開發效率和質量有一定程度的提升，但是它始終面臨一個很明顯的侷限，那就是人的因素。人雖然在創造性方面有絕對優勢，但是在精確性、永續性、效率、質量上是無法比擬機器的。

什麼是軟體架構師?

　　架構師(Architecture)是目前很多軟體企業最急需的人才，也是一個軟體企業中薪水最高的技術人才。換句話說，架構師是企業的人力資本，與人力資源相比其能夠通過架構、創新使企業獲得新的產品、新的市場和新的技術體系。那麼什麼是架構師、架構師的作用、如何定位一個架構師和如何成為一個架構師呢?這是許多企業、許多程式設計師朋友希望知道的或希望參與討論的話題內容。

　　所謂架構師通俗的說就是設計師、畫圖員、結構設計者，這些定義範疇主要用在建築學上很容易理解。小時候到河中玩耍，經常乾的事就是造橋，步驟如下：1、在沙灘上畫圖;2、選擇形狀好看、大小適合的石頭;3、搭建拱橋。其中我們挑出來畫圖的那位光PP小孩就是傳說中的“架構師”了。

　　所謂架構師通俗的說就是設計師、畫圖員、結構設計者，這些定義範疇主要用在建築學上很容易理解。小時候到河中玩耍，經常乾的事就是造橋，步驟如下：1、在沙灘上畫圖;2、選擇形狀好看、大小適合的石頭;3、搭建拱橋。其中我們挑出來畫圖的那位光PP小孩就是傳說中的“架構師”了。

　　在軟體工程中，架構師的作用在於三方面：1、行業應用架構，行業架構師往往是行業專家，瞭解行業應用需求，其架構行為主要是將需求進行合理分析佈局到應用模型中去，偏向於應用功能佈局;2、應用系統技術體系架構，技術架構師往往是技術高手中的高手，掌握各類技術體系結構、掌握應用設計模式，其架構行為考慮軟體系統的高效性、複用性、安全性、可維護性、靈活性、跨平臺性等;3、規範架構師是通過多年磨礪或常年苦思頓悟後把某一類架構抽象成一套架構規範，當然也有專門研究規範而培養的規範架構師。他們的產物往往也分為應用規範和技術規範兩類。

　　與建築學類似，如果軟體系統沒有一個好的架構是不可能成為成功的軟體系統的。沒有圖紙的建築工地、沒有設計的造橋工程都是不可以想象的混亂世界。建築工程如是，軟體工程中亦然!

架構的目標是什麼

正如同軟體本身有其要達到的目標一樣，架構設計要達到的目標是什麼呢？一般而言，軟體架構設計要達到如下的目標：

·可靠性（Reliable）。軟體系統對於使用者的商業經營和管理來說極為重要，因此軟體系統必須非常可靠。

·安全行（Secure）。軟體系統所承擔的交易的商業價值極高，系統的安全性非常重要。

·可擴充套件性（SCAlable）。軟體必須能夠在使用者的使用率、使用者的數目增加很快的情況下，保持合理的效能。只有這樣，才能適應使用者的市場擴充套件得可能性。

·可定製化（CuSTomizable）。同樣的一套軟體，可以根據客戶群的不同和市場需求的變化進行調整。

·可擴充套件性（Extensible）。在新技術出現的時候，一個軟體系統應當允許匯入新技術，從而對現有系統進行功能和效能的擴充套件

·可維護性（MAIntainable）。軟體系統的維護包括兩方面，一是排除現有的錯誤，二是將新的軟體需求反映到現有系統中去。一個易於維護的系統可以有效地降低技術支援的花費

·客戶體驗（Customer Experience）。軟體系統必須易於使用。

·市場時機（Time to Market）。軟體使用者要面臨同業競爭，軟體提供商也要面臨同業競爭。以最快的速度爭奪市場先機非常重要。

架構的種類

根據我們關注的角度不同，可以將架構分成三種：

·邏輯架構、軟體系統中元件之間的關係，比如使用者介面，資料庫，外部系統介面，商業邏輯元件，等等。

·物理架構、軟體元件是怎樣放到硬體上的。

比如下面這張物理架構圖描述了一個分佈於北京和上海的分散式系統的物理架構，圖中所有的元件都是物理裝置，包括網路分流器、代理伺服器、WEB伺服器、應用伺服器、報表伺服器、整合伺服器、儲存伺服器、主機等等。

·系統架構、系統的非功能性特徵，如可擴充套件性、可靠性、強壯性、靈活性、效能等。

系統架構的設計要求架構師具備軟體和硬體的功能和效能的過硬知識，這一工作無疑是架構設計工作中最為困難的工作。

此外，從每一個角度上看，都可以看到架構的兩要素：元件劃分和設計決定。

首先，一個軟體系統中的元件首先是邏輯元件。這些邏輯元件如何放到硬體上，以及這些元件如何為整個系統的可擴充套件性、可靠性、強壯性、靈活性、效能等做出貢獻，是非常重要的資訊。

其次，進行軟體設計需要做出的決定中，必然會包括邏輯結構、物理結構，以及它們如何影響到系統的所有非功能性特徵。這些決定中會有很多是一旦作出，就很難更改的。

根據作者的經驗，一個基於資料庫的系統架構，有多少個數據表，就會有多少頁的架構設計文件。比如一箇中等的資料庫應用系統通常含有一百個左右的資料表，這樣的一個系統設計通常需要有一百頁左右的架構設計文件。

構架描述

為了討論和分析軟體構架，必須首先定義構架表示方式，即描述構架重要方面的方式。在 Rational Unified Process 中，軟體構架文件記錄有這種描述。

構架檢視

我們決定以多種構架檢視來表示軟體構架。每種構架檢視針對於開發流程中的涉眾（例如終端使用者、設計人員、管理人員、系統工程師、維護人員等）所關注的特定方面。

構架檢視顯示了軟體構架如何分解為構件，以及構件如何由聯結器連線來產生有用的形式 [PW92]，由此記錄主要的結構設計決策。這些設計決策必須基於需求以及功能、補充和其他方面的約束。而這些決策又會在較低層次上為需求和將來的設計決策施加進一步的約束。

典型的構架檢視集

構架由許多不同的構架檢視來表示，這些檢視本質上是以圖形方式來摘要說明“在構架方面具有重要意義”的模型元素。在 Rational Unified Process 中，您將從一個典型的檢視集開始，該檢視集稱為“4+1 檢視模型”[KRU95]。它包括：

用例檢視：包括用例和場景，這些用例和場景包括在構架方面具有重要意義的行為、類或技術風險。它是用例模型的子集。
邏輯檢視：包括最重要的設計類、從這些設計類到包和子系統的組織形式，以及從這些包和子系統到層的組織形式。它還包括一些用例實現。它是設計模型的子集。
實施檢視：包括實施模型及其從模組到包和層的組織形式的概覽。 同時還描述了將邏輯檢視中的包和類向實施檢視中的包和模組分配的情況。它是實施模型的子集。
程序檢視：包括所涉及任務（程序和執行緒）的描述，它們的互動和配置，以及將設計物件和類向任務的分配情況。只有在系統具有很高程度的並行時，才需要該檢視。在 Rational Unified Process 中，它是設計模型的子集。
配置檢視：包括對最典型的平臺配置的各種物理節點的描述以及將任務（來自程序檢視）向物理節點分配的情況。只有在分散式系統中才需要該檢視。它是部署模型的一個子集。
構架檢視記錄在軟體構架文件中。您可以構建其他檢視來表達需要特別關注的不同方面：使用者介面檢視、安全檢視、資料檢視等等。對於簡單系統，可以省略 4+1 檢視模型中的一些檢視。

構架重點

雖然以上檢視可以表示系統的整體設計，但構架只同以下幾個具體方面相關：

模型的結構，即組織模式，例如分層。
基本元素，即關鍵用例、主類、常用機制等，它們與模型中的各元素相對。
幾個關鍵場景，它們表示了整個系統的主要控制流程。
記錄模組度、可選特徵、產品線狀況的服務。

構架檢視在本質上是整體設計的抽象或簡化，它們通過捨棄具體細節來突出重要的特徵。在考慮以下方面時，這些特徵非常重要：

系統演進，即進入下一個開發週期。
在產品線環境下複用構架或構架的一部分。
評估補充質量，例如效能、可用性、可移植性和安全性。
向團隊或分包商分配開發工作。
決定是否包括市售構件。
插入範圍更廣的系統。

構架模式

構架模式是解決復發構架問題的現成形式。構架框架或構架基礎設施（中介軟體）是可以在其上構建某種構架的構件集。許多主要的構架困難應在框架或基礎設施中進行解決，而且通常針對於特定的領域：命令和控制、MIS、控制系統等等。

構架設計圖
構架檢視的圖形描述稱為構架設計圖。對於以上描述的各種檢視，設計圖由以下統一建模語言圖組成 [UML99]：

邏輯檢視：類圖、狀態機和物件圖。
程序檢視：類圖與物件圖（包括任務 - 程序與執行緒）。
實施檢視：構件圖。
部署檢視：配置圖。
用例檢視：用例圖描述用例、主角和普通設計類；順序圖描述設計物件及其協作關係。

架構師

軟體設計師中有一些技術水平較高、經驗較為豐富的人，他們需要承擔軟體系統的架構設計，也就是需要設計系統的元件如何劃分、元件之間如何發生相互作用，以及系統中邏輯的、物理的、系統的重要決定的作出。

這樣的人就是所謂的架構師（Architect）。在很多公司中，架構師不是一個專門的和正式的職務。通常在一個開發小組中，最有經驗的程式設計師會負責一些架構方面的工作。在一個部門中，最有經驗的專案經理會負責一些架構方面的工作。

但是，越來越多的公司體認到架構工作的重要性，並且在不同的組織層次上設定專門的架構師位置，由他們負責不同層次上的邏輯架構、物理架構、系統架構的設計、配置、維護等工作。

大型專案的經驗
    中國有多少架構師，不在於有多少人通過了什麼考試培訓，而在於中國大型專案的數量。
    問：你這個專案的架構是什麼？一口回答：Spring+Struts+Hibernate。這位很可能就不是架構師了，因為這僅僅是技術Stack，專案規模不大時Spring+Struts+Hibernate才會成為架構的重點。
    除了親自擔任大型專案的架構師，如果瞭解這些專案為了滿足怎樣的功能與非功能需求而把架構設計成這樣子也一樣的。所以，儘量多讀一下公司專案的設計文件，愉快的接受其他專案組架構評審會的邀請。

二、基本能力
完整的軟體開發生命週期經驗
    這個不用說了，幸好中國的架構師什麼髒活累活都做過，甚至跟著市場人員跑去做演示這些國外架構師不一定有的經驗我們都有了，差別只在於一些理論知識--RUP + CMMI3 + 敏捷原則的細節掌握程度。

精通一兩種主流開發語言、保持當下架構的開發體驗
    國內的架構師到了三十歲以後很多就往理論上跑，而國外的架構師則在往上發展的同時保持下面的程式設計體驗，所以國內多水王，而國外則多大師。

    水王的設計一般會層次過高，與實現之間有斷層，與開發人員溝通困難，自己嘩啦啦編個驗證原型的日子更是一去不返。更痛苦的是，人過三十之後學習能力下降，手藝一旦放下了想重新上手還很難:(

    但是，也不必要挽起袖子每月編碼若干行，很可能你的"親自出手"因為時間安排不來反而拖了大家的進度，但一定要保持一個體驗。

巨集觀上的，廣度優先的瞭解當前主流的技術與產品

     架構師如果連Tuxedo與IBM MQ都分不清，一句"這裡搞個非同步呼叫的middleware，有commercial support的"，同樣是層次太高了。架構師對各大公司的完整產品線和著名的開源專案應該有巨集觀上的瞭解，最好在Wiki裡編個索引。

     但同時也要抵制成為某項技術專家如Oracle啟動引數優化專家的誘惑，技術細節掌握到業務職責需要的程度就剛好了。除非如Spring Framework進一步瞭解能帶來天大好處。
與業務域開發域人員溝通的能力及其他領導能力

   IT 架構師處在客戶和開發人員之間，必須能夠使用各種媒體（程式碼、模型、文件、PowerPoint以及談話和講座），與技術和非技術的干係人進行溝通。另外，架構師好歹也是個半大不小的官，其他領導必要的能力就不列了。

到底什麼是架構師呢？所謂的架構師，應該是一個技術企業的最高技術決策者。他主要負責公司軟體產品或軟體專案的技術路線與技術框架的制訂。好的架構師都是善良的獨裁者，具有很強的技術、良好的寫作能力、良好的口頭表達能力，能夠在各個層次進行溝通。從開發人員到架構師的成長應該是階梯式的，一般來講開發人員在剛剛開始工作時只能開發簡單的獨立軟體模組，慢慢的隨著經驗的增長，他開始接觸一些相互之間有資訊傳遞的模組，而後來，他會發現自己接到的開發任務已經不是一個獨立的單體，這些任務由一些專門的軟體部分組成，可能包含資料庫，工作流引擎，訊息服務等等各種功能模組，可能分佈在不同的伺服器上，所有的部分協同起來，完成軟體功能。而這時候，體系結構的好壞將直接決定了系統的效能和可擴充套件性，而就在這時候，這名優秀的開發人員也開始思考架構師應該思考的問題了，或者說，他向成長為架構師的道路邁出了一大步。

            什麼是架構師最具價值的技能呢？就是要了解不同的知識，做一個“雜家”或者說“博學家”。當然，如果你的資料庫技術非常棒，或者你在工作流引擎方面具有不可超越的專家知識，那也是很不錯的。好的架構師有好多都是從專家成長過來的。但是，這不是架構師應該做的事情，架構師應該做的是瞭解所有的東西，既瞭解技術的巨集觀面，又瞭解技術的細節。真正的架構師不僅僅要了解軟體，也要了解硬體，在關鍵的部位使用合適的硬體來取代軟體，可以成倍甚至成百倍的提高整個系統的效率。下面我將會以網際網路行業對的架構師的要求為例，向大家講解作為架構師應該具備的知識。

      網際網路行業是當前最激動人心的行業之一，很多的創新都來自於這個行業，而每一個大型的網站如Google，Yahoo，Myspace等都需要解決一個非常複雜的問題，就是網站的分散式向外擴充套件(Scale Out)的問題。解決這個問題，需要最優秀的架構師對業務進行剖析，利用軟硬體將網站進行重構，甚至根據業務研發相應的分散式技術，解決網站複雜的分散式計算的問題。如果你想在這個行業中成為一名架構師的話，需要至少掌握網路知識，硬體，軟體，網站優化等方方面面的知識：

軟體架構的十大錯誤

不能界定專案範圍。“在這種情況發生時，一個簡單的出差登記系統結果變成內建了完整的花費報銷管理系統，專案費用、時間跨度和質量都留下不可避免的爛攤子……除了簡單的登入真的不需要安全措施了？使用者登入系統後真的不能夠執行任何系統操作嗎？”

網撒得不夠寬。“我們都曾經犯過的一個錯誤是，只關注系統所有利益相關者中的一兩方——通常受讓人（為系統出錢的人）和終端使用者得到了全部的關注。”

只關注功能。“……除非系統表現出了全面的高質量（諸如效能、安全、可維護性等等），否則不太可能成功。”

用方框和線條來描述。“[一個無所不包的]巨大的Visio圖無法成為有效的架構描述，有兩個原因：第一，它試圖在單一表示中呈現太多資訊；第二，沒人真正清楚地知道你畫的各種符號到底表示什麼意思。”

忘了需要培養的過程。“在建造系統的時候常常需要小心的事物包括：開發者和測試者沒法真正理解設計，他們不熱衷或者沒時間學習技術，以及還沒有很好的工具支援的新技術，或者新技術會強迫人們以新的不熟悉的方式工作。”

平臺定義不精確。“光用‘需要Unix和Oracle’來描述你的平臺是不足夠的。你需要精確地說明每一部分具體的版本和配置，才能保證得到你所需的平臺。不然如果有人好心為平臺的某一部分升級了一個庫，就可能導致某些東西停止運作。精確定義平臺你才能在部署中避免這樣的情形。”

對效能和伸縮能力想當然。“及早開始考慮效能和伸縮性，構建效能模型嘗試預測關鍵的效能指標並定位瓶頸，在設計逐漸成型的同時投入到一些實際的驗證性工作中去。這會幫助你提高對設計中不存在嚴重效能和伸縮性缺陷的信心。”

自己發明安全技術。“多年來許多系統所犯的一個錯誤是試圖加入自己發明的安全技術來提高系統安全性。比如定製的加密演算法，開發者自己編寫的稽核系統，甚至完全DIY的訪問控制系統。自家開發的安全方案基本上都是不明智的。雖然很多人都以為自己可以馬上搞出一些聰明的安全技術，但通常都只是自作聰明。”

沒有災難恢復。“要想得到資源來實現系統的災難恢復機制，其關鍵在於在若干真實的場景中，具體衡量系統不可用所導致的損失。如果你還能估算這些場景發生的概率，你就可以用這兩組資料去說服人們災難恢復的重要性，並獲得合理的預算去實現它。”

沒有撤退計劃。“確保無論在系統部署或升級的過程中發生任何事，你都有一份書面的、經過審查的、一致同意的撤退計劃，允許你將整個環境恢復到部署之前的狀態。”

什麼是架構?
   軟體體系結構通常被稱為架構，指可以預製和可重構的軟體框架結構。架構尚處在發展期，對於其定義，學術界尚未形成一個統一的意見，而不同角度的視點也會造成軟體體系結構的不同理解，以下是一些主流的標準觀點。
　　ANSI/IEEE 610.12-1990軟體工程標準詞彙對於體系結構定義是：“體系架構是以構件、構件之間的關係、構件與環境之間的關係為內容的某一系統的基本組織結構以及知道上述內容設計與演化的原理(principle)”。
　　Mary Shaw和David Garlan認為軟體體系結構是軟體設計過程中，超越計算中的演算法設計和資料結構設計的一個層次。體系結構問題包括各個方面的組織和全域性控制結構，通訊協議、同步，資料儲存，給設計元素分配特定功能，設計元素的組織，規模和效能，在各設計方案之間進行選擇。Garlan & Shaw模型[1]的基本思想是：軟體體系結構={構件(component),連線件(connector)，約束(constrain)}．其中構件可以是一組程式碼，如程式的模組；也可以是一個獨立的程式，如資料庫伺服器。連線件可以是過程呼叫、管道、遠端過程呼叫(RPC)等，用於表示構件之間的相互作用。約束一般為物件連線時的規則，或指明構件連線的形式和條件，例如，上層構件可要求下層構件的服務，反之不行；兩物件不得遞規地傳送訊息；程式碼複製遷移的一致性約束；什麼條件下此種連線無效等。
　　關於架構的定義還有很多其他觀點，比如Bass定義、Booch & Rumbaugh &Jacobson定義、Perry & Wolf模型[7]、Boehm模型等等，雖然各種定義關鍵架構的角度不同，研究物件也略有側重，但其核心的內容都是軟體系統的結構，其中以Garlan & Shaw模型為代表，強調了體系結構的基本要素是構件、連線件及其約束（或者連線語義），這些定義大部分是從構造的角度來甚至軟體體系結構，而IEEE的定義不僅強調了系統的基本組成，同時強調了體系結構的環境即和外界的互動。

    什麼是模式?
   模式（Pattern）的概念最早由建築大師Christopher Alexander於二十世紀七十年代提出，應用於建築領域，八十年代中期由Ward Cunningham和Kent Beck將其思想引入到軟體領域，Christopher Alexander將模式分為三個部分：首先是周境（Context，也可以稱著上下文）,指模式在何種狀況下發生作用；其二是動機（System of Forces）,意指問題或預期的目標；其三是解決方案（Solution）,指平衡各動機或解決所闡述問題的一個構造或配置（Configuration）。他提出，模式是表示周境、動機、解決方案三個方面關係的一個規則，每個模式描述了一個在某種周境下不斷重複發生的問題，以及該問題解決方案的核心所在，模式即是一個事物（thing）又是一個過程(process)，不僅描述該事物本身，而且提出了通過怎樣的過程來產生該事物。這一定義已被軟體界廣為接受。

        架構和模式應該是一個屬於相互涵蓋的過程，但是總體來說Architecture更加關注的是所謂的High-Level Design,而模式關注的重點在於通過經驗提取的“準則或指導方案”在設計中的應用，因此在不同層面考慮問題的時候就形成了不同問題域上的 Pattern。模式的目標是，把共通問題中的不變部分和變化部分分離出來。不變的部分，就構成了模式，因此，模式是一個經驗提取的“準則”，並且在一次一次的實踐中得到驗證，在不同的層次有不同的模式，小到語言實現(如Singleton)大到架構。在不同的層面上，模式提供不同層面的指導。根據處理問題的粒度不同，從高到低，模式分為3個層次：架構模式(Architectural Pattern)、設計模式(Design Pattern)、實現模式(Implementation Pattern).架構模式是模式中的最高層次，描述軟體系統裡的基本的結構組織或綱要，通常提供一組事先定義好的子系統，指定它們的責任，並給出把它們組織在一起的法則和指南。比如，使用者和檔案系統安全策略模型，N-層結構，元件物件服務等，我們熟知的MVC結構也屬於架構模式的層次。一個架構模式常常可以分解成很多個設計模式的聯合使用。設計模式是模式中的第二層次，用來處理程式設計中反覆出現的問題。例如，[GOF95][2]總結的23個基本設計模式——Factory Pattern, Observer Pattern等等。實現模式是最低也是最具體的層次，處理具體到程式語言的問題。比如，類名，變數名，函式名的命名規則；異常處理的規則等等。

   由於[GOF95]是論述軟體模式的著作的第一本，也是OO設計理論著作中最流行的一本，因此有些人常常使用設計模式（Design Pattern）一詞來指所有直接處理軟體的架構、設計、程式實現的任何種類的模式。另外一些人則強調要劃分三種不同層次的模式：架構模式 (Architectural Pattern)、設計模式(Design Pattern)、成例(Idiom)。成例有時稱為程式碼模式(Coding Pattern)。

　　這三者之間的區別在於三種不同的模式存在於它們各自的抽象層次和具體層次上。架構模式是一個系統的高層次策略，涉及到大尺度的元件以及整體性質和力學。架構模式的好壞可以影響到總體佈局和框架性結構。設計模式是中等尺度的結構策略。這些中等尺度的結構實現了一些大尺度元件的行為和它們之間的關係。模式的好壞不會影響到系統的總體佈局和總體框架。設計模式定義出子系統或元件的微觀結構。程式碼模式（或成例）是特定的範例和與特定語言有關的程式設計技巧。程式碼模式的好壞會影響到一箇中等尺度元件的內部、外部的結構或行為的底層細節，但不會影響到一個部件或子系統的中等尺度的結構，更不會影響到系統的總體佈局和大尺度框架。

　　1、程式碼模式或成例(Coding Pattern 或 Idiom)
　　程式碼模式（或成例）是較低層次的模式，並與程式語言密切相關。程式碼模式描述怎樣利用一個特定的程式語言的特點來實現一個元件的某些特定的方面或關係。
　　較為著名的程式碼模式的例子包括雙檢鎖（Double-Check Locking）模式等。

　　2、設計模式(Design Pattern)
　　一個設計模式提供一種提煉子系統或軟體系統中的元件的，或者它們之間的關係的綱要設計。設計模式描述普遍存在的在相互通訊的元件中重複出現的結構，這種結構解決在一定的背景中的具有一般性的設計問題。
　　設計模式常常劃分成不同的種類，常見的種類有：
　　建立型設計模式，如工廠方法（Factory Method）模式、抽象工廠（Abstract Factory）模式、原型（Prototype）模式、單例（Singleton）模式，建造（Builder）模式等
　　結構型設計模式，如合成（Composite）模式、裝飾（Decorator）模式、代理（Proxy）模式、享元（Flyweight）模式、門面（Facade）模式、橋樑（Bridge）模式等
　　行為型模式，如模版方法（Template Method）模式、觀察者（Observer）模式、迭代子（Iterator）模式、責任鏈（Chain of Responsibility）模式、備忘錄（Memento）模式、命令（Command）模式、狀態（State）模式、訪問者（Visitor）模式等等。
        以上是三種經典型別，實際上還有很多其他的型別，比如Fundamental型、Partition型，Relation型等等
　　設計模式在特定的程式語言中實現的時候，常常會用到程式碼模式。比如單例（Singleton）模式的實現常常涉及到雙檢鎖（Double-Check Locking）模式等。

　　3、架構模式(Architectural Pattern)
　　一個架構模式描述軟體系統裡的基本的結構組織或綱要。架構模式提供一些事先定義好的子系統，指定它們的責任，並給出把它們組織在一起的法則和指南。有些作者把這種架構模式叫做系統模式[STELTING02]。
　　一個架構模式常常可以分解成很多個設計模式的聯合使用。顯然，MVC模式就是屬於這一種模式。MVC模式常常包括調停者（Mediator）模式、策略（Strategy）模式、合成（Composite）模式、觀察者（Observer）模式等。
　　此外，常見的架構模式還有：
　　·Layers（分層）模式，有時也稱Tiers模式
　　·Blackboard（黑板）模式
　　·Broker（中介）模式
　　·Distributed Process（分散過程）模式
　　·Microkernel（微核）模式
　　架構模式常常劃分成如下的幾種：
　　一）、 From Mud to Structure型。幫助架構師將系統合理劃分，避免形成一個物件的海洋（A sea of objects）。包括Layers（分層）模式、Blackboard（黑板）模式、Pipes/Filters（管道/過濾器）模式等。
　　二）、分散系統（Distributed Systems）型。為分散式系統提供完整的架構設計，包括像Broker（中介）模式等。
　　三）、人機互動（Interactive Systems）型，支援包含有人機互動介面的系統的架構設計，例子包括MVC（Model-View-Controller）模式、PAC（Presentation-Abstraction-Control）模式等。
　　四）、Adaptable Systems型，支援應用系統適應技術的變化、軟體功能需求的變化。如Reflection（反射）模式、Microkernel（微核）模式等。

Layers架構模式
　　在收集到使用者對軟體的要求之後，架構設計就開始了。架構設計一個主要的目的，就是把系統劃分成為很多"板塊"。劃分的方式通常有兩種，一種是橫向的劃分，一種是縱向劃分。
　　橫向劃分將系統按照商業目的劃分。比如一個書店的管理系統可以劃分成為進貨、銷售、庫存管理、員工管理等等。
　　縱向劃分則不同，它按照抽象層次的高低，將系統劃分成"層"，或叫Layer。比如一個公司的內網管理系統通常可以劃分成為下面的幾個Layer:
　　一、網頁，也就是使用者介面，負責顯示資料、接受使用者輸入；
　　二、領域層，包括JavaBean或者COM物件、B2B服務等，封裝了必要的商業邏輯，負責根據商業邏輯決定顯示什麼資料、以及如何根據使用者輸入的資料進行計算；
　　三、資料庫，負責儲存資料，按照查詢要求提供所儲存的資料。
　　四、作業系統層，比如Windows NT或者Solaris等
　　五、硬體層，比如SUN E450伺服器等
　　有人把這種Layer叫做Tier，但是Tier多帶有物理含義，不同的Tier往往位於不同的計算機上，由網路連線起來，而Layer是純粹邏輯的概念，與物理劃分無關。
　　Layers架構模式的好處是：
　　第一、任何一層的變化都可以很好地侷限於這一層，而不會影響到其他各層。
　　第二、更容易容納新的技術和變化。Layers架構模式容許任何一層變更所使用的技術

【Kiki】由於我只接觸過這種，其他（Facade架構模式、Mediator架構模式和Interpreter架構模式）就不轉載了。

如何成為一個出色的網站架構師
一個具有一定知名度的網站，面對的問題無非是：穩定的效能、海量訪問、海量資料。

   優秀的website architecture應該良好的解決上述問題，那麼Terry認為應該熟悉或瞭解下面的技術：

開發語言架構：應該至少熟悉一種web開發語言，包括java、web、python、ror等，然後採用比較穩健的、成熟的開發語言架構
單點登陸
自建session server,類似discuz的passport的方案
目前常用的是cas sso解決方案
web伺服器叢集：
負載均衡：軟體比如keepalived,ultramokey.硬體如四層交換機；
web伺服器叢集方案:常用lvs
web伺服器選型:apache、Nginx、lighttpd
其他伺服器－如java 應用伺服器的叢集部署；
利用快取：
頁面靜態化規則，頁面快取；快取軟體：squid,oscache,等
常用資料快取解決方案，快取資料命中率
如果採用ORM,考慮採用二級快取
ajax：避免頁面全域性重新整理，提高使用者體驗；合理使用，避免氾濫。
資料庫
叢集資料庫
如果資料庫採用mysql,那麼一般是master-slave，對master進行寫入或更新資料，對slave進行資料的查詢。如果使用hibernate那麼，使用native sql太動態繫結不同的資料庫表。複雜一些可以研究一下Hibernate Shards,這是google捐獻給hibernate的專案的。
oracle資料庫叢集，可以採用磁碟陣列方式，oracle部署在幾個伺服器上，表和資料檔案放在磁碟陣列上
做好備份策略
分清不同資料的生命週期。根據不同的生命週期，做好資料的歸檔/轉存的工作
商業資料儲存首選大型商業資料庫，其他資料可以用mysql等開源資料庫。
搜尋引擎：
常用的技術選型是lucene ,另外有ferret，Sphinx。
分散式儲存和分散式查詢
中文分詞
網路蜘蛛：
知道如何抓取別人網站的網頁
懂得如何遮蔽未知或部分蜘蛛訪問你的網站
seo
關注網際網路業內的情況
facebook的f8是啥回事
google的產品和api,瞭解Google Maps API、OpenSocial API、Google Apps等等
找到sns,blog,wiki等web2.0的技術表現形式
guice、google toolkit、Android
關注新冒出來一些網站的情況
研究和分析知名網站的架構
跟蹤一些知名技術專家的文章或blog
適當的參加一些技術或網際網路聚會和話題討論
瞭解比較新的一些技術概念，如soa、esb、雲端計算、MapReduce、BigTable、Google
“隔河觀景的心態應該儘量避免”

架構高負載，高併發的網站的根本和趨勢就是負載均衡，或者叫做分散式，利用多個小型的伺服器來替代單一的大型的伺服器。在WEB伺服器方面的負載均衡很簡單，複雜的是如何在資料庫方面做負載均衡，現在大部分公司的做法還是使用傳統的資料庫叢集或者簡單的庫表雜湊。在這裡給大家提供一種新的思路：藉助成熟資料庫產品的一個分散式資料庫中介軟體， 把數百臺機器組織起來，既有庫表雜湊，又有負載均衡，最終達到高效能，高擴充套件性，高可用性。

最便宜的高負載網站架構
1， LVS做前端四層均衡負載
基於IP虛擬分發的規則,不同於apache,squid這些7層基於http協議的反向代理軟體, LVS在效能上往往能得到更好的保證！

2，squid 做前端反向代理加快取
squid 是業內公認的優秀代理伺服器，其快取能力更讓許多高負載網站青睞！（比如新浪，網易等）
使用他, 配合ESI做WEB動態內容及圖片快取，最合適不過了

3，apache 用來處理php或靜態html，圖片
apache是業內主流http伺服器，穩定性與效能都能得到良好保證!

4，JBOSS 用來處理含複雜的業務邏輯的請求
JBOSS是red hat旗下的優秀中介軟體產品，在java開源領域小有名氣，並且完全支援j2ee規範的，功能非常強大
使用他，既能保證業務流程的規範性，又可以節省開支（免費的）

5，mysql資料庫
使用mysql資料庫，達到百萬級別的資料儲存，及快速響應，應該是沒問題的

6，memcache作為分散式快取
快取應用資料，或通過squid解析esi後，作為資料載體

                             LVS
        squid + jboss        squid + jboss        squid + apache ....

                                       mysql + memcache