在計算機工程中，計算機體系結構是描述計算機系統的功能，組織和實施的一組規則和方法。體系結構的一些定義將其定義為描述計算機的功能和程式設計模型，但不是特定的實現。在其他定義中，計算機體系結構涉及指令集體系結構設計，微體系結構設計，邏輯設計和實現。

第一個記錄在案的計算機架構是Charles Babbage和Ada Lovelace之間的通訊，描述了分析引擎。在1936年建立計算機Z1時，Konrad Zuse在他的未來專案的兩個專利申請中描述了機器指令可以儲存在用於資料的相同儲存器中，即儲存程式概念。另外兩個重要的例子是：

· 約翰馮諾依曼1945年的論文“EDVAC報告初稿”描述了一個邏輯元素組織

· 圖靈更詳細的提議的自動計算引擎的電子計算器，也是1945年，並引用約翰馮諾伊曼的論文。

計算機文獻中的“架構”一詞可以追溯到1959年IBM主要研究中心機器組織部門的所有成員Lyle R. Johnson，Frederick P. Brooks，Jr.和Mohammad Usman Khan的工作。

計算機組織有助於最佳化基於效能的產品。例如，軟體工程師需要知道處理器的處理能力。他們可能需要最佳化軟體才能以最低的價格獲得最高的效能。這可能需要對計算機組織進行非常詳細的分析。例如，在SD卡中，設計人員可能需要安排該卡，以便儘可能快地處理大多數資料。

計算機組織還幫助為特定專案計劃處理器的選擇。多媒體專案可能需要非常快速的資料訪問，而虛擬機器可能需要快速中斷。有時某些任務也需要額外的元件。例如，能夠執行虛擬機器的計算機需要虛擬記憶體硬體，以便不同虛擬計算機的記憶體可以保持分離。計算機的組織和功能也會影響功耗和處理器成本。

兩個字“平衡”，並且不是兩端，而是三端的平衡。哪三端？

錢：讓企業花更少的投入達到想要的結果。

時間：讓團隊花更少的時間完成既定的工作。

人：對人的把握，在選型時選擇團隊能hold住的技術。

內容包括：架構設計丨分散式系統丨產品丨運營丨個人深度思考。

架構師也可以分成兩種：一種是從程式設計師一步一步成長後“進化”成為的架構師，一種是PPT架構師，當然，我們的奮鬥目標肯定是要成為前者。

很多人有一種錯誤的認識，就是架構師的工作只是專案過程中的一個環節，架構設計完成之後，架構師的工作就完事兒了，這種認識是不對的。架構師的工作職責，應該會貫穿整個專案。

程式開發的實質，就是把客戶的需求翻譯成程式碼，用程式功能滿足客戶的需求；所以大多數時候，架構師需要從需求階段就介入的，架構需要和需求人員溝通需求，保證自己可以完整的理解和把握客戶需求。

如果是一個新的專案，架構師需要對專案進行分解，形成專案架構，在此基礎之上再完成技術選型。

例如，根據專案的需求，要把整個系統分解成多個子系統：一個對外提供介面呼叫，一個跑定時服務，還有一個專門監聽MQ獲取訊息並進行處理；資料庫用Mysql而不是Oracle，定時服務需要要用到zk或者Redis做分散式鎖，對外的介面是Rest而不是WebService，這些都需要架構師來確定。

如果是一個老專案，架構師同樣需要這次的需求做在什麼地方，是在現有技術上就能實現，還是需要引入新的技術。

架構師是要跟隨專案的整個流程，架構師就是專案的技術權威，他應該時刻與開發人員進行溝通，讓開發人員理解架構意圖，實現業務功能。

架構師不是一個指揮者，把系統設計好了就讓程式設計師來幹，有一些技術難點，都需要架構師衝在前面解決。而不是當專案遇到一個“坑”時，架構師是要“真刀真槍”的寫程式碼的。

在軟體開發中，架構師的主要職責是系統全域性分析和實施，搭建軟體架構，決策關鍵技術方案，攻克核心技術難題。

