你離架構師還有多遠？

　　軟件架構師在整個軟件開發過程當中都起着重要的做用，並隨着開發進程的推動而其職責或關注點不斷地變化，總結下面幾點。

　　在需求階段，軟件架構師主要負責理解和管理非功能性系統需求，好比軟件的可維護性、性能、複用性、可靠性、有效性和可測試性等等，此外，架構師還要常常審查客戶及市場人員所提出的需求，確認開發團隊所提出的設計；

　　在需求愈來愈明確後，架構師的關注點開始轉移到組織開發團隊成員和開發過程定義上；
　　在軟件設計階段，架構師負責對整個軟件體系結構、關鍵構件、接口和開發政策的設計；
　　在編碼階段，架構師則成爲詳細設計者和代碼編寫者的顧問，而且常常性地要舉行一些技術研討會、技術培訓班等；
　　隨着軟件開始測試、集成和交付，集成和測試支持將成爲軟件架構師的工做重點；
　　在軟件維護開始時，軟件架構師就開始爲下一版本的產品是否應該增長新的功能模塊進行決策。

　　在中國不缺程序員，缺的是高級架構師，先來看看二者的薪酬對比，就知道二者間的差距：

 

 　　但爲何在如此龐大的基數下，架構師的數量這麼少，中間差了什麼？對於普通程序員來講，成爲高級架構師的門檻主要有如下幾點：

一、錯誤的學習方法。在技術突飛猛進的今天，誰在單位時間學到的知識更多，誰的學習方法更高效，誰就得到更強的競爭優點。而不少程序員在工做中，還用着學校時的學習方法，很是低效，公司不是學校，啃書本的學習方法已再也不有效。

二、完整的知識體系。沒有造成系統化的知識架構，最重要的是不知道哪些技術須要重點掌握，學習時頻繁踩坑，最終浪費大量時間。

三、對編程的認知。頂級程序員和平庸程序員，本質區別是遇到問題時的思考方式，這就是所謂的頂級程序員思惟，一種高效解決問題的思惟方式。這種思惟方式，不是讀幾本Java書能學到的，而須要通過大量項目實戰，才能總結提煉出來。

四、差的學習環境。不少程序員的學習環境不好，在公司常常加班，工做幾年後，發現本身除了更熟悉公司業務外，能力沒有獲得半點提高，或週末基本不學習，而是出去玩。這麼差的自制力和學習環境，很難讓能力提到大的提高。

 　　上面四點，每一點都很是難作到，也正由於這樣，纔會出現平庸的程序員不少，架構師卻百裏挑一的現象。

　　那如何才能克服上面四點，成爲一名合格的Java架構師呢？

 　　俗話說「沒有見過好程序，怎麼可能寫出好程序」，一樣，也能夠說「不瞭解架構師的能力、工做，怎麼可能成爲架構師」，若是沒有接觸過頂級架構師，那你怎麼知道本身要往哪一個方向努力？因此，最好的方法是找個頂級架構師，去教你「高效的學習方法」、「完整的知識體系」和「對編程正確的認知」，讓他去督促你學習，爲你營造出「良好的學習環境」。

　　可是大牛很忙，不太可能單獨給你開小竈，更不可能天天都給你開1個小時的小竈；並且一個團隊裏面，若是大牛平時常常給你開小竈，不免會引發其餘團隊成員的疑惑，我我的認爲若是團隊裏的大牛若是真正有心的話，多給團隊培訓是最好的。然而作過培訓的都知道，準備一場培訓是很耗費時間的，課件和材料至少2個小時（還不能是碎片時間），講解1個小時，大牛們一個月作一次培訓已是很高頻了。

　　由於第一個緣由，因此通常要找大牛，都是帶着問題去請教或者探討。由於回答或者探討問題無需太多的時間，更多的是靠經驗和積累，這種狀況下大牛們都是很樂意的，畢竟影響力是大牛的一個重要指標嘛。然而也要特別注意：若是常常問那些書本或者google可以很容易查到的知識，大牛們也會很不耐煩的，畢竟時間寶貴。常常有網友問我諸如「jvm的-Xmn參數如何配置」這類問題，我都是直接回答「請直接去google」，由於這樣的問題實在是太多了，若是本身不去系統學習，每一個都要問是很是浪費本身和別人的時間的。

