架構師這個職位沒什麽神秘的，簡單點兒說就是用戶需求轉化成技術實現，只是在轉化的時候會遇到一系列問題，比如：技術如何選型？ 如何設計才更簡潔、更容易實現和擴展？如何滿足非功能性需求，如性能、安全、高可用性、審計......

除此之外，還得和客戶以及分析人員溝通需求，確保沒有跑偏，有時候還得引導一下，去除或者改變那些不可能實現的需求。

和程序員溝通，讓大家理解技術選型和設計，順利開展設計和編碼。

軟件架構師自身需要是程序員，並且必須一直堅持做一線程序員，還需要承接編程任務，如果不親身承受因系統設計而帶來的麻煩，就體會不到設計不佳所帶來的痛苦，接著就會逐漸迷失正確的設計方向。

軟件架構師不是一蹴而就的，是一個循序漸進的過程，是一個職責不斷擴大的過程。

刨除好奇心和對這個行業的熱愛， 我個人認為至少需要在這些方面進行發展：

一、掌握技術的原理

做一個架構師會涉及到很多技術，要求技術的廣度，如果掌握了原理，不但對技術認識深刻，學習新的東西就能迅速抓住本質。

計算機的基礎知識就不用說了， 網絡、操作系統、數據庫、編譯等， 相對枯燥，最好在大學階段完成。

你是Java開發方向發展， 至少要掌握這些應用層的東西：

• Kafka
• Mysql
• Tomcat
• Docker
• Spring
• MyBatis
• Nginx
• Netty
• Dubbo
• Redis
• Netty
• Spring cloud
• 分布式
• 高並發
• 性能調優
• 微服務
• .....

真是不少啊，關鍵是在應用層學習的時候，要多問為什麽？ 我建議你用這樣的句式： “因為有xxxx的問題，現有的xxx和xxxx解決不了，所有才出現了xxxx這個技術。”

當你在追尋這些技術的本源的時候，對一個技術的思考就會更加深刻，就能超越很多人。

那怎麽算把一個原理給掌握了呢？ 我認為標準就是你能用自己的語言給別人講出來，讓別人能理解。

二、獲取項目經驗和最佳實踐

只知道原理，還是紙上談兵，必須得做很多項目，在項目中去體會它們，應用它們，獲取一些最佳的實踐。

現在能從頭開始設計項目的機會不多了，作為初級程序員，只能從現有項目中去學習，去研究下系統中的網絡請求是怎麽走的？ 負載均衡是怎麽做的，四層還是七層？ 如果做的集群？如何做的復制？ ......

一定要努力地往上看，看到整個系統，看到端到端的流程，不能把自己局限在一畝三分地裏， 做一個認領工作，完成工作的HTML填空人員， 那樣路子真的就越走越窄了。

同樣，要多問為什麽， 在你通過自己或者求助別人探尋答案的時候，也許會發現現有設計的問題，這就是你的機會。

當你從局部慢慢走到整體以後，你的機會自然就越來越多，承擔的職責越來越大，話語權越來越重，離架構師越來越近。

三、鍛煉自己的抽象能力

寫程序是一件挺簡單的事情，把一個高中生拉來培訓一下，就能寫得像模像樣。

但是想寫好程序又是一件非常難的事情，因為系統越來越復雜，通過堆砌代碼的方式來實現，很快就幹不下去了，難度會成幾何級數增長。

解決這個問題的關鍵就是抽象，架構師得找到系統中那些不變的東西，把他們作為支點來架起整個系統的設計，升華一下就是一些正交、分層等思想。

通過把系統的組件劃分到不同維度，不同層次就可以實現封裝“變化”的目標。

這些思想從哪裏學習？ 怎麽內化成自己的能力？

• 一是從項目中來，我相信你的項目肯定有這些思想的體現，只是你去用心去發現。
• 二是閱讀書籍，閱讀源碼，看看牛人們是怎麽做的。
• 三是自己要總結思考，總有那麽一刻，你會頓悟： 啊，原來如此！

四、要發出自己的聲音

做開發的很多都是性格偏內向，喜歡和電腦打交道，但是想發展成架構師，只是悶頭幹活肯定是不行，必須得在小組內，部門內，公司內發出自己的聲音。

例如對於架構，設計，編碼，工程實踐，技術發展趨勢都能提出自己的見解，讓別人能信服、尊重你的意見，這樣才能成為自然的技術領導。

如果只是靠領導的任命或者威權來領導，那下屬可能要造反。

對了，這裏的“聲音”可以是小組討論，部門會議，緊急任務處理，技術演講，博客，客戶交流等等。

總之，等到你精通原理，能把基本的思想應用到項目中， 還能看到全局，有足夠的項目經驗，被別人尊重、信服，那架構師離你就近在咫尺。

有夢想就去追！

我的夢想是十年內成為架構師，該怎麽辦？