架構師大致有兩類，一類是職業架構師，一類是從技術崗成長起來的架構師。職業架構師主導過很多專案，以其豐富的理論和標準化的方案著稱，專案平臺，甚至是公司平臺跨越容易，大多數採用通用的框架和技術，這類架構師可替代性高，類似職業經理人。另一類從技術崗成長起來的架構師，是專案的頂樑柱，是部門的定海神針，這類架構師理論紮實，業務精通，根據需求為專案量身定製，能將技術展現最最佳化，框架，模組，方案，甚至包括程式碼習慣，都帶著濃厚的個人色彩和團隊文化，這類架構師一般只從內部團隊成長起來，可替代性低，但有明顯的缺陷，技術上容易偏離行業潮流，甚至不夠標準化。

架構師主要是負責框架，將需求徹底消化，用最合適的技術來實現全部需求的骨架部分。架構師應具備豐富實際經驗，紮實的理論基礎，熟悉各種框架，業務，方案，甚至工具。架構師應具備良好的領導和溝通能力，在部門協作和團隊工作中起到技術貫通的作用。架構師應具備廣泛的知識面，對行業的潮流和發展有中肯的把握。架構師應具備能說理論能寫方案能程式設計實現或熟悉開發語言的能力，抽象化，模型化，事件化，介面化，協議化等等，都是其重要能力。

一般提到架構師這個詞的大都水平不咋地，水平高的都說自己僅僅是個程式設計師。真正提現水平的還要看做過的專案有多厲害。

架構師的職責是根據需求設計系統的頂層結構，解決軟體系統複雜度帶來的問題，包括：高效能、高可用、可擴充套件性、低成本、安全、規模等非功能特性。

下面附上架構師的知識圖譜，以供參考：

以前對於架構師這個職位定位比較模糊，一直在探索怎樣從一個普通程式設計師成為一個能力與溝通卓越的架構師，現在我就闡述一下我現在對架構師這個職位的膚淺看法。

架構師，是一個既需要掌控整體又需要洞悉區域性瓶頸並依據具體的業務場景給出解決方案的團隊領導型人物。架構師不是一個人，他需要建立高效的體系，帶領團隊去攻城略地，在規定的時間內完成專案。

首先要搞清楚架構師主要做些什麼

1 確認需求

架構師要懂得使用者需求，理解使用者真正想要什麼，這使得架構師必須要和分析人員不斷溝通，反覆確認需求規格說明書，以此來保證他精準清楚使用者需求。

架構師會與很多人溝通，例如開發人員，例如我們專案經理，有時甚至是使用者本身。架構設計的目的很明確，目的是什麼呢？挖掘使用者需求。

2 系統分解

在架構師認可需求規格說明書後，架構師已明確使用者需求是是什麼，這時候便看架構師的分解能力了。

一般分為縱向分解和橫向分解，縱向分解是將整個系統分層，從而將整體系統分解成下一級的子系統與元件。橫向分解是在系統分解成不同的邏輯層或服務後，對邏輯層進行分塊，確定層與層之間的關係。

3 技術選型

在系統分解後，架構師會最終形成軟體整體架構，接下來，架構師的職責是技術選型。

前端到底用瘦客戶端還是富客戶端呢？資料庫是用MySQL還是MSSQL又或是Oracle呢？在瞭解使用者需求後，分解完系統後，技術選型是非常重要的環節，提出各個方向，我再進行評估。不過，很多人都以為架構師是有決定權的，其實不是，架構師沒有拍版的權力，決定由專案經理來做。

架構師在技術選型階段會提供參考資訊給專案經理，專案經理再從預算、進度、人力、資源等各方面情況來權衡，最終確認。

4 制定技術規格說明

如前文調查顯示，架構師在專案開發過程中是「靈魂人物」，並且要具備協調組織能力和懂得人員分工。

在制定技術規格說明階段，架構師要協調起所有的開發人員，架構師通常會用技術規格說明書與開發人員保持溝通，讓開發人員能從各個視角去觀測、理解他們負責的模組或者子系統，確保開發人員能夠按照架構意圖實現各項功能。

在瞭解架構師的職責後，再來看看架構師該具備什麼能力才能成為一家公司中的靈魂人物。

1 設計能力－擅長整合分析

架構是過程，並非結果。

