上線穩定性如何保證？開關編程很有用

大家好，我是架構擺渡人。這是實踐經驗系列的第一篇文章，這個系列會給大家分享很多在實際工作中有用的經驗，如果有收穫，還請分享給更多的朋友。

在日常工作中，無論是一週一個迭代，還是兩週一個迭代，都避免不了上線的環節。唯一的區別就是上線的頻次不同而已。那麼我們如何保證在這麼高頻次的發版裏面同時保證穩定性呢？

答案就是開關編程，所謂的開關編程其實就是加個 if 判斷，但是可以動態去調整 if 裏面的值，能夠隨時控制邏輯的走向。開關需要自己編寫，自己控制，動態調整值則可以藉助於配置中心，改變後實時刷新。

案例一：舊功能裏面加新邏輯

假設你要對訂單詳情頁面做調整，增加一部分內容或者修改老的邏輯。正常的做法就是直接改掉老邏輯，然後測試，然後上線。

如果測試覆蓋了所有的場景，上線後也不會有任何問題。就怕有某些場景遺漏了，導致在測試環境中沒有發現的問題，一上線就出問題了。此時你的邏輯已經是最新的了，唯一的解決辦法就是回滾應用到之前的版本，回滾是下下策，不到萬不得已千萬不要做，因爲回滾可能帶來更嚴重的問題。

這次發佈的功能全丟了

 

如果執行回滾操作，也就意味着這次發佈要上的新功能都沒有了，如果你的服務拆的夠細，可能影響面會稍微小點。

假設服務端回滾了，如果此時客戶端已經發布，像 H5 還好說，也可以回滾，像 APP 如果用戶已經更新到最新版本了，你服務端回滾了，用戶一用到新功能就直接報錯了。所以請慎重回滾。

所以此時你可能沒辦法回滾，只能快馬加鞭改 Bug，然後緊急發佈進行修復，玩的就是心跳啊。

開關的作用來啦

在改動舊邏輯的時候，不要直接改，可以在內部採用分版本的方式進行調整。把之前的邏輯定位 V1，要改的邏輯定位 V2，然後通過開關去切換。

僞代碼如下：

boolean switch = false;
if (switch) {
  // 走新改的邏輯
} else {
  // 走舊邏輯
}

通過增加開關來保證穩定性，默認開關是關閉的，上線後還是走舊邏輯，無任何影響。發佈完成後再將開關開啓，此時走新邏輯。如果新邏輯出現了 Bug，立馬將開關關閉走舊邏輯，不用回滾整個服務，是不是很穩。

此時，又有同學擡槓了，你這雖然能快速回滾，如果流量大的話影響還是很大啊。是的，如果要保證最小的影響，那麼就需要結合灰度來實現了，這塊後面再給大家介紹如何去做。

案例二：大促前的功能降級

對於很多電商公司來說，大促必不可少。每年都有像週年慶，618，雙十一，雙十二之類的大促期。

大促的時候，流量也是最高的時候。此時最重要的就是 P0 級別的核心鏈路，其他不是很重要的可以降級，以免影響到主鏈路的功能。

比如訂單詳情頁裏面，大部分都是訂單的快照信息，可能有個別信息是需要調用其他的接口進行展示的，但這個信息不是必要的，此時就可以在調用這個接口的地方加開關，平時關閉，大促之前打開，不進行調用，這樣就保證了詳情頁的穩定性。

僞代碼如下：

boolean switch = false;
XxxInfo xxxInfo = null;
if (!switch) {
  // 調用外部接口獲取信息
  xxxInfo = xxxRpc.getxxx();
}

開關注意點

開關雖然很有用，但是凡事有利也有弊。當項目中出現了很多的開關之後，對於代碼的可讀性比較差，特別是對於新同學來說，這麼多開關，可能也不知道幹嘛的，所以第一點就是註釋一定要寫清楚。

然後對於那些保證上線穩定性的開關，在上線後過一點時間，功能穩定了，就應該及時刪除開關的邏輯，提高代碼可讀性。對於降級的開關，還是要保留的。

開關總結

我相信大家在工作中也會用開關去做一些事情，特別是在上線新功能，或者改老功能，或者重構的時候，真的很有用。

**有了開關，上線不慌，沒有開關，聽天由命。**想不想保住工作，就看你開關用的溜不溜啦！

大家好，我是從古代穿越過來的美男子：架構擺渡人。我將把我的武功祕籍全部傳授與你們，覺得有用請分享給身邊的朋友。來個三連吧，感謝各位！另外我還在 B 站錄製了**《真實訂單業務，億級數據帶你實戰分庫分表》**的實戰課程，記得去學習哦！

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

猜你喜歡