我眼中的架構師：一個優秀的架構師應該具備什麼？
時光退回到七八年以前，那個時候“架構師“還是一個很“高大上“的title。可是在今天的網際網路圈，隨便一個工作了三、五年的開發人員，都可以稱之為架構師。
隨便多翻幾個招聘網站，你可以看到：前端架構師、後端架構師、Android架構師、iOS架構師、php架構師、運維架構師、DB架構師、搜尋架構師、中介軟體架構師、大資料架構師。。。五花八門，不一而足。
從這些崗位需求可以看出，“架構師“這個詞其實是一個很“虛“的詞，不同技術領域、不同行業，所要求的技能點、所側重的能力模型是差別很大的，不是一個簡單的“架構師“就可以概括的。
而本文也將談談我個人對“架構師“這個職位的理解：雖然不同領域要求的能力模型不一樣，但個人認為，作為一個“架構師“，還是有一些共同的東西需要掌握的。
格局
“格局“這個詞聽起來比較虛，但我舉個通俗的例子：你去一個陌生的城市旅遊，我想你首先需要的就是一張“地圖“。這張地圖定義了這個城市的“邊界“，也定義了這個城市的所有地方，通過這張地圖，你會對這個城市有一個“全域性的瞭解“。
而這種“全域性的視野“，不是說架構師才需要，換做其他職位、其他行業，同樣的道理。做產品經理，需要對產品有“全域性視野“；做運營，做市場，需要運營、市場相對應的全域性視野；做技術，需要技術相關的全域性視野。
說了這麼多，可能還是比較“虛“，我就舉個例子來說明到底什麼叫“全域性視野“，比如你現在負責開發一個新系統，你可能需要去理解下面這些關係到“大局的問題“：
這個系統的定位是什麼？它能創造什麼核心價值？
做這個系統的背景是什麼？－－ 為什麼以前不做，現在要上？是因為業務發展到了一定規模？還是開發資源現在有多餘，沒事可幹？
這個系統在整個組織架構中，處於什麼位置？跟這個系統關聯的其它系統目前什麼狀況？
產品經理如何看待這個系統？技術老大如何看？
這個系統的需求，是處於比較確定、比較清晰狀態？還是有很大灰度空間？很多核心點，大家還沒想清楚？
這個系統所用的技術體系，是比較老？還是最新的？
業界類似的系統，人家是如何做的？
。。。
關鍵點：上面隨便舉的這個例子，並沒有標準答案，我想表達的是，一個有“大局觀“，一個有“格局“的人，在做一件事情之前，要對所做的事情有一個“全域性把握“，風險在哪？挑戰在哪？提前要有心理準備！
最後再多說一句：“格局“是有層次的，國家總理在“國家“這個層次思考，CEO在行業、“公司“這個層次思考，業務線負責人在他所負責的那個“業務“層面思考，技術老大可能主要在“技術層面“思考，產品老大在“產品層面“，到了最下面，寫程式碼的，在“程式碼“這個層面思考。
不同層次的人，聚焦的範圍大小不一樣。可如果你能把你的“範圍“往外擴一圈，這對你做自己的“本職工作“會很有好處。
而這，在我看來就是“格局“。
歷史觀-技術血脈
如果說“格局“是從空間的角度去看待問題，那麼“歷史觀“就是從時間的角度去看。
任何一種技術，都不是誰吃飽了沒事幹憑空想象出來的，它一定是要解決某個特定問題。而這個特定問題，一定有它的歷史背景：是因為之前的技術，在解決這個特定問題上，解決的不夠好、或者有其它副作用，所以才發明了這個新技術。
所以，看待一個技術，一個方法論，需要把它放到“歷史長河“中，去看它在歷史中，處於什麼位置。
推而廣之，何止是技術，任何其他學問，何嘗不需要“歷史觀“？說個更專業點的哲學名詞，就這是所謂的“歷史唯物主義“吧！
抽象能力
同“格局“一樣，“抽象能力“又是一個很“虛“的詞。可作為架構師，就是需要這種“務虛思維“。
抽象也是一個“層次“結構，從最底層到最上層，不同工作階段，你需要在不同抽象層級進行思考。
很多寫程式碼的人，都比較習慣“自底向上“的思維方式。當你跟他討論需求的時候，他首先想的是這個需求如何實現，而不是這個需求本身是否合理？這個需求跟其它需求有什麼關聯關係？
這種過早考慮“實現細節“的思考方式，會讓你“只見樹木，不見森林“，最終淹沒在茫茫的各種細節之中，層次混亂，把握不住重點。
同樣拿上面的例子舉例，假如讓你做一個新的系統，那麼從“抽象“到“細節“，你可能需要考慮：
每個需求的合理性？
這個系統的領域模型是什麼樣的？
這個系統是應該在舊的上面改造？還是應該另起爐灶？
這個系統可以分成幾期，分期實施？
這個系統要拆分成幾個子系統？
每個子系統又拆分出多少個模組？
系統的表設計？api介面設計？job的設計？系統之間的訊息傳輸？
。。。
從上到下，是一個逐級細化的過程，並且進入到下1級之後，上1級可能又會退回去修改。
深入思考的能力
深入思考能力，這裡主要指“技術“的深度。關於“廣度“，在上面的“格局“這個層面已經包含。
“深度“不是說，你要在所有領域都很深。人一生的精力是有限的，你不可能對所有技術領域都很深，但你需要1個比較深的領域。
這種深度，並不代表你當前的工作就需要這個技術領域，而是說這種“深入思考的方式“，會讓你在思考其他問題時，也會帶著這個“習慣“。
這個東西很重要，因為技術一直在更新換代，當你面對一個新技術的時候，如果你有深入思考的能力和習慣，那你對新技術的理解往往也就很透徹。
同時，“深度“會讓你對“技術風險“有更加清醒的認知，你做一個專案的時候，這裡面潛在的“坑“，你可能會提前發現，而不是等做到那了，發現問題了，被迫思考。
架構的落地
任何的架構必須可以落地，可以實現。不能落地，只能停留在ppt上面的架構，那隻能忽悠人。這種架構，對實際不僅沒有指導作用，還會有反作用，對實際開發產生誤導。
而一個架構師，應該跟蹤從架構設計到架構落地到完整過程，“理論“到“實際“必然是有間隙的，跟蹤這個過程，實時修正，才可能真的做到“理論“與“實際“的統一。
業務架構 vs. 技術架構 vs. 基礎架構
基礎架構：這個很容易理解，IDC、雲平臺、網路、分散式儲存、資料庫、訊息中介軟體、SOA中介軟體、快取、監控系統、大資料計算平臺。。。
技術架構：為了支撐某類業務，強調系統的“高效能“，“高併發“，“高可靠“、強一致性等。
業務架構：同樣是為了支撐某類業務，但和技術架構的側重點不同。業務架構強調的是對“領域“的深刻理解，這通常和“領域專家“密切相關，這裡可能會強調系統的“可擴充套件性“，“可複用性“，對需求的彈性應對。
自底往上，基礎架構、技術架構、業務架構並不是相互獨立的，一般都是“業務驅動技術“，2者在互相促進中，同時往深度、廣度上發展。
組織架構與領導力
再複雜的系統，都是“人“開發出來的。而人多了之後，“人“相關的問題都會自然產生：溝通不充分、組織混亂、職責不清。。。
作為一個架構師，一般很難“獨善其身“，說我只管“技術“，不管“人“。因為你的工作，是一個“團隊“完成的，而不是一個“千里走單騎“的英雄。
所以熟悉整個組織架構，瀝青職責，把各種混亂的流程、協作理順，也是應該考慮在內的。
另一方面，組織架構和技術架構有著非常強的關聯：
合理的團隊，組織架構應該是根據業務的架構來拆分的，業務一直在發展，業務的架構也會一直迭代，組織架構也跟著迭代；
但現實中，往往遇到的情況是組織架構僵化，因為這涉及到利益分配，結果是組織架構約束了業務架構，也約束了技術架構的發展。而這就是看公司高層的領導力了。
總結
說到現在，你會發現，我可能說的並不是一個“純粹的架構師“。的確如此，上面這些是我認為作為一個“技術人“，應該去不斷修煉的東西，而不是光“架構師“需要。