大廠微服務及後端基礎若干面試題總結

shanyue發表於2019-12-27

我在 github 上新建了一個倉庫 日問,每天一道面試題,有關前端,後端,devops以及軟技能,促進職業成長,敲開大廠之門,歡迎交流

並且記錄我的面試經驗

ali 為 ali,為避內容檢查

以下是總結的問題,我將在本週末補充答案,另外也歡迎各位補充答案

分類

計算機與程式設計基礎

計算機網路 | 演算法與資料結構 | 作業系統 | Linux基礎 | http | vim | git

前端

CSS | Javascript | html | React | Vue | Webpack | 前端工程化

後端

後端基礎 | 資料庫 | Redis | 微服務架構

DevOps

DevOps | Docker | kubernetes

開放式問題

開放式問題

歷史記錄

檢視所有問題

01 生產環境的某個介面報錯,如何定位

在 Issue 中交流與討論: Issue 地址

  1. 測試環境有沒有問題,有問題可以在測試環境測試
  2. 有沒有異常報警系統,如 sentry,如果有在 sentry 中檢視堆疊資訊以及相關上下文,定位程式碼
  3. 如果堆疊資訊不足夠找到問題,看有沒有鏈路追蹤工具,如 zipkin。從 sentry 中找到 requestId,在資料庫日誌/上下游鏈路日誌中查詢對應 requestId 的日誌
  4. 檢視介面相關程式碼

既然報錯,那麼一定會在異常上報系統中找到 Issue 進行定位。最怕的是那種介面沒報錯,但是業務方反饋資料有誤的問題了,只能開了 debug,進行程式碼除錯了

02 後端的敏感資料在生產環境是如何配置的

更多描述: 後端的敏感資料在生產環境是如何配置的,如資料庫的賬號密碼,jwt 的 secret,聯調上游服務的 token 等

在 Issue 中交流與討論: Issue 地址

目前我們的方式是在每次部署之前,在 vaultconsul 拉取敏感資料,寫在配置檔案中

另外,還有幾種可選的方案

  1. 跟隨 CI/CD 的環境變數,敏感配置放在 CI 平臺
  2. 跟隨 k8s secret/configMap,敏感配置放在 k8s 叢集
  3. 跟隨專有的配置服務,如 consul/vault

03 如何實現一個分散式鎖

在 Issue 中交流與討論: Issue 地址

04 websocket 服務多節點部署時會有什麼問題,怎麼解決

在 Issue 中交流與討論: Issue 地址

多節點問題

在開始思考分散式會有什麼問題時,先來回答一個問題: 服務端如何與客戶端交流?

在 ws 服務端,當與客戶端連線成功後,會生成一個物件 connection,ws 會維護一個與客戶端所有連線的 connections。如果想要主動推送訊息到客戶端,只需要呼叫API connection.sendText(message)

那如何給所有人廣播訊息呢?

伺服器只需要與它自身的所有連線 server.connections 挨個發訊息就是廣播,所以它只是一個偽廣播:我要給群裡所有人發訊息,但我不能在群裡發,只能挨個私發。

單節點

當單節點時所有使用者都能正常受到通知,流程如下

ws 單節點時

這時所有使用者都能收到訊息通知

多節點

當多節點時,就會有部分使用者無法正常受到通知,從以下流程圖中可以很清楚地看到問題所在

ws 多節點時

負載到節點2的所有使用者都沒有收到訊息通知

如何解決

多節點伺服器就會有分散式問題,解決分散式問題就找一個大家都能找到的地,比如說 Redis,比如說 Kafka 等訊息件

改進後流程圖如下

  1. 需要向所有使用者推送訊息,請求 websocket 服務
  2. 負載均衡到某個節點
  3. 該節點向 redis/kafka 推送訊息: 向所有使用者推送訊息通知
  4. 所有節點在 redis/kafka 上訂閱訊息
  5. 訂閱成功後所有節點向客戶端 push 訊息

借用 redis

redis PUBSUB

其中有一個細節是 pub/sub 那裡,redis 的 pubsubKafka 等訊息中介軟體更為輕便,最主要的是與ws整合的社群方案比較成熟,這點很重要,如 Node 中的以下兩個

