架構(gòu)師成長之路：如何提升技術(shù)掌控力？

簡介：?在很多人眼里，架構(gòu)師就猶如古代的將軍一般，既能運籌帷幄決勝千里，又能獨闖敵營取人首級，是所有士兵們崇拜的偶像...好了，其實我只是想說：能成為一名優(yōu)秀的架構(gòu)師，確實是所有工程師的夢想。那么，架構(gòu)師應(yīng)該具備什么能力呢？

來源：阿里云MVP

聊聊自己

---

前幾天看到阿里云小編姐姐在群里拋出了《架構(gòu)師成長之路》這個專題，其實蠻開心的，因為我終于可以“被迫”總結(jié)下這些年的經(jīng)驗了，所謂壓力才是生產(chǎn)力，偶爾對自己施壓總結(jié)，提升最大的還是自己，假如讀者也能從中有一點收獲，那我大概是賺翻了:-)

在這之前，我先賣賣自己。

我大約10年前入行，一直從事軟件開發(fā)類工作，以Java技術(shù)棧為主，偶爾用Node，其他技術(shù)也略有涉及。期間做過各式各樣的產(chǎn)品，包括但不僅限于政務(wù)、電商、教育、社交、金融及區(qū)塊鏈等等。18年出版過一本技術(shù)書籍《Akka實戰(zhàn)》（機械工業(yè)出版社），今年也可能會出一本譯作。我目前坐標上海，擔(dān)任多家公司高級技術(shù)顧問，提供技術(shù)分享、培訓(xùn)和咨詢等服務(wù)。同時今年也非常榮幸，被授予阿里云最有價值專家(MVP)，希望能在自我提升的同時，也帶給大家一些有價值的思考。

我算是一個典型的白羊座，以及非典型的工程師。為什么這么說呢？因為我多多少少有點冒險精神，也擅長折騰，中途曾多次嘗試過創(chuàng)業(yè)，有的是自己主導(dǎo)的，有的是跟隨合伙創(chuàng)業(yè)，但無論怎樣，都一直沒有脫離技術(shù)圈。在任何組織里，都是以技術(shù)負責(zé)人或者架構(gòu)師的角色存在，算是見證了多個產(chǎn)品從0到1，然后從1到100的成長過程。在這個過程中，無論是研發(fā)體系還是業(yè)務(wù)體系，甚至HR體系，都會快速發(fā)生變化，正是因為我親歷過這些變化，才使得我能以業(yè)務(wù)全局和團隊整體情況來考慮技術(shù)架構(gòu)問題，而不會從最開始就陷入技術(shù)細節(jié)之中。

我是一個非常喜歡寫作和分享的人，這算是我迄今為止養(yǎng)成的一個最重要的習(xí)慣?；ヂ?lián)網(wǎng)行業(yè)發(fā)展太快，要學(xué)習(xí)的東西非常多，我們每天都能接收到來自四面八方的信息，僅依靠大腦來做瞬時的過濾分析，已基本不可能，甚至?xí)霈F(xiàn)思維鈍化的情況。寫作，可以讓自己內(nèi)心平靜，對信息進行有效去噪，然后將所思所想真實的記錄下來，形成自己的知識財富。同時，分享給其他人，看起來是幫助別人，但可能會因為收到有價值的反饋，反而提升了自己。所以說，分享者往往是最大受益者，正如我寫本篇文章一樣。

回到架構(gòu)師成長之路這個話題，在很多人眼里，架構(gòu)師就猶如古代的將軍一般，既能運籌帷幄決勝千里，又能獨闖敵營取人首級，是所有士兵們崇拜的偶像...好了，其實我只是想說：能成為一名優(yōu)秀的架構(gòu)師，確實是所有工程師的夢想。架構(gòu)師這個title，沒有一個統(tǒng)一的標準，大多數(shù)都是公司內(nèi)部按照一定職級設(shè)定的，甚至有的工程師一直在做架構(gòu)師的事情，但仍然沒有架構(gòu)師的title，這都很正常。我相信大多數(shù)人不是為了混title才想當(dāng)架構(gòu)師的，最終還是希望自己能達到架構(gòu)師的能力級別。那么，架構(gòu)師應(yīng)該具備哪些能力呢？基于我近幾年來的一些血淚經(jīng)驗，大致總結(jié)出了下面幾點：

