如何才能真正的提高自己，成為一名出色的架構師？

12-10

想成為一個出色的架構師，但是學得知識不是很系統。
目前屬於自學，設計模式，演算法導論，編譯原理，UML2.0等都在看。
自學可想而知，肯定不夠系統，不夠全面，也不科學。

身邊也沒什麼人可以在這方面教導我，工作已經3年了，每次換工作都是呆在小公司，技術這塊的基本自己來抗，很多東西都自己摸索的。去年開始到現在完成了算是從頭到尾自己全權負責的項目（PHP-MYSQL-PYTHON，PHP的MVC框架自己寫的），做下來發現自己有很多的不足。

除了看書，自學，看看MIT的公開課，還有什麼辦法可以讓自己有很大的提升空間？

架構師是一個充滿挑戰的職業，知識面的寬窄往往決定著一個架構師的架構能力，所以在這一點上我比較贊成你的學習方式，就是要閱讀大量的技術書籍，但我希望你不要僅限於軟體相關的書籍，經常泡技術論壇，一方面可以結交朋友，一方面可以增加自己的知識面。
公司的大小往往決定了所做的項目規模，一般的大項目不太可能直接總包給小公司去做，但這並不妨礙小公司可以分包到大項目的一部分。在做小項目的同時也可以積累豐富的經驗，我自己就是一個這樣的例子。
我在小公司混跡了5年多，其中也偶爾有1兩個大公司，比如大唐電信，但是基本上都是小公司，從基層的程序要到公司的開發總監都做過，甚至自己還設計過包括LED顯示屏，密碼鍵盤在內的收費系統，自己聯繫廠家OEM，當然這些今天已經廣泛應用了，當時我們的客戶用上之後還是非常震撼的。
知識面的寬廣對於一名出色的架構師來說是必不可少的技能，也許很多人對架構的理解還停留在設計模式，重構，SOA等等的軟體層面，然而這僅僅是非常基本的東西，架構師的腦子裡不光需要知道讓軟體如何高效的運行，還需要知道如何去結合網路，存儲，甚至一些文件系統的特性，比如GFS，NFS，XFS，NTFS等等，而且架構師還需要知道一些編程語言的特性，C，C++，Java，PHP，Python，Lisp，JS等等，現在是一個混合編程的時代，只了解一種語言，即使再精通也會使你在架構系統的時候受到很大的局限性。
再有一點，架構師需要對資料庫技術有深刻的認識，因為現今是一個信息時代，大量的信息都是需要存儲並檢索的，資料庫設計的不好，將會嚴重影響系統的性能，而這一點往往會被我們的設計人員忽略，他們只知道遵守那些範式而不會結合數據的特性去設計資料庫。
看你的編程情況，你好像做PHP開發比較多，PHP比較適合B/S結構的應用開發，這會限制一個架構師的思路，我建議你再學習一門適合做C/S開發的語言，拓寬自己的視野。
從一個程序員到架構師是一個很大的變化，架構師需要從大的方面考慮，而不只是考慮這個模塊該用哪種設計模式去開發。不能急於求成，也許是我自己變化的比較慢，我用了10年的時間，這10年里，我使用超過一年的編程語言包括了delphi，C++，Java，python，使用的資料庫包括了oracle，infomix，sybase，sqlserver，mysql，javadb，sqlite等等，使用過大型機，小型機，伺服器。unix，linux，windows都至少做過兩年以上的開發，這些使用和開發的經歷會大大增強一個人在做架構師這個職業時的技術素養。
總之，想要成為架構師，需要有耐心，不斷學習，拓寬自己的視野，不僅僅局限於自己眼前的項目，關注開源技術，關注熱門技術社區的新動向。

06年寫的如何循序漸進向dotnet架構師發展，可參考：

微軟的DotNet開發絕對是屬於那種入門容易提高難的技術。而要能夠成為DotNet架構師沒有三年或更長時間的編碼積累基本上是不可能的。特別是在大型軟體項目中，架構師是項目核心成員，承上啟下，因此RUP方法論也認同以架構為核心，體現4+1視圖在整個軟體開發過程中的重要作用。架構人員既要精通技術，又要熟悉業務，而且基本對軟體生命周期各階段的相關技術都需要有相關的積累和知識儲備，而這些不經過多年的磨練是很難達到這個高度的。

要成為一個合格的架構師首先必須是一個合格或優秀的編碼人員，對於開發來講編碼始終都是最重要的一項技能，在編碼過程中只要自己善於去思考和分析問題，就可以多學到很多相關的知識和技術。所以我們在開發過程中一定要注意新知識和新技術的學習，前人經驗和成果的學習。編碼過程中應該去思考的一些問題有：

1.在編碼過程中自己是否做單元測試，是否使用相關工具做單元測試，如果沒有的話是什麼原因無法把單元測試做起來？
2.自己編碼的泄露率情況，編碼泄露的BUG的原因分析
3.是否有意識的對代碼進行重構，重構過程中是否引入了相關設計模式的思想？
4.是否對C#語言的一些高級特性進行學習，如反射調用，非同步處理等。
5.是否對Remoting和WebService兩種分散式技術做過研究和對比分析？
6.是否經常研究開源項目和開源代碼，如Duwamish，PetShop，NUnit,Enterprise Library，Nant等
7.是否對對象持久化機制和O/R Mapping等相關技術做過相關的研究
8.平時在編碼過程中是否注重公用組件和公用類的復用和抽取
9.自己在平時工作和學習中是否經常開發些小工具提高工作效率，鞏固學習知識

設計和編碼其實是密切而不可分的，對於嚴格將設計和編碼分開的瀑布模型一般也僅僅在大型項目中應用。而及時編碼和設計分離，也不是將編碼人員不需要思考，編碼活動始終是一項創造性的勞動，如果否定這個觀點那就代表編碼過程完全不需要人員介入而可以完全自動化。因此在這裡談設計主要還是指設計人員的系統化思維能力，設計人員應該比開發人員站高一個層次來分析和思考問題。設計人員最重要的一個技能就是現實-&>抽象的轉換，而這個就需要談到方法論的問題了，技術人員需要積累面對對象分析和設計或結構化分析知識的積累，需要有較強的資料庫分析和設計能力。一個設計能否成為很好的架構師關鍵就在這種積累的深度和廣度上面了。