pubsub 在 redis 中的命令如下

  • pub: publish channel message
  • sub: subscribe

如果我們要訂閱 eat 這個 channel 的話,圖示如下

redis pubsub example

進一步追問

面試官見我回答完問題後,又一次追問

那 websocket 如何向特定的使用者組推送訊息?

假如一個學校有以下資料結構

  1. Class: 代表班級
  2. Student: 代表學生,每個學生都在其中一個班級

那假如要向 Class:201901 班級的所有學生髮送通知,應該如何實現

歡迎在 Issue 中討論: 【Q029】websocket 如何向特定使用者組推送訊息

小結

借用解決方案的圖作為小結

借用 redis

05 如何對介面進行壓力測試

在 Issue 中交流與討論: Issue 地址

$ ab
複製程式碼

06 websocket 如何向特定的使用者組推送訊息

更多描述: 假如一個學校有以下資料結構
  1. Class: 代表班級
  2. Student: 代表學生,每個學生都在其中一個班級

那假如要向 Class:201901 班級的所有學生髮送通知,應該如何實現

在 Issue 中交流與討論: Issue 地址

redis 處維護一個物件,記錄每個 group 所對應的 connections/sockets

{
  'Class:201901': [student1Socket, student2Socket]
}
複製程式碼

當 client 剛連入 server 時,便加入某個特定的組,或者叫 room,比如 student01,剛開始連入 server,可能要加入 room:Student:01Class:201901Group:10086

07 如何對介面進行限流

在 Issue 中交流與討論: Issue 地址

一般採用漏桶演算法:

  1. 漏桶初始為空
  2. API 呼叫是在往漏桶裡注水
  3. 漏桶會以一定速率出水
  4. 水滿時 API 拒絕呼叫

漏桶演算法

可以使用 redis 的計數器實現

  1. 計數器初始為空
  2. API 呼叫計數器增加
  3. 給計數器設定過期時間,隔段時間清零,視為一定速率出水
  4. 計數器達到上限時,拒絕呼叫

當然,這只是大致思路,這時會有兩個問題要注意

  1. 最壞情況下的限流是額定限流速率的2倍
  2. 條件競爭問題

不過實際實現時注意以下就好了(話說一般也是呼叫現成的三方庫做限流...),可以參考我以前的文章 shanyue.tech/post/rate-l…

08 如何設計一個高併發系統

在 Issue 中交流與討論: Issue 地址

09 什麼是服務降級

在 Issue 中交流與討論: Issue 地址

10 什麼是熔斷機制,微服務如何做熔斷

在 Issue 中交流與討論: Issue 地址

11 什麼是負載均衡

在 Issue 中交流與討論: Issue 地址

12 四層負載均衡與七層負載均衡有什麼區別

在 Issue 中交流與討論: Issue 地址

13 你們專案中的計劃任務是如何組織的

在 Issue 中交流與討論: Issue 地址

14 RPC 與 REST 有什麼優劣

在 Issue 中交流與討論: Issue 地址

15 如何實現服務發現 (Service Discovery)

在 Issue 中交流與討論: Issue 地址

那 k8s 的服務發現是如何實現的

16 如何設計一個短網址生成服務

在 Issue 中交流與討論: Issue 地址

17 你們後端程式碼上線部署一次需要多長時間

在 Issue 中交流與討論: Issue 地址

18 什麼是 Basic Auth 和 Digest Auth

在 Issue 中交流與討論: Issue 地址

19 如何保證內網服務的安全性

更多描述: 如 `gitlab CE` 經常暴露出重大漏洞,而它也只需要在公司內部使用。部署 `gitlab` 時我們如何保證它的安全性

在 Issue 中交流與討論: Issue 地址

basic auth,digest auth,ip whitelist,vpn

20 負載均衡有哪幾種方式,它們的原理是什麼

在 Issue 中交流與討論: Issue 地址

我是山月,可以加我微信 shanyue94 與我交流,備註交流。另外可以關注我的公眾號【全棧成長之路】

如果你對全棧面試,前端工程化,graphql,devops,個人伺服器運維以及微服務感興趣的話,可以關注我

相關文章