穩定性實踐：開關和預案
穩定性實踐：開關和預案
在穩定性保障中，限流降級的技術方案，是針對服務介面層面的，也就是服務限流和服務降級。這裡還有另外一個維度，就是業務維度，所以今天我們就從業務降級的維度來分享，也就是開關和預案。
如何理解開關和預案
開關，這個概念更多是業務和功能層面的，主要是針對單個功能的啟用和停止進行控制，或者將功能狀態在不同版本之間進行切換。
-
在業務層面，就像我們前面經常提到的大促場景案例，我們會關閉掉很多非核心功能，只保留交易鏈路的核心功能。比如我們認為商品評論是非核心功能，這時就會通過開關推送這種方案將這個功能關閉。當用戶訪問商品詳情頁時，這個介面就不再被呼叫，從使用者角度來說，就是在大促峰值時刻看不到所瀏覽商品的評論列表。
-
在功能層面，我們技術架構中會使用快取技術，但是要考慮到快取有可能也會出現故障，比如不可訪問，或者資料錯亂異常等狀況，這時我們就會考慮旁路掉快取，直接將請求轉到資料庫這一層。
這裡有兩種做法：一種做法是通過我們上一篇介紹到的降級手段，也就是我們常說的熔斷，自動化地旁路；另一種做法，比如在資料異常情況下，請求是正常的，但是資料是有問題的，這時就無法做到自動化旁路，就要通過主動推送開關的方式來實現。
預案，可以理解為讓應用或業務進入到某種特定狀態的複雜方案執行，這個方案最終會通過開關、限流和降級策略這些細粒度的技術來實現，是這些具體技術方案的場景化表現。
我們還是接著上面的這個案例來討論。因為每個業務或應用都會有自己的開關配置，而且數量會有很多，如果在大促前一個個推送，效率就會跟不上，所以我們就會針對某個應用的具體場景，提供批量操作的手段，通過預案場景將同一應用，甚至多個應用的開關串聯起來。
比如上面提到的商品詳情頁，我們不僅可以關閉商品評論，還可以關閉商品收藏提示、買家秀、店鋪商品推薦、同類型商品推薦以及搭配推薦等等。有了場景化的預案，管理和維護起來就會更容易。
除了業務層面的預案，我們還可以將預案應用到應急場景下，比如上面提到的快取故障異常。在真實場景下，要考慮得更全面，比如快取能夠支撐的業務訪問量是要遠遠大於資料庫的，這時我們就要做功能降級，這就要考慮資料庫是否能夠支撐住這麼大的請求量（通常情況下肯定是支撐不住的）。所以，遇到這種場景，我們首要考慮的是限流，先將業務流量限掉三分之一甚至是一半，然後再將功能降級到資料庫上。
這樣就又涉及到多種策略的序列執行。如果沒有預案都是單個執行的話，效率肯定會低，而且還可能涉及到多個應用都會執行相同的業務降級策略，這時就必須要有預案來統一管理，提前梳理好哪些應用需要在這種場景下執行對應的開關、限流和降級策略。
技術解決方案
技術方案上並不複雜，開關的欄位主要以Key-Value方式管理，並從應用維度，通過應用名管理起來，這個對應關係就可以放到統一的控制檯中管理。
下圖是整個開關和預案管理，以及推送的示意圖，我們一起分步驟看一下。
1.開關管理
通過上述我們所說的Key-Value方式儲存，與程式碼中的具體Field欄位對應起來。這裡就又會涉及到我們上篇內容中講到的Spring的AOP和註解技術。
如下面程式碼所示，我們通過註解方式定義了一個開關testKey，它與控制檯中配置的Key相對應，並獲取對應的Value取值，在業務執行階段，我們就可以根據這個值，來決定業務執行邏輯，下面是簡化的示例。
@AppSwitcher(key="key1",valueDes = "Boolean型別")
private Boolean key1;
程式碼中直接呼叫AppName對應的開關配置，進行不同業務邏輯的實現：
Boolean key1 = MoguStableSwitch.isStableSwitchOn("key1");
if (key1)
{
//開關開啟時業務邏輯實現
}else
{
//開關關閉時業務邏輯實現
}
####
2.開關推送
當在控制檯上修改開關值後，會推送到微服務的配置中心做持久化，這樣當應用下次重啟時依然可以獲取到變更後的值。還有另外一種方式，就是通過HTTP的方式推送，這種情況的應用場景是，當第一種情況失敗時，為了讓開關快速生效預留的第二個介面。
3.配置變更
應用中引入的開關SDK客戶端會監聽對應配置的變更，如果發生變化，就會馬上重新獲取，並在業務執行時生效。
4.預案執行
就是多個開關策略的序列執行，會重複上面這幾個關鍵步驟。
關於開關和預案的內容，我們今天就介紹到這裡。留一個問題，我們在上篇文章中介紹到限流降級方案的難點，請你思考一下，我們今天講的開關預案這個內容，可能會遇到哪些難點呢？歡迎留言與我討論。
精選提問
-
隨著程式碼迭代開關會不會使程式碼邏輯越來越複雜 各種if else呢
1、開關及預案最初研發是都要考慮清楚 2、這部分應該歸屬架構部分