架构师成长之路：如何提升技术掌控力？
架構師成長之路：如何提升技術掌控力？
簡介：?在很多人眼里，架構師就猶如古代的將軍一般，既能運籌帷幄決勝千里，又能獨闖敵營取人首級，是所有士兵們崇拜的偶像...好了，其實我只是想說：能成為一名優秀的架構師，確實是所有工程師的夢想。那么，架構師應該具備什么能力呢？
來源：阿里云MVP
聊聊自己
前幾天看到阿里云小編姐姐在群里拋出了《架構師成長之路》這個專題，其實蠻開心的，因為我終于可以“被迫”總結下這些年的經驗了，所謂壓力才是生產力，偶爾對自己施壓總結，提升最大的還是自己，假如讀者也能從中有一點收獲，那我大概是賺翻了:-)
在這之前，我先賣賣自己。
我大約10年前入行，一直從事軟件開發類工作，以Java技術棧為主，偶爾用Node，其他技術也略有涉及。期間做過各式各樣的產品，包括但不僅限于政務、電商、教育、社交、金融及區塊鏈等等。18年出版過一本技術書籍《Akka實戰》（機械工業出版社），今年也可能會出一本譯作。我目前坐標上海，擔任多家公司高級技術顧問，提供技術分享、培訓和咨詢等服務。同時今年也非常榮幸，被授予阿里云最有價值專家(MVP)，希望能在自我提升的同時，也帶給大家一些有價值的思考。
我算是一個典型的白羊座，以及非典型的工程師。為什么這么說呢？因為我多多少少有點冒險精神，也擅長折騰，中途曾多次嘗試過創業，有的是自己主導的，有的是跟隨合伙創業，但無論怎樣，都一直沒有脫離技術圈。在任何組織里，都是以技術負責人或者架構師的角色存在，算是見證了多個產品從0到1，然后從1到100的成長過程。在這個過程中，無論是研發體系還是業務體系，甚至HR體系，都會快速發生變化，正是因為我親歷過這些變化，才使得我能以業務全局和團隊整體情況來考慮技術架構問題，而不會從最開始就陷入技術細節之中。
我是一個非常喜歡寫作和分享的人，這算是我迄今為止養成的一個最重要的習慣。互聯網行業發展太快，要學習的東西非常多，我們每天都能接收到來自四面八方的信息，僅依靠大腦來做瞬時的過濾分析，已基本不可能，甚至會出現思維鈍化的情況。寫作，可以讓自己內心平靜，對信息進行有效去噪，然后將所思所想真實的記錄下來，形成自己的知識財富。同時，分享給其他人，看起來是幫助別人，但可能會因為收到有價值的反饋，反而提升了自己。所以說，分享者往往是最大受益者，正如我寫本篇文章一樣。
回到架構師成長之路這個話題，在很多人眼里，架構師就猶如古代的將軍一般，既能運籌帷幄決勝千里，又能獨闖敵營取人首級，是所有士兵們崇拜的偶像...好了，其實我只是想說：能成為一名優秀的架構師，確實是所有工程師的夢想。架構師這個title，沒有一個統一的標準，大多數都是公司內部按照一定職級設定的，甚至有的工程師一直在做架構師的事情，但仍然沒有架構師的title，這都很正常。我相信大多數人不是為了混title才想當架構師的，最終還是希望自己能達到架構師的能力級別。那么，架構師應該具備哪些能力呢？基于我近幾年來的一些血淚經驗，大致總結出了下面幾點：
1.有扎實的技術功底，對底層有庖丁解牛的能力；
2.對領域內的技術棧有全面的了解，能做合理的架構評估；
3.對新技術敏感多情，并能預判其引入風險；
4.有較強溝通、學習、分享、協作能力；
5.有較強業務分析能力，深刻理解業務及產品價值；
大家會看到，這里面大概有一半兒與技術有關，另外一半兒純屬軟技能，這些都非常重要。我們以前評價一個技術牛人，都會以【技術實力】強來描述他，但實際上，作為一個架構師，技術實力只是他能力模型的一部分，我認為，一個更能描述架構師能力的詞匯應該是【技術掌控力】，上面列的這5點，其實都屬于其范疇。本篇我們主要看看，什么是技術掌控力？以及如何提升技術掌控力？
什么是技術掌控力？
大家都知道，技術實力是架構師安身立命的基礎，也是你的同仁或朋友對你打的最重要的一個標簽，你在團隊內的影響力大概率由你的技術實力來決定，假如在技術上有明顯問題，那么在這個團隊內基本上沒有未來。那么，技術實力是怎么體現的呢？
圖中兩個妹子雖然是外行，但是有時候“寫代碼快”，確實也會被認為是技術實力強勁的表現（雖然不一定準確），不過更多的，可能是下面這類同行們的評價：
“張某某的算法寫的真好哎，技術牛人一枚啊。。。”
“李某某剛才解決了一個并發問題，技術真牛逼啊。。。”
“王某某剛采用了一個新的中間件，一下解決了耦合度過高的問題，膜拜一下。。。”
不得不說，這三個人的技術實力肯定是不錯的，他們都能在自己的方向上解決產品上的問題，但是，假如要做一個優秀的通用型架構師，僅僅在某一方向偏科是不行的。架構師不僅要能在某一方向上做到頂尖，更應該【對領域下的技術棧有全面的掌控力，并有能力通過技術手段讓業務及產品發揮出最大價值】，這里的領域可以理解為當下要做的事情，比如產品、方案、系統升級等。說的更具體一點，所謂【技術掌控力】，大致包含兩個方面：
1.從技術層面來說，能夠對各類技術方案的核心底層邏輯有非常清晰的了解，然后根據實際情況進行架構評估（比如易用性評估、擴展性評估、替代方案評估、風險評估等等），最終做出一個最合適的架構方案。
2.從業務和產品層面來說，能時刻關注業務產品發展現狀，以及預判未來發展趨勢，進而動態的、持續的調整和完善架構方案，通過技術手段，實現業務產品的最大價值。
所以說，技術掌控力，是技術實力的全方位升級，是更加全面的一種能力。工程師假如要往架構師方向發展，應該將技術實力進化為技術掌控力。
至于如何提升技術掌控力，我有下面一些粗淺的看法。
苦練內功
很多工作幾年的工程師，在精通CURD之后，往往會陷入技術上的停滯狀態，
這時候可能會出現兩個極端：
1.由于沒有學習目標，所有學習想法只停留在腦袋里，最終出師未捷心先死；
2.由于學習目標太多，頻繁在各個技術領域來回劃水，最終弱水三千一瓢都沒取到；
老實說，每個人都可能會在某段時間內突然失去目標感（沒有目標或者目標太多），包括我自己，每個月也有那么幾天是這樣:-)?
其實這個時候最好的做法就是去苦練內功，就好比你打籃球一樣，當周圍全是防守人員，擋住了你傳球的思路，什么都做不了的時候，那么最好的做法就是：拼命往球框的方向扔就完事兒了，進不進無所謂，至少方向是對的吧...而苦練內功，絕對是最正確的方向。
不知道大家愛不愛看武俠，在武俠中，內功是所有絕學的基礎，只會招式而內功缺乏，戰力非常有限。比如《射雕英雄傳》，主角郭靖武功蓋世，人人敬仰，是我們年少時的偶像。那么他的武功是怎么一步步達到頂尖的呢？郭靖在年少時，由江南七怪教他練一些拳腳功夫，以招式為主，內功基本沒有，打打小流氓不在話下，假如遇到高手，肯定會輸的吐血，會再多的招式也沒用。后來，全真派馬玨傳授了2年全真內功，武力值一下提升了數倍，這才為日后練習降龍十八掌打下堅實基礎。假如沒有內功基礎，我想洪七公肯定是不會貿然將此神功傳授于他的。包括后來學會老頑童的空明拳、以及被騙學會九陰真經，都是因為他有強大的全真派內功基礎。
其實在技術領域，道理是一樣的，技術領域的底層基礎，既是內功。對于工作兩三年的工程師來說，想入門一個新的編程語言、框架，其實都非常簡單，搭建完環境，跑跑demo，看看API，相信一天內能完全搞定。但是，你要開發生產級別的產品，你會發現，以前用A框架要面對的問題，用B框架也仍然需要面對。就以最常見的并發、GC這類問題來說，只要你用Java，采用任何框架都是逃不掉的。而這類問題，就屬于內功問題，一旦內功提升，哪怕用最簡單的招式，也能解決很多問題。同時，學習其他新技術的時候，也自然可以融會貫通。
在我看來，練習內功（底層基礎）其實是蠻簡單的一件事，大部分情況下，你不需要依賴其他環境，比如說學習并發編程，直接打開IDE就可以開始做了。再比如GC，只需要配置幾個啟動參數，學會幾個命令，就直接可以開始看了。相對于其他各種大而全的框架技術來說，它對環境的依賴程度非常低，提升效率非常高。
所以，當大家不知道學什么，而又想提升自己的時候，練內功吧，成長速度比自己想象的要快，We can do this all day...
對技術敏感多情
以前在面試的時候，我經常會問候選人幾個額外的問題：
1.你會經常逛什么技術社區嘛？哪些社區？
2.最近有哪些想了解的新技術？
3.你關注了哪幾個技術類的公眾號？
4.最近讀的一本技術書籍是什么？（偶爾還會問下對方作者是誰？）
5.最近技術圈兒有什么八卦沒？
6.......
之所以會問這些問題，主要是想考察候選人是不是經常關注IT圈子，對一些新的技術或技術牛人有沒有過了解，我認為，哪怕是天天在社區里面灌水或者搞八卦，也比什么都不聞不問強。可是，很多工程師自詡熱愛技術，卻連技術社區都不逛，對新技術新名詞一無所知，讓人如何相信呢？
我認為，工程師一定要對新技術保持敏感，“花心”一點。每種新技術的出現，肯定是為解決當下問題而出現的，雖說解決問題的方式有很多種，但最終肯定有一種最優解法，對新技術理解的越多，在做技術選型時就會越從容，更易做出最優選擇。我們經常說，要學習一門技術，得通過項目實踐才能真正掌握，這是一句正確的廢話。很多時候，你想要學習的技術，并不一定會在實際項目中采用，你能做的，只有自己創造Demo場景，然后編寫各種測試代碼進行研究。我在工作的前幾年，也經常抱怨不能通過實際場景學習新技術，然后心安理得的拖著不去做研究，以至于在遇到真實案例時，只能邊學邊用，出過很多嚴重的生產問題，經常吐血。
所以，大家要盡早放棄用生產案例供自己學習新技術的想法，任何機會都是留給有準備的人的。
學會識別風險
雖說我們要對新技術保持敏感，但是在真正選型時需要格外慎重，有句話說的好：大膽嘗試、小心求證，我覺得放在這里非常合適。有很多新技術，雖然能解決現有的問題，但是也可能帶來新的問題，所以很多時候，工程師都是在不停填坑，然后挖坑，最后繼續填坑的反復循環中。作為架構師，需要識別任何新技術帶來的風險問題。
這里舉一個之前經歷過的一個小例子。當時有個老產品，除了做運營活動時會出現一定的性能波動，其他時間一直平穩運行。團隊中某工程師發現，之所以會出現性能波動，是因為在訂單處理時同時會做一些積分、贈券相關的計算，當量大的時候，計算量水漲船高，占用了極大的資源，也會導致更長的延遲。該工程師提議，可以在訂單處理時引入MQ，將訂單更新成功的消息發往一個計算服務去執行，這樣不僅使訂單落庫的更快，還解耦了這塊的復雜邏輯。老實說，這是個非常好的方案。但是呢，仔細思考，這個做法會帶來下面的風險：
1.引入MQ中間件，勢必要保障MQ的高可用，假如出問題了怎樣？運維是否有能力hold住它；
2.萬一發現RabbitMQ存在問題，RocketMQ能不能在盡可能少改動代碼的情況下進行快速替換；
3.計算服務獨立出來，需要增派人手進行開發（人是否夠？），并且也需要納入運維的日常巡檢管理；
4.計算服務既不能少算，也不能重復計算（冪等性），可靠性要非常強；
5........
當然，這里面還有很多細節問題，不再一一列出。由于這確實是個好的方案，所以最終采納并完成實施，在解決完這些風險后，順利上線了。順便說一下，第1、2個問題，由于考慮到當時團隊現狀，直接上云保平安了。
所以大家看，即使這么一個看起來非常簡單的方案，也需要考慮很多問題才能最終執行。我一直認為，能有效識別風險，是架構師技術掌控力的最佳體現。
關注非功能性需求
應用程序一般包括兩類需求：功能性需求和非功能性需求。功能性需求是指應用應該實現的業務功能，這類需求一般由產品經理提出并形成PRD。非功能性需求是指應用的性能、維護性、擴展性、可靠性、以及高可用等運維保障性需求。本質上，我們做架構，大部分時候都是在做非功能性需求，這是架構師最重要的工作之一。
現實情況是，Boss或產品經理往往只會關注功能性需求，它們最常見的說辭就是：我要加個這么小的功能怎么這么麻煩？老實說，我理解他們，因為站在他們的角度，都是以業務實現來看待研發問題，能把功能性需求的邏輯整自恰了就已經很好了。而作為架構師，此時的價值就需要體現出來，不能完全被動接受純功能性開發的需求，老實說，即使你用最糟糕的語言、最糟糕的架構，你都能實現Boss給你的任務，但是一旦產品稍微有點起色，就免不了完全推倒從來的風險，最后不僅給自己和團隊挖坑，還會對公司造成損失。有的工程師可能會吐槽，產品開發周期有限，功能性需求都可能做不完，非功能性需求更加沒空做。確實存在這種問題，我認為，即使由于deadline太緊而無法顧及更多非功能性設計，也應該在整個架構設計文檔和開發文檔中加以說明，這是作為“技術負債”的一部分，是需要給產品或者Boss詳述報告的。除了讓他們對當前產品有個合理的預期之外，也給團隊以后“還債”預留時間和空間。順便提一句：假如永遠沒有還債的機會，可能公司并不需要一名架構師:-)?
我們工程師很容易進入一個誤區，那就是總覺得只有大一點的產品才需要考慮非功能性需求。實際上，不同階段的產品有不同階段的非功能性需求。比如說，很多互聯網公司的產品，特別是創業階段的產品，都遵循MVP（最小可行性產品）策略，即用最短的時間內完成最核心的功能，然后小范圍投入市場進行反饋收集，并持續迭代。這種產品開發形式，雖然不考慮高性能、擴展性等問題，但是仍然需要考慮快速迭代、快速發布、穩定性等問題，否則用戶會吐槽“你這款產品本身就已經極簡了，不僅發新版慢，還各種卡死閃退”，好不容易積累的種子用戶也會消失殆盡。隨著產品不斷發展，非功能性需求會原來越多，工程師需要關注更多更復雜的非功能性需求，比如考慮性能問題、服務或數據拆分等問題。假如一直堅持下去，不僅可以持續為產品發展帶來價值，自己也能得到很大的提升。
學會交流與分享
在我入行的時候，經常聽求伯君當年單槍匹馬一年多，寫出了WPS的傳奇故事，總是感覺熱血沸騰，不能自已。在那時候，我心里的技術大牛，就像武俠中的世外高人，他們獨來獨往，身懷絕世神功，但不為外界所知，而一旦橫空出世，必定威震武林。事實上，在幾十年前的IT行業，確實存在著大量頂尖高手，他們以一己之力推動者行業的發展。那個時候的高手們，是孤獨的，就像求伯君說的：“有了難題，不知道問誰，解決了難題，也沒人分享喜悅。”。
不過，IT&互聯網行業發展到現在，已經不是當初的樣子了，應用的復雜度急劇上升，靠單打獨斗已經搞不定了。過去之所以個人英雄主義更多，其實是因為信息傳播能力、交流協作工具等受限，人與人之間基本是信息孤島，不像現在，有Github，各種社區、甚至微信群，可以很方便的進行交流協作。
事實證明，當信息傳播能力越強，交流協作工具越來越高效，IT行業的整體水平都有更快發展，以Github為例，它吸引了全世界最知名的互聯網公司，以及最有創造力的工程師群體，最終產出了最頂級的開源軟件，為整個IT行業的發展做出巨大貢獻，這是集體智慧發揮到極致的典型案例。
作為工程師個體來說，我們不應該故步自封，關起門來搞建設，而應該多和外界交流學習，無論是社區、行業大會，還是高質量的微信交流群，直播群，都可以盡可能的去參加，以吸取大家的集體智慧，這對增強行業見識，拓寬技術視野都是很有幫助的，當然了，假如能持續在Github上 show your code，那肯定是最高級的交流方式了:-)?
我一直相信，人的精力非常有限，不可能所有技術都能完全精通，在我們自己冥思苦想仍不得解的時候，可能別人的一句話就點醒了自己，反過來也一樣，這些都在我身上時有發生。老實說，以前的自己，也不太喜歡和人交流，內心總有點小傲氣，總覺得人家講的都是XX，有那么一點“技術相輕”的意思，而自己想去和別人分享心得吧，又抹不開面子，生怕自己講不好，毀了自己的人設。直到后來，因為做了一次講師，我才改變了這個觀念。那是我人生第一次受邀做分享嘉賓，對方是一知名外企。第一次嘛，我亞歷山大，也格外認真，在準備內容的過程中，竟然把我有關該主題的一些不起眼的盲點全部掃清了一遍，當時我就兩個感覺：
1.這次分享我收獲最大，這么爽的事兒以后不要錢都干啊；
2.分享的講師之所以有底氣站在臺上，肯定是掌握了聽眾不知道的東西；
所以可以看到，無論是當分享者還是當聽眾，都是會有很大收獲的。這里特別提一下，假如大家在公司內外都能做幾場成功的分享，你自身的影響力也會逐漸提高，然后對很多事情的掌控能力也會越來越強，這對自己未來的職業發展是有很大幫助的，至少，你可以來申請阿里云MVP，對吧:-)
關注產品與業務
我和很多工程師一樣，早年間只迷戀技術，對業務開發非常排斥，對業務的理解僅限于最基本的邏輯，對業務功能所能帶來的價值更是不了解，讓我理解用戶？對不起，我可能連用戶是啥群體都還沒摸清楚。所以在頭幾年里，總感覺自己一身武藝，卻沒有發揮的地方，實際上是自己“作妖”導致的。后來在積累了更多開發經驗后，就發現，假如對業務的理解有偏差，做出來的技術架構，開發出來的產品，基本上都是“不良品”，正是印證了那句話：雖然懂得很多技術，但仍然做不好架構，原因就在于此:-)?
依我看來，IT行業對架構師的業務理解與分析能力的要求是越來越高的。以往有很多人，把架構師分為技術架構師和業務架構師。技術架構師，通常負責做好技術選型、搭建技術框架、攻克技術難點等工作。而業務架構師，通常負責平臺架構、產品規劃、領域模型等工作。但實際上，技術類架構師越來越需要擁有業務架構的能力，因為技術肯定是為業務服務的，他需要對實現業務價值做出自己的貢獻，而脫離業務場景談技術架構純屬耍流氓。
舉個最常見的例子，大家現在都在討論微服務架構（如圖所示，這是我參考《微服務架構設計模式》并結合自己的經驗給出的一個通用步驟），我們都知道微服務化是有諸多好處的，比如提高可擴展性、可維護性、資源利用率等等，這是會對產品帶來長期價值的非功能性需求，是每個架構師都想做好的一件事。其實做微服務，最難的點已經不是技術棧了，畢竟SpringCloud、Dubbo這類框架已經非常易用了。最難的實際上是領域模型、服務拆分等問題。什么叫領域模型呢？這是DDD（領域驅動設計）中的常見詞匯，它是指通過業務需求建立的具有統一術語的業務實體模型，它指導著程序的開發實現，同時，DDD中的另外一個概念叫限界上下文，對它的識別可以有效解決微服務拆分的問題。而這些概念，都與業務息息相關。所以說，假如對業務分析不足，是不可能做好微服務架構的。
平日里我也經常和眾多研發團隊負責人進行交流，大家有個共識就是：假如某個小團隊里存在一位只追求用新技術或所謂“底層”技術而對業務完全不care的架構師，是非常容易出問題的。而且說句可能會被噴的話，對于大部分中小互聯網公司來說，業務發展的規模可能還遠遠不到拼技術（我是指硬核的那種）的時候，這些公司架構師產出的，其實是業務產品。更何況，由于云計算的普及，有很多以前看起來“高高在上”的技術，已經完全達到開箱即用，便利性猶如水電煤一樣。當然，這倒不是說技術無用，然后大家轉型去做業務專家算了。技術實力仍然是架構師最重要的能力，但是，我們不要忽略業務領域知識的重要性。時常關注業務與產品，不僅對當前架構的合理性進行有效評估，還能夠讓自己對產品未來發展有個更好的預判，以便提前做出合理的架構規劃，筆者認為，業務與產品的深入理解，其實也是【技術掌控力】的一部分。
最后，送給大家一句話：技術能力將決定你能走多快，而產品(業務)能力將決定你能走多遠！共勉！
總結
以上是生活随笔為你收集整理的架构师成长之路：如何提升技术掌控力？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Java经典面试题整理及答案详解（三）
- 下一篇： 2020 前端开源领域技术展望