如何處理分佈式系統中的緊急情況？

作者 | Gregory Pabian

策劃 | 凌敏

由於發生意外或遭受攻擊，任何分佈式系統都可能會遇到緊急情況。即便是像執行腳本這樣看似無害的操作，也可能會對整個平臺造成嚴重破壞，最終導致用戶無法使用。本文作者分享了軟件開發者在緊急情況發生之前爲系統做好準備的一些方法。

1 應急預案

我相信系統設計者可能會考慮準備一個應急預案，至少要知道如何保護一個分佈式系統不受內外威脅。我從各種 OWASP（即 Open Web Application Security Project，開放式 Web 應用程序安全項目，是一個在線社區，在 Web 應用安全領域提供免費的文章、方法、文檔、工具和技術。）資源中學到了很多關於網絡應用安全的知識。

• 誰可以啓動應急預案，以及有哪些權利；

• 應急預案實施期間將發生什麼情況，在哪裏發生；

• 如何纔能有人啓動應急預案，將會持續多久。

2 時間框架

• 過去和未來：系統會根據指定的過去和所有未來事件改變其行爲；

• 未來：系統會根據所有未來事件改變其行爲。

當然，並非所有的分佈式系統都支持逆行性行爲變更。在使用長時間運行事務的系統中，遵守這樣的轉換要求執行補償性事務，這樣才能明顯消除原始過去事務的影響。

3 解決方案

無狀態協議中阻止訪問

阻止特定的訪問令牌（例如 JWT）可以說是通過限制特定用戶對資源的訪問來解決緊急情況的最精確的方法。若攻擊者已獲得訪問令牌，並且可能將其用於非法用途，則系統可應用此解決方案。根據暴露程度的不同，此解決方案可以影響到一個或多個後端。

系統也可以組織訪問特定的訪問方法（例如 HTTP 端點或 RPC）。如果系統管理員不知道特定攻擊者的訪問令牌，或者由於最新的部署，端點無法正常工作，那麼他們可能會選擇此解決方案。在選擇用這種方法解決問題之前，我認爲人們應該考慮一下鎖定整個功能的後果，以及如何與最終用戶溝通這個選擇。

在阻止某些服務中的某些訪問方法無效的情況下，可以考慮關閉該服務。在分佈式系統中，這相當於禁止在相關服務實例中向負載均衡器轉發請求，或者終止所有以上實例。不管選擇哪種解決方案，都會對系統造成嚴重的影響，因爲很多功能已經不能工作了。

最後，系統管理員可以決定關閉整個系統（或者至少所有後端）。關閉分佈式系統的精確算法在很大程度上取決於其基礎設施和使用的冗餘。若有人考慮到這一可能性，則應考慮到後果，因爲除了某些可能在離線模式下工作的前端功能外，系統將會停止工作。

基於消息的系統中阻止訪問

系統管理員可以禁止在基於消息的系統內共享特定的消息。有些情況下，消息代理可以應用此類策略，而有些情況下，這一工作屬於後端。這樣的規則，讀者可以將其視爲判定函數，它接受一個參數、一條消息，然後返回一個布爾值。

另外，人們可以選擇阻止特定的主題或通道分發消息。它會間接地影響依賴這種通信方式的後端。此外，人們也可以禁止某種服務通過某一主題或通道收發消息。

最後，有人可能會決定阻止整個消息管道。與關閉整個系統一樣，這種解決方案對系統內的通信產生巨大影響，並可能導致多個功能失效。軟件開發者在出現這種情況之前，應該弄清楚哪些功能可能會崩潰。

回滾事務

在後端向關係數據庫提交某些事務之前，系統可能會回滾它們。這類規則的應用要求對後端架構進行有效性檢查，並確保後端能夠及時接收策略變更信息。此解決方案可以作爲取消已啓動事務的示例。

對於使用依賴注入的後端，一個基於緊急情況的限制列表可以駐留在所有請求或消息處理程序重用的組件中。人們可以使用全局變量實現類似的結果，但是我不贊成這種方法。

處理程序可以運行一個檢查函數，以驗證對於當前評估的請求是否存在某些限制。當系統使用緊急編排時，接受緊急通告的後端需要與系統的其他部分通過無狀態請求或消息管道共享信息。若後端無法執行此操作，則將阻止應急響應的傳播。系統設計者應該找到避免這個障礙的方法，例如，讓前一個服務等待下一個服務確認信息處理，然後繼續進行處理。

4 總結

在本文的開頭，我已經指出，由於不同的系統使用不同的模式進行後端到後端的通信，所以在分佈式系統中處理緊急情況的方法多種多樣。我認爲，嘗試將危機應對措施融入開發中的系統中，或許可以爲系統設計提供許多參考。

作者介紹：

Gregory Pabian，全棧軟件開發者，熱愛構建產品。

原文鏈接：

https://levelup.gitconnected.com/emergencies-in-distributed-systems-9f93c6d75600

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/ziHgqW2Xg-qxdHx18u7dCQ