架構(gòu)面試筆試題目
經(jīng)常有朋友問到，“感覺你們的系統(tǒng)最近沒什么太大變化，你們那么多工程師在忙什么?”，下面的這個(gè)場景，可能是工程師花費(fèi)了不少時(shí)間的情況之一。
有如下一個(gè)場景，某個(gè)服務(wù)需要構(gòu)建一個(gè)列表數(shù)據(jù)返回給調(diào)用方(調(diào)用方通常是客戶端)，服務(wù)本身是一個(gè)數(shù)據(jù)聚合器，它由內(nèi)部多個(gè)遠(yuǎn)程服務(wù)的數(shù)據(jù)聚合而生成。在正常情況下，需要將所有內(nèi)部服務(wù)的結(jié)果全獲取成功后再返回。但是在一個(gè)大系統(tǒng)中，多個(gè)服務(wù)中某個(gè)服務(wù)出現(xiàn)不穩(wěn)定的概率會比較大，當(dāng)出現(xiàn)如圖遠(yuǎn)程服務(wù)3不可用的時(shí)候，有三種不同的解決思路。
方案1：忽略出錯(cuò)的數(shù)據(jù)(圖中數(shù)據(jù)3)，直接返回?cái)?shù)據(jù)1、2、4。
方案2：遇到任意失敗，整個(gè)請求返回錯(cuò)誤503 service unavailable。
方案3：忽略出錯(cuò)的數(shù)據(jù)(圖中數(shù)據(jù)3)，并告知調(diào)用方出錯(cuò)的范圍，需要自定義的返回格式。如 {“load_data3_success”: false}
如果你作為一個(gè)架構(gòu)師，會選擇哪種方案?
方案一類似架構(gòu)設(shè)計(jì)里面常說的優(yōu)雅降級，在出現(xiàn)問題情況下，除了數(shù)據(jù)3不能返回之外，其它數(shù)據(jù)可以正常返回，原理上可以將損失降低到最低。但這種方案會給用戶體驗(yàn)帶來一定傷害，用戶在使用系統(tǒng)時(shí)候會存在不確定性的心理感受。
方案二比較依賴調(diào)用方的容錯(cuò)邏輯，如果調(diào)用方保存了上一次緩存，且容錯(cuò)邏輯處理得當(dāng)，用戶表面會感受不到這個(gè)異常。如果沒有容錯(cuò)邏輯，最壞情況則將會返回白頁。但是即使有容錯(cuò)邏輯，由于正常的數(shù)據(jù)也不能及時(shí)返回，從工程師到用戶可能不太容易接受這個(gè)結(jié)果。
方案三是一個(gè)看起來相對合理的方案，但是需要添加自定義的'字段，本來這個(gè)調(diào)用是一個(gè)標(biāo)準(zhǔn)的LIST數(shù)據(jù)返回，但如要判斷每個(gè)數(shù)據(jù)項(xiàng)是否返回失敗，需要額外添加一些標(biāo)識字段如 {“load_data3_success”: false}，用于標(biāo)識哪些數(shù)據(jù)返回失敗了。因此，接口設(shè)計(jì)及實(shí)現(xiàn)變得更加繁瑣，調(diào)用方也需要實(shí)現(xiàn)緩存及容錯(cuò)邏輯，從服務(wù)方到調(diào)用方的熵都增加了很多。
因此，這個(gè)選擇題已經(jīng)不好做了。但雪上加霜的是，在大部分應(yīng)用中，對于數(shù)據(jù)列表訪問同時(shí)還存在未讀數(shù)的功能，如下圖中的小紅點(diǎn)數(shù)字。如果這個(gè)未讀數(shù)由另外一個(gè)API提供(本討論假設(shè)未讀數(shù)API功能正常)，情況就更復(fù)雜。
補(bǔ)充討論一下，如果不提供單獨(dú)的未讀數(shù)API，客戶端需要每次需要加載新的全量數(shù)據(jù)才能本地算出未讀數(shù)，會帶來訪問速度的下降及客戶端更多流量的消耗。因此大多數(shù)情況提供一個(gè)未讀數(shù)API整體開銷會更低。通過未讀數(shù)API判斷當(dāng)服務(wù)端有新數(shù)據(jù)時(shí)候才去訪問列表接口。
這時(shí)候如果未讀數(shù)都出來了，遠(yuǎn)程數(shù)據(jù)又取不到的情況下，你作為架構(gòu)師，會選擇何種方案?至少，碰到這種情況時(shí)如果還未找到理想方案，建議不要盲目優(yōu)化，因?yàn)樗嗽黾酉到y(tǒng)的熵，不會將事情變得更好。
【架構(gòu)面試筆試題目】相關(guān)文章：
面試會計(jì)的筆試題目12-22
小升初面試常見筆試題目09-09
電廠面試筆試題目07-12
中專面試筆試題目07-12
公司面試筆試題目09-08
護(hù)士面試筆試題目09-09
企業(yè)面試筆試題目08-31
華為面試代碼筆試題目08-22
小升初面試筆試及面試常見題目08-31