架構面試筆試題目

　　經(jīng)常有朋友問(wèn)到，“感覺(jué)你們的系統最近沒(méi)什么太大變化，你們那么多工程師在忙什么?”，下面的這個(gè)場(chǎng)景，可能是工程師花費了不少時(shí)間的情況之一。

　　有如下一個(gè)場(chǎng)景，某個(gè)服務(wù)需要構建一個(gè)列表數據返回給調用方(調用方通常是客戶(hù)端)，服務(wù)本身是一個(gè)數據聚合器，它由內部多個(gè)遠程服務(wù)的數據聚合而生成。在正常情況下，需要將所有內部服務(wù)的結果全獲取成功后再返回。但是在一個(gè)大系統中，多個(gè)服務(wù)中某個(gè)服務(wù)出現不穩定的概率會(huì )比較大，當出現如圖遠程服務(wù)3不可用的時(shí)候，有三種不同的解決思路。

　　方案1：忽略出錯的數據(圖中數據3)，直接返回數據1、2、4。

　　方案2：遇到任意失敗，整個(gè)請求返回錯誤503 service unavailable。

　　方案3：忽略出錯的數據(圖中數據3)，并告知調用方出錯的范圍，需要自定義的返回格式。如 {“load_data3_success”: false}

　　如果你作為一個(gè)架構師，會(huì )選擇哪種方案?

　　方案一類(lèi)似架構設計里面常說(shuō)的優(yōu)雅降級，在出現問(wèn)題情況下，除了數據3不能返回之外，其它數據可以正常返回，原理上可以將損失降低到最低。但這種方案會(huì )給用戶(hù)體驗帶來(lái)一定傷害，用戶(hù)在使用系統時(shí)候會(huì )存在不確定性的心理感受。

　　方案二比較依賴(lài)調用方的容錯邏輯，如果調用方保存了上一次緩存，且容錯邏輯處理得當，用戶(hù)表面會(huì )感受不到這個(gè)異常。如果沒(méi)有容錯邏輯，最壞情況則將會(huì )返回白頁(yè)。但是即使有容錯邏輯，由于正常的數據也不能及時(shí)返回，從工程師到用戶(hù)可能不太容易接受這個(gè)結果。

　　方案三是一個(gè)看起來(lái)相對合理的方案，但是需要添加自定義的'字段，本來(lái)這個(gè)調用是一個(gè)標準的LIST數據返回，但如要判斷每個(gè)數據項是否返回失敗，需要額外添加一些標識字段如 {“load_data3_success”: false}，用于標識哪些數據返回失敗了。因此，接口設計及實(shí)現變得更加繁瑣，調用方也需要實(shí)現緩存及容錯邏輯，從服務(wù)方到調用方的熵都增加了很多。

　　因此，這個(gè)選擇題已經(jīng)不好做了。但雪上加霜的是，在大部分應用中，對于數據列表訪(fǎng)問(wèn)同時(shí)還存在未讀數的功能，如下圖中的小紅點(diǎn)數字。如果這個(gè)未讀數由另外一個(gè)API提供(本討論假設未讀數API功能正常)，情況就更復雜。

　　補充討論一下，如果不提供單獨的未讀數API，客戶(hù)端需要每次需要加載新的全量數據才能本地算出未讀數，會(huì )帶來(lái)訪(fǎng)問(wèn)速度的下降及客戶(hù)端更多流量的消耗。因此大多數情況提供一個(gè)未讀數API整體開(kāi)銷(xiāo)會(huì )更低。通過(guò)未讀數API判斷當服務(wù)端有新數據時(shí)候才去訪(fǎng)問(wèn)列表接口。

　　這時(shí)候如果未讀數都出來(lái)了，遠程數據又取不到的情況下，你作為架構師，會(huì )選擇何種方案?至少，碰到這種情況時(shí)如果還未找到理想方案，建議不要盲目?jì)?yōu)化，因為它除了增加系統的熵，不會(huì )將事情變得更好。

【架構面試筆試題目】相關(guān)文章：

面試會(huì )計的筆試題目12-22

小升初面試常見(jiàn)筆試題目09-09

電廠(chǎng)面試筆試題目07-12

中專(zhuān)面試筆試題目07-12

公司面試筆試題目09-08

護士面試筆試題目09-09

企業(yè)面試筆試題目08-31

華為面試代碼筆試題目08-22

小升初面試筆試及面試常見(jiàn)題目08-31