在今天的技術圈，可能隨便遇到一個人遞給你一張名片，title 就是某某架構師。架構師多如過江之鯽，也正是眼下業內一個有趣的現象。對于架構師，你有什么看法？

什么是架構師？

隨便打開某招聘網站：系統架構師、搜索架構師、前端架構師、iOS/Android 架構師、平臺架構師、（大）數據架構師、JAVA/PHP/.NET 架構師、高級架構師、資深架構師、BI 架構師，這些是大家常見的，君不見還有后臺架構師、MIS/ERP/OA 系統架構師、金融系統架構師、搜索架構師、總線架構師、運維架構師，安全架構師...... 林林總總，不一而足。

僅僅是上面這些崗位名稱，就能看到架構師崗位的差異之大，方向不同、技術棧不同、行業不同，即便同一個崗位，水平差距也是天壤之別，如果僅以架構師一個稱謂來描述，顯然是不合適的，所以我覺得今天在行業內這個稱謂還有點”虛”。

李維先生曾經有過一次演講，講到了一個架構師應該具備的特性：

1. 核心軟件技術。要攻克數據庫設計問題，必須深入了解數據庫的工作原理，而不是會寫復雜的SQL會管理個備份會設計個表結構就算精通數據庫。有人甚至把會用hibernate\structs\spring當作自己會核心軟件技術。

2. 產品特性。你學了那么多核心技術，到底要干嗎？我一直在商業軟件公司工作，沒有在研究所工作過。我各種技術要做到的就是幫助企業軟件生產，如何更快更省力氣質量更好市場競爭力更強。

3. 軟件趨勢。在企業管理軟件開發領域，往往會見到這樣的現象：不少開發人員精通客戶業務需求，深入第一線做客戶實施。他們學習技術也是為了解決現有手頭的問題。尤其企業管理軟件開發領域，技術要求并不高，而如果不了解客戶需求，開發的軟件實用性就不強，即使你的功能開發的又性能好又安全性好也沒實用意義。

架構切分，本質上是利益的調整

在識別出是誰的問題之后，大部分情況下問題都迎刃而解。但總還有一部分確實是有問題的，需要做調整。

這個調整就是架構的切分。簡單來說：

• 架構的切分的導火索是人的負載太重。

• 架構的切分實際就是對 stakeholder 的利益進行切分或合并，使得每個 stakeholder 的權責是對等的，每個 stakeholder 可以為自己的利益負責。

• 架構切分的最終結果都會體現在組織架構上，只有這樣才能夠讓架構落地并推進。

• 架構切分的結果一定是一個樹狀，這也是為什么會產生分層。層數越多溝通越多，效率越低，分層要越少越好。盡可能變成一顆平衡樹，才能讓整個系統的效率最大化。

如何才能把握好這兩個問題？怎樣才能快速的層層剖析，找到問題的主題？又如何才能合理有效的進行切分？這些問題，是制約是否成為出色架構師的關鍵。

什么是好的軟件架構

這個問題，可能大家一直都在問，包括一些IT企業也在問，對于這個問題的回答，可能不僅僅是一個簡單的語句或者是定義就可以回答的出的，我們來看下面的幾個形象的例子：

這個是什么東東呢？樂高玩具，樂高玩具大家肯定都玩過吧？

它即可以以一個完整的模型賣給你，你也可以把它全部打碎了重新從一個模型自由的再去組裝成另一個模型，因為每一個樂高的模塊在橫向、堅向里都有標準的接口，這就是我們常說的高內聚、低耦合。

良好的溝通

架構師需要知道，有效溝通是建立信任和影響團隊以外成員的關鍵技能。他們知道不同群體使用不同的詞匯，而使用技術術語和描述與業務人員溝通將會變得比較困難。與其談論模式、工具和編程概念，架構師需要使用聽眾熟悉的詞匯與之交流，諸如風險回報、成本和收益等。這比單純使用技術詞匯進行溝通來得更好。架構師還需要認識到團隊內部溝通與外部溝通同樣重要，可以使用圖表和小組討論的方式來建立和完善技術愿景，并書面記錄之（如架構決策日志或Wiki等），從而為將來留下可追溯的歷史。

結語

架構之路任重而道遠。程序設計和架構設計是互通的，每個人都可以從設計好一個程序往設計好一個系統架構前進。

想成為架構師不是懂了一大堆技術就可以了，這些是解決問題的基礎、是工具，不懂這些怎么去提解決方案呢？這是成為架構師的必要條件。

架構師還要針對業務特點、系統的性能要求提出能解決問題成本最低的設計方案才合格，人家一個幾百人用戶的系統，訪問量不大，數據量小，你給人家上集群、上分布式存儲、上高端服務器，為了架構而架構，這是最扯淡的，架構師的作用就是第一滿足業務需求，第二最低的硬件網絡成本和技術維護成本。

另外還有一點可以通過自身的學習來獲取一大進步。

分享給超過5萬的程序員朋友下載，這次我把所有資料重新梳理精簡，免費分享給大家 。

究竟有哪些干貨呢？先給你們一個目錄：

免費領取資料途徑：公眾平臺 “程序員編程"