　　大牛很少，不太可能每一個團隊都有技術大牛，只能說團隊裏面會有比你水平高的人，即便他天天給你開小竈，最終你也只能提高到他的水平；而若是是跨團隊的技術大牛，因爲工做安排和分配的緣由，直接請教和輔導的機會是比較少的，單憑參加幾回大牛的培訓，是不太可能就成爲技術大牛的。

　　因此要想成爲技術大牛，首先仍是要明白「主要靠本身」這個道理，適當的時候能夠經過請教大牛或者和大牛探討來提高本身，但大部分時間仍是本身系統性、有針對性的提高。

　　既然java架構師，首先你要是一個高級java工程師，熟練使用各類框架，並知道它們實現的原理。

1. jvm虛擬機原理、調優，懂得jvm能讓你寫出性能更好的代碼；
2. 池技術，什麼對象池，鏈接池，線程池，java反射技術，寫框架必備的技術，可是有嚴重的性能問題，替代方案java字節碼技術；
3. nio，值得注意的是「直接內存」的特色，使用場景；
4. java多線程同步異步；
5. java各類集合對象的實現原理，瞭解這些可讓你在解決問題時選擇合適的數據結構，高效的解決問題，好比hashmap的實現原理，好多五年以上經驗的人都弄不清楚，還有爲什擴容時有性能問題？不弄清楚這些原理，就寫不出高效的代碼，還會認爲本身作的很對；總之一句話越基礎的東西越重要，不少人認爲本身會用它們寫代碼了，其實僅僅是知道如何調用api而已，離會用還差的遠。
6. 熟練使用各類數據結構和算法，數組、哈希、鏈表、排序樹...，就是一句話要麼是時間換空間要麼是空間換時間，這裏展開能夠說一大堆，須要有必定的應用經驗，用於解決各類性能或業務上的問題。

熟練使用linux操做系統，必備。

1. 熟悉tcp協議，建立鏈接三次握手和斷開鏈接四次握手的整個過程，不瞭解的話，沒法對高併發網絡應用作優化；
2. 熟悉http協議，尤爲是http頭，我發現好多工做五年以上的都弄不清session和cookie的生命週期以及它們之間的關聯。
3. 系統集羣、負載均衡、反向代理、動靜分離，網站靜態化。
4. 分佈式存儲系統nfs，fastdfs，tfs，Hadoop瞭解他們的優缺點，適用場景。
5. 分佈式緩存技術memcached，redis，提升系統性能必備，一句話，把硬盤上的內容放到內存裏來提速，順便提個算法一致性hash。
6. 工具nginx必備技能超級好用，高性能，基本不會掛掉的服務器，功能多多，解決各類問題。
7. 數據庫的設計能力，mysql必備，最基礎的數據庫工具，免費好用，對它基本的參數優化，慢查詢日誌分析，主從複製的配置，至少要成爲半個mysqldba。其餘nosql數據庫如mongodb。
8. 還有隊列中間件。如消息推送，能夠先把消息寫入數據庫，推送放隊列服務器上，由推送服務器去隊列獲取處理，這樣就能夠將消息放數據庫和隊列裏後直接給用戶反饋，推送過程則由推送服務器和隊列服務器完成，好處異步處理、緩解服務器壓力，解藕系統。

　　那成爲架構師所須要具有哪些技能？

　　架構師思考的是全局的東西，是如何組織你的系統，以達到業務要求，性能要求，具有可擴展性（scalability），可拓展性（extendability），先後兼容性等。可能涉及到的東西包括了從硬件到軟件的方方面面。

　　一個合格的架構師要耐得住寂寞，在同事不停的在打榮耀而你只能不停的學習，是踩着坑上位的，是無數次推翻以前本身設計 的 「狗屎」架構，無數第二天日夜夜加班而煉成的。

　　架構師不只要上知技術實現細節，並且還要會項目管理、設計理論、性能優化、熟練使用各類工具，爲公司各類業務提供技術支持，從前端到後臺再到數據庫、運維，哪裏須要去哪裏，還要一副好口才能睡服領導同事。

　　如今的架構師還要懂微服務、不會點分佈式、大數據技術、機器學習也會被鄙視的。

 

