大家好，我是架構擺渡人。這是實踐經驗系列的第一篇文章，這個系列會給大家分享很多在實際工作中有用的經驗，如果有收獲，還請分享給更多的朋友。
在日常工作中，無論是一周一個疊代，還是兩周一個疊代，都避免不了上線的環節。唯一的差別就是上線的頻次不同而已。那麼我們如何保證在這麼高頻次的發版裡面同時保證穩定性呢？
答案就是開關程式設計，所謂的開關程式設計其實就是加個if判斷，但是可以動态去調整if裡面的值，能夠随時控制邏輯的走向。開關需要自己編寫，自己控制，動态調整值則可以借助于配置中心，改變後實時重新整理。
假設你要對訂單詳情頁面做調整，增加一部分内容或者修改老的邏輯。正常的做法就是直接改掉老邏輯，然後測試，然後上線。
如果測試覆寫了所有的場景，上線後也不會有任何問題。就怕有某些場景遺漏了，導緻在測試環境中沒有發現的問題，一上線就出問題了。此時你的邏輯已經是最新的了，唯一的解決辦法就是復原應用到之前的版本，復原是下下策，不到萬不得已千萬不要做，因為復原可能帶來更嚴重的問題。
如果執行復原操作，也就意味着這次釋出要上的新功能都沒有了，如果你的服務拆的夠細，可能影響面會稍微小點。
假設服務端復原了，如果此時用戶端已經釋出，像H5還好說，也可以復原，像APP如果使用者已經更新到最新版本了，你服務端復原了，使用者一用到新功能就直接報錯了。是以請慎重復原。
是以此時你可能沒辦法復原，隻能快馬加鞭改Bug，然後緊急釋出進行修複，玩的就是心跳啊。
在改動舊邏輯的時候，不要直接改，可以在内部采用分版本的方式進行調整。把之前的邏輯定位V1，要改的邏輯定位V2，然後通過開關去切換。
僞代碼如下：
通過增加開關來保證穩定性，預設開關是關閉的，上線後還是走舊邏輯，無任何影響。釋出完成後再将開關開啟，此時走新邏輯。如果新邏輯出現了Bug，立馬将開關關閉走舊邏輯，不用復原整個服務，是不是很穩。
此時，又有同學擡杠了，你這雖然能快速復原，如果流量大的話影響還是很大啊。是的，如果要保證最小的影響，那麼就需要結合灰階來實作了，這塊後面再給大家介紹如何去做。
對于很多電商公司來說，大促必不可少。每年都有像周年慶，618，雙十一，雙十二之類的大促期。
大促的時候，流量也是最高的時候。此時最重要的就是P0級别的核心鍊路，其他不是很重要的可以降級，以免影響到主鍊路的功能。
比如訂單詳情頁裡面，大部分都是訂單的快照資訊，可能有個别資訊是需要調用其他的接口進行展示的，但這個資訊不是必要的，此時就可以在調用這個接口的地方加開關，平時關閉，大促之前打開，不進行調用，這樣就保證了詳情頁的穩定性。
開關雖然很有用，但是凡事有利也有弊。當項目中出現了很多的開關之後，對于代碼的可讀性比較差，特别是對于新同學來說，這麼多開關，可能也不知道幹嘛的，是以第一點就是注釋一定要寫清楚。
然後對于那些保證上線穩定性的開關，在上線後過一點時間，功能穩定了，就應該及時删除開關的邏輯，提高代碼可讀性。對于降級的開關，還是要保留的。
我相信大家在工作中也會用開關去做一些事情，特别是在上線新功能，或者改老功能，或者重構的時候，真的很有用。
有了開關，上線不慌，沒有開關，聽天由命。想不想保住工作，就看你開關用的溜不溜啦！