架構是架構師洞察內在結構、原則、規律與邏輯的過程，架構師要做到清晰理解系統，以及簡潔描述，這是分析整合的能力。

一個架構師必須具備極強的分析能力，要做到根據產品宗旨和目標，分析清楚產品定位以及產品業務，再整合利用現有的技術領域，找出最佳方案，實現產品概念。

2 技術實力－實現產品規劃

架構師首先要將程式碼寫的清晰易懂，要能夠實現功能，做到沒有Bug，這要求架構師必須具備至少熟練掌握一門語言。

這是最重要的，每一名出色的架構師，必定是一位優秀程式設計師。架構師並不是純粹的管理崗位，對那些愛寫各式文件、畫流程圖、脫離程式碼、只說不做、高高在上的架構師，程式設計師們通常會稱他們為——PPT 架構師。

不懂程式設計的架構師的職業生涯必定是短暫的，無論如何都不可本末倒置，要想實現自己的職業規劃，不能荒廢自己本身的技能，技術是架構師賴以生存的最基本能力。

所以，不推薦不熱愛程式設計的人去做架構師，對於團隊工作和個人發展來說，都會帶來糟糕的後果。

3 溝通能力－能夠橫向溝通

架構師必須參與專案開發全過程，包括確認需求、系統分解、架構設計、技術選型、制定技術規格說明、系統實現、整合測試和部署各階段，在這一系列過程中，架構師會與各部門溝通交流。

一個產品會有多部門合作，架構師在其中的溝通極為重要，直接影響產品進度與質量。架構師不僅要與開發人員溝通，也要和專案經理、分析人員甚至使用者溝通，來實現產品的各種可能性。

所以，對於架構師來講，不僅有技術方面的要求，還有能夠橫向溝通的要求

話說回來，一般公司招聘需要架構師的職責概括如下：

架構師的職責就是設計一個公司系統的基礎架構，並提供關於怎樣建立和維護系統的指導方針。具體來講，架構師的職責主要體現在以下幾方面：

1、負責公司系統的架構設計、研發工作。

2、承擔從業務向技術轉換的橋樑作用。

3、協助專案經理制定專案計劃和控制專案進度。

4、負責輔助並指導系統分析開展設計工作。

5、負責組織技術研究和攻關工作。

6、負責組織和管理公司內部的技術培訓工作。

7、負責組織及帶領公司內部員工研究與專案相關的新技術。

8、管理技術支撐團隊並給專案、產品開發實施團隊提供技術保障。

9、理解系統的業務需求，制定系統的整體框架（包括、技術框架和業務框架）。

10、對系統框架相關技術和業務進行培訓，指導開發人員開發。並解決系統開發、執行中出現的各種問題。

系統構架師的作用

系統架構師該怎麼來實現其“架構”企業的職能呢？尤其在設計企業 IT 策略時，該怎樣體現架構師的價值？

這裡以例項說明、

摩托羅拉的副Quattroporte Toby Redshaw 說，架構師是“IT 策略中的中樞”，而且這一角色對公司的影響確實非常大。當 Toby Reshaw 在 2001 年進入摩托羅拉並擔任其策略暨架構副Quattroporte時，他儼然一位購房者對一套搖搖欲墜的公寓進行估價一樣。他並不是僅僅只作些表面上的修改，而是擬定了一個重建摩 託羅拉整個基礎結構的計劃，這個計劃可以徹底修整公司的基礎建設。 就像一個建築師設計一幢房子一樣，Redshaw 擬出了一張技術構架藍圖，一座技術性的建築，以便使被他稱作“如義大利麵條般錯亂的應用程式，機器和管線”那些東西變得井然有序。他說，只要選擇了正確的 架構策略並用對了人，摩托就可以用比以前更快的速度生產出大量應用軟體，而且可以減少維持重疊系統的費用。 Redshaw 說、“如果你連建築架構都搞不好，就算你的石匠技術再高明，又有什麼用？架構師是 IT 策略中的中樞。” 像 Redshaw 這樣的系統架構師們在企業內部的影響力非常大。很久以來，雖然他們一直在資訊科技部門擔任重要職務，但是他們經常受委託提供全面概況分析，並提出一些關於 如何遵照標準執行這些任務的建議，而這些對日常運作的影響極其有限。今天，隨著各公司都在尋找重建他們的 IT 系統，使其更能有效節省成本，更靈活的方法，架構師愈來愈被看作是至關重要的因素。