1.有扎實的技術(shù)功底，對底層有庖丁解牛的能力；
2.對領(lǐng)域內(nèi)的技術(shù)棧有全面的了解，能做合理的架構(gòu)評估；
3.對新技術(shù)敏感多情，并能預(yù)判其引入風(fēng)險；
4.有較強溝通、學(xué)習(xí)、分享、協(xié)作能力；
5.有較強業(yè)務(wù)分析能力，深刻理解業(yè)務(wù)及產(chǎn)品價值；

大家會看到，這里面大概有一半兒與技術(shù)有關(guān)，另外一半兒純屬軟技能，這些都非常重要。我們以前評價一個技術(shù)牛人，都會以【技術(shù)實力】強來描述他，但實際上，作為一個架構(gòu)師，技術(shù)實力只是他能力模型的一部分，我認為，一個更能描述架構(gòu)師能力的詞匯應(yīng)該是【技術(shù)掌控力】，上面列的這5點，其實都屬于其范疇。本篇我們主要看看，什么是技術(shù)掌控力？以及如何提升技術(shù)掌控力？

什么是技術(shù)掌控力？

---

大家都知道，技術(shù)實力是架構(gòu)師安身立命的基礎(chǔ)，也是你的同仁或朋友對你打的最重要的一個標簽，你在團隊內(nèi)的影響力大概率由你的技術(shù)實力來決定，假如在技術(shù)上有明顯問題，那么在這個團隊內(nèi)基本上沒有未來。那么，技術(shù)實力是怎么體現(xiàn)的呢？

圖中兩個妹子雖然是外行，但是有時候“寫代碼快”，確實也會被認為是技術(shù)實力強勁的表現(xiàn)（雖然不一定準確），不過更多的，可能是下面這類同行們的評價：

“張某某的算法寫的真好哎，技術(shù)牛人一枚啊。。。”

“李某某剛才解決了一個并發(fā)問題，技術(shù)真牛逼啊。。?！?/p>

“王某某剛采用了一個新的中間件，一下解決了耦合度過高的問題，膜拜一下。。。”

不得不說，這三個人的技術(shù)實力肯定是不錯的，他們都能在自己的方向上解決產(chǎn)品上的問題，但是，假如要做一個優(yōu)秀的通用型架構(gòu)師，僅僅在某一方向偏科是不行的。架構(gòu)師不僅要能在某一方向上做到頂尖，更應(yīng)該【對領(lǐng)域下的技術(shù)棧有全面的掌控力，并有能力通過技術(shù)手段讓業(yè)務(wù)及產(chǎn)品發(fā)揮出最大價值】，這里的領(lǐng)域可以理解為當(dāng)下要做的事情，比如產(chǎn)品、方案、系統(tǒng)升級等。說的更具體一點，所謂【技術(shù)掌控力】，大致包含兩個方面：

1.從技術(shù)層面來說，能夠?qū)Ω黝惣夹g(shù)方案的核心底層邏輯有非常清晰的了解，然后根據(jù)實際情況進行架構(gòu)評估（比如易用性評估、擴展性評估、替代方案評估、風(fēng)險評估等等），最終做出一個最合適的架構(gòu)方案。

2.從業(yè)務(wù)和產(chǎn)品層面來說，能時刻關(guān)注業(yè)務(wù)產(chǎn)品發(fā)展現(xiàn)狀，以及預(yù)判未來發(fā)展趨勢，進而動態(tài)的、持續(xù)的調(diào)整和完善架構(gòu)方案，通過技術(shù)手段，實現(xiàn)業(yè)務(wù)產(chǎn)品的最大價值。

所以說，技術(shù)掌控力，是技術(shù)實力的全方位升級，是更加全面的一種能力。工程師假如要往架構(gòu)師方向發(fā)展，應(yīng)該將技術(shù)實力進化為技術(shù)掌控力。

至于如何提升技術(shù)掌控力，我有下面一些粗淺的看法。

苦練內(nèi)功

---

