看下資深架構師平時須要解決的問題，對比你離資深架構師還有多少距離——再論技術架構的升級之路

    我目前奮力在技術架構的路上不斷前行，雖然中間遇到不少障礙，目前本身感受，勉強能達到架構師的級別，因此本身感受還有底氣寫這篇文章。

    以前，我寫過篇博文，架構師更多的是和人打交道，說說我見到和據說到的架構師升級步驟和平時的工做內容，這篇文章更多的是從溝通角度分析架構師的升級之道。但咱們知道，架構師更可能是靠技術拿高薪。

    在本文裏，我將列些我見到的技術架構平時須要解決的問題，有技術的，也有溝通協調方面的，以這些實實在在的案例，來列舉些技術架構須要具有的技能，以此來分析下高級開發如何更高效地升級到技術架構。好了，開場白結束，正文開始。

 --------------------------------------------------------------------------------------------------------------

1 技術自己不產生價值，業務纔會，論技術和業務的整合

      通常會把架構分爲技術架構和業務架構，這裏我無心對比這兩類的優劣，但我只想說，在公司裏，是靠業務價值創造盈利點的，因此技術，好比消息隊列，內存優化，以及分庫分表數據庫集羣等，只有嵌入到業務裏，才能經過提高業務的可擴展性或性能，從而產生價值。

    

    上述彷佛是廢話，但偏偏是架構師工做的難點，你們能夠想象一下，好比經過MyCat搭建個分庫分表架構不難，甚至把分庫分表組件經過負載均衡搭建成集羣也不難，這些網上都有現成的案例。但如何要在當前的業務系統裏實現分庫分表，難度就不小了。具體來說，由於業務系統裏或許有冗餘數據，並且有各種帶join, group by等的查詢語句，如何在分庫分表系統裏兼容這些歷史問題，並且在上線新分庫系統後遷移歷史數據，又如，在產線切換到分庫分表時，萬一有問題如何回退，這些絕非是知道些Demo案例的高級開發能解決的問題。

    因此在技術和業務方面，我本身的感覺是（包括我見到的和聽到的） ：只有接觸到業務了，才能用技術解決實際問題，才能更瞭解這個技術用起來的各種坑，像剛纔提到的分庫分表是這樣，其它的諸如日誌組件，消息隊列組件都這樣。經過下面部分給出的架構師平時要解決的實際問題的講述，你們能更深入地體會到這點。

2 資深架構師平時要解決的問題

    以下的問題均是來源於實際，出於項目保密的原則，本人隱去了關鍵性的業務描述，但你們都能看懂，並能感覺到架構師平時要解決問題的難度。

    

    問題一，A公司有財務管理人事管理等10個左右的項目，它們在產線上，須要標準化管理，好比用同一個Maven倉庫，不論功能業務如何，得用同一套配置管理服務，用同一套日誌管理和分析組件，還得用同一套大數據組件來根據不一樣的業務維度來分析數據。

    若是是從新搭建一套系統，這個難度也不小，更況且，對資深架構師的要求是，在歷史項目的技術上作標準化管理，不然每一個項目各管各的，維護成本大不算，不一樣項目間的庫還很容易產生衝突。架構師要在保持業務穩定的前提下實現這點，你們能夠考慮下難度。

    問題二，隨着B公司業務量的上升，數據庫裏的數據達到了T級，因此須要經過分庫分表來實現優化。這自己不難，但如何在升級的過程當中保持業務的穩定？不能說上個功能點，關鍵業務就掛了，並且，萬一上線後出現問題，得提供應急的回退方案。

    問題三，C公司是個創業型公司，剛開始的時候，經過SSM外加Oracle，能知足大多數的業務需求，但隨着業務量的提高，須要資深架構在短期裏實現針對高併發和大數據的方案，好比並髮量高了，系統至少不能垮，並且針對每筆訂單，處理能夠稍做延遲，但不能丟數據。

     問題四，D公司須要在linux上搭建一套和產線同樣的測試環境，在平時的開發過程當中，各業務組能夠經過工具，在測試環境上部署或回退本項目的組件，這裏，不只要搭建測試環境，更要經過jenkins等工具給各業務組搭建一套能便捷部署系統的工具。

     除了上述的問題以外，資深架構更像一個救火隊員，好比在公司的業務體系裏，任何一個團隊報出的和架構相關的問題，好比調消息隊列有延遲，調分庫分表時報內存OOM異常了，或者因Dubbo底層而致使的延遲或OOM，資深架構得能親自或帶領手下解決具體的問題。

