有如下一個場景，某個服務需要構建一個列表數據返回給調用方(調用方通常是客戶端)，服務本身是一個數據聚合器，它由內部多個遠程服務的數據聚合而生成。在正常情況下，需要將所有內部服務的結果全獲取成功後再返回。但是在一個大系統中，多個服務中某個服務出現不穩定的概率會比較大，當出現如圖遠程服務3不可用的時候，有3種不同的解決思路。
方案1：忽略出錯的數據(圖中數據3)，直接返回數據1、2、4。
方案2：遇到任意失敗，整個請求返回錯誤503 service unavailable。
方案3：忽略出錯的數據(圖中數據3)，並告知調用方出錯的範圍，需要自定義的返回格式。如 {“load_date3_success”: false}
如果你作爲一個架構師，會選擇哪種方案？
方案一類似架構設計裏面常說的優雅降級，在出現問題情況下，除了數據3之外，其它數據可以正常返回，原理上可以將損失降低到最低。但會給用戶體驗帶來一定傷害，並且用戶在使用系統時候會存在不確定性的心理。
方案二比較依賴調用方的容錯邏輯，如果調用方存在上一次緩存且容錯處理得當，用戶表面會感受不到這個異常，否則將會返回白頁(最壞結果)。即使調用方有容錯邏輯，但由於正常的數據不能及時返回，從工程師到用戶可能不太容易接受這個結果。
方案三是一個看起來相對合理的方案，但是需要添加自定義的字段，本來這是一個標準的LIST返回，但是需要額外添加一些錯誤字段如 {“load_date3_success”: false}來標識哪些數據返回失敗了。同時在調用方也需要實現緩存及容錯邏輯。這個方案從服務方到調用方的熵都增加了很多。
在大部分應用中，對於數據列表訪問同時還存在未讀數的功能，如下圖中的小紅點數字。如果這個未讀數由另外一個API提供(假設這個API功能是正常的)，情況就更復雜。如果不提供單獨的未讀數API，客戶端則通常每次需要加載全量新數據才能算出未讀數，即使在用戶不展開列表的情況下，這樣會帶來訪問速度的下降及客戶端更多數據流量的消耗。因此大多數情況提供一個未讀數API整體開銷會更低。
這時候如果未讀數都出來了，遠程數據又取不到的情況下，你作爲架構師，會選擇何種方案？
建議繼續學習：
- 整理了一份招PHP高級工程師的面試題 (閱讀：6469)
- 海量數據面試題舉例 (閱讀：6225)
- 有道面試總結 (閱讀：4946)
- 騰訊php程序員面試題目答案 (閱讀：4914)
- 加州求職記 (閱讀：4843)
- 如何在面試中發現優秀程序員 (閱讀：4788)
- 面試IT業界頂尖企業所應該知道的10道題(1) (閱讀：4037)
- IBM面試記 (閱讀：3809)
- 聊聊ThoughtWorks面試 (閱讀：3788)
- 技術人員如何去面試？ (閱讀：3775)