因此在設計過程中應該考慮的問題有：
1.你現在分析和設計能力能否勝任大中型的應用系統還是只是獨立功能分析和設計？
2.設計過程中是否有意識的考慮到組件的復用和相關介面設計準則。是否能夠很自然的將分析模式，設計模式的相關內容應用到自己的設計過程中。
3.是否對XP，RUP，面向對象，結構化等方法論都有過較系統化的學習和思考。
4.是否真正理解系統功能需求和非功能需求對系統設計的不同的指導作用。
5.對自己設計的功能是否會根據後期的變更來反思自己的設計為何不能很好的適應變更？
6.是否在設計過程中經常自己開發些原型來對自己的設計思路進行驗證？
7.是否專註技術的同時開始專業業務流程的分析，關注業務建模？

如果我們在設計和開發過程中經常關注這些知識和技能的話，成為一個合格的架構師是早晚的事情。平時能夠勝任工作開發用到的知識和技能是微不足道的，如果自己不是有意識的去學習這些知識的話，那技能是很難得到進一步提高的。我參加過兩次微軟的架構師培訓，在北京的微軟架構峰會上也有機會專門參加了 PP Workshop的學習，培訓老師是微軟總部SmartClient Architecture and Design Guide一書的作者Edward A.Jezieski，讓我感受最深是老外深刻的技術底蘊，對程序開發的執著。

對於DotNet架構經常用到的知識和技能儲備有
1.RUP方法論，4+1視圖。用例驅動業務建模-&>分析模型-&>設計模型
2.用例模式-&>分析模式-&>設計模式
3.常用的分散式技術
4.對安全，異常，日誌，性能等非功能性需求的關注
5.對應用系統整體業務的關注

相關的一些參考書籍(微軟網站和電驢都可以下載到)

微軟網站提供的參考書籍
Enterprise Solution Patterns Using Microsoft .NET
.NET Data AccessArchitecture Guide
Application Architecture for .NET:Designing Applications and Services
Caching Architecture Guide for .NET Framework Applications
Designing Application-Managed Authorization
Smart Client Architecture and Design Guide

其它架構方面的參考書籍
Software Architecture In Practice
Pattern-Oriented Software Architecture
The Art Of Software Architecture
Beyond Software Architecture

模式方面的書籍
Analysis Patterns
Design Patterns - Elements of Reusable Object-Oriented Software
Applying UML and Patterns
Design Patterns Explained

===================================================
2015年8月，增加架構設計和概要設計的區別

架構設計

架構設計包括了功能性架構和技術架構設計兩個部分的內容，功能性架構解決業務流程和功能問題，而技術架構解決非功能性需求等問題。兩種架構都包括了動態和靜態兩個方面的內容，對於功能性架構中動態部分為業務流程驅動全局用例，用例驅動的用例實現等；對於技術架構中動態部分為架構運行機制，而靜態部分為框架，分層等方面的內容。

功能性架構包括了全局用例設計，這個本身是用例分析和設計的一個延續，而全局用例分析建議的思路仍然是業務流程，業務用例建模到系統用例建模的過程。全局用例分析清楚後可以開始考慮子系統和模塊的劃分，形成系統的功能架構圖，當然在劃分過程中一定要考慮到通過CRUD矩陣等分析方法來分析模塊如何劃分合理，如何保證模塊本身高內聚和松耦合。

在全局用例分析完成後涉及到數據模型的設計，數據建模仍然從業務驅動，從最初的業務對象和單據入手，到最終的數據概念模型和邏輯模型等。架構設計中全局數據模型不一定覆蓋所有的數據對象和數據表；但是核心的主數據，核心業務單據數據一定要覆蓋到，模型到的層次到邏輯模型即可。如果用面向對象的分析方法，這裡需要出的是UML建模中的概念模型和邏輯模型，體現核心對象和類，核心對象和類之間的關係。

將全局用例分析和數據模型建立融合在一起，可以看到這兩者結合起來會形成一個系統完成的領域模型層。一直認為領域模型思路應該引入架構設計，只有領域模型才是真正關注功能性架構，而不用馬上關注到具體的技術分層和技術實現。

前面兩者做完後可以看到一個大系統被分解為了多個子系統或模塊，那麼接著要考慮的就是模塊間的集成架構，分析完集成架構模塊間的介面基本就出來了。介面設計應該是架構設計的另外一個核心內容。要明白架構設計一個重要作用就是架構設計完成後各個模塊可以並行開始概要設計，詳細設計和開發工作。只要大家都遵循架構設計約定的介面規則即可以了。

集成架構考慮完另外一個核心內容就是公共可復用組件的抽取和識別，包括了功能組件和技術組件，需要識別出來哪些是可復用的，如何進行復用。對於復用層次本身又包括了數據層復用，邏輯層組件復用，界面層UI組件的復用等。復用是架構價值體現的的另外一個關鍵點。

這些都做完後，接著一個步驟應該在架構設計階段做的就是對架構輸出成功進行模擬驗證，前面完成了分解動作，必須通過模擬驗證來看看後續分解內容能否很好的集成和組裝。很多時候我們做架構設計的時候往往不做這塊內容，導致架構設計一些內容變成空中樓閣，無法落地。

再回來看技術架構設計，首先談下靜態部分的內容。這裡面就包括了軟體開發的分層架構，開發框架等內容，包括開發規範約定，技術平台和語言的選擇，使用的規約等都需要考慮。很多時候我們看到談架構的時候說到的三層或多層架構，僅僅是完整架構設計裡面很小的一部分內容。