3 和高級開發相比，資深架構必定得精通的技能（或素質）

    其實高級開發和資深架構在須要掌握的技能方面，並沒太大的差異，具體而言，能幫助實現性能優化的分佈式組件和數據庫組件（或者叫中間件）也就這麼多，linux下的操做命令也就這麼些，一些系統管理的工具，好比Maven，Jenkins，ant等的用法也不難。但和高級開發相比，資深架構的差異在於以下幾點。

    1 資深架構解決的問題種類和數量要比高級開發多不少，所謂神槍手得靠子彈喂出來，有些問題，好比針對Kafka消息中間件的問題，資深架構一看日誌就知道該怎麼改，或者一看log4j錯誤信息就知道和其它哪些類有衝突了，又如，在搭建線程池時遇到了OOM問題，資深架構估計也能經過簡單地看日誌，也能快速定位問題所在。

    也就是說，資深架構已經積累了不少處理問題的經驗，遇到通常問題時，無需再經過比較耗時的debug看問題根源，每每在腦子裏已經存儲了大量可能會致使問題的緣由，再經過查看關鍵日誌便可定位到具體的代碼點，而後就能很快地給出解決方案。

    2 在給出解決方案時，好比要上個分佈式redis集羣，或者上個消息中間件，對高級開發而言，每每會有不少試錯的時間，好比上線後有某些功能點沒調通，得經過Debug或查日誌來逐一解決問題，或上線某個基於python的大數據分析系統後，雖然能知足基本的功能，但在某個場景（好比寫日誌線程併發量太多）裏，可能會致使OOM異常。

    而對資深架構來講，每每以前已經作過同類事情，因此能避免不少坑（少了不少試錯成本和時間），並且因爲對底層代碼比較熟悉，因此哪怕出現比較疑難的問題（好比不能穩定重現），資深架構能經過看日誌很快定位到具體的底層類，（而高級開發通常對此就一籌莫展了）。相比之下，資深架構的中流砥柱效應就能體現出來。

    3 資深架構通常具備對各組件的差異很是瞭解，好比作分佈式隊列，該先用Kafka仍是rabbitMQ，或者搭建數據庫集羣時，該用MySQL裏的哪一種引擎。

    這樣，在選型時，因爲知道了各類方案的優缺點，因此能知道哪類方案更適合本業務系統，或者說，經過重寫哪類組件的底層代碼，能很快地搭建起知足本系統的中間件組件。這點，高級開發未必能作到。

    總結一下，資深架構得對關鍵組件的底層很是瞭解，而且精通針對某些組件（好比消息組件，分庫組件）的實施和排查問題的能力，此外，資深架構的基本功也得很是紮實。

    1 debug能力就不用說了，得能熟練地經過linux命令，從各種日誌中發現並解決問題。

    2 無需瞭解全部組件的底層代碼（這太難了，也作不到），但須要了解一些經常使用組件的關鍵底層實現（好比Spring IOC或經常使用中間件） 方式，更得具有到組件內部jar裏debug排查問題的能力。

    3 學習能力更不說了，和高級開發相比，資深架構更得了解哪類組件該學，並且，每一個組件內部的知識太多，好比Kafka的知識就能寫至少一本書，對於資深架構而言，首先須要用較短的時間瞭解該組件（好比kafka）的架構以及和其它分佈式組件（好比Flume）的整合方式，並且還得具有過濾知識的能力，即知道哪些知識不用學。這樣一旦有需求，就能夠較快地搭建出系統原型骨架，隨後再逐步完善功能效果。 

