首先我們看看架構師應該具備哪些能力:

1.抽象能力:能將各種零碎的事物總結出共性，抽象出模型。

2.分解能力:能將複雜的事物分解成簡單的、易實現的模組。

3.具備一定的預見性:業務發展變化快，系統成為業務發展的瓶頸，還是成為助推器，就看系統是否有前瞻性。

總的來說，架構師既要高瞻遠矚，又要腳踏實地。對新技術、行業發展都要足夠了解;對技術應用落地又要胸有成竹。這要求架構師對技術研究必須有一定的深度。

架構師不是神，也是一步一步成長的。從寫一段一段程式開始，你就要思考:功能實現的意義，存在的效能瓶頸，實現方式是否優雅。思考多了，你的架構就更有靈魂，而不是一個空架子。共勉！

java架構師需要做六個方面的工作。

1，需求整理分析

首先，第一手的資訊損失最少，架構師能夠更好的把握需求；其次，分析人員在與客戶交流時，往往不會深入挖掘需求，因為有很多隱藏的需求客戶自己都不見得意識的到，而架構師則可以依靠敏感的軟體嗅覺發現這些需求，減少以後的變數；第三，分析人員往往脫離開發團隊，盲目接受客戶需求，而架構師能夠清楚把握現有的研發團隊能做什麼，不能做什麼，提前預知風險，降低專案失敗的機率。

2，系統分解

在收集完資訊後，架構師需要將使用者需求轉化為軟體需求，同時要補充非業務需求，如健壯性，擴充套件性等等。如何區分和化解使用者需求與軟體需求，如何有效把握使用者需求與軟體需求的區別，是系統分解的核心。這是最考驗架構師的地方，也是隻有架構師參與的工作。

3，技術選型

這一步要根據對軟體需求決定專案該使用何種架構，開發模型，及依賴選項。如使用多層架構還是分散式架構，是瀑布模型還是RUP，是使用MySQL還是SQLServer，是否需要使用企業庫，是否需要使用ORM。但是，架構師對專案的技術選型要提供多種不同的方案，併為每種不同方案提供詳細說明文件，用來闡述每種方案的優勢，劣勢，可行性等內容。這些文件供專案經理或領導決策最終的技術選型。

4，系統設計

依據軟體需求和技術選型，架構師需要和軟體工程師一起將軟體需求落實到軟體詳細設計說明書中。架構師負責將軟體需求分解，重組織為子專案，子系統，元件和模組，以及它們之間的邏輯關係，從而形成不同的邏輯組成部分，最後還需要確定各個子系統及元件間的介面。這些都是作為進一步的團隊分工的依據。同系統分解一樣，系統設計是考驗架構師能力的重要職責。

5，培訓與指導

在軟體詳細設計說明書完成後，為保證專案的順利進行，架構師需要對整個團隊進行技術培訓，讓團隊中的每個人明白自己的職責範圍，該做什麼，不該做什麼。

在專案實施過程中，架構師需要參與到具體開發過程中，給與每個開發人員有效指導，以避免團隊成員對系統設計的誤解而造成專案的延誤。在我看來，這點對於新手比較多的團隊尤為重要。因為國內新手的一個通病是眼高手低，剛學會了一點點就認為自己什麼都會；當他們拿到真正的設計時又往往不知所措，畏首畏尾。

6，保持溝通

溝通是保證專案順利開展的有效保障。架構師要從多方面跟蹤專案進度，及時與專案經理或直屬領導彙報專案進展，與技術開發人員溝通遇到的問題，如果是迭代開發，還需要與使用者溝通需求變更。

架構硬實力

這個章節，基本大家都沒有什麼爭議性，必須是硬實力，拿得出手，能解決技術當前面臨的挑戰，能解決別人解決不了的問題。

從目前大家遇到的挑戰來看，從架構設計要求，我稍微做個總結。

1分層的應用設計思想：SOA，事件驅動等。

SOA這塊的內容，我推薦大家去看支付寶首席架構師程立的文章。這塊支付寶和淘寶算是一起實踐走過來的。但是，程立算是比較早而且很詳盡的把支付寶的SOA之路說得非常詳細。

2分散式原理：CAP，最終一致性，冪等操作等

這方面是的知識，網上比較多而且很全，也可買一本分散式系統相關的書籍瞭解。

大型網路應用結構

訊息中介軟體，分散式快取，負載均衡，叢集技術，資料同步等。

