一、技術本身不產生價值，業務才會，論技術和業務的整合

一般會把架構分為技術架構和業務架構，這裡我無意對比這兩類的優劣，但我只想說，在公司裡，是靠業務價值創造盈利點的，所以技術，比如訊息佇列，記憶體優化，以及分庫分表資料庫叢集等，只有嵌入到業務裡，才能通過提升業務的可擴充套件性或效能，從而產生價值。

上述似乎是廢話，但恰恰是架構師工作的難點，大家可以想象一下，比如通過MyCat搭建個分庫分表架構不難，甚至把分庫分表元件通過負載均衡搭建成叢集也不難，這些網上都有現成的案例。但如何要在當前的業務系統裡實現分庫分表，難度就不小了。具體來講，因為業務系統裡或許有冗餘資料，而且有各類帶join, group by等的查詢語句，如何在分庫分表系統裡相容這些歷史問題，而且在上線新分庫系統後遷移歷史資料，又如，在產線切換到分庫分表時，萬一有問題如何回退，這些絕非是知道些Demo案例的高階開發能解決的問題。

所以在技術和業務方面，我自己的感受是（包括我見到的和聽到的） ：只有接觸到業務了，才能用技術解決實際問題，才能更瞭解這個技術用起來的各類坑，像剛才提到的分庫分表是這樣，其它的諸如日誌元件，訊息佇列元件都這樣。通過下面部分給出的架構師平時要解決的實際問題的講述，大家能更深刻地體會到這點。

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

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

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

如果是重新搭建一套系統，這個難度也不小，更何況，對資深架構師的要求是，在歷史專案的技術上做標準化管理，否則每個專案各管各的，維護成本大不算，不同專案間的庫還很容易產生衝突。架構師要在保持業務穩定的前提下實現這點，大家可以考慮下難度。

問題二，隨著B公司業務量的上升，資料庫裡的資料達到了T級，所以需要通過分庫分表來實現優化。這本身不難，但如何在升級的過程中保持業務的穩定？不能說上個功能點，關鍵業務就掛了，而且，萬一上線後出現問題，得提供應急的回退方案。

問題三，C公司是個創業型公司，剛開始的時候，通過SSM外加Oracle，能滿足大多數的業務需求，但隨著業務量的提升，需要資深架構在短時間裡實現針對高併發和大資料的方案，比如併發量高了，系統至少不能垮，而且針對每筆訂單，處理可以稍作延遲，但不能丟資料。

問題四，D公司需要在linux上搭建一套和產線一樣的測試環境，在平時的開發過程中，各業務組可以通過工具，在測試環境上部署或回退本專案的元件，這裡，不僅要搭建測試環境，更要通過jenkins等工具給各業務組搭建一套能便捷部署系統的工具。

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

三、和高階開發相比，資深架構一定得精通的技能（或素質）

其實高階開發和資深架構在需要掌握的技能方面，並沒太大的差別，具體而言，能幫助實現效能優化的分散式元件和資料庫元件（或者叫中介軟體）也就這麼多，linux下的操作命令也就這麼些，一些系統管理的工具，比如Maven，Jenkins，ant等的用法也不難。但和高階開發相比，資深架構的差別在於如下幾點。

①. 資深架構解決的問題種類和數量要比高階開發多很多，所謂神槍手得靠子彈喂出來，有些問題，比如針對Kafka訊息中介軟體的問題，資深架構一看日誌就知道該怎麼改，或者一看log4j錯誤資訊就知道和其它哪些類有衝突了，又如，在搭建執行緒池時遇到了OOM問題，資深架構估計也能通過簡單地看日誌，也能快速定位問題所在。也就是說，資深架構已經積累了很多處理問題的經驗，遇到一般問題時，無需再通過比較耗時的debug看問題根源，往往在腦子裡已經儲存了大量可能會導致問題的原因，再通過檢視關鍵日誌即可定位到具體的程式碼點，然後就能很快地給出解決方案。