一個定義明確的架構的目標在於降低運行復雜的運算系統的費用。一個公司可以採用一種特定的資料庫配置，如微軟的資料庫，進而將系統標準化，而不需要讓公司的每個部門安裝它們自己所需要的資料庫伺服器。

Express 的技術架構副Quattroporte Andy Miller 說：“如果你沒有一項強有力的架構策略，人人各行其是，最後以得到六種伺服器和軟體平臺而告終，你的系統變成了大雜燴，而那將使你的費用激增。”把架構師 獨立出來有很多好處，比如系統的整體把握，質量上的保障，技術上的先進性，架構的靈活性，高效性，還可有效地降低成本。試想，1 個月薪 1w 的架構師+10 個月薪5k 的工程師，肯定比 11 個月薪 6k 的高階工程師效果要好。一般來說，級別越高的架構師，經驗更豐富，爭相聘請的人也多，他們也是與公司全部的 IT 策略密切相關的專業人員。

系統構架師與其他角色的區別

系統構架師與產品經理的關係及區別產品經理通常是指負責產品設計的“專人”。一個優秀的理想的產品經理，應同時具備較高的商業素 質和較強的技術背景。產品經理要有深厚的領域經驗，也就是說，對該軟體系統要應用到的業務領域非常之熟悉。比如，開發房地產銷售軟體的產品經理，應該對房 地產公司的標準銷售流程瞭如指掌，甚至比大多數銷售人員還要清楚。如果開發的是通用產品，他/她還具備對市場、潛在客戶需求的深刻洞察力。

那麼，系統架構師與產品經理有什麼不同呢？

我們不應該把二者混為一談，這是不少論述和實踐常犯的錯誤。我看來，如果把開發軟體比作攝製電 影，產品經理之於系統架構師，就正像編劇之於導演。產品經理雖然要有一定技術背景，但仍應屬於“商業人士（business people）”，而系統架構師則肯定是一個技術專家。二者看待問題的立場、角度和出發點完全不同。

系統構架師與專案經理的關係及區別軟體專案經理是指對專案控制/管理，關注專案本身的進度、質量，分配、調動、協調、管理好人、 財、物等資源的負責人。對於軟體專案經理來講，包括專案計劃、進度跟蹤/監控、質量保證、配置/釋出/版本/變更管理、人員績效評估等方面。優秀的專案經 理需要的素質，並不僅在於會使用幾種軟體或是瞭解若干抽象的方法論原則，更重要的在於從大量專案實踐中獲得的寶貴經驗，以及交流、協調、激勵的能力，甚至 還應具備某種個性魅力或領袖氣質（Charisma）。

由此可見，專案經理和系統架構師在職責上有很大差異。混同這兩個角色，往往也會導致低效、無序 的開發。特別是，從性格因素上講，單純的技術人員傾向於忽視“人”的因素，而這正是管理活動的一個主要方面。另外，就像戰爭中的空軍掩護（Air Cover）一樣，專職的專案經理能夠應付開發過程中大量的偶發事件和雜務，對於一個規模稍大的專案，這些雜務本身就能佔用一個全職工作者的幾乎全部時 間。在一個專案中，推動專案發展的是系統構架師，而不是專案經理。專案經理的職責只是配合系統構架師，提供各個方面的支援。主要職責是與內外部溝通和管理 資源（包括人）。系統構架師提出系統的總體構架，給出開發指導。一個專案中，專案經理的角色什麼？如果他即使管理人員又是設計人員，則必須比別人強，能夠 有讓別人服的東西。如果他只是專案管理人員，系統構架師有專門人員，就可以不用精通或者說了解 it 各個方面的知識，如果瞭解更好。另外，如果在一個專案沒有人在技術構架上和開發指導上負全部責任，而是每個人都負責一快的架構、分析、設計、程式碼和實施 等，最後肯定會失去管理。