除了分層架構外，接著考慮的就是各種非功能性需要，我們在架構上需要如何設計。這裡面包括了事務，緩存，異常，日誌，安全，性能，可用性，容錯能力等。這些逐個點都要在架構設計中說清楚如何考慮，由於這些本身就屬於一個應用系統中技術平台要考慮的內容，因此應該設計為較為公用的技術組件供上層的業務組件使用。要明白很多時候為何談到AOP或可插拔架構，只有這樣去考慮問題，才會考慮真正的功能性架構設計和功能實現和非功能性技術架構這塊充分解耦，實現進一步的靈活裝配。

再回到架構設計視圖層面，還需要考慮的就是整個應用系統的部署架構，部署架構本身也包括了邏輯視圖和物理視圖，應用最終開發出來了如何進行部署，這涉及到了IT基礎架構方面的細化，也需要考慮清楚。

概要設計

概要設計首先要明白的是根據架構設計的內容進一步對某個模塊的設計進一步細化。架構設計在系統級，而概要設計在子系統或模塊級。拿建築來比喻，架構設計是把一個建築的框架結構全部定清楚，包括地基要挖多深，核心框架和承重結構如何，每一層的結構圖如何，應該分為幾個大套間這些內容都應該定下來。每個大套間的水，電，氣等管道接入點在哪裡等。而概要設計要做的是拿著一個套間，來考慮這個套間內部該如何設計，如何劃分功能區域，如何將水電氣接入點進一步在房間內延伸，哪些地方需要進一步增加非承重的隔斷等。

基於以上思路我們看到在架構設計的時候，除了很少部分的核心用例我們會談到具體的用例實現完，大多數功能我們都不會談到具體的用例實現層面。而到了概要設計則需要進一步的分解我這塊模塊究竟需要實現哪些功能點，具體的每個功能點究竟如何實現都必須要考慮到。

嚴格的概要設計，我們希望是到了概要設計的某個功能模塊，模塊所涉及到的核心的類全部會出來，類關係圖全部會出來。資料庫設計也進一步細化到該模塊的資料庫物理模型。對於用例進行用例實現分析，在實現分析過程中可以看到每個類核心的public方法全部會分析識別出來。

拿著架構設計的介面，概要設計也需要進一步細化，細化出介面具體的輸入輸出和使用方法，包括模塊應該使用哪些外部介面，模塊本身又提供哪些介面出去都必須細化清楚。做概要設計的時候一定要清楚當前做的這個模塊在整個應用系統架構中的位置，和外部的集成和交互點。

概要設計不用到詳細設計這麼細化，包括類裡面的私有方法，public方法的具體實現步驟和邏輯，偽代碼等。但是我們要看到概要設計裡面對於核心的業務邏輯必須要設計清楚如何實現，實現的機制和方法。很多時候我們到了概要設計畫uml的時序圖，很多時候一看沒有任何意義，全是跨層的簡單的交互和調用。這個應該在架構設計的架構運行機制說清楚即可。設計到多個業務類間的交互調用才是重點，一個簡單的功能增刪改查，完全沒有必要畫什麼時序圖。

其次架構設計中給出了各種安全，性能，緩存的設計。那麼在概要設計中出來另外一個問題，即架構給出的各種實現方案和技術，我們在概要設計中如何選擇，如何使用。不是所有功能都需要緩存，那就要說清楚哪些功能根據分析需要緩存，需要緩存哪些對象，緩存本身的時效性如何設置等問題。

概要設計作為我們要達到一個目的，就是不論是誰拿走概要設計來做，最終實現出來的功能模塊不會走樣，功能模塊最終實現出來可能有性能，易用性等方面的問題，但是整個功能實現的大框架一定是定了的。

============================================================
2015-10月更新，架構思考

組件劃分和服務介面

組件化開發思路在很早以前就已經提出，只是當時的組件間交互更多的談介面而非服務，同時也沒太關心單個組件本身的全生命周期管理。談組件的時候一定不要先談開發和技術框架，而是真正從業務架構和應用架構出發去考慮整個業務系統的組件劃分，其中包括了業務組件和技術組件，各自應該暴露業務和技術服務能力。業務能力組件化和組件能力服務化也是一直強調的SOA核心思想。

在組件劃分清楚後，需要優先考慮組件間的交互而需要暴露出來的服務介面，即組件之間只能通過服務進行協同以進一步實現組件間的松耦合。其次才是考慮單個組件在實現的時候，結合分層開發技術框架涉及到分層，在這裡可以進一步參考領域模型驅動和設計的思路，否則很容易實現為資料庫表驅動功能而不關心領域模型設計和領域邏輯的實現，即雖然技術框架分層了但是職責不清，邏輯混亂並多處實現。

組件內部的實現一個重點就是應用層和領域層之間的關係，即在應用和領域層之間增加了一個服務層，服務層重點是服務介面和服務的組合等工作，而具體業務規則和數據處理的邏輯在倉儲類和規則類裡面來實現。注意對於組件內部應用層和領域層交互的服務並不一定要做為分散式的Service服務，也可以直接使用內部的API服務介面即可。將服務層服務介面具體的邏輯實現分離的一個重點就是在後期很容易將服務介面發布為一個供其它組件遠程調用的服務方法。

開源組件和技術

對於單一的技術往往很難滿足互聯網業務場景下不同的功能需求和非功能性需求，對於不同的功能或技術實現往往都需要選擇大量的開源組件或技術進行集成。但是這些獨立的技術組件如何集成為一個高效的整體就變得相當重要。任何技術的選擇都必須為了業務需求服務，模式分析是選擇技術的一個重點，即在什麼樣的業務場景下，面對什麼問題我們究竟應該選擇什麼樣的開源技術來實現最合適。