4 對於程序員而言，如何高效地升級到架構或資深架構？

     當我還處在通常開發和高級開發的中間水平時，我認爲我能很快地升級到架構師的水平，所謂無知者無畏。當我邁出升級的步伐時，剛開始，我忽然發現升級的難度很大，從而無處下手，由於平時我缺少實踐架構師技能的實戰機會。如今，經過一些努力，我雖然沒有自信說本身必定達到了架構師的水平，但大多數架構師能幹的活，我勉強能作好。並且我平時也在不斷揣摩身邊技術架構的思考方式和解決問題的方法，因此在這方面我自認爲給出的建議不會耽誤你們。

    首先是鞏固本身基本功方面的建議。

    1 學再多的視頻和材料，也不及動手實踐一個案例。

    好比，你們在學習消息隊列時，必定得動手搭建個環境，最好用虛擬機模式分佈式的場景，這時可能就有同窗說了，環境太難搭建，怎麼辦？本身查資料，這種動手能力對架構師而言就屬於基本功，若是這也作很差，那麼也沒但願升級到架構師了。

    相似這樣，你們可列個學習列表，網上升級到架構師的系列視頻不少，質量高的也很多，都是別人的經驗之談，但若是就看理論，或者看關鍵點，這連架構師的面試都經過不了，更況且作實際的架構師的活。

    2 平時不能畏難，必定得多解決問題。

    在平時工做中，必定會出不少問題，並且很多是出在核心代碼和底層代碼裏，這時就必定得經過看日誌等方式去排查問題。 我知道，對不少想升級的高級開發而言，剛開始的時候必定很難，好比linux命令都不熟，或者效率很慢，別人都找出問題點了，本身才剛打開日誌。其實你們都這樣過來的，多查多練，最多三個月，動手能力必定能提高。 

    3 得鍛鍊本身在linux裏（或在分佈式環境裏）部署系統部署組件的能力，尤爲是部署集羣的能力，在此基礎上，經過各類工具能進行壓力測試。

   好比仍是拿kafka來講，搭建好集羣后，就能夠用kafka自帶的Performance來作壓測。其實若是是本身練習，壓測的結果沒太大的意義，但這個流程走下來，必定能對搭建環境，使用工具和看日誌等技巧就很是熟悉了。

    4 儘可能培養本身的調優意識。說這個話很虛，具體而言，本身得能經過各類數據庫日誌（好比各sql的運行時間）來找出長sql，並在此基礎上經過執行計劃來優化，又如，能夠經過dump文件和GC日誌來看虛擬機的內存使用曲線，看內存主要耗在哪些方面，若是是本身代碼沒寫好那還好辦，若是是耗在（中間件的）底層jar包裏的代碼裏，那也得知道解決方案。

    以上只是架構師所須要的基礎技能， 其實若是能真正作到上述4點的話，你們離開架構師的水準也不遠了，在此基礎上，你們還得繼續鍛鍊整合的能力。

    從縱向來說，須要進一步深化搭建集羣的技能，好比能從底層代碼的角度，瞭解集羣的組成方式，這樣的話，就能很清晰地瞭解到集羣的擴展方式和性能調優勢。

    從橫向來說，須要進一步瞭解多種組件的整合方式，好比系統如何同日志組件整合，大數據分析工具如何同日志組件整合等。

    剩下的就是不斷積累經驗技能了。

5 在升級路上，如何避免一些坑

    我在平時還有機會接觸一些大神，這些其實都是大神們的經驗之談。下面分享下在升級過程當中應當避免哪些坑。

    1 就像你們之前準備政治考試時，先準備大點，在保證大點不拉下的基礎上，再詳細複習每一個大點裏的細節。好比，能夠先了解Spring Cloud裏有哪些組件，好比Ribbon能夠用來負載均衡，Hystrix能夠用來容錯等，先把Spring Cloud裏諸多組件先了解個大概，能用它們搭建成一個微服務體系後，再深刻了解其中每一個組件的細節，好比Spring Cloud Stream裏Kafka配置細節。

    但我通過和多位架構師溝通，他們在升級時，多少都在這方面走過彎路，我本身有時候也會不知不覺陷入技術細節之中，而忘記我學這個技術的初衷。這裏給你們的建議是，在明確學習目標後（好比要學Spring Cloud），剛開始別先本身閉門造車地爲本身制定學習目標，能夠先借鑑現有的視頻講解等的學習路線。制定學習計劃時，以兩到三天爲單位，給本身定好一個短時間目標，等到Spring Cloud組件全都瞭解後，再經過運行通若干個案例來深刻了解組件的細節，這樣就能控制住本身的學習步驟。

    2 千萬別理論和實際脫節。這彷佛是廢話，但我見過不少高級開發，平時就看視頻和書，也不運行代碼，結果進步的速度很慢。

    若是沒機會實踐架構技能怎麼辦？看本身組裏有沒有架構的活。若是也沒有怎麼辦？（別嫌我囉嗦）回家本身準備環境，按視頻裏的搭建架構環境。必要時，你甚至能夠經過跳槽來換得一個架構師的實踐機會。

    3 架構師能夠是技術控，但毫不能是完美主義，畢竟解決方案得和實際業務切合，並得考慮解決問題的成本。並且，架構師不能過於拘泥於細節，不能什麼都事必躬親，不少時候，得給出方向，或者把問題拆分紅開發能理解的子問題，而後讓手下人去幹。 這彷佛和技術沒有關係，這就要求架構師更具有和人打交道的能力了，這點將在本文的第6部分詳細說明。