　　想成爲架構師不是懂了一大堆技術就能夠了，這些是解決問題的基礎、是工具，若是這些技術問題不懂怎樣作到，如何可以找到解決方案呢？這是成爲架構師的必要條件。
　　架構師還要針對業務特色、系統的性能要求提出能解決問題成本最低的設計方案才合格，人家一個幾百人用戶的系統，訪問量不大，數據量小，你給人家上集羣、上分佈式存儲、上高端服務器，爲了架構而架構，這是不可取的，因此總結兩點：架構師的做用就是第一知足業務需求，第二最低的硬件網絡成本和技術維護成本。
　　若是想要成爲一名優秀的架構師還須要根據業務發展狀況，提早預見發展到下一個階段系統架構的解決方案，而且設計當前架構時將架構的升級擴展考慮進去，作到易於升級;不然等系統瓶頸來了，出問題了再去出方案，或現有架構沒法擴展直接扔掉重作，或擴展麻煩問題一大堆，這會對企業形成損失。

大廠的大神還有以下的幾個建議：

　　首先是要多讀一些書，其中最基礎的是相似於重構和設計模式這種書，你須要知道不少小尺度級別上的問題解決技巧（若是你要作導演，你首先要作得是能熟練地把一個句子翻譯爲一組鏡頭），以及這些做者梳理問題的方式，反過來問一下本身，若是讓你來寫設計模式這本書，你有哪些知識點能夠寫？你如何組織這些知識點？如何讓你們接受你的觀點。

　　看完這兩本書以後，很是推薦你看一下 Martin Fowler 寫的《企業應用架構模式》和 Eric Evans 的《領域驅動設計》這類書，他能擴大你的視野，專一於更有意義的問題，而不是設計模式究竟有多少種這種缺少意義的問題。有一句話叫，「若是要成功，就要遠離那些廉價的娛樂」。相似的，對於軟件工程師來說，要想讓本身更強，就要遠離那些廉價的爭論（vim vs emacs, linux vs unix, redhat vs debian, 這些爭論其實並無太大的價值）。

　　其次，你要對大量開源軟件的實際特性有深刻的瞭解，容量究竟多大？高可用怎麼作？如何擴容？是否易維護？這些知識部分來自網上的各類測試和經驗文章，部分還要來自你的親手測試。做爲架構師，你的每個技術選型都是在挖坑，給你的開發、測試、運維團隊挖坑，而你的做用之一，就是保證你的團隊可以在你的幫助下從坑裏走出來。

　　另外，要解決不少大尺度的問題，你須要從不少同行去吸取經驗，我我的的經驗就是，閱讀每一年兩次 QCon 和 ArchSummit 架構相關的幻燈片，先只看題目和問題部分，本身想想解決方案是啥，而後再看一下演講者給出的解答，經過這種方式來淬鍊本身的思惟，豐富本身的工具箱。我想提醒的一點是，因爲軟件行業還遠不成熟，因此一個架構師會長期跟進一個項目，這就致使了一個架構師若是不主動去練習的話，一生也作不了幾個架構，至少相對於建築專業的結構工程師來說，咱們每一年的項目缺乏少不少。你作的架構越少，你就越容易自滿。

　　最後，我但願你是一個終身學習者，無論多忙，必定要規劃你的學習時間，一個星期也許不用太多，幾個小時便可，但這幾個小時必定要用在刀刃上，因此最好是哪些須要幾十個小時甚至更多時間才能弄清楚的課題，並且一直要堅持到這個課題結束。千萬不能是學一點這個概念，遇到新事物，就立刻轉移方向。若是你有這樣的習慣，我建議你先把新想法放到一個池子裏，等手邊的課題學習完，再到池子裏邊撈一個新課題來繼續學習。不過關於學習，這個是一個很大的話題，就不在這兒闡述了。

那如何學習呢？

　　如何掌握有效的學習方法呢，參考網友給的一些不錯的方法拿來分享，光看不用效果不好，怎麼辦？

例如：

1. 學習了jvm的垃圾回收，可是線上比較少出現FGC致使的卡頓問題，就算出現了，恢復業務也是第一位的，不太可能線上出現問題而後讓每一個同窗都去練一下手，那怎麼去實踐這些jvm的知識和技能呢？

2. Netty我也看了，也瞭解了Reactor的原理，可是我不可能參與Netty開發，怎麼去讓本身真正掌握Reactor異步模式呢？