首先是開發技術框架層面的，即常說的基於MVC模式的多層框架，用的最多的估計還是SSH框架，其中在資料庫層面又有Hibernate或iBatis多種實現，在控制層本身又有struts和spring mvc多種實現。在展現層相關的技術點更多，包括了一些前端基於javascript和jquery的框架引入，Ajax實現，包括當前互聯網各種前端響應式框架，Html5技術等。技術框架的選擇看似和業務無關，但是卻需要進行業務場景分析，包括當前開發的應用是否需要同時支撐web端和移動app端，是否存在和外部集成和服務介面暴露，在業務交互和易用性層面有哪些要求，這些都需要考慮進去。

其次是實現核心技術能力的技術組件，其中包括了緩存，消息，流程引擎，搜索，安全，任務，日誌等諸多內容，這些當前往往都有現成比較成熟的開源技術來實現。如通過memcached或redis來實現緩存，通過rabbitMQ或zeroMQ來實現消息和事件管理，基於lucence的全文檢索引擎，開源的ETL技術實現數據集成，開源的jbpm流程集成等。在選擇這些技術的時候要注意和前面整體技術框架的集成，技術組件應該保持其高內聚和獨立性，僅僅技術組件的能力通過服務暴露出去實現和上層應用的集成。要做到這一點往往就需要對開源組件進一步進行封裝和定製，以和技術框架形成一個完整的整體，同時又不要把底層技術組件的複雜度暴露給業務功能的開發過程中。還有就是互聯網應用還涉及到外部技術服務能力的引入，如外部的郵件通知服務能力，地圖能力，支付能力，各個外部開放平台開發的各種內容提供服務能力引入等。對於外部服務能力的引入建議是要在技術平台層單獨進行管理和封裝，即在技術能力層有獨立和統一的服務代理。

最後是資料庫和持久化層，包括常見的關係資料庫，半結構化和基於key-value的redis，mongoDB等資料庫，還有就是完全基於hdfs的非結構化文件存儲能力。對於不同的業務場景和業務對象，往往需要底層不同的數據和存儲能力進行支撐，如何形成一個完整能力的資料庫服務能力層是架構設計時候需要考慮的。

去IOE化

對於去IOE化是這兩年互聯網架構設計談得最多的問題，即去掉小型機，集中存儲和商用資料庫。如果簡單來說下去IOE化的核心就是基於開源的類似Mysql資料庫和集群技術，通過X86伺服器硬體資源來實現和原來使用IOE架構時候同樣的性能和高可用性。在之前淘寶有開源的corba基於mysql資料庫來實現分散式資料庫和集群，現在有開源的MyCat來實現，核心就是提供一個DaaS服務層和封裝，來實現高性能和高可用的資料庫中間件產品。

對於去IOE的熱度在當前已經有所下降，這裡面有兩個原因一個是本身技術成熟度和CAP原則約束，一個方面的原因就是在去IOE和引入DaaS資料庫中間件後本身是增加了架構複雜度和應用開發難度。一個方面是由於DaaS層引入導入的分散式事務問題和對於跨庫查詢和Sql語句本身的約束增加。一個是在架構設計中就需要考慮前端業務如何進行組件化，業務對於的數據存儲如何進行分區和分片，究竟如何進行水平拆分和垂直拆分。

可以講在架構設計中的去IOE設計和前面講到的組件化和服務化設計思路密不可分，同時在去IOE下的組件化是徹底的組件化，即組件本身對應的資料庫也是獨立的，組件可以擁有完全獨立的硬體資源和全生命周期管理。因此如果組件沒有劃分，在後期業務功能實現中就可能導致大量的跨庫操作和分散式事務問題。這些都應該在架構設計階段就思考清楚並制定清晰的架構設計約束，任何架構設計都不會有普適性的通用架構存在，架構約束定義是一個架構要發揮其高效能力的關鍵。

去中心化

首先來看一個最簡單的場景，即客戶和請求端是A，服務提供端是B，對於服務提供端已經實現為了分散式集群即(B1,B2,B3...Bn)，在這種場景下可以看到對於請求會轉發不同的集群節點進行處理。但是對於這種分散式架構來看，集群是可以完全平滑彈性擴展的，但是問題關鍵點在於A的請求究竟應該轉發到哪個B節點去處理，這裡面就有一個控制層或管理節點，而對於大多數分散式應用來講管理節點本身是很難集群化擴展的。及時當前很多分散式架構實現過程中已經實現了消息請求和數據傳輸的分離，但是仍然存在對於管理節點無法水平擴展的問題。

對於水平彈性擴展問題的解決，往往會引入集群技術和硬體負載均衡，但是這不是一個完全意義上的去中心化架構，當前我們說的去中心化架構都是沒有統一的管理節點，完全分散式，只有在這種架構下才是完全的去中心化。要做到去中心化就涉及到幾個關鍵點的引入，一個是請求通過sdk包在客戶端的植入進行前移，即客戶端發起請求的時候就已經判斷清楚；其次是對於管理職責後移，即管理端後續重點是從各個集群節點准實時採集數據再進行分析。要實現第二點往往又涉及到高性能的消息中間件的引入。

從樓主題目里描述的背景出發，我的建議是這樣的：

對計算機這種工程學科，自學不一定不科學，但是要保持大量的實踐。
為一個成型的產品Troubleshooting是進入架構領域的好辦法。有一點必須強調：它不一定得是優秀的成熟產品。對善於總結的人來說，爛產品提供的反面教材從某種角度上看更加珍貴。
無論Troubleshooting經驗如何豐富，最終我們必須要得到自己設計的機會。這是從經驗積累落實到架構能力的唯一方法。如果條件許可，參與開源產品其實是個很好的機會（當然有的公司明令員工除非特許否則禁止參與開源項目，比如微軟）。

具體用什麼技術前面很多朋友都有精彩論述，我一做驅動的，就不多啰嗦了。

還有一點必須指出的是，儘管我也認同架構的重要性，但從樓主自己說的自學內容（目前屬於自學，設計模式，演算法導論，編譯原理，UML2.0等都在看）來看，我感覺樓主還沒搞明白架構師究竟是什麼。如今業界人人都在講架構，但所謂架構師細分起來實際上有很多種，即便只是算軟體行業經常要打交道的（也就是說晶元架構師不算），我見過的情況就包括如下：