系統構架師與系統分析員的關係及區別系統分析員（System analyst）是指對系統開發中進行分析、設計和領導實施的人。一般意思上講，系統分析員的水平將影響系統開發的質量，甚至成敗。但在一個完善的系統開 發隊伍中，還需要有業務專家，技術專家和其他輔助人員。所以，系統分析員只是其中的角色之一。但中國許多的 IT 公司，一般只有系統分析員而沒有技術專家。系統分析員固然是對特定系統進行分析、設計。所以他的任務、目標是明確的。他只是去執行任務，完成系統的最終設 計。

系統架構師應該和系統分析員分開，但架構師必須具備系統分析員的所有能力，同時還應該具備設計 員所沒有的很多能力。 系統架構師是指導、檢督系統分析員的工作，要求系統分析員按什麼標準，什麼工具，什麼模式，什麼技術去設計系統的。同時，系統架構師應該對系統分析員所提 出的問題，碰到的難題及時地提出解決的方法。並檢查、評審系統分析員的工作。

進階成為架構師是大多數java程式設計師們的夢想，架構師從廣義上可分為軟體架構師、系統架構師，下面給你仔細講下兩個架構師的主要職責。

軟體架構師是程式設計師最容易突破、最可能進階的一條職業發展路徑，主要職責有：1.根據客戶需求及市場行業需求進行軟體構架的制定(技術框架和業務框架);2.對軟體構架相關人員進行技術和業務培訓，並指導開發人員進行開發;3.解決軟體開發過程中遇到的問題;4.為技術決策提供規則，平衡各類涉眾的不同觀點，化解技術風險;5.負責組合和帶領公司內部員工研究與專案相關的新技術;6.完成領導交給的其他任務。

軟體構架師職業發展：由一名優秀的軟體架構師成為企業專案成為獲得成功的關鍵，軟體架構師成為一個流行的職業，軟體架構師是由演算法應用開發工程師、需求工程師、JAVA軟體工程師等發展而來。軟體架構師的發展方向為專案經理。

系統架構師主要著眼於系統的“技術實現”。因此應該是特定的開發平臺、語言、工具的大師，對常見應用場景能給出最恰當的解決方案，同時要對所屬的開發團隊有足夠的瞭解，能夠評估自己的團隊實現特定的功能需求需要的代價，主要職責有：

1、負責伺服器系統的技術規格定義和系統架構設計；

2、負責伺服器關鍵部件如機箱、主機板、電源的規格和方案設計；

3、負責系統和部件供應商選擇和關鍵部件選型；

4、負責開發過程的技術質量管理和關鍵設計驗證；

5、負責技術問題的解決。

系統架構師職業發展：

系統架構師→資深架構師→專案經理→專案總監→CTO(首席技術官)

架構師根據行業可以分為網路安全架構師、大資料架構師、前端架構師、Java架構師、移動端架構師。

根據領域可以分為資料架構師、應用架構師、中臺架構師、業務架構師、運維架構師。

架構師在公司裡面根據職能可分為強矩陣架構師以及弱矩陣架構師。強矩陣架構師相當於技術總監，權利很大，屬於公司管理層，既負責技術、也負責管理，彙報物件是副總，可以相當於部門經理的權力。弱矩陣架構師僅負責技術，架構選型，權力沒有技術經理、專案經理大，技術方案還得技術經理、專案經理拍板稽核。

架構師應該技術棧全面，具有行業前瞻性，能為公司的技術引領潮流，還應該具備帶人、指導程式設計師的能力，架構師本身也是程式設計師。

架構師至少要精通一個領域，再做技術橫向擴充套件，並提供程式碼稽核。能解決專案中的難點、做救火隊員，對框架的原理也應該理解，能負責公司框架研發。

這是我在知乎上查到的：

一般來說，應用架構師負責構建一個以解決特定問題為目標的軟體應用的內部結合結構，一般以滿足各種功能性需求以及維護性需求為設計考慮目標；系統架構師則提供運營支撐軟體應用的資訊系統的結構設計，一般以滿足各種非功能性需求或運營性需求為設計目標（如安全性、可伸縮性、可互操作性等等）；企業架構師，就不光只顧IT系統的架構了，他應以企業的持續經營目標為考慮要素來構建企業所需要的內在結構設計；基礎設施架構師以及其他架構師職責也大體如此。

