聊聊自己
前幾天看到阿裡雲小編姐姐在群裡抛出了《架構師成長之路》這個專題，其實蠻開心的，因為我終于可以“被迫”總結下這些年的經驗了，所謂壓力才是生産力，偶爾對自己施壓總結，提升最大的還是自己，假如讀者也能從中有一點收獲，那我大概是賺翻了:-)
在這之前，我先賣賣自己。
我大約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的架構師，是非常容易出問題的。而且說句可能會被噴的話，對于大部分中小網際網路公司來說，業務發展的規模可能還遠遠不到拼技術（我是指硬核的那種）的時候，這些公司架構師産出的，其實是業務産品。更何況，由于雲計算的普及，有很多以前看起來“高高在上”的技術，已經完全達到開箱即用，便利性猶如水電煤一樣。當然，這倒不是說技術無用，然後大家轉型去做業務專家算了。技術實力仍然是架構師最重要的能力，但是，我們不要忽略業務領域知識的重要性。時常關注業務與産品，不僅對目前架構的合理性進行有效評估，還能夠讓自己對産品未來發展有個更好的預判，以便提前做出合理的架構規劃，筆者認為，業務與産品的深入了解，其實也是【技術掌控力】的一部分。
最後，送給大家一句話：技術能力将決定你能走多快，而産品(業務)能力将決定你能走多遠！共勉！