一、背景
最初遇到這個問題是去58面試。部門領導是原同事，所以面試比較水。水到什么程度呢？
面試就是走個形式而已，不會不過的。
一面面試官就問了一個問題：“一個請求過來都經過了什么?” 剩下的全是閑聊。順便展示一下公司和部門的優勢。期待加入的意思。
聲明
面試如此之松是基於兩點：
第一點，與原同事多年的共事已經展示了能力和綜合素質，比幾個小時的面試得到的結論靠譜的多。
第二點，原同事本身認人識人的能力得到了其他人的認可，所以大家放心他推薦的人。
畢竟沒人願意讓一個不合適的人加入自己團隊拉低整體水准。
二、問題考察點
深度和廣度的綜合考察
三、靜兒的答案
建立虛擬場景
☆ 項目
容器調度服務（根據用戶傳入的機房、CPU、內存等信息給用戶創建所需要的機器）。
項目所用技術棧：SpringBoot、Thrift、緩存、mysql、k8s
☆ 需求
程序中需要用thrift（RPC調用）請求基礎服務取所有的機房信息。
☆ 設計
基礎服務提供了「傻瓜式」客戶端給調用方。客戶端只需要引入jar包，就可以像調用本地接口一樣進行訪問。
客戶端實現方法
因為機房信息是低頻的、對變更一定時延不敏感的資源信息。所以客戶端首先RPC去遠程取結果放到本地JVM緩存中。每次調用直接返回JVM緩存信息。客戶端有定時任務定時將最新結果刷新到JVM緩存。
設計特點：
1、對thrift接口做封裝，封裝包括設定了遠程獲取異常的重試次數、重試間隔、遠程服務信息等。原因：基礎服務提供方自己最清楚自己服務的響應時間、服務可用性等信息，自己設置更為精確，避免對使用方造成困擾。
2、每次返回本地JVM存的機房信息。信息更新通過自帶定時任務。原因：基礎服務提供方自己最清楚自己的資源被更新頻率如何，提供數據的實時性重要性如何。怎么保持數據一致性。怎樣更高效。這些難題不應該拋給調用方。
3、懶加載處理。原因：不能因為jar包被引用就直接占用內存、CPU等資源。要按需提供。
服務端實現方法
服務端收到請求，考慮到這個是基礎服務，使用方多。為了防止壓力直接作用於數據庫，上面加了一層集中式緩存。不穿透的情況下，直接返回緩存信息。
數據庫中的所有機房信息是從k8s標簽中獲取過濾的。有變化直接刷緩存。即數據庫中存的是所有的標簽信息，其中一個小功能是從所有標簽中過濾機房標簽。這種設計是區別於有個機房管理系統錄入這種管理，機房信息永遠是實時准確的。（這塊涉及到內部系統的設計問題，如果看不懂直接忽略即可。）
☆ 請求過來經過了什么
從程序設計上，大體經過的如上圖。限於篇幅（如果你想了解不限於篇幅是個什么狀態，可以閱讀下面一篇《一個請求過來都經過了什么？(2017年http版)》），本篇不講JVM經過了怎樣的過程，主內存和工作內存交互，內存可能的分頁，numa綁核、定頻非定頻等等。深度上只介紹thrift調用這一層。
籠統的過程如上圖。大體分為三個部分：
1、有IP直接訪問IP，沒有IP通過其他信息獲取到IP。
在此部分中，第一次連接需要根據環境和服務標識獲取機器列表。客戶端一般會有本地進程代理。對於美團OCTO來說，就是Sg_Agent(服務治理代理)。代理會和OCTO服務器進行通信，及時獲取最新信息。連接建立后，下次訪問就是直接IP訪問了。
2、通過IP訪問服務端，根據類名+方法簽名獲取方法。
3、通過攔截器認證的請求被服務端處理后返回結果。
Thrift內部的架構是分層次的。客戶端和服務端都可大體分為代碼層、協議層、傳輸層、IO處理層四部分。客戶端和服務端的IO處理層直接交互。
代碼層：
代碼在美團OCTO體系中MtThrift中會直接由框架自動從java代碼轉成IDL文件，框架再根據IDL文件生成代碼實現數據的讀寫。
協議層(實現Tprotocol接口)：
將數據編碼、解碼。最三種的三種傳輸格式支持是：二進制格式、壓縮格式、Json格式。
傳輸層(實現Ttransport接口)：
提供從網絡等媒介讀取和寫入數據的方式。常用的有：向文件進行讀寫、從內存上讀寫、壓縮讀寫。
IO處理層：
這層所做的就是阻塞、非阻塞，單線程、多線程這些。一般像獲取所有機房信息這樣的讀操作用的是多線程阻塞方式。寫操作一般用多線程非阻塞方式。
再往下linux系統層的東西也是可以講講的，內容有點多，大家自己做思考題吧。還有涉及網絡傳輸的信道、全雙工傳輸模式這些，大家可以自己想一想，查一查。
四、總結
本次公眾號文章共三篇《一個請求過來都經過了什么?(Thrift版)》、《一個請求過來都經過了什么？(2017年http版)》、《思維發散的雙刃劍》。首篇是剛寫的，第二篇是17年寫的。最后一篇是一些總結思考。