上一篇也談到了中介軟體，基本上現在大的網際網路公司，中介軟體基本可以與架構組劃上等好了。他們基本提供了分散式場景下的應用擴充套件的大部分基礎設施。淘寶在這塊的實力比較強，基本都已經開源出來了。常見的分散式快取Tair,分散式小檔案儲存TFS,等等。我之前一篇淘寶最具挑戰的的架構演變，也談到。

3高可用，可容災分散式系統設計能力。

例如，阿里雲SLB產品使用開源軟體LVS＋keeplived實現4層的負載均衡。

採用淘寶的Tengine實現7層的負載均衡。所有負載均衡均採用叢集部署，叢集之間實時會話同步，以消除伺服器單點，提升冗餘，保證服務穩定。在各個地域採用多物理機房部署，實現同城容災。

SLB在整體設計上讓其可用性高達99.99%。且能夠根據應用負載進行彈性擴容，在任意一臺SLB故障或流量波動等情況下都能做到不中斷對外服務。

大容量資料儲存和檢索系統設計能力：資料庫分割槽，NoSQL，搜尋引擎等。

當然，還有自動化部署、回滾機制等，以及監控系統等等。

架構師前瞻性

所謂前瞻性表面聽起來還是比較空洞，什麼叫前瞻性？這裡我談談我看到或者觀察到的例子，這樣來觀察，也許更好感受到什麼叫前瞻性。

比如，這是當時支付寶程立在談到支付寶SOA之路的場景。

“瞻前”、“顧後” ――這是我現在體會到的最大挑戰。

先談談“瞻前”。當業務個性不明顯、業務規模也不大時，架構師還是有很多容易模仿的定式與先例的。但當業務的個性與規模到達一定階段時，一定會有一些別人從未遇到過的非常困難的問題需要你去解決。作為站在企業技術金字塔塔尖上的一群人，當過去的經驗用不上，搜尋引擎也不能向你提供任何有用的答案，只有獨立去思考，去做出重大決定時，如果沒有充分的準備，對企業對個人都是巨大的風險。這需要架構師建立未雨綢繆的意識，不斷推演未來可能的變化並思索應對之策，持續而有方向地積累知識、發展能力，建立廣泛的技術交流圈子，並且“顧後”。

再談談“顧後”。架構師的另一個重要的職責是發掘團隊中的好苗子，幫助他們，使他們趕上並超越自己。無論這一點是否寫入你的KPI，這樣做都是必須的。站在架構師的立場看，架構必須有一個好的技術梯隊一層層傳遞下去，才能夠有效、持續地貫徹執行，如果只是架構師們衝在前面，背後空了一大片，架構永遠只能停留在藍圖上。站在企業的立場看，企業真正的技術實力，不在於已經有怎樣的系統或者平臺，而在於是否有一個強大而有生命力的技術團隊，透過快速複製架構師的技術與經驗，可以幫助發展並壯大這樣的團隊，而企業整體技術實力的提升也促進了架構師提升。

業務產品架構

技術架構的目的是為了服務好業務，技術離開了業務，啥都不是。所以，對於好的架構師來講，對業務的掌握以及理解，需要一個團隊從早期就意識起來。

我用一個例子來舉例：語言翻譯能力。

將業務語言翻譯為產品語言、開發語言的能力很重要。業務需求來自客戶或業務部門，收集到的資訊是基於業務語言描述。 業務架構師需要學會基於自己的經驗知識進行分析，把業務語言轉換成產品語言、開發語言。這樣在跟產品、研發團隊的溝通中，才能完成資訊的有效、高保真傳遞。我早幾年前接觸過很多大公司的BD，基本就是幹著活。能把一個使用者的需求，從需求、產品、市場、功能、流程分析出一份詳細的需求報告書出來，在與使用者確認後，才能需求分析書轉到技術部開始架構設計等後續的工作。

一般來講，公司的很多需求業務模型，都是他們在整理。比如，公司的核心業務介紹等手冊。

當然，這裡還有好幾個方面。比如，對行業的理解、交流溝通能力等等。

第一，解決問題的能力，第二，程式碼的結構穩定性，合理的資料結構設計，以及可擴充套件性，第三，程式碼的效能，能處理高併發情況下的伺服器穩定平穩執行的能力

看需於何途。如果是框架創作的話，創意 和 靈感最重要。

比如設計新的程度語言，新的通訊框架。。。