很多工作幾年的工程師，在精通CURD之后，往往會陷入技術(shù)上的停滯狀態(tài)，
這時候可能會出現(xiàn)兩個極端：

1.由于沒有學(xué)習(xí)目標，所有學(xué)習(xí)想法只停留在腦袋里，最終出師未捷心先死；

2.由于學(xué)習(xí)目標太多，頻繁在各個技術(shù)領(lǐng)域來回劃水，最終弱水三千一瓢都沒取到；

老實說，每個人都可能會在某段時間內(nèi)突然失去目標感（沒有目標或者目標太多），包括我自己，每個月也有那么幾天是這樣:-)?

其實這個時候最好的做法就是去苦練內(nèi)功，就好比你打籃球一樣，當(dāng)周圍全是防守人員，擋住了你傳球的思路，什么都做不了的時候，那么最好的做法就是：拼命往球框的方向扔就完事兒了，進不進無所謂，至少方向是對的吧...而苦練內(nèi)功，絕對是最正確的方向。

不知道大家愛不愛看武俠，在武俠中，內(nèi)功是所有絕學(xué)的基礎(chǔ)，只會招式而內(nèi)功缺乏，戰(zhàn)力非常有限。比如《射雕英雄傳》，主角郭靖武功蓋世，人人敬仰，是我們年少時的偶像。那么他的武功是怎么一步步達到頂尖的呢？郭靖在年少時，由江南七怪教他練一些拳腳功夫，以招式為主，內(nèi)功基本沒有，打打小流氓不在話下，假如遇到高手，肯定會輸?shù)耐卵?#xff0c;會再多的招式也沒用。后來，全真派馬玨傳授了2年全真內(nèi)功，武力值一下提升了數(shù)倍，這才為日后練習(xí)降龍十八掌打下堅實基礎(chǔ)。假如沒有內(nèi)功基礎(chǔ)，我想洪七公肯定是不會貿(mào)然將此神功傳授于他的。包括后來學(xué)會老頑童的空明拳、以及被騙學(xué)會九陰真經(jīng)，都是因為他有強大的全真派內(nèi)功基礎(chǔ)。

其實在技術(shù)領(lǐng)域，道理是一樣的，技術(shù)領(lǐng)域的底層基礎(chǔ)，既是內(nèi)功。對于工作兩三年的工程師來說，想入門一個新的編程語言、框架，其實都非常簡單，搭建完環(huán)境，跑跑demo，看看API，相信一天內(nèi)能完全搞定。但是，你要開發(fā)生產(chǎn)級別的產(chǎn)品，你會發(fā)現(xiàn)，以前用A框架要面對的問題，用B框架也仍然需要面對。就以最常見的并發(fā)、GC這類問題來說，只要你用Java，采用任何框架都是逃不掉的。而這類問題，就屬于內(nèi)功問題，一旦內(nèi)功提升，哪怕用最簡單的招式，也能解決很多問題。同時，學(xué)習(xí)其他新技術(shù)的時候，也自然可以融會貫通。

在我看來，練習(xí)內(nèi)功（底層基礎(chǔ)）其實是蠻簡單的一件事，大部分情況下，你不需要依賴其他環(huán)境，比如說學(xué)習(xí)并發(fā)編程，直接打開IDE就可以開始做了。再比如GC，只需要配置幾個啟動參數(shù)，學(xué)會幾個命令，就直接可以開始看了。相對于其他各種大而全的框架技術(shù)來說，它對環(huán)境的依賴程度非常低，提升效率非常高。

所以，當(dāng)大家不知道學(xué)什么，而又想提升自己的時候，練內(nèi)功吧，成長速度比自己想象的要快，We can do this all day...

對技術(shù)敏感多情

---

以前在面試的時候，我經(jīng)常會問候選人幾個額外的問題：

1.你會經(jīng)常逛什么技術(shù)社區(qū)嘛？哪些社區(qū)？
2.最近有哪些想了解的新技術(shù)？
3.你關(guān)注了哪幾個技術(shù)類的公眾號？
4.最近讀的一本技術(shù)書籍是什么？（偶爾還會問下對方作者是誰？）
5.最近技術(shù)圈兒有什么八卦沒？
6.......