網站基礎設施設計師。比如一個能承受百萬級訪問量的網站該如何配置伺服器等。這種架構師關注的是如何配置異地伺服器，如何分流請求，如果做負載均衡、備份和同步等等。
IT基礎設施設計師。這種架構師和網站基礎設施的架構師有一定交集，除此之外經常還需要考慮跟硬體有關的話題，比如機房空調溫度，UPS，帶寬升級等等。
軟體設施設計師。這種架構師經常要負責對軟體系統使用的部件做選擇，比如安全系統上使用的是Kerbero還是SSH，圖形系統選擇本地UI還是跨平台庫，網路協議或文件格式使用公開的標準還是自己設計等等。此類人往往還關心許多諸如性能、兼容性等方面的話題。
框架狂熱綜合症患者。此類「架構師」最喜歡的就是在一個項目里搞個所謂的類庫，裡面寫上一堆抽象類和介面，然後到處宣稱其類庫設計極其便於擴展云云並強迫同事負責實現其具體功能。另外，此類人的一個顯著特徵是對各種新框架或語言特性異乎尋常地熱衷，卻從不屑於實現一個真正具有能用功能的部件。

樓主希望自己成為架構師，這本身很好。但作為善意的提醒，我想樓主現在更需要搞清楚的是自己究竟希望成為哪一種架構師（我猜測更可能是第一種），然後才能針對性地去學習。無論如何，前三類架構師的共同特徵是他們都具備對各種實際功能代碼或硬體優缺點的知識，並且懂得如何根據項目需求（而非個人喜好）選擇合理的技術完成任務。甚至有時候一個頂尖的架構師必須同時理解三個不同的方向——換言之，架構師的知識廣度必須超過普通程序員。而至於第四種「架構師」，可能大家已經注意到我說到此類人時用了引號，因為恕我直言，在我看來他們只由兩類人組成：只會招搖撞騙的騙子，或是半桶水卻不自知的可憐蟲。

當然了，要做第四種顯然最容易，哈哈。

這是個非常好的問題。

我想說，題主的心態已經保證了其已經成功了一半。

剩下的，我不想去抄各個教程書籍裡面的大堆定義，因為以我的體驗來說，基本沒什麼用，例如什麼系統架構師，什麼需求分析師，什麼模塊、組件、介面等等，都是政治正確的廢話。

都正確，但是看了也白看，完全沒有幫助。

所以，我基於我的經驗給些建議吧。

第一、知識面要廣

其實我認為做架構師的，從來都是CTO儲備，因為需要涉及的能力太廣。

做架構，其實最簡單的理解就是一句話，就是在有各種限制的情況下想辦法解決問題。

所謂的限制就是性能、穩定性、開發效率、可維護性等因素。

例如，百度貼吧這種應用場景，每天可能有幾十億次的訪問，幾千萬甚至上億次的寫入。肯定是性能要求為先，可能為了做性能的提升犧牲一部分開發的效率。

再如，銀行的應用場景，不是非常在意用戶的體驗和訪問延遲，但是對於數據的安全性和一致性非常非常重視。這種時候，肯定是安全和穩定優先，性能後面考慮。

在限制中做權衡，也就是意味著要做大量的選擇。但做選擇那首先你得知道有哪些選擇。

所謂的性能和安全，除了這幾個字之外，具體的技術實施上，總得知道都有哪些方案吧。

1.例如java體系、php體系、c體系、還有python/nodejs/golang等，各自有各自的優勢劣勢，你總得有過相關開發經驗才能做出正確的選擇吧。道聽途說是沒有發言權的。

2.雖然現在資料庫用的最多的是mysql，但是oracle/pgsql也都有其優勢。

3.現在項目幾乎沒有不用到大數據的，那麼大數據的演算法至少得有些理解吧，大數據的平台得有些經驗吧。

4.玩轉整體項目還有許多許多的點，例如代碼如何管理、上線部署，如何測試保證bug率，系統的監控，伺服器部署，灰度發布等等。

不要聽那些一提架構師就好像多麼高大上，做的都是些設計師類似的工作，系統設計、軟體設計等。那些都是人云亦云YY出來的。

沒有哪個互聯網公司讓你去專門做設計，因為互聯網公司領導們統統無一例外需要都是功能的實現，戰略戰術想法的實現。

所有的大型系統架構，全部都是基於面臨的問題一步一步解決迭代出來的。沒有場景會讓人一步到位(甚至哪怕提前一段提前量)去設計一套牛逼系統的，因為世界變化太快，項目如果不趕緊實現，明天可能就掛了，哪有那些閑心去給未來幾年做設計。

所以，做架構師最關鍵的是對整個項目的把控能力，可以讓項目高效率的運轉。

第二、卓越的代碼能力

想要成為架構師，首先得是一個優秀的程序員。怎麼樣才算優秀的程序員呢？

光寫代碼不思考、不學習肯定是不行的。

最明確的，就是得深入掌握各類數據結構、各類設計模式、計算機網路、操作系統、各種常見的架構模式等。這些提的非常多，但是能做到深入理解的我感覺可能沒幾個人。

包括我自己，當年剛開始看設計模式的時候，1個多月就感覺已經全部理解了。但是之後每次或者複習的時候，或者看到寫的非常好的代碼的時候，重新去溫故此方面的知識，都能感到有新的收穫、都會有更深的領悟。

而且，理解也僅僅是開始。如何完完全全的融入自己的代碼中，才是關鍵。

寫代碼經常也同樣充斥著架構設計的感覺。其實我認為，程序員寫代碼叫編碼或coding，而架構師寫代碼就叫架構設計。

因為兩者寫代碼時考慮問題的角度完全不同。程序員可能更多考慮的是如何實現功能，而優秀的程序員才可能會考慮的例如性能、可讀性、可維護性的問題。

