技術(shù)實力的時候，我們到底在聊什么
轉(zhuǎn)載：https://mp.weixin.qq.com/s/LZqQaKanPztUQ_-NHJAE5A
技術(shù)實力詳解
理解評估技術(shù)實力的基本原則后，我們知道了需要解決的問題復雜度越高，技術(shù)實力就越高。在這個基礎上，我把技術(shù)實力分為兩大類 6 分類：
硬實力：真正解決問題的能力，別人可以看出來的能力，技術(shù)實力按照“點、線、面、體”的 4 個分類逐層上升；
軟實力：比硬實力更厲害但也更虛的能力，簡單來說，要想解決問題首先得發(fā)現(xiàn)問題，但很多時候問題并不是一目了然的，需要有一定的技術(shù)洞察力。軟實力主要包括 2 個核心能力：發(fā)現(xiàn)問題、技術(shù)創(chuàng)新。
硬實力
我把技術(shù)硬實力分為四個等級：點、線、面、體，技術(shù)等級依次提升，解決的問題復雜度也越來越高，下面詳細解釋一下。
技術(shù)點
“點”就是某個具體的技術(shù)，用來解決某個具體的問題，例如使用 JDBC 從數(shù)據(jù)庫讀取數(shù)據(jù)，目的是解決數(shù)據(jù)掉電丟失的問題；使用 Java 多線程，目的是為了解決大量用戶并發(fā)訪問的吞吐量和時延問題。掌握了技術(shù)點，就可以開始基本的業(yè)務功能開發(fā)了。
技術(shù)線
“線”就是一系列相關(guān)的技術(shù)點組成，每個技術(shù)點都是為了解決某個問題。例如：
為了完成一個用戶請求，開發(fā)框架首先要有路由 router 功能，路由到具體 Controller 后，Controller 進行業(yè)務邏輯處理，處理過程中可能會使用 JDBC 來讀取數(shù)據(jù)，訪問 Redis 讀取緩存等，這一連串的技術(shù)每個都解決了一個問題點，串起來就完成了一個業(yè)務功能的處理過程。
為了定位一個線上 Java 服務器響應慢的問題，需要用到 tcpdump 抓包，使用 Java 工具查看 jvm 的狀態(tài)，使用 mysql 命令行或者工具查看數(shù)據(jù)庫狀態(tài)，使用 explain 分析可疑 SQL 語句。
掌握了技術(shù)線，就可以完成某個業(yè)務功能的全流程設計和開發(fā)了。
技術(shù)面
“面”就是某一類相關(guān)技術(shù)線的綜合。例如：
Java 開發(fā)是一個技術(shù)面，包括多線程、JDBC、文件讀寫、JVM 調(diào)優(yōu)、JVM 工具等多個技術(shù)線；
高性能開發(fā)是一個技術(shù)面，包括：數(shù)據(jù)庫分庫分表、緩存、多線程、HTTP 優(yōu)化等；
數(shù)據(jù)庫維護是一個技術(shù)面，包括：數(shù)據(jù)庫調(diào)優(yōu)、數(shù)據(jù)庫問題定位、高性能數(shù)據(jù)庫表設計等；
掌握技術(shù)面，已經(jīng)是某個領(lǐng)域的專家了，簡單來說就是這個領(lǐng)域的問題找你都可以搞定。
技術(shù)體
“體”就是多個技術(shù)面的綜合。
最常見的“體”就是架構(gòu)設計，對于一個大型業(yè)務或者系統(tǒng)的架構(gòu)師來說，需要掌握多個技術(shù)面，然后進行設計和取舍。例如，一個后臺架構(gòu)師需要掌握 Java 的技術(shù)面、數(shù)據(jù)庫的技術(shù)面、網(wǎng)絡的技術(shù)面等，以及業(yè)務領(lǐng)域知識。
架構(gòu)設計是橫向技術(shù)面的綜合，我稱之為廣度技術(shù)體；還有一種縱向技術(shù)面的綜合，我稱之為深度技術(shù)體。例如 Java 的開發(fā)工程師，當達到技術(shù)面的水平時掌握了“多線程、JDBC、文件讀寫、JVM 調(diào)優(yōu)、JVM 工具等”，如果需要進一步在 Java 這個領(lǐng)域提升技術(shù)，就需要向下了解操作系統(tǒng)、硬件（CPU、內(nèi)存、磁盤等），從而更好的解決某些復雜的問題，例如 Disruptor 高性能并發(fā)框架的設計。掌握了技術(shù)體，就可以進行架構(gòu)設計，或者成為某個領(lǐng)域的資深專家了，解決領(lǐng)域級的復雜問題。
軟實力
發(fā)現(xiàn)問題
有的問題很明顯，例如線上出故障，系統(tǒng)性能不達標，系統(tǒng)性能需要達到 5W QPS；但有的問題并不那么明顯，并不能一眼看出是問題在哪里，是技術(shù)問題還是管理問題。
例如我們曾遇到團隊間協(xié)作開發(fā)效率很低，每次開發(fā)一個業(yè)務功能，都需要幾個系統(tǒng)的研發(fā)人員來討論接口協(xié)議、接口數(shù)據(jù)格式、接口安全加密、業(yè)務邏輯等，大家都不厭其煩，但好像又都必不可少，團隊間為了提高效率，項目經(jīng)理制定了規(guī)范、流程、模板等，但作用最終都不大。那后來是怎么解決的呢？通過引入服務中心來完成系統(tǒng)間同步接口調(diào)用，通過引入消息隊列來完成系統(tǒng)間異步消息通知，系統(tǒng)間協(xié)作效率大大提高，以前要開會討論幾個小時的事情，現(xiàn)在只要明確接口傳輸?shù)臄?shù)據(jù)內(nèi)容即可，甚至都不用開會，兩個研發(fā)一討論就差不多了。
除此以外，問題的根源往往掩蓋在很多問題表象之下，如果不解決根源問題，解決一個表象問題，獲得一時安寧，一段時間后又發(fā)生另外的問題，長此以往反反復復。
例如我們曾有個系統(tǒng)，今天交換機故障導致業(yè)務問題，明天系統(tǒng) bug 導致業(yè)務問題，后天機柜斷電導致業(yè)務問題，還被黑客攻擊過，這些問題看起來都很獨立，問題的發(fā)生也感覺都是偶然的，按照出一個問題解決一個問題的方式也沒什么問題，但全年來看，業(yè)務就是出了很多問題，怎么解決？我們經(jīng)過分析，發(fā)現(xiàn)根本原因是業(yè)務需要異地多活，而架構(gòu)是雙機房單中心的，我們需要做到的不是避免每個問題的發(fā)生（事實上也不可能避免），而是應該做到問題發(fā)生后能夠快速處理，于是通過將架構(gòu)重構(gòu)為異地多活，重構(gòu)完成后還是有各種偶發(fā)問題發(fā)生，但對業(yè)務的影響就很小了。
發(fā)現(xiàn)問題的能力主要來源于經(jīng)驗，包括成功的經(jīng)驗、踩坑的經(jīng)驗、參考別人的經(jīng)驗，因此如果要培養(yǎng)自己這方面的能力，多思考、多總結(jié)、多學習、多參加行業(yè)交流。
技術(shù)創(chuàng)新
達到這個級別基本都是業(yè)界大神一般的級別，說實話我也沒什么經(jīng)驗，只能仰慕這些大神。
例如：
當年貝索斯要求亞馬遜公司內(nèi)的系統(tǒng)都服務化，后來是哪位大神想到可以把這個能力開放出來轉(zhuǎn)換為“云計算”？
阿里云王堅博士當年在眾人都不看好的情況下為何堅持云計算是未來？
Google 在解決大數(shù)據(jù)問題時，如何能夠提煉出三篇論文，開啟了一個大數(shù)據(jù)時代？
技術(shù)實力案例點評
一個面試者面試 Java 技術(shù)專家崗位，其中有一項項目經(jīng)驗很牛逼：XX 架構(gòu)重構(gòu)，性能提升 10 倍。于是，我針對這個項目經(jīng)驗進行了深入的考察，結(jié)果……
下面是我們大概的對話過程：
我：請簡單介紹一下這個項目重構(gòu)。
面：我們某個業(yè)務和比賽有關(guān)，每次關(guān)鍵比賽前業(yè)務訪問量是平時的 10 倍以上，原來的系統(tǒng)量一大就卡死了，用戶體驗很不好，需要重構(gòu)。
我：具體怎么做的呢？
面：我通過引入 mc 緩存，將原來直接訪問數(shù)據(jù)庫的操作改為先訪問緩存，性能比原來提升了 10 倍。我：為何你想到了引入 mc？
面：（卡了一下，有點驚訝我的問題）……我上網(wǎng)查了一下資料，很多都說 mc 能夠大幅提升性能，并且使用后確實效果很好。
[點評 1] 這是典型的“代碼靠抄，方案靠搜，效果靠試”，面試者看到了一個問題，但沒有分析和思考，然后上網(wǎng)搜方案，看到了好像很多人都說引入 mc 都能解決問題，于是嘗試引入了 mc，最終確實好像解決了，這讓面試者自我感覺良好。
為何我在面試的時候問“為何引入”，這是不是一種“面試造航母，入職擰螺絲”的裝逼面試呢？其實不然，我們的業(yè)務中遇到性能瓶頸的問題是非常常見的，而簡單的“性能瓶頸”只是一個表象，我們看看可能的原因有哪些：
數(shù)據(jù)庫慢查詢，例如不合理的查詢、沒有索引、表數(shù)量太大等；
并發(fā)設計不合理，例如多線程鎖設計不合理，采用了不合理的 Reactor 模型等；
代碼邏輯不合理，例如本來可以異步處理的也采用了同步處理，某個循環(huán)里面重復訪問數(shù)據(jù)庫，某個接口打印了大量日志等；
外部系統(tǒng)性能低，例如依賴的某個系統(tǒng)性能低，太多無效的外部接口請求等；
數(shù)據(jù)訪問不合理，例如沒有用緩存，沒有分頁等；
非核心業(yè)務和核心業(yè)務互相影響；
以上僅僅是舉例，還有更多可能的原因，如果一個技術(shù)專家不具備“面”的技術(shù)，只知道 mc 可以提升性能這個“點”的技術(shù)，是遠遠不夠的，一次運氣好能解決問題，但不可能次次都運氣好。
當然，如果面試的是“Java 高級開發(fā)工程師”，面試重點和面試問題又不一樣了。
我：mc 能大幅提升性能的原理是什么？
面：緩存訪問快，數(shù)據(jù)庫訪問慢。
我：那 mc 性能多高，數(shù)據(jù)庫性能多高？
面：……（想了 10 秒）抱歉，沒有研究過。
[點評 2] 這是典型的知其然不知其所以然，開源方案拿來就用，基本的測試和原理研究都沒做過。大部分人對于很多概念的理解都是“性能高”，“可靠性好”，“聽說很厲害”，但在具體設計的時候，這個理解是遠遠不夠的，一定要量化，例如：同樣是負載均衡，Nginx 的性能量級是萬級，LVS 是 10 萬級，F(xiàn)5 這類設備是百萬級（具體數(shù)值和硬件以及數(shù)據(jù)包大小相關(guān)，這里只給量級）。
為何要研究原理呢？以 mc 為例，一致性 hash 和擴容相關(guān)，內(nèi)存分配方式和緩存容量有關(guān)，如果這些都不清楚，實際應該部署多少 mc 節(jié)點，每個節(jié)點應該分配多少內(nèi)存，這些都沒法確定。
我：沒關(guān)系，那我們換個問題，重構(gòu)后你們的系統(tǒng)用到的機器數(shù)量是多少？相比重構(gòu)前減少了多少？
面：機器數(shù)量是 100 臺，相比重構(gòu)前沒有減少。
我：哦，100 臺機器，QPS 每臺才 300 多，我看你們的業(yè)務也不是很復雜，為何這么低？
面：……（卡住 10 秒）這……300 多 QPS 好像也不低吧？
我：那你有沒有分析過每次請求全流程每個階段的性能耗時？瓶頸在哪里？
面：（卡住 5 秒）沒有分析過呢？
我：那為何就認定引入 mc 就有效果？
面：……（卡住 10 秒）我看大家都說引入緩存能大幅提升性能，而且最終效果確實很好。
[點評] 這就是知道技術(shù)點，不知道技術(shù)線和技術(shù)面，按道理對于系統(tǒng)性能問題的分析，至少是技術(shù)線級別的，需要分析每個請求每個階段的耗時和原因；也可以是技術(shù)面級別的，例如分析數(shù)據(jù)庫的設計、服務器的負載均衡等，還可以是技術(shù)體級別的，例如架構(gòu)是否合理，是否可以將某個子系統(tǒng)拆分，引入消息隊列等。
我：好吧，換個問題，如果讓你再一次優(yōu)化系統(tǒng)，你覺得可以怎么做？
面：……（思考 20 秒）我覺得目前的系統(tǒng)性能已經(jīng)足夠，應該不需要優(yōu)化了。
[點評] 考察的是發(fā)現(xiàn)問題的能力，但他發(fā)現(xiàn)不了問題，其實前面已經(jīng)都提到了，100 臺機器就是問題，QPS 過低也是問題，但由于他沒有經(jīng)驗，是看不出這些問題的。
很遺憾，最終這個面試者沒有通過面試。
寫在最后
對于技術(shù)人員實力的判斷，并不存在完全客觀和可量化的標準，多少都帶有評判者的主觀判斷，這也是最容易產(chǎn)生爭議的地方，本文也是我自己的一個思考和總結(jié)，一家之言，拋磚引玉，歡迎大家探討交流。
