現在已經有確定的目標了，真不錯！很多人連自己的職業目標還沒有確定。
架構師這個職位沒什麼神祕的，簡單點兒說就是使用者需求轉化成技術實現，只是在轉化的時候會遇到一系列問題，比如：技術如何選型？ 如何設計才更簡潔、更容易實現和擴充套件？如何滿足非功能性需求，如效能、安全、高可用性、審計......
除此之外，還得和客戶以及分析人員溝通需求，確保沒有跑偏，有時候還得引導一下，去除或者改變那些不可能實現的需求。
和程式設計師溝通，讓大家理解技術選型和設計，順利開展設計和編碼。
軟體架構師自身需要是程式設計師，並且必須一直堅持做一執行緒序員，還需要承接程式設計任務，如果不親身承受因系統設計而帶來的麻煩，就體會不到設計不佳所帶來的痛苦，接著就會逐漸迷失正確的設計方向。
軟體架構師不是一蹴而就的，是一個循序漸進的過程，是一個職責不斷擴大的過程。
刨除好奇心和對這個行業的熱愛， 我個人認為至少需要在這些方面進行發展：
一、掌握技術的原理
做一個架構師會涉及到很多技術，要求技術的廣度，如果掌握了原理，不但對技術認識深刻，學習新的東西就能迅速抓住本質。
計算機的基礎知識就不用說了， 網路、作業系統、資料庫、編譯等， 相對枯燥，最好在大學階段完成。
你是Java開發方向發展， 至少要掌握這些應用層的東西：
- Kafka
- Mysql
- Tomcat
- Docker
- Spring
- MyBatis
- Nginx
- Netty
- Dubbo
- Redis
- Netty
- Spring cloud
- 分散式
- 高併發
- 效能調優
- 微服務
- .....
真是不少啊，關鍵是在應用層學習的時候，要多問為什麼？ 我建議你用這樣的句式： “因為有xxxx的問題，現有的xxx和xxxx解決不了，所有才出現了xxxx這個技術。”
當你在追尋這些技術的本源的時候，對一個技術的思考就會更加深刻，就能超越很多人。
那怎麼算把一個原理給掌握了呢？ 我認為標準就是你能用自己的語言給別人講出來，讓別人能理解。
二、獲取專案經驗和最佳實踐
只知道原理，還是紙上談兵，必須得做很多專案，在專案中去體會它們，應用它們，獲取一些最佳的實踐。
現在能從頭開始設計專案的機會不多了，作為初級程式設計師，只能從現有專案中去學習，去研究下系統中的網路請求是怎麼走的？ 負載均衡是怎麼做的，四層還是七層？ 如果做的叢集？如何做的複製？ ......
一定要努力地往上看，看到整個系統，看到端到端的流程，不能把自己侷限在一畝三分地裡， 做一個認領工作，完成工作的HTML填空人員， 那樣路子真的就越走越窄了。
同樣，要多問為什麼， 在你通過自己或者求助別人探尋答案的時候，也許會發現現有設計的問題，這就是你的機會。
當你從區域性慢慢走到整體以後，你的機會自然就越來越多，承擔的職責越來越大，話語權越來越重，離架構師越來越近。
三、鍛鍊自己的抽象能力
寫程式是一件挺簡單的事情，把一個高中生拉來培訓一下，就能寫得像模像樣。
但是想寫好程式又是一件非常難的事情，因為系統越來越複雜，通過堆砌程式碼的方式來實現，很快就幹不下去了，難度會成幾何級數增長。
解決這個問題的關鍵就是抽象，架構師得找到系統中那些不變的東西，把他們作為支點來架起整個系統的設計，昇華一下就是一些正交、分層等思想。
通過把系統的元件劃分到不同維度，不同層次就可以實現封裝“變化”的目標。
這些思想從哪裡學習？ 怎麼內化成自己的能力？
- 一是從專案中來，我相信你的專案肯定有這些思想的體現，只是你去用心去發現。
- 二是閱讀書籍，閱讀原始碼，看看牛人們是怎麼做的。
- 三是自己要總結思考，總有那麼一刻，你會頓悟： 啊，原來如此！
四、要發出自己的聲音
做開發的很多都是性格偏內向，喜歡和電腦打交道，但是想發展成架構師，只是悶頭幹活肯定是不行，必須得在小組內，部門內，公司內發出自己的聲音。
例如對於架構，設計，編碼，工程實踐，技術發展趨勢都能提出自己的見解，讓別人能信服、尊重你的意見，這樣才能成為自然的技術領導。
如果只是靠領導的任命或者威權來領導，那下屬可能要造反。
對了，這裡的“聲音”可以是小組討論，部門會議，緊急任務處理，技術演講，部落格，客戶交流等等。
總之，等到你精通原理，能把基本的思想應用到專案中， 還能看到全域性，有足夠的專案經驗，被別人尊重、信服，那架構師離你就近在咫尺。
有夢想就去追！
針對上面的Kafka、Mysql、Tomcat、Docker、Spring、MyBatis、Nginx、Netty、Dubbo、Redis、Netty、Spring cloud、分散式、高併發、效能調優、微服務等架構技術我給大家準備一些學習資料和學習視訊，如果你開發了1~5年，技術遇到了瓶頸，但是你又拒絕平庸，期待蛻變，我相信資料一定對你有用
資料領取方式：加入粉絲群963944895，私信管理員即可免費領取
