我目前奮力在技術架構的路上不斷前行，雖然中間遇到很多障礙，目前自己感覺，勉強能達到架構師的級别，是以自己感覺還有底氣寫這篇文章。
但我們知道，架構師更多是靠技術拿高薪。
在本文裡，我将列些我見到的技術架構平時需要解決的問題，有技術的，也有溝通協調方面的，以這些實實在在的案例，來列舉些技術架構需要具備的技能，以此來分析下進階開發如何更高效地更新到技術架構。好了，開場白結束，正文開始。
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等的用法也不難。但和進階開發相比，資深架構的差别在于如下幾點。
第一，資深架構解決的問題種類和數量要比進階開發多很多，所謂神槍手得靠子彈喂出來，有些問題，比如針對Kafka消息中間件的問題，資深架構一看日志就知道該怎麼改，或者一看log4j錯誤資訊就知道和其它哪些類有沖突了，又如，在搭建線程池時遇到了OOM問題，資深架構估計也能通過簡單地看日志，也能快速定位問題所在。
也就是說，資深架構已經積累了很多處理問題的經驗，遇到一般問題時，無需再通過比較耗時的debug看問題根源，往往在腦子裡已經存儲了大量可能會導緻問題的原因，再通過檢視關鍵日志即可定位到具體的代碼點，然後就能很快地給出解決方案。
第二，在給出解決方案時，比如要上個分布式redis叢集，或者上個消息中間件，對進階開發而言，往往會有很多試錯的時間，比如上線後有某些功能點沒調通，得通過Debug或查日志來逐一解決問題，或上線某個基于python的大資料分析系統後，雖然能滿足基本的功能，但在某個場景（比如寫日志線程并發量太多）裡，可能會導緻OOM異常。
而對資深架構來說，往往之前已經做過同類事情，是以能避免很多坑（少了很多試錯成本和時間），而且由于對底層代碼比較熟悉，是以哪怕出現比較疑難的問題（比如不能穩定重制），資深架構能通過看日志很快定位到具體的底層類，（而進階開發一般對此就束手無策了）。相比之下，資深架構的中流砥柱效應就能展現出來。
第三，資深架構一般具有對各元件的差别非常了解，比如做分布式隊列，該先用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、總結，版權說明
本人不想把這篇文章寫成雞湯文，而且更想在文内增加盡量多的幹貨， 是以本文三易其稿。
寫完再回顧，感覺文内更多的是我見到的和我的感受，而且，本文從架構師所具備的技能入手，分析了架構師的高效更新方法，以及提升自己溝通能力的技巧，在每一個要點裡，都給了出具體的有可操作性的建議。
由于出自實際項目，是以自己感覺對大家多少有些幫助，如果大家有什麼問題，請通過留言說明。感謝大家本文。
![虛拟機---kafka的安裝[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)