目錄
1、業務背景介紹
2、架構演進考察
3、對公司底層技術的原理考察
4、系統難點的考察
5、擅長技術的考察
6、總結
“ 這篇文章，給大家分享一個同學面試阿里某個部門時的經歷。
簡單說一下這個同學面試的背景，本身技術底子還不錯，在幾個有一定知名度的中型網際網路公司工作過，然後之前打算嘗試一下阿里的職位，就去面試了。
第一輪和第二輪面試，全部都通過了，面試官評價也是基本技術素養還可以，基礎也不錯，定級都是P6+的職級。
但是第三面是那個部門老大P9出來面試他，結果就掛在這裡了，所以把這個第三面的一些問題分享出來，給大家參考。
1、業務背景介紹
首先這個同學上來先闡述了一下自己的一些專案經歷，當前他在公司裡主要是負責一個資料類的系統，業務邏輯並不複雜，但是有一點技術難度。
主要是每天都會有人呼叫他的介面，然後有資料會落入資料庫表中。
簡化一下來說，大概是這個背景，如下圖：
這個系統每天介面呼叫大概會落入資料庫中有20萬左右的資料量，那麼每個月大概是600萬左右的資料量，每年大概是近億級的資料量會落入資料庫中。
但是這是針對整個資料庫來說的，平攤到裡面核心的每個表，大概每個表每年新增個千萬級別的資料量。
2、架構演進考察
系統就是這麼個情況，接著面試官就開始發問了。。。
面試官
現在你的系統壓力其實不大，每天20萬新增資料量也不大，每年哪怕單表新增千萬級資料其實也還算可以接受。
第一個問題：如果假設你的系統承載的業務量翻了10倍，每天新增200萬資料，你的系統架構要如何演進？
如果你的系統承載的業務量翻了100倍，每天新增2000萬資料，你的系統架構要如何演進？
候選人
這個。。。我們還沒這種需求，所以我暫時還沒想過這個問題。。。
面試官
心想：（這小夥子想面P6+ ？那是資深Java職位，起碼得有點架構演進的意識吧，怎麼一點意識都沒有）
面試官對面試者的印象有點扣分了。。
【旁白解讀】
實際上這類問題在BAT、美團、京東等大公司裡面試，都是常問的，為什麼呢？
因為大公司裡的系統面對的就是業務經常翻倍的增長，系統壓力越來越大，所以每年都要做幾次技術升級，一直要進行架構演進。
所以在網際網路公司裡，架構設計能力中非常關鍵的一環，就是針對業務增長，架構演進的能力是非常核心的。
你要有一個意識說如果你的業務量10倍增長，100倍增長，你的系統架構要如何演進？這幾乎是資深工程師必須要有的一個意識和能力。
其實大家可以思考一下，如果10倍增長，單表每年新增近億資料，還能用單庫單表的方式來承載嗎？
肯定不行了，所以必然針對10倍增長的場景，需要引入分庫分表的技術，保證每個庫每個表分散一定的資料量，避免單表單庫資料量過大。
那麼大家再思考一下，如果100倍增長呢，每年單表新增近10億資料，你分庫分表也不一定夠了。因為此時可能會有高併發訪問的問題，資料庫抗起來很吃力。
此時，你要不要考慮資料異構、冷熱分離等資料儲存的架構設計？
比如採用MySQL分庫分表 + 分散式NoSQL資料庫 + Elasticsearch分散式搜尋 + Redis快取的架構，來整體設計這個資料儲存架構。
你可以先做冷熱分離的架構，比如最熱的資料放入分散式NoSQL資料庫，專門承載當日資料的高併發寫入，以及高效能的讀寫。
然後每過一段時間，做資料歸檔，把NoSQL裡不再頻繁使用的冷資料遷移到MySQL裡去歸檔。
最後就是應對海量資料的檢索，可以把索引構建在Elasticsearch裡來應對，但是從NoSQL+MySQL的異構儲存來提取明細資料即可。
而且針對一些特別熱查詢的資料，可以依託Redis做一個快取。
其實那個P9面試官的面試評價裡，期望的也是候選人把這一套架構說出來。雖然P6+的職級不一定說有能力完全hold住這個架構，但是起碼要有這個意識。
結果候選人完全什麼都說不出來，那當然會讓人很失望了。
3、對公司底層技術的原理考察
這位同學他們的系統有一部分的資料是放在特殊儲存服務裡的，用的是雲平臺上的儲存服務，而且存放在儲存服務裡的資料還是很核心的資料。
所以面試官就開始問第二個問題了。
面試官
你能說說你對這種特殊儲存服務的理解嗎，他的原理是什麼？
你們用的雲平臺上的服務儲存他的架構是什麼樣的，你們的儲存是如何規劃的？
候選人
我。。。一般是呼叫API往裡面寫資料，詳細的還沒太多關注過
面試官
心想：（ 搞什麼鬼，核心資料放這種特殊的儲存服務裡，結果從沒關注過，起碼也得了解一下他的原理，把人家的文件仔細看幾遍吧 ）
（ 而且對於自己的儲存是如何規劃的，容量是否充足，他是怎麼擴容的，怎麼什麼都不知道 ）
【旁白分析】
這是該同學犯的第二個錯誤，不說資深工程師，就說作為一個高階工程師，應該對自己負責的系統使用到的方方面面都有一定的瞭解。
比如你要是用了語音轉換API，或者是快遞公司的查詢API，那你起碼知道人家背後大致在幹什麼，或者問清楚人家API的QPS極限，以及你們的訪問量是多少。
你們用了特殊的儲存服務，起碼知道那種儲存服務的實現原理是什麼，儲存的容量規劃等等問題，這是一個高階工程師hold住自己工作的起碼工作素養。
4、系統難點的考察
面試氣氛尷尬，不過仍然繼續。。。
面試官
那你覺得你們這個系統最大的技術難點是什麼？
候選人
我想想（思索10秒後）。。。好像沒什麼難的，主要就是一些介面，然後資料就落入資料庫了。。。
面試官
心想：（這傢伙難道在公司混日子？）
【旁白分析】
大公司面試一定會問你係統的難點是什麼，這代表你的專案經驗有多少含金量。
哪怕你們專案很low，你硬湊平時也得想辦法弄點新技術進去，沒難點也要湊點兒難點出來，否則去面試必然給人鄙視。
舉個例子，比如上面的這個系統，實際上他有一個步驟是要做資料遷移，也就是說把資料庫裡可能幾百萬資料量，一次性遷移到另外一套儲存裡去
那麼這個資料遷移的步驟，其實涉及到千萬級的資料量遷移。
你如何保證資料遷移的效率？如何保證遷移後的資料準確性？在遷移的過程中如何避免影響資料庫的效能？
像這些問題，其實你平時都應該考慮一下，作為一個技術難點好好闡述一下吧。
5、擅長技術的考察
面試官
那你說說你認為自己最擅長最有深度的技術吧
候選人
我好像平時自己用MQ技術比較多一些
面試官
那你說說Kafka、RabbitMQ、RocketMQ幾種MQ的對比，還有他們各自的原理。
它們分別如何實現分散式訊息佇列架構的，底層的機制都聊一下，對比一下特點以及優缺點。
候選人
心想：（。。。我要回家！）
【旁白分析】
大公司一定會考察你的技術深度，一般就是對你平時用的最多，或者最熟悉的技術深入挖掘和考察，看你的技術深度有多深。
結果這個同學自己說了MQ，但是對MQ的瞭解實際上非常的淺薄，深入的東西都說不出來，那麼最後一定就是讓面試官很無語了。
6、總結
其實這個同學技術底子還是不錯的，包括一些技術的基礎，所以前兩輪面試都是過了的。但是第三輪面試考察的角度都是完全不同的，一下子暴露出來了他的能力缺陷。
對自己負責系統的架構演進完全無意識，負責系統的難點從沒思考過，系統涉及的一些技術的細節不瞭解，沒有技術深度的積累，都導致他在三面表現很不好，最後就是直接掛掉。
所以希望大家通過這篇文章，吸取這位同學的經驗教訓，平時多思考自己負責系統的技術難點，以及業務量成倍增長時架構如何演進，系統涉及到的各種技術的細節，以及積累相關技術的技術深度。
一大波微服務、分散式、高併發、高可用的原創系列文章正在路上,
歡迎關注公眾號：石杉的架構筆記
週一至週五早八點半！精品技術文章準時送上！！！
十餘年BAT架構經驗傾囊相授