②. 在給出解決方案時，比如要上個分散式redis叢集，或者上個訊息中介軟體，對高階開發而言，往往會有很多試錯的時間，比如上線後有某些功能點沒調通，得通過Debug或查日誌來逐一解決問題，或上線某個基於python的大資料分析系統後，雖然能滿足基本的功能，但在某個場景（比如寫日誌執行緒併發量太多）裡，可能會導致OOM異常。而對資深架構來說，往往之前已經做過同類事情，所以能避免很多坑（少了很多試錯成本和時間），而且由於對底層程式碼比較熟悉，所以哪怕出現比較疑難的問題（比如不能穩定重現），資深架構能通過看日誌很快定位到具體的底層類，（而高階開發一般對此就束手無策了）。相比之下，資深架構的中流砥柱效應就能體現出來。

③. 資深架構一般具有對各元件的差別非常瞭解，比如做分散式佇列，該先用Kafka還是rabbitMQ，或者搭建資料庫叢集時，該用MySQL裡的哪種引擎。這樣，在選型時，由於知道了各種方案的優缺點，所以能知道哪類方案更適合本業務系統，或者說，通過重寫哪類元件的底層程式碼，能很快地搭建起滿足本系統的中介軟體元件。這點，高階開發未必能做到。

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

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

②. 無需瞭解所有元件的底層程式碼（這太難了，也做不到），但需要了解一些常用元件的關鍵底層實現（比如Spring IOC或常用中介軟體） 方式，更得具備到元件內部jar裡debug排查問題的能力。

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

四、對於程式設計師而言，如何高效地升級到架構或資深架構？

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

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

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

比如，大家在學習訊息佇列時，一定得動手搭建個環境，最好用虛擬機器模式分散式的場景，這時可能就有同學說了，環境太難搭建，怎麼辦？自己查資料，這種動手能力對架構師而言就屬於基本功，如果這也做不好，那麼也沒希望升級到架構師了。

類似這樣，大家可列個學習列表，網上升級到架構師的系列視訊很多，質量高的也不少，都是別人的經驗之談，但如果就看理論，或者看關鍵點，這連架構師的面試都通過不了，更何況做實際的架構師的活。

②. 平時不能畏難，一定得多解決問題。

在平時工作中，一定會出很多問題，而且不少是出在核心程式碼和底層程式碼裡，這時就一定得通過看日誌等方式去排查問題。 我知道，對很多想升級的高階開發而言，剛開始的時候一定很難，比如linux命令都不熟，或者效率很慢，別人都找出問題點了，自己才剛開啟日誌。其實大家都這樣過來的，多查多練，最多三個月，動手能力一定能提升。 

③. 得鍛鍊自己在linux裡（或在分散式環境裡）部署系統部署元件的能力，尤其是部署叢集的能力，在此基礎上，通過各種工具能進行壓力測試。

比如還是拿kafka來說，搭建好集群后，就可以用kafka自帶的Performance來做壓測。其實如果是自己練習，壓測的結果沒太大的意義，但這個流程走下來，一定能對搭建環境，使用工具和看日誌等技巧就非常熟悉了。

④. 儘量培養自己的調優意識。說這個話很虛，具體而言，自己得能通過各種資料庫日誌（比如各sql的執行時間）來找出長sql，並在此基礎上通過執行計劃來優化，又如，可以通過dump檔案和GC日誌來看虛擬機器的記憶體使用曲線，看記憶體主要耗在哪些方面，如果是自己程式碼沒寫好那還好辦，如果是耗在（中介軟體的）底層jar包裡的程式碼裡，那也得知道解決方案。

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

從縱向來講，需要進一步深化搭建叢集的技能，比如能從底層程式碼的角度，瞭解叢集的組成方式，這樣的話，就能很清晰地瞭解到叢集的擴充套件方式和效能調優點。