之所以會問這些問題，主要是想考察候選人是不是經(jīng)常關(guān)注IT圈子，對一些新的技術(shù)或技術(shù)牛人有沒有過了解，我認為，哪怕是天天在社區(qū)里面灌水或者搞八卦，也比什么都不聞不問強。可是，很多工程師自詡熱愛技術(shù)，卻連技術(shù)社區(qū)都不逛，對新技術(shù)新名詞一無所知，讓人如何相信呢？

我認為，工程師一定要對新技術(shù)保持敏感，“花心”一點。每種新技術(shù)的出現(xiàn)，肯定是為解決當(dāng)下問題而出現(xiàn)的，雖說解決問題的方式有很多種，但最終肯定有一種最優(yōu)解法，對新技術(shù)理解的越多，在做技術(shù)選型時就會越從容，更易做出最優(yōu)選擇。我們經(jīng)常說，要學(xué)習(xí)一門技術(shù)，得通過項目實踐才能真正掌握，這是一句正確的廢話。很多時候，你想要學(xué)習(xí)的技術(shù)，并不一定會在實際項目中采用，你能做的，只有自己創(chuàng)造Demo場景，然后編寫各種測試代碼進行研究。我在工作的前幾年，也經(jīng)常抱怨不能通過實際場景學(xué)習(xí)新技術(shù)，然后心安理得的拖著不去做研究，以至于在遇到真實案例時，只能邊學(xué)邊用，出過很多嚴重的生產(chǎn)問題，經(jīng)常吐血。

所以，大家要盡早放棄用生產(chǎn)案例供自己學(xué)習(xí)新技術(shù)的想法，任何機會都是留給有準備的人的。

學(xué)會識別風(fēng)險

---

雖說我們要對新技術(shù)保持敏感，但是在真正選型時需要格外慎重，有句話說的好：大膽嘗試、小心求證，我覺得放在這里非常合適。有很多新技術(shù)，雖然能解決現(xiàn)有的問題，但是也可能帶來新的問題，所以很多時候，工程師都是在不停填坑，然后挖坑，最后繼續(xù)填坑的反復(fù)循環(huán)中。作為架構(gòu)師，需要識別任何新技術(shù)帶來的風(fēng)險問題。

這里舉一個之前經(jīng)歷過的一個小例子。當(dāng)時有個老產(chǎn)品，除了做運營活動時會出現(xiàn)一定的性能波動，其他時間一直平穩(wěn)運行。團隊中某工程師發(fā)現(xiàn)，之所以會出現(xiàn)性能波動，是因為在訂單處理時同時會做一些積分、贈券相關(guān)的計算，當(dāng)量大的時候，計算量水漲船高，占用了極大的資源，也會導(dǎo)致更長的延遲。該工程師提議，可以在訂單處理時引入MQ，將訂單更新成功的消息發(fā)往一個計算服務(wù)去執(zhí)行，這樣不僅使訂單落庫的更快，還解耦了這塊的復(fù)雜邏輯。老實說，這是個非常好的方案。但是呢，仔細思考，這個做法會帶來下面的風(fēng)險：

1.引入MQ中間件，勢必要保障MQ的高可用，假如出問題了怎樣？運維是否有能力hold住它；

2.萬一發(fā)現(xiàn)RabbitMQ存在問題，RocketMQ能不能在盡可能少改動代碼的情況下進行快速替換；

3.計算服務(wù)獨立出來，需要增派人手進行開發(fā)（人是否夠？），并且也需要納入運維的日常巡檢管理；

4.計算服務(wù)既不能少算，也不能重復(fù)計算（冪等性），可靠性要非常強；

5........

當(dāng)然，這里面還有很多細節(jié)問題，不再一一列出。由于這確實是個好的方案，所以最終采納并完成實施，在解決完這些風(fēng)險后，順利上線了。順便說一下，第1、2個問題，由于考慮到當(dāng)時團隊現(xiàn)狀，直接上云保平安了。

所以大家看，即使這么一個看起來非常簡單的方案，也需要考慮很多問題才能最終執(zhí)行。我一直認為，能有效識別風(fēng)險，是架構(gòu)師技術(shù)掌控力的最佳體現(xiàn)。

