阿里P7架構師帶你走向java架構師——你離架構師還多遠？
軟體架構師在整個軟體開發過程中都起著重要的作用，並隨著開發程序的推進而其職責或關注點不斷地變化，總結下面幾點。
在需求階段，軟體架構師主要負責理解和管理非功能性系統需求，比如軟體的可維護性、效能、複用性、可靠性、有效性和可測試性等等，此外，架構師還要經常審查客戶及市場人員所提出的需求，確認開發團隊所提出的設計；
在需求越來越明確後，架構師的關注點開始轉移到組織開發團隊成員和開發過程定義上；
在軟體設計階段，架構師負責對整個軟體體系結構、關鍵構件、介面和開發政策的設計；
在編碼階段，架構師則成為詳細設計者和程式碼編寫者的顧問，並且經常性地要舉行一些技術研討會、技術培訓班等；
隨著軟體開始測試、整合和交付，整合和測試支援將成為軟體架構師的工作重點；
在軟體維護開始時，軟體架構師就開始為下一版本的產品是否應該增加新的功能模組進行決策。
在中國不缺程式員，缺的是高階架構師，先來看看兩者的薪酬對比，就知道兩者間的差距：
但為什麼在如此龐大的基數下，架構師的數量這麼少，中間差了什麼？對於普通程式設計師來說，成為高階架構師的門檻主要有以下幾點：
1、錯誤的學習方法。在技術日新月異的今天，誰在單位時間學到的知識更多，誰的學習方法更高效，誰就獲得更強的競爭優勢。而很多程式員在工作中，還用著學校時的學習方法，非常低效，公司不是學校，啃書本的學習方法已不再有效。
2、完整的知識體系。沒有形成系統化的知識架構，最重要的是不知道哪些技術需要重點掌握，學習時頻繁踩坑，最終浪費大量時間。
3、對程式設計的認知。頂級程式設計師和平庸程式設計師，本質區別是遇到問題時的思考方式，這就是所謂的頂級程式設計師思維，一種高效解決問題的思維方式。這種思維方式，不是讀幾本Java書能學到的，而需要經過大量專案實戰，才能總結提煉出來。
4、差的學習環境。很多程式設計師的學習環境很差，在公司經常加班，工作幾年後，發現自己除了更熟悉公司業務外，能力沒有得到半點提升，或週末基本不學習，而是出去玩。這麼差的自制力和學習環境，很難讓能力提到大的提升。
上面四點，每一點都非常難做到，也正因為這樣，才會出現平庸的程式設計師很多，架構師卻鳳毛麟角的現象。
那如何才能克服上面四點，成為一名合格的Java架構師呢？
俗話說“沒有見過好程式，怎麼可能寫出好程式”，同樣，也可以說“不瞭解架構師的能力、工作，怎麼可能成為架構師”，如果沒有接觸過頂級架構師，那你怎麼知道自己要往哪個方向努力？所以，最好的方法是找個頂級架構師，去教你“高效的學習方法”、“完整的知識體系”和“對程式設計正確的認知”，讓他去督促你學習，為你營造出“良好的學習環境”。
但是大牛很忙，不太可能單獨給你開小灶，更不可能每天都給你開1個小時的小灶；而且一個團隊裡面，如果大牛平時經常給你開小灶，難免會引起其他團隊成員的疑惑，我個人認為如果團隊裡的大牛如果真正有心的話，多給團隊培訓是最好的。然而做過培訓的都知道，準備一場培訓是很耗費時間的，課件和材料至少2個小時（還不能是碎片時間），講解1個小時，大牛們一個月做一次培訓已經是很高頻了。
因為第一個原因，所以一般要找大牛，都是帶著問題去請教或者探討。因為回答或者探討問題無需太多的時間，更多的是靠經驗和積累，這種情況下大牛們都是很樂意的，畢竟影響力是大牛的一個重要指標嘛。然而也要特別注意：如果經常問那些書本或者google能夠很容易查到的知識，大牛們也會很不耐煩的，畢竟時間寶貴。經常有網友問我諸如“jvm的-Xmn引數如何配置”這類問題，我都是直接回答“請直接去google”，因為這樣的問題實在是太多了，如果自己不去系統學習，每個都要問是非常浪費自己和別人的時間的。
大牛不多，不太可能每個團隊都有技術大牛，只能說團隊裡面會有比你水平高的人，即使他每天給你開小灶，最終你也只能提升到他的水平；而如果是跨團隊的技術大牛，由於工作安排和分配的原因，直接請教和輔導的機會是比較少的，單憑參加幾次大牛的培訓，是不太可能就成為技術大牛的。
所以要想成為技術大牛，首先還是要明白“主要靠自己”這個道理，適當的時候可以通過請教大牛或者和大牛探討來提升自己，但大部分時間還是自己系統性、有針對性的提升。
既然java架構師，首先你要是一個高階java工程師，熟練使用各種框架，並知道它們實現的原理。
jvm虛擬機器原理、調優，懂得jvm能讓你寫出效能更好的程式碼；
池技術，什麼物件池，連線池，執行緒池，java反射技術，寫框架必備的技術，但是有嚴重的效能問題，替代方案java位元組碼技術；
nio，值得注意的是“直接記憶體”的特點，使用場景；
java多執行緒同步非同步；
java各種集合物件的實現原理，瞭解這些可以讓你在解決問題時選擇合適的資料結構，高效的解決問題，比如hashmap的實現原理，好多五年以上經驗的人都弄不清楚，還有為什擴容時有效能問題？不弄清楚這些原理，就寫不出高效的程式碼，還會認為自己做的很對；總之一句話越基礎的東西越重要，很多人認為自己會用它們寫程式碼了，其實僅僅是知道如何呼叫api而已，離會用還差的遠。
熟練使用各種資料結構和演算法，陣列、雜湊、連結串列、排序樹...，就是一句話要麼是時間換空間要麼是空間換時間，這裡展開可以說一大堆，需要有一定的應用經驗，用於解決各種效能或業務上的問題。
熟練使用linux作業系統，必備。
熟悉tcp協議，建立連線三次握手和斷開連線四次握手的整個過程，不瞭解的話，無法對高併發網路應用做優化；
熟悉http協議，尤其是http頭，我發現好多工作五年以上的都弄不清session和cookie的生命週期以及它們之間的關聯。
系統叢集、負載均衡、反向代理、動靜分離，網站靜態化。
分散式儲存系統nfs，fastdfs，tfs，Hadoop瞭解他們的優缺點，適用場景。
分散式快取技術memcached，redis，提高系統性能必備，一句話，把硬碟上的內容放到記憶體裡來提速，順便提個演算法一致性hash。
工具nginx必備技能超級好用，高效能，基本不會掛掉的伺服器，功能多多，解決各種問題。
資料庫的設計能力，mysql必備，最基礎的資料庫工具，免費好用，對它基本的引數優化，慢查詢日誌分析，主從複製的配置，至少要成為半個mysqldba。其他nosql資料庫如mongodb。
還有佇列中介軟體。如訊息推送，可以先把訊息寫入資料庫，推送放佇列伺服器上，由推送伺服器去佇列獲取處理，這樣就可以將訊息放資料庫和佇列裡後直接給使用者反饋，推送過程則由推送伺服器和佇列伺服器完成，好處非同步處理、緩解伺服器壓力，解藕系統。
那成為架構師所需要具備哪些技能？
架構師思考的是全域性的東西，是如何組織你的系統，以達到業務要求，效能要求，具備可擴充套件性（scalability），可拓展性（extendability），前後相容性等。可能涉及到的東西包括了從硬體到軟體的方方面面。
一個合格的架構師要耐得住寂寞，在同事不停的在打榮耀而你只能不停的學習，是踩著坑上位的，是無數次推翻之前自己設計 的 “狗屎”架構，無數次日日夜夜加班而煉成的。
架構師不僅要上知技術實現細節，而且還要會專案管理、設計理論、效能優化、熟練使用各種工具，為公司各種業務提供技術支援，從前端到後臺再到資料庫、運維，哪裡需要去哪裡，還要一副好口才能睡服領導同事。
歡迎工作一到五年的Java工程師朋友們加入Java架構開發：760940986
群內提供免費的Java架構學習資料（裡面有高可用、高併發、高效能及分散式、Jvm效能調優、Spring原始碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！
領取下面架構視訊資料！
效能調優專題：
常用框架原始碼分析：
B2C商城顯目實戰：
團隊協作開發專題：
微服務專題：
網際網路分散式架構專題：
學到這裡，你離架構師就不遠了！
當然，想成為架構師不是懂了一大堆技術就可以了，這些是解決問題的基礎、是工具，如果這些技術問題不懂怎樣做到，如何能夠找到解決方案呢？這是成為架構師的必要條件。
架構師還要針對業務特點、系統的效能要求提出能解決問題成本最低的設計方案才合格，人家一個幾百人使用者的系統，訪問量不大，資料量小，你給人家上叢集、上分散式儲存、上高階伺服器，為了架構而架構，這是不可取的，所以總結兩點：架構師的作用就是第一滿足業務需求，第二最低的硬體網路成本和技術維護成本。
如果想要成為一名優秀的架構師還需要根據業務發展情況，提前預見發展到下一個階段系統架構的解決方案，並且設計當前架構時將架構的升級擴充套件考慮進去，做到易於升級;否則等系統瓶頸來了，出問題了再去出方案，或現有架構無法擴充套件直接扔掉重做，或擴充套件麻煩問題一大堆，這會對企業造成損失。
大廠的大神還有如下的幾個建議：
首先是要多讀一些書，其中最基礎的是類似於重構和設計模式這種書，你需要知道很多小尺度級別上的問題解決技巧（如果你要做導演，你首先要做得是能熟練地把一個句子翻譯為一組鏡頭），以及這些作者梳理問題的方式，反過來問一下自己，如果讓你來寫設計模式這本書，你有哪些知識點可以寫？你如何組織這些知識點？如何讓大家接受你的觀點。
看完這兩本書之後，非常推薦你看一下 Martin Fowler 寫的《企業應用架構模式》和 Eric Evans 的《領域驅動設計》這類書，他能擴大你的視野，專注於更有意義的問題，而不是設計模式究竟有多少種這種缺乏意義的問題。有一句話叫，“如果要成功，就要遠離那些廉價的娛樂”。類似的，對於軟體工程師來講，要想讓自己更強，就要遠離那些廉價的爭論（vim vs emacs, linux vs unix, redhat vs debian, 這些爭論其實並沒有太大的價值）。
其次，你要對大量開源軟體的實際特性有深入的瞭解，容量究竟多大？高可用怎麼做？如何擴容？是否易維護？這些知識部分來自網上的各種測試和經驗文章，部分還要來自你的親手測試。作為架構師，你的每一個技術選型都是在挖坑，給你的開發、測試、運維團隊挖坑，而你的作用之一，就是保證你的團隊能夠在你的幫助下從坑裡走出來。
另外，要解決很多大尺度的問題，你需要從很多同行去吸收經驗，我個人的經驗就是，閱讀每年兩次 QCon 和 ArchSummit 架構相關的幻燈片，先只看題目和問題部分，自己想一想解決方案是啥，然後再看一下演講者給出的解答，通過這種方式來淬鍊自己的思維，豐富自己的工具箱。我想提醒的一點是，由於軟體行業還遠不成熟，所以一個架構師會長期跟進一個專案，這就導致了一個架構師如果不主動去練習的話，一輩子也做不了幾個架構，至少相對於建築專業的結構工程師來講，我們每年的專案缺少少很多。你做的架構越少，你就越容易自滿。
最後，我希望你是一個終身學習者，不管多忙，一定要規劃你的學習時間，一個星期也許不用太多，幾個小時即可，但這幾個小時一定要用在刀刃上，所以最好是哪些需要幾十個小時甚至更多時間才能弄清楚的課題，而且一直要堅持到這個課題結束。千萬不能是學一點這個概念，遇到新事物，就馬上轉移方向。如果你有這樣的習慣，我建議你先把新想法放到一個池子裡，等手邊的課題學習完，再到池子裡邊撈一個新課題來繼續學習。不過關於學習，這個是一個很大的話題，就不在這兒闡述了。
那如何學習呢？
如何掌握有效的學習方法呢，參考網友給的一些不錯的方法拿來分享，光看不用效果很差，怎麼辦？
例如：
學習了jvm的垃圾回收，但是線上比較少出現FGC導致的卡頓問題，就算出現了，恢復業務也是第一位的，不太可能線上出現問題然後讓每個同學都去練一下手，那怎麼去實踐這些jvm的知識和技能呢？
Netty我也看了，也瞭解了Reactor的原理，但是我不可能參與Netty開發，怎麼去讓自己真正掌握Reactor非同步模式呢？
看了《高效能SQL/">MySQL》，但是線上的資料庫都是DBA管理的，測試環境的資料庫感覺又是隨便配置的，我怎麼去驗證這些技術呢？
框架封裝了DAL層，資料庫的訪問我們都不需要操心，我們怎麼去了解分庫分表實現？
諸如此類問題還有很多，我這裡分享一下個人的經驗，其實就是3個詞：learning、trying、teaching！
1）Learning
這個是第一階段，看書、google、看視訊、看別人的部落格都可以，但要注意一點是“系統化”，特別是一些基礎性的東西，例如JVM原理、Java程式設計、網路程式設計，HTTP協議等等，這些基礎技術不能只通過google或者部落格學習，我的做法一般是先完整的看完一本書全面的瞭解，然後再通過google、視訊、部落格去有針對性的查詢一些有疑問的地方，或者一些技巧。
2）Trying
這個步驟就是解答前面提到的很多同學的疑惑的關鍵點，形象來說就是“自己動手豐衣足食”，也就是自己去嘗試搭建一些模擬環境，自己寫一些測試程式。例如：
Jvm垃圾回收：可以自己寫一個簡單的測試程式，分配記憶體不釋放，然後調整各種jvm啟動引數，再執行的過程中使用jstack、jstat等命令檢視jvm的堆記憶體分佈和垃圾回收情況。這樣的程式寫起來很簡單，簡單一點的就幾行，複雜一點的也就幾十行。
Reactor原理：自己真正去嘗試寫一個Reactor模式的Demo，不要以為這個很難，最簡單的Reactor模式程式碼量（包括註釋）不超過200行（可以參考Doug Lee的PPT）。自己寫完後，再去看看netty怎麼做，一對比理解就更加深刻了。
MySQL：既然有線上的配置可以參考，那可以直接讓DBA將線上配置發給我們（注意去掉敏感資訊），直接學習；然後自己搭建一個MySQL環境，用線上的配置啟動；要知道很多同學用了很多年MySQL，但是連個簡單的MySQL環境都搭不起來。
框架封裝了DAL層：可以自己用JDBC嘗試去寫一個分庫分表的簡單實現，然後與框架的實現進行對比，看看差異在哪裡。
用瀏覽器的工具檢視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，這個流程全部走一遍，基本上對一個知識點掌握就比較全面了。
最後撒點雞湯，所謂學而時習之，溫故而知新，即使是架構師也需要不停的學習、思考，新的技術層出不窮，不變的是那顆不甘安逸的心。
歡迎工作一到五年的Java工程師朋友們加入Java架構開發：760940986
群內提供免費的Java架構學習資料（裡面有高可用、高併發、高效能及分散式、Jvm效能調優、Spring原始碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！