而這些對於架構師來說則是必須考慮的，考慮的緯度經常還會更多一些。

所以，不要想著一步到位的跳過優秀程序員而直接成為架構師。不現實。

第三、對某些相關領域要有深度

剛才講了技術的廣度，但是如果什麼都知道，但是什麼也不善長，沒有什麼精通的。那依然只能做個程序員。

那麼哪些領域算是關鍵的領域呢？

到此基本就由業務方向的不同而區分不同的架構師了。

例如金融領域的架構師，可能需要金融知識。

例如大數據領域，可能對hadoop/spark/hive之類的大數據領域知識要求深一些。

再如高並發領域，可能對整個系統的性能優化，分散式系統設計等更深入一些。

第四、要有技術洞見

這個技術洞見是借用《重新定義公司》里的詞。換個易理解的詞，就是技術上的遠見卓識。

以事後諸葛亮的方式舉幾個例子：

1.當年的京東如果選用的不是windows平台，可能發展比現在好不少。

2.百度如果不是李XX的目光短淺，總是比市場慢幾拍，現在也不致於被AT遠遠甩開。

這種事太多太多。

不要感覺好像很虛幻，如果你現在身為一個創業公司的架構師，你現在的一個貌似正確的決策可能直接導致未來公司的大量損失，甚至倒閉。

第五、管理能力

架構師少有不帶項目、不帶人的，所以管理能力肯定也是必須。

但管理能力是個很大的主題，這裡就不多說了。

這些就是我多年架構經驗的一些總結。謝謝。

————————————————————————

2017-7-19補充

回頭看看，其實我寫的也都是些方向性的東西。

但是由於架構師職業的特殊性，真的很難給出一條具體的道路，只要按照這個道路走下去就能成為優秀的架構師。

但有些原則性的方法還是有的：

我說過，作為架構師，其實所謂的設計能力並非關鍵，因為一個項目完全憑空設計的機會很少，而且也都可以基於當時情況的權衡，直接使用別人們的設計方案的組合。

這就是為什麼看架構師相關的帖子看多了，就會發現所謂的分散式架構、大型網站架構，基本來來回回就那麼幾種。導致是個人出來都能喊兩句架構怎樣怎樣。

那麼關鍵的是什麼？是項目的把控能力，以及面對具體問題的解決能力。

而要鍛煉項目的把控能力和解決一些具體問題的能力，有時候光靠公司里的項目是不夠的。

因為公司項目中你往往只是其中的一員，只是干某個具體的工作，例如前端js、app、後端業務等。項目整體的運轉情況你一般是了解不到的。即使運氣好，項目負責人對此的把控很到位，而且還願意全部講解給你聽，但畢竟很多環境你沒動手做出，光憑別人說是不大可能有深刻的理解的。

那怎麼辦？你應該自己抽空全新做一個自己的項目，例如一個BBS網站、一個有後台的app等。網站或app本身不重要，重要是你要自己開發、自己搞定上線系統、搞定監控系統、搞定發布系統、搞定測試系統等等。

就是像一個正式公司的正式產品一樣對待這個自己的項目。

這樣幾個回合下來之後，你就會發現，你對整個項目的感知度提高極大。不再像以前那樣，對項目除了自己負責的部分，其它都是迷迷糊糊的。

提升實力從點贊開始。

技術人員，最大的通病，就是就技術而技術，這個在初級階段很實用，也高效，但是，想真正做好架構師這個職位，一定要清楚產品，甚至如何運營，一個好的架構，一定是符合當下並可以在一定時間內不用重構的架構（最少為半年，互聯網的特點，不可能不重構，twitter之前披露的資料顯示他們平均半年重構一次架構）。
關於混合語言的問題。這個問題我覺得要辯證的看，混合不一定好，也不一定不好，關鍵是要看團隊的接受能力，單一語言的特點是整個團隊的執行效率高，維護成本低；混合語言的特點是軟體整體優，但維護成本和整個團隊的執行成本就會很高，架構師也應該有這方面的考慮。
學習，保持好奇心，按著「1000」考慮問題，按著「1024」設計架構，總有一天，會成長起來的

一句話概括的話，就是得犯過足夠多、足夠深刻的錯誤才行

稍微具體而言的話，架構設計一般有兩個層次

設計性能不敏感、或是低計算量的應用：這是個初級層級，在這個層次上的普遍思路是分解問題，然後通過組合各種「solver」來解決。架構師可以隨便翩翩起舞，使用各種「框架」、「類庫」，借鑒各種「模式」，發明各種「概念」（這些全部都是solver）。由於計算量低，所以最後總能「條條大路通羅馬」
性能極端敏感，計算密集的應用：這時候初級層次的很多經驗反而起反作用了。因為組合「solver」只能解決計算正確性目標，但不能解決性能目標。所以架構師需要能「腦內模擬」業務需要的必要數據流，然後充分利用（exploit）數據流的特性來儘可能地削減計算、避免瓶頸。這時演算法功底就尤為重要，很多第三方的「框架」、「庫」只有拆解以後「白盒利用」的意義。性能設計要優先於「代碼的封裝性」、「可讀性」、「可測試性」、「可管理性」以及「團隊可分工/協作性」（基本上軟體工程里的原則都要讓位於性能設計）

個人意見：作為一個「架構師」，最重要的兩點：
第一，也是最重要的一點是深刻理解業務規則和業務特點。忽略了這一點，做不出好軟體。
其次，是技術視野必須要寬，寬度甚至比深度更重要。不是用某種你諳熟的技術去解決業務問題，而是根據業務問題選擇合適的技術。

知道什麼可為不是要點，要點是知道什麼不可為。