關(guān)注非功能性需求

---

應(yīng)用程序一般包括兩類需求：功能性需求和非功能性需求。功能性需求是指應(yīng)用應(yīng)該實現(xiàn)的業(yè)務(wù)功能，這類需求一般由產(chǎn)品經(jīng)理提出并形成PRD。非功能性需求是指應(yīng)用的性能、維護性、擴展性、可靠性、以及高可用等運維保障性需求。本質(zhì)上，我們做架構(gòu)，大部分時候都是在做非功能性需求，這是架構(gòu)師最重要的工作之一。

現(xiàn)實情況是，Boss或產(chǎn)品經(jīng)理往往只會關(guān)注功能性需求，它們最常見的說辭就是：我要加個這么小的功能怎么這么麻煩？老實說，我理解他們，因為站在他們的角度，都是以業(yè)務(wù)實現(xiàn)來看待研發(fā)問題，能把功能性需求的邏輯整自恰了就已經(jīng)很好了。而作為架構(gòu)師，此時的價值就需要體現(xiàn)出來，不能完全被動接受純功能性開發(fā)的需求，老實說，即使你用最糟糕的語言、最糟糕的架構(gòu)，你都能實現(xiàn)Boss給你的任務(wù)，但是一旦產(chǎn)品稍微有點起色，就免不了完全推倒從來的風(fēng)險，最后不僅給自己和團隊挖坑，還會對公司造成損失。有的工程師可能會吐槽，產(chǎn)品開發(fā)周期有限，功能性需求都可能做不完，非功能性需求更加沒空做。確實存在這種問題，我認為，即使由于deadline太緊而無法顧及更多非功能性設(shè)計，也應(yīng)該在整個架構(gòu)設(shè)計文檔和開發(fā)文檔中加以說明，這是作為“技術(shù)負債”的一部分，是需要給產(chǎn)品或者Boss詳述報告的。除了讓他們對當(dāng)前產(chǎn)品有個合理的預(yù)期之外，也給團隊以后“還債”預(yù)留時間和空間。順便提一句：假如永遠沒有還債的機會，可能公司并不需要一名架構(gòu)師:-)?

我們工程師很容易進入一個誤區(qū)，那就是總覺得只有大一點的產(chǎn)品才需要考慮非功能性需求。實際上，不同階段的產(chǎn)品有不同階段的非功能性需求。比如說，很多互聯(lián)網(wǎng)公司的產(chǎn)品，特別是創(chuàng)業(yè)階段的產(chǎn)品，都遵循MVP（最小可行性產(chǎn)品）策略，即用最短的時間內(nèi)完成最核心的功能，然后小范圍投入市場進行反饋收集，并持續(xù)迭代。這種產(chǎn)品開發(fā)形式，雖然不考慮高性能、擴展性等問題，但是仍然需要考慮快速迭代、快速發(fā)布、穩(wěn)定性等問題，否則用戶會吐槽“你這款產(chǎn)品本身就已經(jīng)極簡了，不僅發(fā)新版慢，還各種卡死閃退”，好不容易積累的種子用戶也會消失殆盡。隨著產(chǎn)品不斷發(fā)展，非功能性需求會原來越多，工程師需要關(guān)注更多更復(fù)雜的非功能性需求，比如考慮性能問題、服務(wù)或數(shù)據(jù)拆分等問題。假如一直堅持下去，不僅可以持續(xù)為產(chǎn)品發(fā)展帶來價值，自己也能得到很大的提升。

學(xué)會交流與分享

---

在我入行的時候，經(jīng)常聽求伯君當(dāng)年單槍匹馬一年多，寫出了WPS的傳奇故事，總是感覺熱血沸騰，不能自已。在那時候，我心里的技術(shù)大牛，就像武俠中的世外高人，他們獨來獨往，身懷絕世神功，但不為外界所知，而一旦橫空出世，必定威震武林。事實上，在幾十年前的IT行業(yè)，確實存在著大量頂尖高手，他們以一己之力推動者行業(yè)的發(fā)展。那個時候的高手們，是孤獨的，就像求伯君說的：“有了難題，不知道問誰，解決了難題，也沒人分享喜悅?！?。

