0 大綱 Lower the Timeouts, and Let the Service Fail Early Add Circuit Breakers Capacity Planning Add monitoring and alerting Implement Structured Loggin ...
0 大綱
- Lower the Timeouts, and Let the Service Fail Early
- Add Circuit Breakers
- Capacity Planning
- Add monitoring and alerting
- Implement Structured Logging
- Use Idempotency Keys
- Be Consistent with Reconciliation
- Incorporate Load Testing
- Get on top of incident management
- Organize Incident Retrospectives
1 降低超時時間,讓服務儘早失敗
預設超時時間為 60 秒。根據 Shopify 的經驗,5 秒的讀取超時時間和 1 秒的寫入超時時間是不錯的設置。
超時時間也可以在數據存儲中設置。例如,MySQL 有 MAX_EXECUTION_TIME 優化提示,用於以毫秒為單位設置每個 SELECT 查詢的超時時間。
Go 中的 http.Client 和 Node.JS 中的 http.request 等其他編程語言中的 HTTP 客戶端根本沒有預設超時時間!這意味著一個無響應的伺服器可能會無限期地占用您的資源,並不必要地增加基礎架構費用。
2 添加斷路器
Shopify 開發了 Semian 來使用 Ruby 中的斷路器來保護 Net::HTTP、MySQL、Redis 和 gRPC 服務。
通過在檢測到服務已關閉時立即引發異常,他們通過不等待預期會發生的另一次超時來節省資源。
就像在家中或公寓中會發現的斷路器一樣,一旦斷路器打開或觸發,就沒有什麼可以通過。
3 容量規劃
如果我們的隊列中有 50 個請求到達，處理一個請求平均需要 100 ms，那吞吐量是每秒 500 個請求。
N+1 查詢會增加請求的延遲並降低吞吐量。
capacity = throughput x latency
4 添加監控和告警
谷歌的站點可靠性工程(SRE)書中列出了一個面向用戶的系統應該監控的四個黃金信號: 延遲、流量、錯誤和飽和度。
5 實現結構化日誌記錄
將日誌存儲在集中地方,並使它們易於搜索。
指標提供了系統行為的高級概述,而日誌記錄允許我們瞭解單個 Web 請求或後臺作業內部發生的事情。
在分散式系統中,傳遞某種關聯標識符很有用。一個假設的例子是當買家在結賬時啟動支付,關聯_id 由我們的 Rails 控制器生成。
6 使用冪等鍵
確保支付或退款只發生一次,儘管偶爾會出現小故障。
請改用通用唯一辭彙排序標識符 (ULID) 作為這些冪等鍵,而不是隨機版本 4 UUID。
在 Shopify 的規模下,每一百萬次不可靠的支付處理機會意味著它每天發生很多次。如果這是超時的支付 API 調用,他們希望重試請求,但要安全地進行重試。
7 與調節保持一致
在資料庫中存儲與 Shopify 的金融合作伙伴的調節中斷。
通過調節,他們確保自己的記錄與金融合作伙伴的記錄一致。他們調節單個記錄,如費用或退款,以及尚未支付給商戶的當前餘額等彙總記錄。
8 結合負載測試
如果傳入工作的數量足夠大,他們的伺服器甚至會耗盡記憶體來存儲隊列上的工作並崩潰。
Shopify 定期模擬大量搶購活動以獲得基準測試結果。
9 掌握事件管理
事件通常從值班服務所有者收到頁面開始,這可能是基於監視的自動警報,也可能是如果有人註意到問題,他們會手動發送。
每個事件通道都有 3 個角色:值班事件管理器(IMOC)、支持響應管理器(SRM)和服務所有者。
10 復盤
對於每個事件,Shopify 會提出 3 個問題:確切發生了什麼?他們對系統有什麼錯誤的假設?他們可以做些什麼來防止這種情況發生?
一旦瞭解了這些,通常會分配幾個行動項來實施保護措施,以防止同樣的事情再次發生。
本文由博客一文多發平臺 OpenWrite 發佈！