要想成為一名架構師，你需要具備幾點素質，並且保持平衡。
1、技術能力，有一個方面很深入，然後又要有廣度。這點很重要，因為架構師所面臨的都是各種別人遇不到或待解決的場景。深度保證你能在某個方面是專家並能舉一反三的去保證你對其他技術方面理解和見解，廣度保證你的視野。切勿技術崇拜，Java.NetC++ ，MSIBM 都是在不同的方面你要了解的內容和工具。
2、管理能力，通常你要運用一個Team的能力去實現的架構，並保證。很好的計劃、組織、溝通是必備的。越高的架構職位，這方面就越重要。我們所說的主架則是技術和管理的最佳結合。
3、高情商，不要期待技術完美的架構。會有很多人、資金、現實情況的因素來決定你的架構，如果是技術唯論，通常你的架構是無效的。你會很鬱悶，並且無法實現。架構師的技術上最牛的地方就是綜合所有因素讓方案按照你的設想去實現，又讓所有人滿意。這意味著你是一個高情商的人。
4、最後如果作為一名應用架構師的話，首先你要做到業務專家，才能成為應用架構師。
所以呢，通常沒有8-10年你很難做到。只要你持續努力，自然水到渠成。

如何成為一個架構師？樓上好多各種理論了，來看看實際？

來看看架構師的簡歷理解下？我正好收到三個簡歷，來看看summary

還想知道什麼真實的情況？咱不搞虛的，就看fact。只要不違反保密的部分，都可以mock了給你看

最重要的是溝通能力。
1. 服眾。只有別人信服你，你的思路才能落地，才會有最終的產出。建立信任之前，你得先證明自己，不是以你最高大上的方式，而是以他們能聽懂的方式。
2. 開放。你是否聽得進別人的意見？是否能準確判斷別人的意見是否適合當前場景？如果不適合怎麼能讓對方覺察出你的專業與尊重？
3. 全面。架構師的核心能力之一是權衡。你需要通過溝通找出很多很多不同的、彼此衝突的訴求，然後對響應每個訴求的影響和效果如何、成長性如何，給出全面的評估。

所以，在你的書單中加上一本《語文》吧。

1 程序員不會因為寫了很多代碼就成為架構師，程序員和架構師之間有一道巨大的鴻溝。
2 如何填補這條鴻溝，先佔個坑。
====================================
還是講個故事吧。

故事發生在十年前，故事的主人公就叫老L吧，老L現在名副其實了，但是當時還不老，從一個和計算機毫不沾邊的專業跨行到一家做對日軟體外包的小公司做程序員已兩年。
和所有的外包公司中的低級程序員一樣，老L每天的工作就是對照著日文的式樣書需求寫代碼，代碼沒有什麼難度，對照著需求文檔和樣例代碼照葫蘆畫瓢就可以了。

老L之所以轉行做程序員，一則是因為本專業找工作實在是比較困難，二則是老L在學校的時候剛好趕上第一波互聯網熱，後來互聯網泡沫破裂了，但是編程改變人生，互聯網改變世界的念頭卻在老L的心中紮下根，念念不忘。
老L那時候的偶像是求伯君，是雷軍。雷軍那時候還是個程序員，人們也不叫他雷布斯，雷軍笑的時候很靦腆，老L覺得雷軍笑的時候象自己，老L覺得雷軍很酷，老L覺得自己應該也去做程序員。
為了順利轉行，老L在學校里選修了好幾門計算機軟體專業課，但是工作以後，每天都是重複而簡單的代碼，連最基本的數據結構都很難用到。
日子就這樣過了兩年，老L已經忘了雷軍，忘了編程改變命運，老L覺得程序員就是這個樣子，編程就是這樣，工作就是這樣，忙碌著重複，重複著忙碌。

然而，有些東西，只要曾經惦記過，即使後來自己都遺忘了，命運之神也會在某個不經意的時候去提醒你。
多年以後，老L在一部電影里看到一句台詞「念念不忘，必有迴響」，老L一瞬間就想到2005年的那個春天。

待續。。。

讓現任架構師來告訴你吧：
首先，你要付出你所有的業餘時間，用在閱讀大量書籍和鑽研最新技術上面，你要去掉你80%的興趣愛好，因為架構師是一個和世界IT新技術賽跑的瘋狂的職業。如果你每天下班後用於研究技術的時間少於2小時，那麼你必然無法成為一個優秀的架構師。先有了這個覺悟，至於後面具體學習些什麼，學習的順序，那都是次要的問題，上面各位說的都很全面了。

其次，你現在最需要做的就是找一個女朋友。因為如果你走上架構師這條路，你很可能沒有時間找女朋友了。

1. 心理準備：小公司可以作為實踐的最佳平台，大集團可以作為學習的平台。不要灰心。
2. 從小事做起：僅僅從狹隘的軟體系統架構來說，全部出自於實踐和對每一個細微環節的設計：小的設計組成大的架構，而這些小的設計有很多模式可以幫助你（設計模式）。因此即便你只是編寫一個計算器，也最好花精力去分析，設計。
3. 架構不是大而空的：面試的時候很多面試者都認為軟體三層架構就是架構了，實際上這很片面。架構實際上是由需求，團隊能力，開發周期（資金支持），版許可權制等一系列因素疊加影響的，沒有萬能架構，只有針對一個具體項目的架構，因此應當從以上的諸多方面去分析，我需要什麼樣子的設計。

舉個例子吧（當然，仍是相當籠統）。我有一個小的項目，就是一個基於 Web 的加減乘除計算器。首先這個需求很簡單，操作非常有限（10個左右），開發人員可能1-2個，今後可能追加其他操作，但是這些其他操作和現有操作關係不大。5天之內完成上線。
（1）那麼我會基於這些因素採用事務腳本的設計（請參見P of EAA）：
（1.1）這種設計的優點就是簡潔，開發速度快。容易處理這種數量不多，耦合不強的需求。這正適合我們。
（1.2）其缺點是在需求不斷增多的情況下容易產生冗餘代碼，由於我們對今後的需求和現階段的功能有所估計（數量有限，耦合不強），認為這個問題對此項目影響不大，於是這樣足以。
（2）而對於事物腳本的每一個操作，可以採用命令模式（Command Pattern）進行詳細設計。
（3）我的團隊開發人員均熟悉 .NET 下的開發，那麼我們從語言上選擇 C#， Framework 上可以選擇 http://ASP.NET MVC。
（4）這個項目的數據存儲要求非常有限，我們可以選擇用 MySQL 或者 SQLite 作為解決方案。