不過，IT&互聯(lián)網(wǎng)行業(yè)發(fā)展到現(xiàn)在，已經(jīng)不是當(dāng)初的樣子了，應(yīng)用的復(fù)雜度急劇上升，靠單打獨斗已經(jīng)搞不定了。過去之所以個人英雄主義更多，其實是因為信息傳播能力、交流協(xié)作工具等受限，人與人之間基本是信息孤島，不像現(xiàn)在，有Github，各種社區(qū)、甚至微信群，可以很方便的進行交流協(xié)作。

事實證明，當(dāng)信息傳播能力越強，交流協(xié)作工具越來越高效，IT行業(yè)的整體水平都有更快發(fā)展，以Github為例，它吸引了全世界最知名的互聯(lián)網(wǎng)公司，以及最有創(chuàng)造力的工程師群體，最終產(chǎn)出了最頂級的開源軟件，為整個IT行業(yè)的發(fā)展做出巨大貢獻，這是集體智慧發(fā)揮到極致的典型案例。

作為工程師個體來說，我們不應(yīng)該故步自封，關(guān)起門來搞建設(shè)，而應(yīng)該多和外界交流學(xué)習(xí)，無論是社區(qū)、行業(yè)大會，還是高質(zhì)量的微信交流群，直播群，都可以盡可能的去參加，以吸取大家的集體智慧，這對增強行業(yè)見識，拓寬技術(shù)視野都是很有幫助的，當(dāng)然了，假如能持續(xù)在Github上 show your code，那肯定是最高級的交流方式了:-)?

我一直相信，人的精力非常有限，不可能所有技術(shù)都能完全精通，在我們自己冥思苦想仍不得解的時候，可能別人的一句話就點醒了自己，反過來也一樣，這些都在我身上時有發(fā)生。老實說，以前的自己，也不太喜歡和人交流，內(nèi)心總有點小傲氣，總覺得人家講的都是XX，有那么一點“技術(shù)相輕”的意思，而自己想去和別人分享心得吧，又抹不開面子，生怕自己講不好，毀了自己的人設(shè)。直到后來，因為做了一次講師，我才改變了這個觀念。那是我人生第一次受邀做分享嘉賓，對方是一知名外企。第一次嘛，我亞歷山大，也格外認真，在準備內(nèi)容的過程中，竟然把我有關(guān)該主題的一些不起眼的盲點全部掃清了一遍，當(dāng)時我就兩個感覺：

1.這次分享我收獲最大，這么爽的事兒以后不要錢都干啊；
2.分享的講師之所以有底氣站在臺上，肯定是掌握了聽眾不知道的東西；

所以可以看到，無論是當(dāng)分享者還是當(dāng)聽眾，都是會有很大收獲的。這里特別提一下，假如大家在公司內(nèi)外都能做幾場成功的分享，你自身的影響力也會逐漸提高，然后對很多事情的掌控能力也會越來越強，這對自己未來的職業(yè)發(fā)展是有很大幫助的，至少，你可以來申請阿里云MVP，對吧:-)

關(guān)注產(chǎn)品與業(yè)務(wù)

---

我和很多工程師一樣，早年間只迷戀技術(shù)，對業(yè)務(wù)開發(fā)非常排斥，對業(yè)務(wù)的理解僅限于最基本的邏輯，對業(yè)務(wù)功能所能帶來的價值更是不了解，讓我理解用戶？對不起，我可能連用戶是啥群體都還沒摸清楚。所以在頭幾年里，總感覺自己一身武藝，卻沒有發(fā)揮的地方，實際上是自己“作妖”導(dǎo)致的。后來在積累了更多開發(fā)經(jīng)驗后，就發(fā)現(xiàn)，假如對業(yè)務(wù)的理解有偏差，做出來的技術(shù)架構(gòu)，開發(fā)出來的產(chǎn)品，基本上都是“不良品”，正是印證了那句話：雖然懂得很多技術(shù)，但仍然做不好架構(gòu)，原因就在于此:-)?

