這篇文章更多的是從溝通角度分析架構(gòu)師的升級之道。但我們知道，架構(gòu)師更多是靠技術(shù)拿高薪。
在本文里，我將列些我見到的技術(shù)架構(gòu)平時需要解決的問題，有技術(shù)的，也有溝通協(xié)調(diào)方面的，以這些實實在在的案例，來列舉些技術(shù)架構(gòu)需要具備的技能，以此來分析下高級開發(fā)如何更高效地升級到技術(shù)架構(gòu)。好了，開場白結(jié)束，正文開始。
1 技術(shù)本身不產(chǎn)生價值，業(yè)務(wù)才會，論技術(shù)和業(yè)務(wù)的整合
一般會把架構(gòu)分為技術(shù)架構(gòu)和業(yè)務(wù)架構(gòu)，這里我無意對比這兩類的優(yōu)劣，但我只想說，在公司里，是靠業(yè)務(wù)價值創(chuàng)造盈利點的，所以技術(shù)，比如消息隊列，內(nèi)存優(yōu)化，以及分庫分表數(shù)據(jù)庫集群等，只有嵌入到業(yè)務(wù)里，才能通過提升業(yè)務(wù)的可擴展性或性能，從而產(chǎn)生價值。
上述似乎是廢話，但恰恰是架構(gòu)師工作的難點，大家可以想象一下，比如通過MyCat搭建個分庫分表架構(gòu)不難，甚至把分庫分表組件通過負載均衡搭建成集群也不難，這些網(wǎng)上都有現(xiàn)成的案例。但如何要在當(dāng)前的業(yè)務(wù)系統(tǒng)里實現(xiàn)分庫分表，難度就不小了。具體來講，因為業(yè)務(wù)系統(tǒng)里或許有冗余數(shù)據(jù)，而且有各類帶join, group by等的查詢語句，如何在分庫分表系統(tǒng)里兼容這些歷史問題，而且在上線新分庫系統(tǒng)后遷移歷史數(shù)據(jù)，又如，在產(chǎn)線切換到分庫分表時，萬一有問題如何回退，這些絕非是知道些Demo案例的高級開發(fā)能解決的問題。
所以在技術(shù)和業(yè)務(wù)方面，我自己的感受是（包括我見到的和聽到的） ：只有接觸到業(yè)務(wù)了，才能用技術(shù)解決實際問題，才能更了解這個技術(shù)用起來的各類坑，像剛才提到的分庫分表是這樣，其它的諸如日志組件，消息隊列組件都這樣。通過下面部分給出的架構(gòu)師平時要解決的實際問題的講述，大家能更深刻地體會到這點。
2 資深架構(gòu)師平時要解決的問題
如下的問題均是來源于實際，出于項目保密的原則，本人隱去了關(guān)鍵性的業(yè)務(wù)描述，但大家都能看懂，并能感受到架構(gòu)師平時要解決問題的難度。
問題一，A公司有財務(wù)管理人事管理等10個左右的項目，它們在產(chǎn)線上，需要標(biāo)準(zhǔn)化管理，比如用同一個Maven倉庫，不論功能業(yè)務(wù)如何，得用同一套配置管理服務(wù)，用同一套日志管理和分析組件，還得用同一套大數(shù)據(jù)組件來根據(jù)不同的業(yè)務(wù)維度來分析數(shù)據(jù)。
如果是重新搭建一套系統(tǒng)，這個難度也不小，更何況，對資深架構(gòu)師的要求是，在歷史項目的技術(shù)上做標(biāo)準(zhǔn)化管理，否則每個項目各管各的，維護成本大不算，不同項目間的庫還很容易產(chǎn)生沖突。架構(gòu)師要在保持業(yè)務(wù)穩(wěn)定的前提下實現(xiàn)這點，大家可以考慮下難度。
問題二，隨著B公司業(yè)務(wù)量的上升，數(shù)據(jù)庫里的數(shù)據(jù)達到了T級，所以需要通過分庫分表來實現(xiàn)優(yōu)化。這本身不難，但如何在升級的過程中保持業(yè)務(wù)的穩(wěn)定？不能說上個功能點，關(guān)鍵業(yè)務(wù)就掛了，而且，萬一上線后出現(xiàn)問題，得提供應(yīng)急的回退方案。
問題三，C公司是個創(chuàng)業(yè)型公司，剛開始的時候，通過SSM外加Oracle，能滿足大多數(shù)的業(yè)務(wù)需求，但隨著業(yè)務(wù)量的提升，需要資深架構(gòu)在短時間里實現(xiàn)針對高并發(fā)和大數(shù)據(jù)的方案，比如并發(fā)量高了，系統(tǒng)至少不能垮，而且針對每筆訂單，處理可以稍作延遲，但不能丟數(shù)據(jù)。
問題四，D公司需要在linux上搭建一套和產(chǎn)線一樣的測試環(huán)境，在平時的開發(fā)過程中，各業(yè)務(wù)組可以通過工具，在測試環(huán)境上部署或回退本項目的組件，這里，不僅要搭建測試環(huán)境，更要通過jenkins等工具給各業(yè)務(wù)組搭建一套能便捷部署系統(tǒng)的工具。
除了上述的問題之外，資深架構(gòu)更像一個救火隊員，比如在公司的業(yè)務(wù)體系里，任何一個團隊報出的和架構(gòu)相關(guān)的問題，比如調(diào)消息隊列有延遲，調(diào)分庫分表時報內(nèi)存OOM異常了，或者因Dubbo底層而導(dǎo)致的延遲或OOM，資深架構(gòu)得能親自或帶領(lǐng)手下解決具體的問題。
3 和高級開發(fā)相比，資深架構(gòu)一定得精通的技能（或素質(zhì)）
其實高級開發(fā)和資深架構(gòu)在需要掌握的技能方面，并沒太大的差別，具體而言，能幫助實現(xiàn)性能優(yōu)化的分布式組件和數(shù)據(jù)庫組件（或者叫中間件）也就這么多，linux下的操作命令也就這么些，一些系統(tǒng)管理的工具，比如Maven，Jenkins，ant等的用法也不難。但和高級開發(fā)相比，資深架構(gòu)的差別在于如下幾點。
1 資深架構(gòu)解決的問題種類和數(shù)量要比高級開發(fā)多很多，所謂神槍手得靠×××喂出來，有些問題，比如針對Kafka消息中間件的問題，資深架構(gòu)一看日志就知道該怎么改，或者一看log4j錯誤信息就知道和其它哪些類有沖突了，又如，在搭建線程池時遇到了OOM問題，資深架構(gòu)估計也能通過簡單地看日志，也能快速定位問題所在。
也就是說，資深架構(gòu)已經(jīng)積累了很多處理問題的經(jīng)驗，遇到一般問題時，無需再通過比較耗時的debug看問題根源，往往在腦子里已經(jīng)存儲了大量可能會導(dǎo)致問題的原因，再通過查看關(guān)鍵日志即可定位到具體的代碼點，然后就能很快地給出解決方案。
2 在給出解決方案時，比如要上個分布式redis集群，或者上個消息中間件，對高級開發(fā)而言，往往會有很多試錯的時間，比如上線后有某些功能點沒調(diào)通，得通過Debug或查日志來逐一解決問題，或上線某個基于python的大數(shù)據(jù)分析系統(tǒng)后，雖然能滿足基本的功能，但在某個場景（比如寫日志線程并發(fā)量太多）里，可能會導(dǎo)致OOM異常。
而對資深架構(gòu)來說，往往之前已經(jīng)做過同類事情，所以能避免很多坑（少了很多試錯成本和時間），而且由于對底層代碼比較熟悉，所以哪怕出現(xiàn)比較疑難的問題（比如不能穩(wěn)定重現(xiàn)），資深架構(gòu)能通過看日志很快定位到具體的底層類，（而高級開發(fā)一般對此就束手無策了）。相比之下，資深架構(gòu)的中流砥柱效應(yīng)就能體現(xiàn)出來。
3 資深架構(gòu)一般具有對各組件的差別非常了解，比如做分布式隊列，該先用Kafka還是rabbitMQ，或者搭建數(shù)據(jù)庫集群時，該用MySQL里的哪種引擎。
這樣，在選型時，由于知道了各種方案的優(yōu)缺點，所以能知道哪類方案更適合本業(yè)務(wù)系統(tǒng)，或者說，通過重寫哪類組件的底層代碼，能很快地搭建起滿足本系統(tǒng)的中間件組件。這點，高級開發(fā)未必能做到。
總結(jié)一下，資深架構(gòu)得對關(guān)鍵組件的底層非常了解，并且精通針對某些組件（比如消息組件，分庫組件）的實施和排查問題的能力，此外，資深架構(gòu)的基本功也得非常扎實。
1 debug能力就不用說了，得能熟練地通過linux命令，從各類日志中發(fā)現(xiàn)并解決問題。
2 無需了解所有組件的底層代碼（這太難了，也做不到），但需要了解一些常用組件的關(guān)鍵底層實現(xiàn)（比如Spring IOC或常用中間件） 方式，更得具備到組件內(nèi)部jar里debug排查問題的能力。
3 學(xué)習(xí)能力更不說了，和高級開發(fā)相比，資深架構(gòu)更得了解哪類組件該學(xué)，而且，每個組件內(nèi)部的知識太多，比如Kafka的知識就能寫至少一本書，對于資深架構(gòu)而言，首先需要用較短的時間了解該組件（比如kafka）的架構(gòu)以及和其它分布式組件（比如Flume）的整合方式，而且還得具備過濾知識的能力，即知道哪些知識不用學(xué)。這樣一旦有需求，就可以較快地搭建出系統(tǒng)原型骨架，隨后再逐步完善功能效果。
4 對于程序員而言，如何高效地升級到架構(gòu)或資深架構(gòu)？
當(dāng)我還處在一般開發(fā)和高級開發(fā)的中間水平時，我認(rèn)為我能很快地升級到架構(gòu)師的水平，所謂無知者無畏。當(dāng)我邁出升級的步伐時，剛開始，我突然發(fā)現(xiàn)升級的難度很大，從而無處下手，因為平時我缺乏實踐架構(gòu)師技能的實戰(zhàn)機會?，F(xiàn)在，通過一些努力，我雖然沒有自信說自己一定達到了架構(gòu)師的水平，但大多數(shù)架構(gòu)師能干的活，我勉強能做好。而且我平時也在不斷揣摩身邊技術(shù)架構(gòu)的思考方式和解決問題的方法，所以在這方面我自認(rèn)為給出的建議不會耽誤大家。
首先是鞏固自己基本功方面的建議。
1 學(xué)再多的視頻和材料，也不及動手實踐一個案例。
比如，大家在學(xué)習(xí)消息隊列時，一定得動手搭建個環(huán)境，最好用虛擬機模式分布式的場景，這時可能就有同學(xué)說了，環(huán)境太難搭建，怎么辦？自己查資料，這種動手能力對架構(gòu)師而言就屬于基本功，如果這也做不好，那么也沒希望升級到架構(gòu)師了。
類似這樣，大家可列個學(xué)習(xí)列表，網(wǎng)上升級到架構(gòu)師的系列視頻很多，質(zhì)量高的也不少，都是別人的經(jīng)驗之談，但如果就看理論，或者看關(guān)鍵點，這連架構(gòu)師的面試都通過不了，更何況做實際的架構(gòu)師的活。
2 平時不能畏難，一定得多解決問題。
在平時工作中，一定會出很多問題，而且不少是出在核心代碼和底層代碼里，這時就一定得通過看日志等方式去排查問題。 我知道，對很多想升級的高級開發(fā)而言，剛開始的時候一定很難，比如linux命令都不熟，或者效率很慢，別人都找出問題點了，自己才剛打開日志。其實大家都這樣過來的，多查多練，最多三個月，動手能力一定能提升。
3 得鍛煉自己在linux里（或在分布式環(huán)境里）部署系統(tǒng)部署組件的能力，尤其是部署集群的能力，在此基礎(chǔ)上，通過各種工具能進行壓力測試。
比如還是拿kafka來說，搭建好集群后，就可以用kafka自帶的Performance來做壓測。其實如果是自己練習(xí)，壓測的結(jié)果沒太大的意義，但這個流程走下來，一定能對搭建環(huán)境，使用工具和看日志等技巧就非常熟悉了。
4 盡量培養(yǎng)自己的調(diào)優(yōu)意識。說這個話很虛，具體而言，自己得能通過各種數(shù)據(jù)庫日志（比如各sql的運行時間）來找出長sql，并在此基礎(chǔ)上通過執(zhí)行計劃來優(yōu)化，又如，可以通過dump文件和GC日志來看虛擬機的內(nèi)存使用曲線，看內(nèi)存主要耗在哪些方面，如果是自己代碼沒寫好那還好辦，如果是耗在（中間件的）底層jar包里的代碼里，那也得知道解決方案。
以上只是架構(gòu)師所需要的基礎(chǔ)技能， 其實如果能真正做到上述4點的話，大家離開架構(gòu)師的水準(zhǔn)也不遠了，在此基礎(chǔ)上，大家還得繼續(xù)鍛煉整合的能力。
從縱向來講，需要進一步深化搭建集群的技能，比如能從底層代碼的角度，了解集群的組成方式，這樣的話，就能很清晰地了解到集群的擴展方式和性能調(diào)優(yōu)點。
從橫向來講，需要進一步了解多種組件的整合方式，比如系統(tǒng)如何同日志組件整合，大數(shù)據(jù)分析工具如何同日志組件整合等。
剩下的就是不斷積累經(jīng)驗技能了。
5 在升級路上，如何避免一些坑
我在平時還有機會接觸一些大神，這些其實都是大神們的經(jīng)驗之談。下面分享下在升級過程中應(yīng)當(dāng)避免哪些坑。
1 就像大家以前準(zhǔn)備政治考試時，先準(zhǔn)備大點，在保證大點不拉下的基礎(chǔ)上，再詳細復(fù)習(xí)每個大點里的細節(jié)。比如，可以先了解Spring Cloud里有哪些組件，比如Ribbon可以用來負載均衡，Hystrix可以用來容錯等，先把Spring Cloud里諸多組件先了解個大概，能用它們搭建成一個微服務(wù)體系后，再深入了解其中每個組件的細節(jié)，比如Spring Cloud Stream里Kafka配置細節(jié)。
但我經(jīng)過和多位架構(gòu)師溝通，他們在升級時，多少都在這方面走過彎路，我自己有時候也會不知不覺陷入技術(shù)細節(jié)之中，而忘記我學(xué)這個技術(shù)的初衷。這里給大家的建議是，在明確學(xué)習(xí)目標(biāo)后（比如要學(xué)Spring Cloud），剛開始別先自己閉門造車地為自己制定學(xué)習(xí)目標(biāo)，可以先借鑒現(xiàn)有的視頻講解等的學(xué)習(xí)路線。制定學(xué)習(xí)計劃時，以兩到三天為單位，給自己定好一個短期目標(biāo)，等到Spring Cloud組件全都了解后，再通過運行通若干個案例來深入了解組件的細節(jié)，這樣就能控制住自己的學(xué)習(xí)步驟。
2 千萬別理論和實際脫節(jié)。這似乎是廢話，但我見過很多高級開發(fā)，平時就看視頻和書，也不運行代碼，結(jié)果進步的速度很慢。
如果沒機會實踐架構(gòu)技能怎么辦？看自己組里有沒有架構(gòu)的活。如果也沒有怎么辦？（別嫌我啰嗦）回家自己準(zhǔn)備環(huán)境，按視頻里的搭建架構(gòu)環(huán)境。必要時，你甚至可以通過跳槽來換得一個架構(gòu)師的實踐機會。
3 架構(gòu)師可以是技術(shù)控，但絕不能是完美主義，畢竟解決方案得和實際業(yè)務(wù)切合，并得考慮解決問題的成本。而且，架構(gòu)師不能過于拘泥于細節(jié)，不能什么都事必躬親，很多時候，得給出方向，或者把問題拆分成開發(fā)能理解的子問題，然后讓手下人去干。 這似乎和技術(shù)沒有關(guān)系，這就要求架構(gòu)師更具備和人打交道的能力了，這點將在本文的第6部分詳細說明。
6 指導(dǎo)技術(shù)難于自己實現(xiàn)功能，再論資深架構(gòu)的協(xié)調(diào)（或者說扯皮）能力的煉成
不少開發(fā)者，尤其是資深開發(fā)者，或許都有這樣的體會，對于一些功能，我寧可自己做，而不是把它們拆分成若干個子功能再安排手下人去做?；蛘呶覍幙扇スタ艘恍┘夹g(shù)的難題，也不愿意去和人扯皮，從而去制定架構(gòu)里組件的選型方案。
可以這樣說，架構(gòu)師30%的價值來自他擁有的專業(yè)技能，30%的價值來自他分析和解決問題的能力，而40%的價值（甚至更高）來自于指導(dǎo)和協(xié)調(diào)能力。除去最后40%的價值，架構(gòu)師其實和高級開發(fā)沒什么差別。比如通過下面的例子，我們能看到架構(gòu)師為什么還得具備指導(dǎo)和協(xié)調(diào)的能力。
案例1：當(dāng)架構(gòu)師被要求改善本公司系統(tǒng)（比如是個應(yīng)用網(wǎng)站）的調(diào)用性能時，他就得和多個組打交道，往往是，有些組未必肯支持（畢竟現(xiàn)有系統(tǒng)用得不錯誰都不愿改），或者具體的改善點需要一些組來落實，這就相當(dāng)于增加該組的工作量了。
案例2：當(dāng)架構(gòu)師搭建好一套分布式緩存系統(tǒng)后，就得培訓(xùn)其它組的開發(fā)人員，讓他們合理使用這套系統(tǒng)。
案例3：又如架構(gòu)師幫一個組解決了一個典型的OOM問題后，得把解決這個問題的思路向其他組推廣，以便節(jié)省解決同類問題的時間。
從上述案例中，我們一定能感受到在溝通，協(xié)調(diào)方面架構(gòu)師需要掌握的技能水準(zhǔn)。這方面說難不難，多練就行，但對IT開發(fā)而言，動嘴要比動手寫代碼要難。下面也給出些提升“動嘴”能力的技巧。
1 首先得提升自己綜合邏輯思維的能力，這點可以靠多寫博客，甚至寫書來提升。其實寫的時候，就相當(dāng)于把自己要講的內(nèi)容用文字整理了一遍，這樣無形中也提升了自己綜合表達能力。
2 在組內(nèi)要多分享技術(shù)。其實剛開始分享時，一定不知道該說什么，甚至講完后沒人能懂（當(dāng)然自己一定能懂），但多講幾次后，口頭表達和與別人的交流能力也上去了。
3 在遇到和其它組交流時（比如聯(lián)調(diào)或溝通接口），一定得抓住機會多開口，剛開始的時候，估計很難讓別人能接受自己的觀點，或者自己有理也未必能講清楚，但經(jīng)過多次協(xié)調(diào)后，就能讓別人接受自己的觀點，或者大家能達成彼此能接受的妥協(xié)方案。
聯(lián)系客服