View(JQuery-UI, JQuery-UI mobile)
---------(JSON)-------
Controller (事務腳本支持-&>命令模式)
---------(http://ADO.NET Provider)---
Storage(MySQL, SQLite)

這個例子的每一個部分都可以再詳細劃分，最終形成一個整體的決策。

總之，請不要灰心浮躁，不論多大（多小）的軟體，每一個部分都影響著架構設計。設計好軟體的每一個部分即可。

自己經驗總結一下，優秀架構師應該從「四度」進行學習和提升，同時這也是優秀架構師應該具備的能力。

一、廣度

廣度指的是架構師應該對所在領域的主流技術體系有一個全面清晰的認識，每一種技術不需要很深入的了解，但必須知道每種技術的3W：

1，Why：每種技術的由來，為什麼會出現這種技術，這個技術是用來解決什麼問題的？

2，What：每種技術是什麼？技術的基本組成部分是什麼？

3，Which：解決同一問題的相同技術各自的優缺點是什麼，更適合哪種場景？比如，ORM框架（Hibernate與IBatis），MVC框架（Struts與SpringMVC），大數據技術（Hadoop與Spark）它們各自的優缺點是什麼，只有清晰認識同一類型技術的優缺點，才能在技術選型時能夠使用更加合理的技術。

廣度的學習方法：對各主流技術一一通過搜索引擎了解其3W的內容。

二、高度

高度指的是架構師應具備對客觀事物的「拔高」能力，能夠從紛繁雜亂的信息中建立秩序，也就是我們一般所說的抽象能力。抽象能力包括：

1，業務抽象：能夠軟體和產品的複雜的需求中抽象核心業務實體，並給各業務實體建立合理的關係；

2，技術抽象：能夠對複雜的技術架構進行分層抽象、服務抽象（微服務抽象）、組件抽象，並為各層和各服務之間的調用建立合理的「關係」；

高度的學習方法：深入理解和學習面向對象、設計模式，琢磨優秀開源框架的設計原理和設計思想。

三、深度

深度指的是架構師能對主流技術有較為深入的理解，主要包括：

1，可以不了解源代碼，但對主流技術的原理，運作機理有一個基本的理解；

2，至少對一種技術有深入的認識，是這種技術的專家，熟悉其源代碼

以上2點，1為必須，2為非必須

深度的學習方法：上文已說。

四、寬度

寬度指的是架構師能夠熟知當前的技術前沿和熱點，能夠使用新的技術解決問題。比如，微服務、大數據、雲計算、人工智慧等。

寬度的學習方法：可以使用手機訂閱相關的技術資訊了解，定期了解即可，對於跟所負責工作相關的技術進行進一步的了解。

小結：

廣度決定了系統架構技術選型的合理性；

高度決定了系統架構設計的合理性；

深度決定了系統架構的優化能力；

寬度決定了系統架構的領先性，不至於三五年被淘汰

以上，四度缺一不可。

有點文

2017-1-7

這是我在另外一個問題中的回答：
架構師的路到底怎麼走？ - 劉欣的回答

好的架構師除了自身技術能力外，眼光更加重要。對於創業公司而言，架構師需要能準確看到公司業務核心需要解決的問題，比如我們公司業務價值在於資訊和行情的速度，那麼最開始做架構的時候就花了非常大的精力去提升系統的實時性，比如投入人員去自動化整個信息發布流程，比如使用WebSocket代替有延遲的輪詢方案，同時又對低端設備準備好降級的替代方案等。而對於一般架構中比較重要的用戶系統，其實我們是等到公司開始涉及金融交易業務時才去將這一塊完善的。

個人愚見是，沒有什麼架構能解決所有問題，大公司的架構也未必能適合創業公司用，如果我們一開始就花精力去做用戶，去規劃分表分庫，系統本身固然會得到更好的擴展性，但是公司的發展速度卻會受阻。我總結創業公司做架構優先考慮的應該是用較低的成本滿足當前需求，並且保證一定的前瞻性就夠了。

個人覺得，有些方面的能力是天生的。
如果你想成為一個好的架構師，不是看幾本書，讀幾年書就能成為的。

我覺得好的架構師需要2個根本的，比較天生的能力（相對比較天生，但也是日積月累出來的）。

1、在項目的開發過程中，能很快的感覺到問題會發生在哪個環節。

當然，要做到這點，最主要靠的是經驗，其次才是意識，這個能力是必須的。不管什麼項目，對於進度影響最大的其實就是當問題突然的出現。我們或許規避不了問題，但我們可以有準備，在前期編碼，或下層代碼的開發過程中，針對可能出現的問題，做一些預備工作。

2、對於每個項目的責任心。

或許，這個是做任何事情都需要的一種，人身上必須要有的要素。
當問題發生時，第一時間，和同事一起去找問題，而不是推卸自身的責任。當你的同事，在架構內，開發進度緩慢、bug數量增加、經常抱怨時，你是否需要去詢問一下問題，分析一下是否是架構導致以上原因。

當然，架構師必須的當然是，寫上N年的代碼，這個誰都知道，就不必多說了。其他的，以上幾位已經講的很多了。

笨人拙見，祝我們一起奔向自己的未來。

首先真正的架構師沒有幾個，都是一般半桶水給自己臉上貼金，或者一些不入流的公司也要搞這種職位，先老老實實的在一線工作十年在說吧，而且工作內容還要涉及各個領域的，才有資格

不要太在意【架構師】這個字眼，在技術行業，保持對新技術的探索、求知慾望、積極的去思考，腳踏實地的去做產品（或項目），你會發現，原來所謂的架構師，不過如此