從橫向來講，需要進一步瞭解多種元件的整合方式，比如系統如何同日志元件整合，大資料分析工具如何同日志元件整合等。

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

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

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

①. 就像大家以前準備政治考試時，先準備大點，在保證大點不拉下的基礎上，再詳細複習每個大點裡的細節。比如，可以先了解Spring Cloud裡有哪些元件，比如Ribbon可以用來負載均衡，Hystrix可以用來容錯等，先把Spring Cloud裡諸多元件先了解個大概，能用它們搭建成一個微服務體系後，再深入瞭解其中每個元件的細節，比如Spring Cloud Stream裡Kafka配置細節。但我經過和多位架構師溝通，他們在升級時，多少都在這方面走過彎路，我自己有時候也會不知不覺陷入技術細節之中，而忘記我學這個技術的初衷。這裡給大家的建議是，在明確學習目標後（比如要學Spring Cloud），剛開始別先自己閉門造車地為自己制定學習目標，可以先借鑑現有的視訊講解等的學習路線。制定學習計劃時，以兩到三天為單位，給自己定好一個短期目標，等到Spring Cloud元件全都瞭解後，再通過執行通若干個案例來深入瞭解元件的細節，這樣就能控制住自己的學習步驟。

②. 千萬別理論和實際脫節。這似乎是廢話，但我見過很多高階開發，平時就看視訊和書，也不執行程式碼，結果進步的速度很慢。如果沒機會實踐架構技能怎麼辦？看自己組裡有沒有架構的活。如果也沒有怎麼辦？（別嫌我囉嗦）回家自己準備環境，按視訊裡的搭建架構環境。必要時，你甚至可以通過跳槽來換得一個架構師的實踐機會。

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

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

不少開發者，尤其是資深開發者，或許都有這樣的體會，對於一些功能，我寧可自己做，而不是把它們拆分成若干個子功能再安排手下人去做。或者我寧可去攻克一些技術的難題，也不願意去和人扯皮，從而去制定架構裡元件的選型方案。 

可以這樣說，架構師30%的價值來自他擁有的專業技能，30%的價值來自他分析和解決問題的能力，而40%的價值（甚至更高）來自於指導和協調能力。除去最後40%的價值，架構師其實和高階開發沒什麼差別。比如通過下面的例子，我們能看到架構師為什麼還得具備指導和協調的能力。

案例1：當架構師被要求改善本公司系統（比如是個應用網站）的呼叫效能時，他就得和多個組打交道，往往是，有些組未必肯支援（畢竟現有系統用得不錯誰都不願改），或者具體的改善點需要一些組來落實，這就相當於增加該組的工作量了。

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

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

從上述案例中，我們一定能感受到在溝通，協調方面架構師需要掌握的技能水準。這方面說難不難，多練就行，但對IT開發而言，動嘴要比動手寫程式碼要難。下面也給出些提升“動嘴”能力的技巧。

①. 首先得提升自己綜合邏輯思維的能力，這點可以靠多寫部落格，甚至寫書來提升。其實寫的時候，就相當於把自己要講的內容用文字整理了一遍，這樣無形中也提升了自己綜合表達能力。

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

③. 在遇到和其它組交流時（比如聯調或溝通介面），一定得抓住機會多開口，剛開始的時候，估計很難讓別人能接受自己的觀點，或者自己有理也未必能講清楚，但經過多次協調後，就能讓別人接受自己的觀點，或者大家能達成彼此能接受的妥協方案。

七、總結

本人不想把這篇文章寫成雞湯文，而且更想在文內增加儘量多的乾貨， 所以本文三易其稿。寫完再回顧，感覺文內更多的是我見到的和我的感受，而且，本文從架構師所具備的技能入手，分析了架構師的高效升級方法，以及提升自己溝通能力的技巧，在每一個要點裡，都給了出具體的有可操作性的建議。由於出自實際專案，所以自己感覺對大家多少有些幫助，如果大家有什麼問題，或者需要看哪些方面的博文，請通過留言說明。