一個請求過來都經過了什麼?(Thrift版)

一、背景

最初遇到這個問題是去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年寫的。最後一篇是一些總結思考。