3. 看了《高性能MySQL》，可是線上的數據庫都是DBA管理的，測試環境的數據庫感受又是隨便配置的，我怎麼去驗證這些技術呢？

4. 框架封裝了DAL層，數據庫的訪問咱們都不須要操心，咱們怎麼去了解分庫分表實現？

諸如此類問題還有不少，我這裏分享一下我的的經驗，其實就是3個詞：learning、trying、teaching！

1）Learning

　　這個是第一階段，看書、google、看視頻、看別人的博客均可以，但要注意一點是「系統化」，特別是一些基礎性的東西，例如JVM原理、Java編程、網絡編程，HTTP協議等等，這些基礎技術不能只經過google或者博客學習，個人作法通常是先完整的看完一本書全面的瞭解，而後再經過google、視頻、博客去有針對性的查找一些有疑問的地方，或者一些技巧。

2）Trying

　　這個步驟就是解答前面提到的不少同窗的疑惑的關鍵點，形象來講就是「本身動手豐衣足食」，也就是本身去嘗試搭建一些模擬環境，本身寫一些測試程序。例如：

1. Jvm垃圾回收：能夠本身寫一個簡單的測試程序，分配內存不釋放，而後調整各類jvm啓動參數，再運行的過程當中使用jstack、jstat等命令查看jvm的堆內存分佈和垃圾回收狀況。這樣的程序寫起來很簡單，簡單一點的就幾行，複雜一點的也就幾十行。

2. Reactor原理：本身真正去嘗試寫一個Reactor模式的Demo，不要覺得這個很難，最簡單的Reactor模式代碼量（包括註釋）不超過200行（能夠參考Doug Lee的PPT）。本身寫完後，再去看看netty怎麼作，一對比理解就更加深入了。

3. MySQL：既然有線上的配置能夠參考，那能夠直接讓DBA將線上配置發給咱們（注意去掉敏感信息），直接學習；而後本身搭建一個MySQL環境，用線上的配置啓動；要知道不少同窗用了不少年MySQL，可是連個簡單的MySQL環境都搭不起來。

4. 框架封裝了DAL層：能夠本身用JDBC嘗試去寫一個分庫分表的簡單實現，而後與框架的實現進行對比，看看差別在哪裏。

5. 用瀏覽器的工具查看HTTP緩存實現，看看不一樣種類的網站，不一樣類型的資源，具體是如何控制緩存的；也能夠本身用Python寫一個簡單的HTTP服務器，模擬返回各類HTTP Headers來觀察瀏覽器的反應。

　　還有不少方法，這裏就不一一列舉，簡單來講，就是要將學到的東西真正試試，才能理解更加深入，印第安人有一句諺語：I hear and I forget. I see and I remember. I do and I understand ，並且「試試」其實能夠比較簡單，不少時候咱們均可以本身動手作。

　　固然，若是可以在實際工做中使用，效果會更好，畢竟實際的線上環境和業務複雜度不是咱們寫個模擬程序就可以模擬的，但這樣的機會可遇不可求，大部分狀況咱們還真的只能靠本身模擬，而後等到真正業務要用的時候，可以信手拈來。

3）Teaching

　　通常來講，通過Learning和Trying，能掌握70%左右，但要真正掌握，我以爲必定要作到可以跟別人講清楚。由於在講的時候，咱們既須要將一個知識點系統化，也須要考慮各類細節，這會促使咱們進一步思考和學習。同時，講出來後看或者聽的人能夠有不一樣的理解，或者有新的補充，這至關於繼續完善了整個知識技能體系。

　　這樣的例子不少，包括我本身寫博客的時候常常遇到，原本我以爲本身已經掌握很全面了，但一寫就發現不少點沒考慮到；組內培訓的時候也常常看到，有的同窗寫了PPT，可是講的時候，你們一問，或者一討論，就會發現不少點尚未講清楚，或者有的點實際上是理解錯了。寫PPT、講PPT、討論PPT，這個流程所有走一遍，基本上對一個知識點掌握就比較全面了。

　　最後撒點雞湯，所謂學而時習之，溫故而知新，即便是架構師也須要不停的學習、思考，新的技術層出不窮，不變的是那顆不甘安逸的心。