01．基礎技術體系

我認為知識技能體系化是判斷技術是否過關的第一步。知識體系化包含兩層含義：

1、 能夠知道技術知識圖譜（高清版圖譜掃文末二維碼）的內容

比如分散式系統中常用的RPC技術，其背後就涉及到網路IO（Netty）、網路協議、服務發現（Zookeeper配置中心）、RPC服務治理（限流、熔斷、降級）、負載均衡等。

2、 能夠理清各類技術概念之間的區別和聯絡

在分散式系統領域中，有很多相似的概念，但又分佈在不同的產品或層級中。比如負載均衡這個詞，DNS、LVS、Ngnix、F5等產品都能實現，而且在大型分散式系統中他們會同時存在，那麼就要搞清楚他們各自的位於什麼層級，解決了什麼問題。

再比如快取這項技術，有分散式快取、本地快取、資料庫快取，在往下還有硬體層級的快取。同樣都是快取，他們之間的區別又是什麼？

如果你仔細去觀察，大廠的後端開發工程師總是能對整個技術體系瞭如指掌，從而在系統設計與技術選型階段就能夠做出較為合理的架構。 

02．實踐經驗的積累

       能否快速解決實戰中的業務問題是判斷技術是否過關的第二步。
       大家在面試的過程中，都會有一種體會：我的知識體系已經建立了，但在回答面試官問題的時候，總感覺像在背答案，而且也沒有辦法針對性的回答面試官問題。比如在面試官問到這些問題時：

1. 我們知道訊息佇列可應用於耦系統，應對非同步消費等場景，那如何在網路不可靠的場景下保證業務資料處理的正確性？
2. 我們都知道在分散式系統會用到快取，那該如何設定快取失效機制才能避免系統出現快取雪崩？
3. 我們都或多或少的知道系統釋出上線的流程，但在大流量場景下采用何種釋出機制才能儘可能的做到平滑？

能完善的解決這些問題是區分一個程式設計師是否有經驗的重要標誌，知識的體系化是可以從書本不斷的凝練來獲得，但經驗的積累需要通過實戰的不斷總結

對很多人來說很為難的一點是，平時寫著的業務程式碼，很少有機會接觸到大廠的優秀實踐，那麼這時候更需要從如下兩個角度逼問：

1、當流量規模再提高几個量級，那麼我的系統會出現什麼問題？

2、假如其中一個環節出現了問題，那麼該怎麼保證系統的穩定性？

03．技術的原理

上面的提到都是將技術用於業務實踐，以及高效的解決業務中出現的問題。但這是否就意味著自己的技術已經過關了呢？我認為還不能。

判斷技術是否過關的第三步是能否洞察技術背後的設計思想和原理。

如果你參加過一些大廠面試，還會問到一些開放性的問題：

1、 寫一段程式，讓其執行時的表現為觸發了5次Young GC、3次Full GC、然後3次Young GC；

2、 如果一個Java程序突然消失了，你會怎麼去排查這種問題？

3、 給了一段Spring載入Bean的程式碼片段，闡述一下具體的執行流程？

       是不是看上去很難，是不是和自己準備的“題庫”中的問題不一樣？不知道從何處下手？如果你有這種感覺，那麼說明你的技術還需要繼續修煉。

       你要明白的是這種開放性的問題，提問的角度千變萬化，但最終落腳點卻都是基本原理。如果你不瞭解GC的觸發條件，你就肯定無法答出第一題；同樣，如果你對Spring啟動機制瞭解的很清楚，那麼無論他給出的是什麼樣的程式碼，你都能回答出程式碼經歷的過程。如果你能以不變應萬變，那麼恭喜你，你的技術過關了。

       上面提到了很多技術問題，這裡我不做詳細的解釋，都能在下面的技術圖譜中找到答案:

相關推薦