依我看來，IT行業(yè)對架構(gòu)師的業(yè)務(wù)理解與分析能力的要求是越來越高的。以往有很多人，把架構(gòu)師分為技術(shù)架構(gòu)師和業(yè)務(wù)架構(gòu)師。技術(shù)架構(gòu)師，通常負責(zé)做好技術(shù)選型、搭建技術(shù)框架、攻克技術(shù)難點等工作。而業(yè)務(wù)架構(gòu)師，通常負責(zé)平臺架構(gòu)、產(chǎn)品規(guī)劃、領(lǐng)域模型等工作。但實際上，技術(shù)類架構(gòu)師越來越需要擁有業(yè)務(wù)架構(gòu)的能力，因為技術(shù)肯定是為業(yè)務(wù)服務(wù)的，他需要對實現(xiàn)業(yè)務(wù)價值做出自己的貢獻，而脫離業(yè)務(wù)場景談技術(shù)架構(gòu)純屬耍流氓。

舉個最常見的例子，大家現(xiàn)在都在討論微服務(wù)架構(gòu)（如圖所示，這是我參考《微服務(wù)架構(gòu)設(shè)計模式》并結(jié)合自己的經(jīng)驗給出的一個通用步驟），我們都知道微服務(wù)化是有諸多好處的，比如提高可擴展性、可維護性、資源利用率等等，這是會對產(chǎn)品帶來長期價值的非功能性需求，是每個架構(gòu)師都想做好的一件事。其實做微服務(wù)，最難的點已經(jīng)不是技術(shù)棧了，畢竟SpringCloud、Dubbo這類框架已經(jīng)非常易用了。最難的實際上是領(lǐng)域模型、服務(wù)拆分等問題。什么叫領(lǐng)域模型呢？這是DDD（領(lǐng)域驅(qū)動設(shè)計）中的常見詞匯，它是指通過業(yè)務(wù)需求建立的具有統(tǒng)一術(shù)語的業(yè)務(wù)實體模型，它指導(dǎo)著程序的開發(fā)實現(xiàn)，同時，DDD中的另外一個概念叫限界上下文，對它的識別可以有效解決微服務(wù)拆分的問題。而這些概念，都與業(yè)務(wù)息息相關(guān)。所以說，假如對業(yè)務(wù)分析不足，是不可能做好微服務(wù)架構(gòu)的。

平日里我也經(jīng)常和眾多研發(fā)團隊負責(zé)人進行交流，大家有個共識就是：假如某個小團隊里存在一位只追求用新技術(shù)或所謂“底層”技術(shù)而對業(yè)務(wù)完全不care的架構(gòu)師，是非常容易出問題的。而且說句可能會被噴的話，對于大部分中小互聯(lián)網(wǎng)公司來說，業(yè)務(wù)發(fā)展的規(guī)?？赡苓€遠遠不到拼技術(shù)（我是指硬核的那種）的時候，這些公司架構(gòu)師產(chǎn)出的，其實是業(yè)務(wù)產(chǎn)品。更何況，由于云計算的普及，有很多以前看起來“高高在上”的技術(shù)，已經(jīng)完全達到開箱即用，便利性猶如水電煤一樣。當(dāng)然，這倒不是說技術(shù)無用，然后大家轉(zhuǎn)型去做業(yè)務(wù)專家算了。技術(shù)實力仍然是架構(gòu)師最重要的能力，但是，我們不要忽略業(yè)務(wù)領(lǐng)域知識的重要性。時常關(guān)注業(yè)務(wù)與產(chǎn)品，不僅對當(dāng)前架構(gòu)的合理性進行有效評估，還能夠讓自己對產(chǎn)品未來發(fā)展有個更好的預(yù)判，以便提前做出合理的架構(gòu)規(guī)劃，筆者認為，業(yè)務(wù)與產(chǎn)品的深入理解，其實也是【技術(shù)掌控力】的一部分。

最后，送給大家一句話：技術(shù)能力將決定你能走多快，而產(chǎn)品(業(yè)務(wù))能力將決定你能走多遠！共勉！

總結(jié)

以上是生活随笔為你收集整理的架构师成长之路：如何提升技术掌控力？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。