6 指導技術難於本身實現功能，再論資深架構的協調（或者說扯皮）能力的煉成

    很多開發者，尤爲是資深開發者，或許都有這樣的體會，對於一些功能，我寧肯本身作，而不是把它們拆分紅若干個子功能再安排手下人去作。或者我寧肯去攻克一些技術的難題，也不肯意去和人扯皮，從而去制定架構裏組件的選型方案。 

    能夠這樣說，架構師30%的價值來自他擁有的專業技能，30%的價值來自他分析和解決問題的能力，而40%的價值（甚至更高）來自於指導和協調能力。除去最後40%的價值，架構師其實和高級開發沒什麼差異。好比經過下面的例子，咱們能看到架構師爲何還得具有指導和協調的能力。

    案例1：當架構師被要求改善本公司系統（好比是個應用網站）的調用性能時，他就得和多個組打交道，每每是，有些組未必肯支持（畢竟現有系統用得不錯誰都不肯改），或者具體的改善點須要一些組來落實，這就至關於增長該組的工做量了。

    案例2：當架構師搭建好一套分佈式緩存系統後，就得培訓其它組的開發人員，讓他們合理使用這套系統。

    案例3：又如架構師幫一個組解決了一個典型的OOM問題後，得把解決這個問題的思路向其餘組推廣，以便節省解決同類問題的時間。

    從上述案例中，咱們必定能感覺到在溝通，協調方面架構師須要掌握的技能水準。這方面說難不難，多練就行，但對IT開發而言，動嘴要比動手寫代碼要難。下面也給出些提高「動嘴」能力的技巧。

    1 首先得提高本身綜合邏輯思惟的能力，這點能夠靠多寫博客，甚至寫書來提高。其實寫的時候，就至關於把本身要講的內容用文字整理了一遍，這樣無形中也提高了本身綜合表達能力。

    2 在組內要多分享技術。其實剛開始分享時，必定不知道該說什麼，甚至講完後沒人能懂（固然本身必定能懂），但多講幾回後，口頭表達和與別人的交流能力也上去了。

    3  在遇到和其它組交流時（好比聯調或溝通接口），必定得抓住機會多開口，剛開始的時候，估計很難讓別人能接受本身的觀點，或者本身有理也未必能講清楚，但通過屢次協調後，就能讓別人接受本身的觀點，或者你們能達成彼此能接受的妥協方案。

7 總結，版權說明

    本人不想把這篇文章寫成雞湯文，並且更想在文內增長儘可能多的乾貨， 因此本文三易其稿。寫完再回顧，感受文內更多的是我見到的和個人感覺，並且，本文從架構師所具有的技能入手，分析了架構師的高效升級方法，以及提高本身溝通能力的技巧，在每個要點裏，都給了出具體的有可操做性的建議。

    因爲出自實際項目，因此本身感受對你們多少有些幫助，若是你們有什麼問題，或者須要看哪些方面的博文，請經過留言說明。

    本文在轉載前，請和做者說明，同時註明文章來源，同時給出本人寫的兩本書的鏈接Java Web輕量級開發面試教程和Java核心技術及面試指南。

     再次感謝你們讀完本文。