中軟國際哈爾濱ETC：架構師的技術升級之路

這篇文章更多的是從溝通角度分析架構師的升級之道。但我們知道，架構師更多是靠技術拿高薪。

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

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

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！