當然，現實中的架構師往往會身兼數職，而不僅僅是構思架構本身。比如，大部分軟體架構師也會組織軟體團隊、進行一些相關研究，甚至擔負一些行政管理的工作，就不再延伸贅述。

我自身也在動力節點培訓學習Java，未來想著成為一名架構師，現在還在努力中...不過不得不說，這個培訓機構挺不錯的，只教Java語言，課程體系多，老師們都特別負責，風風雨雨12年了，每天上課都感覺特別有保障，希望和我有一樣目標的小夥伴一起沖沖衝！

理解架構師的正確姿勢

　　這個題目在我的腦子裡存在好久很久很久，尤其在軟體行業，架構師更是普遍的不能再普遍的存在，“你是做什麼的，我是做架構的，你是做什麼的，我在公司也是做架構的”。哪到底什麼是架構師呢，什麼才是他應該具有的姿勢，接下來我們一起剝洋蔥說下我的理解。

架

　　架，我們架什麼呢，軟體當然是架軟體的需求了，我們得知道我們做什麼的軟體及軟體本身所處的環境及位置，只有把需求瞭解清楚&清晰，才好梳理整個架構的經脈，如果需求搞不清楚，就開始搞架構，或者不管需求，封閉起來做架構，基本到最後都會有蹩腳的感覺。悔恨當初為什麼不先高畫質需求，就動工。這基本也是年輕的架構師或者是剛剛有點架構思想的同行的常規誤區，還有一點就是軟體這行雖然經驗很重要，但具體到具體軟體需求還是有不少不同的，不然天下軟體大同，我們也就沒必要擼碼了，“不要跟我談需求，我以前做過很多類似案例了，我保證能給你做好”，年輕的同行經常掛到嘴邊的一句要命的話，其實不知道無休止的加班正在靠近，我們不要在需求不清楚的情況下，保證任何事，架就是架的需求，是根基，是源泉。

構

　　構，我們構什麼呢，構建我們架的需求，類似工人師傅建造大樓，提前把骨架搭建起來，構是非常考驗一個架構師真正落地能力的部分，貫穿縱橫，不光考驗一個架構師的擼碼能力，運維知識，還有平常拓展的行業視野，這一步跟工作經驗有非常大的關係，我們往往想當然的把以前的經驗帶到新的架構中，所以，構是更需要長時間的、更多專案的經驗沉澱，才能面對不同架的需求，才能得心應手、遊刃有餘。

師

　　師，很多人認為很容易，就是開個小會，裝逼培訓下就行了，其實是大錯特錯，思想的灌輸是很難的，把自己的架構思想灌輸給別人，是很難的，尤其是軟體行業，鑽牛角尖的特多，一個問題能跟你糾結一天，說服很難，接受更難，這師不容易，特難，考驗的是溝通、交流，更是心智。

總結：

架構師是一個混合體，涉及業務需求、技術能力、工作經驗、交流溝通等等，雖然很辛苦，但只要持之以恆，聰明的擼碼人，有什麼做不到的呢。

對於架構師來講，其實是分兩種架構師的，一種叫做業務架構師，一種叫做技術架構師。

業務架構師。

對於業務架構師而言，它首先就是要搭建業務模型，配合產品經理形成業務的一個可行性閉環，因為有的產品經理規劃的在現實當中，可能在技術環這個時候就需要業務來完成業務的一個閉環從銷售實業務架構師來，從整體的框架上來配合來完成業務的一個閉環，從，客戶入口一直到客戶交付，整個完整過程的一個業務閉環。

技術架構師

技術家公司呢，主要是完成在實現方案上的總體設計和模組劃分。既要保證高併發高可用，還要保證靈活性。所以技術架構師主要還是站在一個技術模組的角度來看待問題，而不是站在技術細節的角度來看待問題。這也就為什麼技術將公司需要，懂的知識要比較多的一個原因。技術選型，模組的劃分，呃互動協議，這些都是技術加工所要重點關注的內容。