#研發解決方案介紹#基於持久化配置中心的業務降級

時間 2019-11-05

標籤研發解決方案介紹基於持久配置中心業務降級简体版

原文原文鏈接

鄭昀最後更新於2014/4/18

關鍵詞：業務降級，配置中心，基本可用性，

A.業務降級的背景知識： html

淘寶就雙十一課題曾經講過：數據庫

『

所謂業務降級，就是犧牲非核心的業務功能，保證核心功能的穩定運行。簡單來講，要實現優雅的業務降級，須要將功能實現拆分到相對獨立的不一樣代碼單元，分優先級進行隔離。 在後臺經過開關控制，降級部分非主流程的業務功能，減輕系統依賴和性能損耗，從而提高集羣的總體吞吐率。

』

主動關閉系統功能的場景：

咱們更新系統或數據庫刷庫時，可能會提出，某天凌晨幾點到幾點不能下單，幾點到幾點不能驗證，若是都靠人工手動調整、手動開關跳轉頁面或提示文字的話，非常不方便。而咱們的理念是，平常發生的事情，不能有心理負擔，不能成爲一件很麻煩甚至須要臨時修改代碼的事情。因此停服引起的降級，須要方便快捷地作到。

因而，一個集中存儲的開關控制這些核心功能全線關閉，能夠有。

被動關閉系統功能的場景：

咱們都知道，某東在2011年，某客在2012年，某美在2013年，耗費了不少人財物爲大促銷作準備，結果時間到了，網站宕機宕得死死的。

此時，限制鏈接數可能會讓網站暫時性活過來了，可是 能進來的人很少，銷售額上不去，其實仍是公司損失。

在這種被動的場景下，能夠力保核心購買流程能走通，保證基本可用性，即確保可以下單和提交支付，保證錢能流進來，同時保證消費驗證。

因此業務降級的作法是， 逐一全局關閉非核心流程的業務功能。

B.窩窩業務降級的實操： 瀏覽器

與以前窩窩實現的業務降級不一樣，研發1部的明駿把 降級功能配置 與 降級項目配置 分開，以下圖1所示：網絡

圖1 業務降級配置管理的菜單項架構

即：異步

一，降級的最小單位是功能性能

我能夠單獨針對「（首頁右側欄）熱門專賣店（列表）」功能。以下圖2所示，配置狀態爲「未過濾」表明該功能未被攔截。網站

圖2 功能配置實例 lua

1.1.能夠獲知該（URL/class攔截）功能在哪些項目裏生效。如上圖2中的「所含項目配置」列所示。 spa

1.2.能夠配置跳轉地址，以下圖3所示。第一，若是功能過濾啓用了，當攔截到目標後，須要引導瀏覽器跳轉到哪個頁面，譬如跳到停服公告頁上。第二，能夠定義啓用時間，好比明天凌晨1點。

圖3 功能配置詳情頁

1.3.若是一個功能被多個項目包含，好比「（通欄）廣告」功能被 aether 和 mars 包含，那麼當這個功能處於「已過濾」時，aether 和 mars 上的通欄廣告就會都消失，即便這兩個項目的配置狀態爲「未過濾」。

1.4.過濾某個功能，點擊配置狀態列的按鈕便可，啓用狀態以下圖4所示。

圖4 功能處於已過濾

二，功能之上是項目

2.1.項目的出現，是爲了更靈活多樣地降級。

2.2.你既能夠過濾橫跨多個項目的一個功能，一關全關。你也能夠只關某個項目裏的功能集合，好比你能夠只關閉 aether 工程裏的通欄廣告和推薦列表。

2.3.當項目處於「已過濾」狀態時，不想過濾某個功能，那就勾掉它，以下圖5所示。

圖5 項目配置詳情頁

2.4.在被動關閉系統功能場景裏，因爲目前尚未開發預案級降級，因此最快的辦法是，到降級功能配置管理裏，把相關功能的開關所有打開。

2.5.有了基於功能和項目的降級配置管理，下一步就能夠基於（遠端）服務質量作自動降級了。

三，項目之上是預案

3.1.舉例，紅色預警預案將關閉全部下單、支付、充值等功能，橙色預警預案將關閉全部推薦、評價、積分等功能。

3.2.預案級別的降級控制目前尚未實現。

C.持久化配置中心的背景知識：

diamond是淘寶內部使用的一個管理持久配置的系統，它的特色是簡單、可靠、易用，目前淘寶內部絕大多數系統的配置，由diamond來進行統一管理。

diamond爲應用系統提供了獲取配置的服務，應用不只能夠在啓動時從diamond獲取相關的配置，並且能夠在運行中對配置數據的變化進行感知並獲取變化後的配置數據。

持久配置是指配置數據會持久化到磁盤和數據庫中。

diamond的特色是簡單、可靠、易用：

簡單：總體結構很是簡單，從而減小了出錯的可能性。

可靠：應用方在任何狀況下均可以啓動，在承載淘寶核心系統並正常運行一年多以來，沒有出現過任何重大故障。

易用：客戶端使用只須要兩行代碼，暴露的接口都很是簡單，易於理解。

值得一提的是 diamond 的容災機制，這也是阿里系很多開源中間件的容災通用思路。

C.1.diamond的容災機制

diamond之因此表現的穩定可靠，除了架構簡單以外，另外一個重要緣由是diamond具備一套完備的容災機制，容災機制涉及到client和server兩部分，主要包括如下幾個方面：

c.1.1.server存儲數據的方式

server存儲數據是「數據庫 + 本地文件」的方式，集羣間的數據同步咱們在以前的文章中講過（請參考專題二的原理部分），client訂閱數據時，訪問的是本地文件，不查詢數據庫，這樣即便數據庫出問題了，仍然不影響client的訂閱。

c.1.2.server是一個集羣

這是一個基本的容災機制，集羣中的一臺server不可用了，client發現後能夠自動切換到其餘server上進行訪問，自動切換在client內部實現。

c.1.3.client保存snapshot

client每次從server獲取到數據後，都會將數據保存在本地文件系統，diamond稱之爲snapshot，即數據快照。當client下次啓動發如今超時時間內全部server均不可用（多是網絡故障），它會使用snapshot中的數據快照進行啓動。

c.1.4.client校驗MD5

client每次從server獲取到數據後，都會進行MD5校驗（數據保存在response body，MD5保存在response header），以防止因網絡故障形成的數據不完整，MD5校驗不經過直接拋出異常。

c.1.5.client與server分離

client能夠和server徹底分離，單獨使用，diamond定義了一個「容災目錄」的概念.

client在啓動時會建立這個目錄，每次主動獲取數據（即調用getAvailableConfigInfomation()方法），都會優先從「容災目錄」獲取數據，若是client按照一個固定的規則，在「容災目錄」下配置了須要的數據，那麼client直接獲取到數據返回，再也不經過網絡從 diamond-server獲取數據。

一樣的，在每次輪詢時，都會優先輪詢「容災目錄」，若是發現配置還存在於其中，則再也不向server發出輪詢請求。以上的情形，會持續到「容災目錄」的配置數據被刪除爲止。

根據以上的容災機制，咱們能夠總結一下diamond整個系統徹底不可用的條件：