服務降級經驗總結

2021-08-02 11:53:59 字數 1068 閱讀 2176

服務降級,當伺服器壓力劇增的情況下,根據當前業務情況及流量對一些服務和頁面有策略的降級,以此釋放伺服器資源以保證核心任務的正常執行。

服務降級方式:

服務介面拒絕服務:無使用者特定資訊,頁面能訪問,但是新增刪除提示伺服器繁忙。頁面內容也可在varnish或cdn內獲取。

頁面拒絕服務:頁面提示由於服務繁忙此服務暫停。跳轉到varnish或nginx的乙個靜態頁面。

延遲持久化:頁面訪問照常,但是涉及記錄變更,會提示稍晚能看到結果,將資料記錄到非同步佇列或log,服務恢復後執行。

隨機拒絕服務:服務介面隨機拒絕服務,讓使用者重試,目前較少有人採用。因為使用者體驗不佳。

持久層降級方式

資料操作動作

通過cache工作

通過非同步資料佇列

增insert 禁止

允許但不能有重複問題

刪delete 禁止

允許但不能有復合操作

改update 禁止

允許只留最後結果

查query

允許,若未命中問詢mysql或其他持久層 走

cache

降級方式

直覺管理方式:運維人員可以指定哪些模組降級。

當伺服器檢測到壓力增大,伺服器監測自動傳送通知給運維人員

運維人員根據自己或相關人員判斷後通過配置平台設定當前執行等級來降級

降級首先可以對非核心業務進行介面降級。

如果效果不顯著,開始對一些頁面進行降級,以此保證核心功能的正常執行。

分級管理方式:運維人員無需關心業務細節,直接按級別降低即可。

當伺服器檢測到壓力增大,服務檢測自動傳送通知給運維人員。

運維人員根據情況選擇執行等級1~10.

各個應用根據自己的級別自動判斷是否工作,如何拒絕

服務降級埋點的地方:

訊息中介軟體:所有api呼叫可以使用訊息中介軟體進行控制

底層資料驅動:拒絕所有增刪改動作,只允許查詢

SOA服務經驗總結

xx電商soa服務化嚴重缺陷 很榮幸進入xx電商公司從事soa服務化的工作,由於時間倉促,在服務化的過程中出現了乙個嚴重缺陷,為什麼這麼說 soa基本指導思想 電商soa服務合理分層 錯誤的soa分層 錯誤的代價 邊重構邊生活 soa基本指導思想 根據soa基本指導思想,如圖1所示應該是一種比較合理...

伺服器設計經驗總結

伺服器設計經驗總結 在完成我的支援sock4,sock4a,sock5的 伺服器後,寫下的總結。現在它在公司的linux伺服器 處於乙個校園網 上7 24小時的執行 伺服器通訊設計的三種經典架構 1 one thread request 對於每個服務請求使用乙個執行緒來處理。在高併發狀態下這種方法需...

經驗總結 資料預處理經驗總結1

1.對於特徵較多的df,進行資料預處理時需要對每個特徵變數進行相關處理,為了避免混亂,可以df.info 後將輸出複製到sublime,然後在sublime中針對每個特徵變數進行處理方式標註 非python 只是為了展示在sublime中的效果 action type 30697 non null ...