架构师画像
架構(gòu)師，這個title就和總監(jiān)之類的title一樣，已經(jīng)徹底被用爛了，但在一個軟件產(chǎn)品的生命周期中，架構(gòu)師是實實在在的一個極度重要的角色，這篇文章就來講講我覺得的架構(gòu)師的畫像，到底具備什么素質(zhì)的同學是貼合架構(gòu)師形象的，同時歡迎大家回復下在你心目中NB的架構(gòu)師的畫像是怎么樣的呢。
?
業(yè)務理解和抽象能力
架構(gòu)師的第一職責是理解業(yè)務，并轉(zhuǎn)換為可被研發(fā)理解的實現(xiàn)方案，因此業(yè)務理解能力是架構(gòu)師的必備技能，通常來說一個資深的業(yè)務架構(gòu)師，對業(yè)務會有非常深的認識和積累，一個極好的業(yè)務架構(gòu)師應該能大概預判業(yè)務未來的發(fā)展趨勢，以便在系統(tǒng)的可擴展性上留好一定的空間，所以也會很自然的出現(xiàn)有些業(yè)務架構(gòu)師做著做著就干脆轉(zhuǎn)為PD類型的角色。
抽象能力是通過對業(yè)務的理解轉(zhuǎn)換為系統(tǒng)實現(xiàn)的模型，這顯然也是重要的能力，抽象很多時候也承擔了分解清楚多個團隊的職責，分工清晰化。
?
NB的代碼能力
之所以現(xiàn)在很多的架構(gòu)師都會被認為是大忽悠，就是有一堆頂著架構(gòu)師頭銜，又不干活的人（甚至會出現(xiàn)對技術(shù)幾乎不太懂的人），光說不干，再加上說的不靠譜的話自然很容易被認為是大忽悠，就我自己而言，我一直認為架構(gòu)師有個非常重要的職責是編寫整個系統(tǒng)中核心部分的代碼，這個部分并不一定是技術(shù)挑戰(zhàn)最高的，但對整個系統(tǒng)的質(zhì)量/成敗與否是具備非常關(guān)鍵的控制作用的，所以架構(gòu)師必須是從寫核心代碼的人中誕生出來的。
在一個跨多領(lǐng)域的大型系統(tǒng)中，架構(gòu)師不太可能什么都擅長，不可能寫各個部分的核心代碼，這種時候架構(gòu)師一定要知道怎么判斷非自己知識領(lǐng)域的部分實現(xiàn)是否OK，以確保各部分組合在一起的時候是符合架構(gòu)設計預期的，通常這種確保各部分組織在一起work的機制部分的代碼應該由架構(gòu)師自己操刀。
?
全面
全面是一個架構(gòu)師展現(xiàn)出來的最關(guān)鍵素質(zhì)，全面會體現(xiàn)在三點上：
1. 在面對業(yè)務問題上，架構(gòu)師腦海里是否會浮現(xiàn)出多種技術(shù)方案，這點其實挺重要的，否則可能就會出現(xiàn)明明有一個簡單成熟的方案，但由于不知道而做了其他復雜不成熟的方案，所以廣闊的技術(shù)視野是架構(gòu)師的必備，另外架構(gòu)師不可能全部擅長，在自己不擅長的點上，需要知道找哪個專業(yè)的人是靠譜的，這點也非常重要；
2. 在做系統(tǒng)設計時是否考慮到了足夠多的方方面面：
? ?例如很多系統(tǒng)設計容易遺漏上線環(huán)節(jié)的細節(jié)，導致在上線時發(fā)現(xiàn)漏掉了什么考慮，臨時解決或只能重來，記得有一年我做的一個設計沒有考慮到上線階段的一個細節(jié)，導致上線的時候發(fā)現(xiàn)由于網(wǎng)段的問題完全不work，并且沒有臨時解決方案，只好重來，系統(tǒng)設計不僅僅指導研發(fā)同學怎么寫代碼，也包括指導其他所有相關(guān)技術(shù)同學的工作；
? ?又例如我2008年在做服務框架設計的時候，集群和集群之間通過硬件負載均衡設備來訪問的，連接的方式是單個長連接，這個設計導致了運行過程中如果要發(fā)布被調(diào)用的服務方，很容易出現(xiàn)壓力都集中在前面重啟的機器上，這也是典型的整個鏈路沒有考慮清楚造成的設計問題；
? ?再例如2013年我在做一個比較大范圍的系統(tǒng)改造的設計時，由于對其中一部分的軟件了解的不夠，判斷錯誤，導致后來這個改造在進行過程中才發(fā)現(xiàn)有些需要改造的關(guān)鍵軟件的設計做的太粗糙，最后上線進度差不多推遲了一個多月，而且那些后來補的設計都是緊急做的，風險非常高；
? ?回顧自己設計過的軟件，發(fā)現(xiàn)在這個點上犯的錯可以講好幾天，看來我應該整理另外一篇文檔《我在系統(tǒng)設計上犯過的xxx個錯誤》，里面有些其實靠一份好的系統(tǒng)設計模板也許就能避免掉，一份好的系統(tǒng)設計模板是可以幫助架構(gòu)師思考全面些的。
3. 在做系統(tǒng)設計時是否考慮到了未來的一些發(fā)展，盡可能不要出現(xiàn)未來的一點變化就導致現(xiàn)在白干或要花大量力氣來改造的現(xiàn)象，想當年做服務框架的時候，后來就發(fā)現(xiàn)由于當年做設計的時候沒有考慮到將來服務調(diào)用trace的問題，導致了后來為了彌補這點花了巨大的力氣（不是技術(shù)上，而是實施上）。
全面需要架構(gòu)師有足夠廣的技術(shù)領(lǐng)域知識和足夠多的經(jīng)驗積累，從全面這點就可以看到架構(gòu)師的工作絕不是畫幾個框，連幾根線那么簡單。
對架構(gòu)師全面這點的挑戰(zhàn)，會隨著系統(tǒng)的范圍越大（一個系統(tǒng)的設計，和100個系統(tǒng)組成的大系統(tǒng)的設計挑戰(zhàn)是完全不同的）而變得越難，無論是知識的廣度、考慮的點的覆蓋度、還是未來趨勢，更復雜的情況甚至會出現(xiàn)架構(gòu)的調(diào)整對應著組織結(jié)構(gòu)的調(diào)整，這種也要考慮到，例如服務化這種大的架構(gòu)改造，就意味著專職的專業(yè)領(lǐng)域服務團隊的成立。
?
全局
全局觀通常是指在系統(tǒng)設計時是否考慮到了對上下游的系統(tǒng)的影響，畢竟通常所設計的系統(tǒng)不是一個孤立的系統(tǒng)，如果沒有足夠好的全局觀，有可能會導致自己的系統(tǒng)做完上線，其他上下游系統(tǒng)（尤其有些連上下游是誰，怎么用的都不知道的情況下）出現(xiàn)問題，這種案例同樣不少。
?
權(quán)衡
權(quán)衡同樣也是架構(gòu)師極度重要的能力，或者也可以認為是決策能力，技術(shù)方案的拍板是一個架構(gòu)師最重要的職責。
上面說的全面是架構(gòu)師在思考時開的過程，而權(quán)衡就是收的過程，收的過程結(jié)束基本就意味著技術(shù)方案的確定，同時也確定了節(jié)奏，權(quán)衡在兩點上會體現(xiàn)的特別突出：
1. 技術(shù)方案決策原則
? ?通常一個問題都會有多種可解決的技術(shù)方案，怎么來決策就至關(guān)重要了，而決策通常又和全面相關(guān)，大的來說通常決策的原則就是性價比和可持續(xù)發(fā)展。
? ?性價比簡單來說是方案的實現(xiàn)成本，這個成本要包括非常多的方面，例如有些場景可能會是用硬件解決看起來是花錢，但最終折算成本是最劃算的，很多系統(tǒng)設計在決策性價比時都過于隨意，例如一個另外常見的場景就是建設一套新系統(tǒng)替代舊系統(tǒng)，這個時候可能完全沒考慮舊系統(tǒng)的遷移代價甚至超過了改造舊系統(tǒng)的代價；
? ?可持續(xù)發(fā)展簡單來說就是所選擇的技術(shù)方案在公司是否可持續(xù)，例如簡單的案例是公司主體的研發(fā)人員都是php，卻搞一個其他語言，且只有極少人懂的（當然，這還是要看性價比，如果搞一個其他語言帶來的效益超過了語言/人才體系的更換成本），又例如引入一個開源產(chǎn)品，有無專業(yè)團隊維護這都是要考慮的關(guān)鍵因素。
?
2. 優(yōu)先級和節(jié)奏控制
? ?經(jīng)常我會問做系統(tǒng)設計的同學一個問題：對于這個業(yè)務場景而言，在系統(tǒng)設計上最需要把握的一個點是什么；這是一個關(guān)鍵問題，全面意味著考慮到了很多地方的問題，但通常業(yè)務需求實現(xiàn)都是有很強的時間要求的，因此在這個時候必須考慮清楚不同點的優(yōu)先級，同時也包括技術(shù)方案在決策時也要做出取舍，有可能選了一個不是那么好的技術(shù)方案，但通過留下一些可改造的空間，為以后的重構(gòu)做好鋪墊，那就是很不錯的，尤其技術(shù)同學有些時候比較容易陷入解決技術(shù)問題的場景去，但那個問題其實有可能不是現(xiàn)階段最重要的。
優(yōu)先級和節(jié)奏控制是我認為一個最NB的架構(gòu)師的最佳體現(xiàn)，優(yōu)先級意味著把握住了重點，可以確保在所設計的架構(gòu)指導下業(yè)務實現(xiàn)不會出現(xiàn)大問題，節(jié)奏控制則意味著全面，知道隨著業(yè)務發(fā)展該在什么時間點做什么事，為將來做好鋪墊。
總結(jié)
- 上一篇： 在做技术面试官时，我是这样甄别大忽悠的—
- 下一篇： 我在系统设计上犯过的14个错