天天寫業務程式碼確實不一定能成為架構師，但是寫不好業務程式碼肯定不能成為架構師！

架構師寫程式碼的時間不超過工作時間的40%，剩餘的大部分時間主要與業務相關，每天參加各種各樣的KT會，只有徹底的理解了業務需求，才能設計好一套擴充套件性好，穩定性好，效能優異的架構！

不過大多數架構師還是先以寫程式碼做起的，不是說實現需求就是好程式碼，後期的擴充套件，使用者量激增對於系統的要求等都要考慮清楚！

那麼架構師通常需要哪些技術棧呢？

1，需求建模，流程圖：良好的流程圖模型是整個專案循序推進的一個導向，也是合理分配任務的好方法！

2，業務抽象：面向物件的思想，將需求抽象為一個個關鍵物件，一張張表，一對多，多對多等關係梳理清楚，這個時候就已經要注意後期業務擴充套件，技術擴充套件等因素！

3，技術選型：前後端分離？微服務框架（spring boot？dubbo）？服務間通訊方式（TPC，HTTP，MQ）？批處理服務？快取選擇，訊息中介軟體選擇？日誌收集與分析，資料儲存（mysql分庫分表？mongo），專案持續整合部署！

4，重難點突破：流程如何驅動？分散式事務如何保證資料一致？服務間通訊的安全問題？整個系統的可承載量！

5，任務分配，萬事大吉：架構師基本上不寫程式碼，設計多於建造，將任務合理的分配也是架構師需要考慮的東西，整合敏捷開發等，掌控整個專案的進度，直至整個專案的交付！

架構師真的不怎麼寫程式碼，但是各方面能力卻要要求很高，想要當架構師，還是先從寫業務程式碼開始吧！

這也是大部分程式設計師一直困惑的問題，因為他們心裡有數，光靠公司裡寫業務程式碼，是遠遠不能成為架構師的。

但是，一定要明白一點 好的架構師一定對公司專案的業務有比較深的瞭解，架構師不僅僅是技術上的選型，更要結合業務去利用技術。因為技術都擺在這個世界，架構師你不可能去發明這麼多中介軟體，但是卻可以根據需求組裝中介軟體。

因此，如果程式設計師想成為架構師，本人認為一定不能因為寫業務程式碼而磨滅這個想法，寫業務程式碼也可以提升自己的業務水平，對一款產品會有自己的理解，並且可以學習這套產品的架構師是什麼樣的架構思路。

然後自己在技術層面也要多向架構師去靠攏，這就意味著自己在工作之餘要不斷自學架構師應該具備的技術，而不能只靠公司裡工作的時間去學習去提升，這不現實。