作為一名工程師，我的目標一直都是成為一名架構師，從最開始對架構師盲目的崇拜以及對架構朦朧片面的認知，到現在對架構有一個初步的認知，並對成為架構師有了自己的規劃，工作 4 年半，雖然沒有太多的實踐與過厚的沉澱積累，但是自己算是有了清晰的方向，所以寫下來，和大家一起探討下，這篇文章沒有乾貨，丟一個話題出來，並記錄下此刻自己的認識。請各位看官，輕噴慢拍 ~~
架構這種東西本身就很虛，不像某個具體的框架，有實實在在的 API 與使用姿勢，而且也與自己的工作經歷與追求有關，窺不得系統全貌聊何架構，沒有資深的業務實戰經驗，又怎麼談得上架構實現。
什麼是架構
聊架構當然要先說清楚什麼是架構？
這個問題的標準答案在知乎上有更權威更專業的回答。這裡我只說說我自己的理解。
往大了說，架構是為了滿足具體的業務的發展而做出的一整套的解決方案。
太抽象了，那就掰開了說，架構是一套解決方案，是能夠滿足所承載的業務可以持續發展的解決方案，即包含軟體層面的框架鏈，當然包含硬體層面（目前不熟，暫時略過）。
軟體層面又區分出了大前端架構，後端架構，這些算是整個公司總的技術架構的子架構，為了能流暢的進行協同，這些子架構又必須遵守某一規範進行設計以及實現，只有這樣，才能在最終子架構之間進行整合的時候足夠的流暢，參與其中的開發同學才能足夠的輕鬆，個人感覺目前的很多公司都缺乏這麼一個擁有上帝視覺的總架構師來制定以及監督執行這一規範，導致的很多成立 N 年的公司依舊沒有太深的技術積累，每每有新需求，都是重頭開始進行前後端的技術選型，專案搭建，甚至每次整合釋出都要解決一遍之前遇到的問題 ~~
囉嗦一大堆，我要表達的核心思想就是：架構就是為了實現業務而為技術實現設計的藍圖，這張藍圖就是上述所說的解決方案和規範。
其實依舊很抽象，這就是源於自己積累不夠，不足以解釋的更加通俗，好在自己能理解到這裡，所以知道了自己缺什麼，也明白了下一步自己要往哪個方向走。
架構要做什麼
說了自己對架構的理解，這裡再說說自己對架構要做什麼的理解，這裡我從兩個方向進行表述：
業務方向
既然架構是為業務服務的，所以架構首要的功能就是為線上業務提供穩定的環境，不管你是直接使用了 N 多開源的框架整合後搭建的框架，還是輔以自研的框架，首先就是要能夠提供穩定環境。否則三天一小掛，五天一大癱，哪個業務能正常運營 ~~
所以架構首要的基礎就是: 穩
其次業務是由市場決定的，所以業務的變化是在所難免的，所以架構要做到的另外一個基本的點就是可擴充套件，甚至，最開始我們可以提供一個穩定但簡單的架構，只要這套架構擁有一定的擴充套件能力，那麼這套框架就可以隨著業務的發展而以一種漸進式的方式進行穩步的增強，滿足更多的業務場景，甚至提供更加強大靈活的擴充套件能力。
所以架構的另外一個基礎就是：可擴充套件
使用者方向
接下來是面向使用者了，任何一套架構完成搭建後，要真正的完成業務的承載還是離不開這我們這些長期奮戰在一線的開發同學們。所以架構設計與實現不可忽略的一點就是面向一線工程師友好，否則再牛批的架構也無法快速的響應市場的變化，快速的完成業務的佈局。
要達到面向一線工程師友好，第一點要做到新概念足夠少，這樣就需要做更多更高層級的封裝，其次逐步的提供更多圍繞架構核心提高開發部署效率的周邊系統平臺，框架，工具鏈，甚至是便於二次開發的 API.
所以在架構設計初期我們就需要把這些點都考慮進來，儘管不可能一步到位，至少要在規劃之內，拆分為若干季度的目標，一步步實現。
所以好架構基礎就必須能做到使用 高效、簡潔
如何成為架構師
說完了自己對架構的認識，我在聊聊自己對成為架構師的一些粗淺的想法：
第一步：既然架構是為了支撐業務的，那邊有必要在某一業務上（當然是自己感興趣的方向嘍）深入學習瞭解，不僅僅是為了更好的實現業務功能，更重要的是為了積累足夠多的樣本資料，這樣才能做到更加合理有價值的抽象，才有可能設計出好的框架，搭建更加強壯的架構，所以沒錯，好的架構師離不開對業務的積累！像我這個 level 的同學還是需要安心在自己的業務線上認真踏實的工作。
第二步：繼續深入學習技術基礎，多多閱讀各種設計規範，只有對使用的技術有更基礎的認知，才能做更出更合理的設計與封裝。同時在深入自己擅長的領域的同時，也要積極的擴充套件自己的知識邊界，建立更加完備的知識體系，這樣才能設計出擴充性足夠好的框架，搭建更加高效的架構。
第三步：虛心學習，業內已經有了足夠多優秀的框架了（業務型，工具型），雖然不一定能夠 100% 滿足各自公司的需求，但是依舊有很多值得借鑑的思想（設計模式），所以在深入業務領域的同時我們要想成為架構師，就要閱讀足夠多的框架原始碼，加油！
上面說的計劃那麼多，平時工作又那麼忙，怎麼辦？根據自己的節奏，保證本職工作的前提下，不放棄，持續學習，時間長了，終有所成。
切勿抱著一技之長而停止學習 ~~