萬字長文 - 解讀功能開關(guān) | IDCF
原文：https://martinfowler.com/articles/feature-toggles.html 作者：Pete Hodgson 譯者：冬哥
作者 Pete Hodgson是舊金山灣區(qū)的一名獨(dú)立軟件交付顧問。他擅長幫助初創(chuàng)工程團(tuán)隊(duì)改進(jìn)他們的工程實(shí)踐和技術(shù)架構(gòu)。Pete 之前曾在 Thoughtworks 擔(dān)任過六年的顧問，領(lǐng)導(dǎo)其西海岸業(yè)務(wù)的技術(shù)實(shí)踐。他還曾在舊金山多家初創(chuàng)公司擔(dān)任技術(shù)主管。
內(nèi)容
一個(gè)開關(guān)的故事 開關(guān)的類別 管理不同類別的開關(guān) 實(shí)施技術(shù) 開關(guān)配置 使用帶有特征開關(guān)的系統(tǒng)
一、一個(gè)開關(guān)的故事
function reticulateSplines () {
// 當(dāng)前的實(shí)現(xiàn)在這里
}這些示例都使用 JavaScript ES2015
加入開關(guān)之后
function reticulateSplines(){
var useNewAlgorithm = false;
// useNewAlgorithm = true; // UNCOMMENT IF YOU ARE WORKING ON THE NEW SR ALGORITHM
if( useNewAlgorithm ){
return enhancedSplineReticulation();
}else{
return oldFashionedSplineReticulation();
}
}
function oldFashionedSplineReticulation(){
// current implementation lives here
}
function enhancedSplineReticulation(){
// TODO: implement better SR algorithm
}
function oldFashionedSplineReticulation () {
// 當(dāng)前的實(shí)現(xiàn)在這里
}
function enhancedSplineReticulation () {
// TODO：實(shí)現(xiàn)更好的 SR 算法
}oldFashionedSplineReticulation?函數(shù)中，并將?reticulateSplines設(shè)置為一個(gè)開關(guān)點(diǎn)?，F(xiàn)在，如果有人正在研究新算法，他們可以通過取消注釋來啟用“使用新算法” 功能useNewAlgorithm = true?。1.2 使標(biāo)志動(dòng)態(tài)化
useNewAlgorithm = true?行的笨拙機(jī)制了：function reticulateSplines () {
if ( featureIsEnabled( "use-new-SR-algorithm" ) ){
return enhancedSplineReticulation();
} else {
return oldFashionedSplineReticulation();
}
}我們現(xiàn)在介紹了一個(gè)featureIsEnabled功能，一個(gè)開關(guān)路由器，它可以用來動(dòng)態(tài)控制哪個(gè)代碼路徑是活動(dòng)的。實(shí)現(xiàn)開關(guān)路由器的方法有很多，從簡(jiǎn)單的內(nèi)存存儲(chǔ)到具有精美 UI 的高度復(fù)雜的分布式系統(tǒng)。
現(xiàn)在我們將從一個(gè)非常簡(jiǎn)單的系統(tǒng)開始：
function createToggleRouter(featureConfig){
return {
setFeature(featureName,isEnabled){
featureConfig[featureName] = isEnabled;
},
featureIsEnabled(featureName){
return featureConfig[featureName];
}
};
}請(qǐng)注意，我們使用的是 ES2015 的方法簡(jiǎn)寫
我們可以基于一些默認(rèn)配置創(chuàng)建一個(gè)新的開關(guān)路由器——也許從配置文件中讀取——但我們也可以動(dòng)態(tài)地打開或關(guān)閉一個(gè)功能。這允許自動(dòng)化測(cè)試來驗(yàn)證開關(guān)功能的兩側(cè)：
describe( 'spline reticulation', function(){
let toggleRouter;
let simulationEngine;
beforeEach(function(){
toggleRouter = createToggleRouter();
simulationEngine = createSimulationEngine({toggleRouter:toggleRouter});
});
it('works correctly with old algorithm', function(){
// Given
toggleRouter.setFeature("use-new-SR-algorithm",false);
// When
const result = simulationEngine.doSomethingWhichInvolvesSplineReticulation();
// Then
verifySplineReticulation(result);
});
it('works correctly with new algorithm', function(){
// Given
toggleRouter.setFeature("use-new-SR-algorithm",true);
// When
const result = simulationEngine.doSomethingWhichInvolvesSplineReticulation();
// Then
verifySplineReticulation(result);
});
});1.3 準(zhǔn)備發(fā)布
更多的時(shí)間過去了，團(tuán)隊(duì)相信他們的新算法功能齊全。為了確認(rèn)這一點(diǎn)，他們一直在修改他們的更高級(jí)別的自動(dòng)化測(cè)試，以便他們?cè)诠δ荜P(guān)閉和打開的情況下運(yùn)行系統(tǒng)。該團(tuán)隊(duì)還希望進(jìn)行一些手動(dòng)探索性測(cè)試，以確保一切按預(yù)期工作——畢竟，樣條網(wǎng)狀結(jié)構(gòu)是系統(tǒng)行為的關(guān)鍵部分。
要對(duì)尚未被驗(yàn)證為可用于一般用途的功能執(zhí)行手動(dòng)測(cè)試，我們需要能夠為生產(chǎn)中的一般用戶群關(guān)閉該功能，但能夠?yàn)閮?nèi)部用戶打開它。有很多不同的方法可以實(shí)現(xiàn)這個(gè)目標(biāo)：
讓開關(guān)路由器根據(jù)開關(guān)設(shè)置做出決策，并針對(duì)特定環(huán)境進(jìn)行配置。僅在預(yù)生產(chǎn)環(huán)境中啟用新功能。 允許通過某種形式的管理 UI 在運(yùn)行時(shí)修改開關(guān)配置。使用該管理 UI 在測(cè)試環(huán)境中啟用新功能。 教開關(guān)路由器如何根據(jù)請(qǐng)求做出動(dòng)態(tài)的開關(guān)決策。這些決策將開關(guān)上下文考慮在內(nèi)，例如通過查找特殊的 cookie 或 HTTP 標(biāo)頭。通常開關(guān)上下文用作識(shí)別發(fā)出請(qǐng)求的用戶的代理。
團(tuán)隊(duì)決定使用按請(qǐng)求開關(guān)路由器，因?yàn)樗鼮樗麄兲峁┝撕艽蟮撵`活性。該團(tuán)隊(duì)特別感激，這將使他們能夠在不需要單獨(dú)的測(cè)試環(huán)境的情況下測(cè)試他們的新算法。相反，他們可以在生產(chǎn)環(huán)境中簡(jiǎn)單地打開算法，但僅限于內(nèi)部用戶（通過特殊 cookie 檢測(cè)到）。團(tuán)隊(duì)現(xiàn)在可以自己打開該 cookie 并驗(yàn)證新功能是否按預(yù)期執(zhí)行。
1.4 金絲雀發(fā)布
基于迄今為止所做的探索性測(cè)試，新的網(wǎng)絡(luò)渲染算法看起來不錯(cuò)。然而，由于它是游戲模擬引擎的重要組成部分，因此仍然有些人不愿意為所有用戶啟用此功能。團(tuán)隊(duì)決定使用他們的功能開關(guān)基礎(chǔ)設(shè)施來執(zhí)行金絲雀發(fā)布，只為他們總用戶群的一小部分——“金絲雀”群組開啟新功能。
該團(tuán)隊(duì)通過向開關(guān)路由器傳授用戶群組的概念來增強(qiáng)開關(guān)路由器 - 用戶群組始終體驗(yàn)始終開啟或關(guān)閉的功能。一組金絲雀用戶是通過 1% 的用戶群的隨機(jī)抽樣創(chuàng)建的——可能使用用戶 ID 的模數(shù)。這個(gè)金絲雀隊(duì)列將始終啟用該功能，而其他 99% 的用戶群仍使用舊算法。監(jiān)控兩組的關(guān)鍵業(yè)務(wù)指標(biāo)（用戶參與度、總收入等），以確保新算法不會(huì)對(duì)用戶行為產(chǎn)生負(fù)面影響。一旦團(tuán)隊(duì)確信新功能沒有不良影響，他們就會(huì)修改他們的開關(guān)配置，以便為整個(gè)用戶群?jiǎn)⒂盟?/span>
1.5 A/B 測(cè)試
團(tuán)隊(duì)的產(chǎn)品經(jīng)理了解到這種方法，非常興奮。她建議團(tuán)隊(duì)使用類似的機(jī)制來執(zhí)行一些 A/B 測(cè)試。關(guān)于修改犯罪率算法以考慮污染水平是否會(huì)增加或降低游戲的可玩性，一直存在長期爭(zhēng)論。他們現(xiàn)在有能力使用數(shù)據(jù)來解決爭(zhēng)論。他們計(jì)劃推出一個(gè)廉價(jià)的實(shí)現(xiàn)，它可以捕捉到這個(gè)想法的本質(zhì)，并通過一個(gè)功能標(biāo)志來控制。他們將為相當(dāng)多的用戶群?jiǎn)⒂迷摴δ?，然后研究這些用戶與“控制”群相比的行為方式。這種方法將允許團(tuán)隊(duì)根據(jù)數(shù)據(jù)解決有爭(zhēng)議的產(chǎn)品辯論，
這個(gè)簡(jiǎn)短的場(chǎng)景旨在說明功能開關(guān)的基本概念，同時(shí)也強(qiáng)調(diào)該核心功能可以有多少不同的應(yīng)用程序?，F(xiàn)在我們已經(jīng)看到了這些應(yīng)用程序的一些示例，讓我們更深入地研究一下。我們將探索不同類別的開關(guān)，看看是什么讓它們與眾不同。我們將介紹如何編寫可維護(hù)的開關(guān)代碼，最后分享實(shí)踐以避免功能開關(guān)系統(tǒng)的一些陷阱。
二、開關(guān)的類別
我們已經(jīng)看到了功能開關(guān)提供的基本功能 - 能夠在一個(gè)可部署單元中提供替代代碼路徑并在運(yùn)行時(shí)在它們之間進(jìn)行選擇。上述場(chǎng)景還表明，該工具可以在各種情況下以各種方式使用。將所有功能開關(guān)集中到同一個(gè)桶中可能很誘人，但這是一條危險(xiǎn)的道路。不同類別開關(guān)的設(shè)計(jì)驅(qū)動(dòng)是完全不同的，并且以相同的方式管理它們可能會(huì)導(dǎo)致痛苦。
功能開關(guān)可以分為兩個(gè)主要維度：功能開關(guān)將存在多長時(shí)間，以及開關(guān)決策必須有多動(dòng)態(tài)。還有其他因素需要考慮——例如，誰來管理功能開關(guān)——但我認(rèn)為生存周期和動(dòng)態(tài)性是兩個(gè)重要因素，可以幫助指導(dǎo)如何管理開關(guān)。
讓我們通過這兩個(gè)維度的視角考慮各種類別的開關(guān)，看看它們適合什么。
2.1 發(fā)布開關(guān)
發(fā)布開關(guān)允許將不完整和未經(jīng)測(cè)試的代碼路徑作為可能永遠(yuǎn)不會(huì)打開的潛在代碼交付到生產(chǎn)環(huán)境。
這些是用于為實(shí)踐持續(xù)交付的團(tuán)隊(duì)啟用基于主干的開發(fā)的功能標(biāo)志。它們?cè)试S將正在進(jìn)行的功能檢入到共享集成分支（例如 master 或trunk）中，同時(shí)仍然允許隨時(shí)將該分支部署到生產(chǎn)中。發(fā)布開關(guān)允許將不完整和未經(jīng)測(cè)試的代碼路徑作為可能永遠(yuǎn)不會(huì)打開的潛在代碼交付到生產(chǎn)環(huán)境。
產(chǎn)品經(jīng)理也可以使用同樣方法的以產(chǎn)品為中心的版本來防止半成品的產(chǎn)品功能暴露給最終用戶。例如，電子商務(wù)網(wǎng)站的產(chǎn)品經(jīng)理可能不想讓用戶看到僅適用于網(wǎng)站的一物流合作伙伴的新預(yù)計(jì)物流日期功能，而是希望等到該功能已為所有物流合作伙伴實(shí)施。產(chǎn)品經(jīng)理可能有其他原因不想公開功能，即使它們已經(jīng)完全實(shí)現(xiàn)和測(cè)試。例如，功能發(fā)布可能與營銷活動(dòng)相協(xié)調(diào)。以這種方式使用發(fā)布開關(guān)是實(shí)現(xiàn)“將 [功能] 發(fā)布與 [代碼] 部署分開”的持續(xù)交付原則的最常見方式。
發(fā)布開關(guān)本質(zhì)上是過渡的。盡管以產(chǎn)品為中心的開關(guān)可能需要保留更長的時(shí)間，但它們通常不應(yīng)停留超過一兩周。發(fā)布開關(guān)的開關(guān)決定通常是非常靜態(tài)的。給定發(fā)布版本的每個(gè)開關(guān)決策都是相同的，通過推出具有開關(guān)配置更改的新版本來更改開關(guān)決策通常是完全可以接受的。
2.2 實(shí)驗(yàn)開關(guān)
實(shí)驗(yàn)開關(guān)用于執(zhí)行多變量或 A/B 測(cè)試。系統(tǒng)的每個(gè)用戶都被放置在一個(gè)群組中，并且在運(yùn)行時(shí)，開關(guān)路由器將根據(jù)他們所在的群組始終如一地將給定的用戶發(fā)送到一個(gè)或另一個(gè)代碼路徑。通過跟蹤不同群組的聚合行為，我們可以比較效果不同的代碼路徑。這種技術(shù)通常用于對(duì)電子商務(wù)系統(tǒng)的購買流程或按鈕上的宣傳性用語等事物進(jìn)行數(shù)據(jù)驅(qū)動(dòng)的優(yōu)化。
實(shí)驗(yàn)開關(guān)需要在相同配置下保持足夠長的時(shí)間以產(chǎn)生具有統(tǒng)計(jì)意義的結(jié)果。取決于可能意味著生命周期數(shù)小時(shí)或數(shù)周的流量模式。更長的時(shí)間不太可能有用，因?yàn)閷?duì)系統(tǒng)的其他更改可能會(huì)使實(shí)驗(yàn)結(jié)果無效。就其性質(zhì)而言，實(shí)驗(yàn)開關(guān)是高度動(dòng)態(tài)的 - 每個(gè)傳入請(qǐng)求都可能代表不同的用戶，因此可能會(huì)以不同于上一個(gè)的方式路由。
2.3 運(yùn)維開關(guān)
這些標(biāo)志用于控制我們系統(tǒng)行為的操作方面。我們可能會(huì)在推出具有不確定性能影響的新功能時(shí)引入運(yùn)維開關(guān)，以便系統(tǒng)操作員可以在需要時(shí)在生產(chǎn)中快速禁用或降級(jí)該功能。
大多數(shù)運(yùn)維開關(guān)的壽命都相對(duì)較短——一旦對(duì)新功能的操作方面獲得信心，就應(yīng)該停用該標(biāo)志。然而，系統(tǒng)擁有少量長壽命的“終止開關(guān)”并不少見，它們?cè)试S生產(chǎn)環(huán)境的操作員在系統(tǒng)承受異常高負(fù)載時(shí)優(yōu)雅地降低非重要系統(tǒng)功能。
例如，當(dāng)我們處于繁重的負(fù)載下時(shí)，我們可能希望禁用我們主頁上的推薦面板，該面板的生成成本相對(duì)較高。我咨詢了一家維護(hù)運(yùn)維開關(guān)的在線零售商，這可能會(huì)在高需求產(chǎn)品發(fā)布之前故意禁用其網(wǎng)站主要采購流程中的許多非關(guān)鍵功能。這種長期存在的運(yùn)維開關(guān)可以視作是一種手工管理的斷路器。
如前所述，這些標(biāo)志中的許多只存在很短的時(shí)間，但一些關(guān)鍵控件可能幾乎無限期地保留給操作員。由于這些標(biāo)志的目的是讓操作員對(duì)生產(chǎn)問題做出快速反應(yīng)，因此他們需要非常快速地重新配置 - 需要推出新版本以翻轉(zhuǎn)運(yùn)維開關(guān)，不太可能讓操作人員滿意。
2.4 許可開關(guān)
這些標(biāo)志用于更改某些用戶收到的功能或產(chǎn)品體驗(yàn)。例如，我們可能有一組“高級(jí)”功能，只為付費(fèi)客戶啟用。或者，也許我們有一組僅供內(nèi)部用戶使用的“alpha”功能和另一組僅供內(nèi)部用戶和 beta 用戶使用的“beta”功能。我將這種為一組內(nèi)部或測(cè)試版用戶打開新功能的技術(shù)稱為香檳早午餐 - 一個(gè)“喝自己的香檳”的早期機(jī)會(huì)。
香檳早午餐在很多方面與金絲雀發(fā)布相似。兩者之間的區(qū)別在于，金絲雀發(fā)布的功能面向隨機(jī)選擇的一組用戶，而香檳早午餐功能面向一組特定用戶。
當(dāng)用作管理僅向高級(jí)用戶公開的功能時(shí)，與其他類別的功能開關(guān)相比，許可開關(guān)的壽命可能非常長 - 以多年為規(guī)模。由于權(quán)限是特定于用戶的，因此許可開關(guān)的開關(guān)決定將始終按請(qǐng)求進(jìn)行，因此這是一個(gè)非常動(dòng)態(tài)的開關(guān)。
三、管理不同類別的開關(guān)
現(xiàn)在我們有了一個(gè)開關(guān)分類方案，我們可以討論動(dòng)態(tài)性和壽命這兩個(gè)維度如何影響我們使用不同類別的特征標(biāo)志的方式。
3.1 靜態(tài)與動(dòng)態(tài)開關(guān)
做出運(yùn)行時(shí)路由決策的開關(guān)必然需要更復(fù)雜的開關(guān)路由器，以及這些路由器的更復(fù)雜配置。
對(duì)于簡(jiǎn)單的靜態(tài)路由決策，開關(guān)配置可以是每個(gè)功能的簡(jiǎn)單開或關(guān)，開關(guān)路由器僅負(fù)責(zé)將靜態(tài)開/關(guān)狀態(tài)中繼到開關(guān)點(diǎn)。正如我們之前所討論的，其他類別的開關(guān)更加動(dòng)態(tài)并且需要更復(fù)雜的開關(guān)路由器。例如，實(shí)驗(yàn)開關(guān)的路由器為給定用戶動(dòng)態(tài)地做出路由決策，可能使用某種基于該用戶 id 的一致群組算法。這個(gè)開關(guān)路由器不需要從配置中讀取靜態(tài)開關(guān)狀態(tài)，而是需要讀取某種隊(duì)列配置，定義諸如實(shí)驗(yàn)隊(duì)列和控制隊(duì)列應(yīng)該有多大。
稍后我們將深入探討管理此開關(guān)配置的不同方法。
3.2 長期開關(guān)與瞬態(tài)開關(guān)
我們還可以將開關(guān)類別劃分為本質(zhì)上是短暫的類別與長期存在且可能存在多年的類別。這種區(qū)別應(yīng)該對(duì)我們實(shí)現(xiàn)功能的開關(guān)點(diǎn)的方法有很大的影響。如果我們要添加一個(gè)將在幾天后刪除的發(fā)布開關(guān)，那么我們可能會(huì)使用一個(gè)開關(guān)點(diǎn)，它對(duì) 開關(guān)路由器進(jìn)行簡(jiǎn)單的 if/else 檢查。這就是我們之前使用樣條網(wǎng)格示例所做的：
function reticulateSplines () {
if ( featureIsEnabled( "use-new-SR-algorithm" ) ){
return enhancedSplineReticulation();
} else {
return oldFashionedSplineReticulation();
}
}但是，如果我們要?jiǎng)?chuàng)建一個(gè)帶有開關(guān)點(diǎn)的新許可開關(guān)，我們希望它會(huì)持續(xù)很長時(shí)間，那么我們當(dāng)然不希望通過不加選擇地散布 if/else 檢查來實(shí)現(xiàn)這些開關(guān)點(diǎn)。我們需要使用更易于維護(hù)的實(shí)現(xiàn)技術(shù)。
四、實(shí)施技術(shù)
功能標(biāo)志似乎會(huì)產(chǎn)生相當(dāng)混亂的開關(guān)點(diǎn)代碼，并且這些開關(guān)點(diǎn)也有在整個(gè)代碼庫中擴(kuò)散的趨勢(shì)。保持這種趨勢(shì)檢查代碼庫中的任何功能標(biāo)志很重要，如果標(biāo)志將長期存在，這一點(diǎn)至關(guān)重要。有一些實(shí)現(xiàn)模式和實(shí)踐有助于減少這個(gè)問題。
4.1 將決策點(diǎn)與決策邏輯解耦
功能開關(guān)的一個(gè)常見錯(cuò)誤是將做出開關(guān)決策的位置（開關(guān)點(diǎn)）與決策背后的邏輯（開關(guān)路由器）結(jié)合起來。
讓我們看一個(gè)例子。我們正在開發(fā)下一代電子商務(wù)系統(tǒng)。我們的一項(xiàng)新功能將允許用戶通過單擊訂單確認(rèn)電子郵件（又稱發(fā)票電子郵件）中的鏈接輕松取消訂單。我們正在使用功能標(biāo)志來管理我們所有下一代功能的推出。我們最初的特征標(biāo)記實(shí)現(xiàn)如下所示：
invoiceEmailer.js
const features = fetchFeatureTogglesFromSomewhere();
function generateInvoiceEmail(){
const baseEmail = buildEmailForInvoice(this.invoice);
if( features.isEnabled("next-gen-ecomm") ){
return addOrderCancellationContentToEmail(baseEmail);
}else{
return baseEmail;
}
}在生成發(fā)票電子郵件時(shí)，我們的 InvoiceEmailler 會(huì)檢查該next-gen-ecomm功能是否已啟用。如果是，那么電子郵件發(fā)送者會(huì)在電子郵件中添加一些額外的訂單取消內(nèi)容。
雖然這看起來是一種合理的方法，但它非常脆弱。關(guān)于是否在我們的發(fā)票電子郵件中包含訂單取消功能的決定直接與next-gen-ecomm功能綁定 - 使用魔術(shù)字符串。為什么發(fā)票電子郵件代碼需要知道訂單取消內(nèi)容是下一代功能集的一部分？如果我們想在不暴露訂單取消的情況下打開下一代功能的某些部分會(huì)怎樣？或反之亦然？如果我們決定只向某些用戶推出訂單取消功能怎么辦？隨著功能的開發(fā)，這種“開關(guān)范圍”更改很常見。還要記住，這些開關(guān)點(diǎn)往往會(huì)在整個(gè)代碼庫中激增。?
令人高興的是，軟件中的任何問題都可以通過添加一個(gè)間接層來解決。我們可以將開關(guān)決策點(diǎn)與該決策背后的邏輯解耦，如下所示：
featureDecisions.js
function createFeatureDecisions(features){
return {
includeOrderCancellationInEmail(){
return features.isEnabled("next-gen-ecomm");
}
// ... additional decision functions also live here ...
};
}
invoiceEmailer.js
const features = fetchFeatureTogglesFromSomewhere();
const featureDecisions = createFeatureDecisions(features);
function generateInvoiceEmail(){
const baseEmail = buildEmailForInvoice(this.invoice);
if( featureDecisions.includeOrderCancellationInEmail() ){
return addOrderCancellationContentToEmail(baseEmail);
}else{
return baseEmail;
}
}我們引入了一個(gè)FeatureDecisions對(duì)象，它充當(dāng)任何功能開關(guān)決策邏輯的收集點(diǎn)。我們?yōu)榇a中的每個(gè)特定開關(guān)決策在此對(duì)象上創(chuàng)建一個(gè)決策方法 - 在這種情況下，“我們是否應(yīng)該在發(fā)票電子郵件中包含訂單取消功能”由?includeOrderCancellationInEmail決策方法表示。
現(xiàn)在，決策“邏輯”是微不足道的通過傳遞next-gen-ecomm檢查狀態(tài)，但現(xiàn)在隨著邏輯的發(fā)展，我們有一個(gè)統(tǒng)一的地方來管理它。每當(dāng)我們想修改特定開關(guān)決策的邏輯時(shí)，我們只需要去一個(gè)地方。
我們可能想要修改決策的范圍——例如哪個(gè)特定的功能標(biāo)志控制決策?；蛘?，我們可能需要修改做出決定的原因——從由靜態(tài)開關(guān)配置驅(qū)動(dòng)到由 A/B 實(shí)驗(yàn)驅(qū)動(dòng)，或者由操作問題驅(qū)動(dòng)，例如我們的一些訂單取消基礎(chǔ)設(shè)施的中斷。在所有情況下，我們的發(fā)票電子郵件發(fā)送者都可能會(huì)很高興地不知道如何或?yàn)槭裁醋龀鲈撻_關(guān)決定。
4.2 反轉(zhuǎn)決定
在前面的示例中，我們的發(fā)票電子郵件發(fā)送器負(fù)責(zé)詢問功能標(biāo)記基礎(chǔ)設(shè)施應(yīng)該如何執(zhí)行。這意味著我們的發(fā)票電子郵件發(fā)送器有一個(gè)需要注意的額外概念 - 功能標(biāo)記 - 以及與之耦合的額外模塊。這使得發(fā)票電子郵件更難單獨(dú)使用和思考，包括使其更難測(cè)試。隨著功能標(biāo)記在系統(tǒng)中變得越來越普遍，我們將看到越來越多的模塊作為全局依賴項(xiàng)與功能標(biāo)記系統(tǒng)耦合。不是理想的情況。
在軟件設(shè)計(jì)中，我們通?？梢酝ㄟ^應(yīng)用控制反轉(zhuǎn)來解決這些耦合問題。在這種情況下確實(shí)如此。以下是我們?nèi)绾螌⑽覀兊陌l(fā)票電子郵件與我們的功能標(biāo)記基礎(chǔ)設(shè)施分離：
invoiceEmailer.js
function createInvoiceEmailler(config){
return {
generateInvoiceEmail(){
const baseEmail = buildEmailForInvoice(this.invoice);
if( config.includeOrderCancellationInEmail ){
return addOrderCancellationContentToEmail(email);
}else{
return baseEmail;
}
},
// ... other invoice emailer methods ...
};
}
featureAwareFactory.js
function createFeatureAwareFactoryBasedOn(featureDecisions){
return {
invoiceEmailler(){
return createInvoiceEmailler({
includeOrderCancellationInEmail: featureDecisions.includeOrderCancellationInEmail()
});
},
// ... other factory methods ...
};
}現(xiàn)在，不是我們InvoiceEmailler接觸它，而是在構(gòu)建時(shí)通過一個(gè)對(duì)象?FeatureDecisions將這些決定注入它。現(xiàn)在對(duì)功能標(biāo)記一無所知。它只知道可以在運(yùn)行時(shí)配置其行為的某些方面。這也使得 testing的行為更容易 - 我們可以通過在測(cè)試期間傳遞不同的配置選項(xiàng)來測(cè)試它生成帶有和不帶有訂單取消內(nèi)容的電子郵件的方式：configInvoiceEmaillerInvoiceEmailler
describe( 'invoice emailling', function(){
it( 'includes order cancellation content when configured to do so', function(){
// Given
const emailler = createInvoiceEmailler({includeOrderCancellationInEmail:true});
// When
const email = emailler.generateInvoiceEmail();
// Then
verifyEmailContainsOrderCancellationContent(email);
};
it( 'does not includes order cancellation content when configured to not do so', function(){
// Given
const emailler = createInvoiceEmailler({includeOrderCancellationInEmail:false});
// When
const email = emailler.generateInvoiceEmail();
// Then
verifyEmailDoesNotContainOrderCancellationContent(email);
};
});我們還引入了一個(gè)FeatureAwareFactory集中創(chuàng)建這些決策注入對(duì)象的方法。這是一般依賴注入模式的應(yīng)用。如果控制反轉(zhuǎn)系統(tǒng)在我們的代碼庫中發(fā)揮作用，那么我們可能會(huì)使用該系統(tǒng)來實(shí)現(xiàn)這種方法。
4.3 避免條件
到目前為止，在我們的示例中，我們的開關(guān)點(diǎn)是使用 if 語句實(shí)現(xiàn)的。這對(duì)于一個(gè)簡(jiǎn)單的、短暫的開關(guān)可能是有意義的。但是，在某個(gè)功能需要多個(gè)開關(guān)點(diǎn)或你希望開關(guān)點(diǎn)長期存在的地方，不建議使用點(diǎn)條件。一種更易于維護(hù)的替代方法是使用某種策略模式來實(shí)現(xiàn)替代代碼路徑：
invoiceEmailler.js
function createInvoiceEmailler(additionalContentEnhancer){
return {
generateInvoiceEmail(){
const baseEmail = buildEmailForInvoice(this.invoice);
return additionalContentEnhancer(baseEmail);
},
// ... other invoice emailer methods ...
};
}
featureAwareFactory.js
function identityFn(x){ return x; }
function createFeatureAwareFactoryBasedOn(featureDecisions){
return {
invoiceEmailler(){
if( featureDecisions.includeOrderCancellationInEmail() ){
return createInvoiceEmailler(addOrderCancellationContentToEmail);
}else{
return createInvoiceEmailler(identityFn);
}
},
// ... other factory methods ...
};
}在這里，我們通過允許我們的發(fā)票電子郵件程序配置內(nèi)容增強(qiáng)功能來應(yīng)用策略模式。FeatureAwareFactory在創(chuàng)建發(fā)票電子郵件時(shí)選擇一種策略，由FeatureDecision. 如果訂單取消應(yīng)該在電子郵件中，它會(huì)傳遞一個(gè)增強(qiáng)功能，將內(nèi)容添加到電子郵件中。否則，它會(huì)傳入一個(gè)identityFn增強(qiáng)器——它沒有任何效果，只是簡(jiǎn)單地將電子郵件傳回而不做任何修改。
五、開關(guān)配置
5.1 動(dòng)態(tài)路由與動(dòng)態(tài)配置
早些時(shí)候，我們將功能開關(guān)分為對(duì)于給定的代碼部署而言開關(guān)路由決策基本上是靜態(tài)的，與那些決策在運(yùn)行時(shí)動(dòng)態(tài)變化的。需要注意的是，標(biāo)志的決定可能會(huì)在運(yùn)行時(shí)以兩種方式發(fā)生變化，這一點(diǎn)很重要。
首先，像運(yùn)維開關(guān)這樣的東西可能會(huì)被動(dòng)態(tài)重新配置從 On 到 Off 以響應(yīng)系統(tǒng)中斷。 其次，某些類別的開關(guān)（例如許可開關(guān)和實(shí)驗(yàn)開關(guān)）根據(jù)某些請(qǐng)求上下文（例如哪個(gè)用戶發(fā)出請(qǐng)求）為每個(gè)請(qǐng)求做出動(dòng)態(tài)路由決策。
function reticulateSplines(){
//return oldFashionedSplineReticulation();
return enhancedSplineReticulation();
}比注釋方法稍微復(fù)雜一點(diǎn)的是使用預(yù)處理器的#ifdef功能，如果可用的話。?
因?yàn)檫@種類型的硬編碼不允許動(dòng)態(tài)重新配置開關(guān)，它僅適用于我們?cè)敢庾裱渴鸫a模式以重新配置標(biāo)志的功能標(biāo)志。
5.5 參數(shù)化開關(guān)配置
硬編碼配置提供的構(gòu)建時(shí)配置對(duì)于許多用例（包括許多測(cè)試場(chǎng)景）來說不夠靈活。至少允許在不重新構(gòu)建應(yīng)用程序或服務(wù)的情況下，重新配置功能標(biāo)志的簡(jiǎn)單方法，是通過命令行參數(shù)或環(huán)境變量指定開關(guān)配置。這是一種簡(jiǎn)單且歷史悠久的開關(guān)方法，早在有人將該技術(shù)稱為功能開關(guān)或特征標(biāo)記之前就已經(jīng)存在。但是，它有局限性?？绱罅窟M(jìn)程協(xié)調(diào)配置可能會(huì)變得不方便，而且開關(guān)配置的更改需要重新部署或者至少重新啟動(dòng)進(jìn)程（并且可能需要重新配置開關(guān)的人對(duì)服務(wù)器進(jìn)行特權(quán)訪問）。
5.6 開關(guān)配置文件
另一種選擇是從某種結(jié)構(gòu)化文件中讀取開關(guān)配置。這種開關(guān)配置的方法很常見，它作為更通用的應(yīng)用程序配置文件的一部分開始使用。
使用開關(guān)配置文件，你現(xiàn)在可以通過簡(jiǎn)單地更改該文件而不是重新構(gòu)建應(yīng)用程序代碼本身來重新配置功能標(biāo)志。但是，盡管在大多數(shù)情況下你不需要重新構(gòu)建應(yīng)用程序來開關(guān)功能，但你可能仍需要執(zhí)行重新部署以重新配置標(biāo)志。
5.7 開關(guān)應(yīng)用數(shù)據(jù)庫中的配置
一旦達(dá)到一定規(guī)模，使用靜態(tài)文件來管理開關(guān)配置可能會(huì)變得很麻煩。通過文件修改配置相對(duì)繁瑣。確保一組服務(wù)器的一致性成為一項(xiàng)挑戰(zhàn)，使更改始終如一地更是如此。作為對(duì)此的回應(yīng)，許多組織將開關(guān)配置轉(zhuǎn)移到某種類型的集中式存儲(chǔ)中，通常是現(xiàn)有的應(yīng)用程序數(shù)據(jù)庫。這通常伴隨著某種形式的管理 UI 的構(gòu)建，它允許系統(tǒng)操作員、測(cè)試人員和產(chǎn)品經(jīng)理查看和修改功能標(biāo)志及其配置。
5.8 分布式開關(guān)配置
使用已經(jīng)是系統(tǒng)架構(gòu)一部分的通用數(shù)據(jù)庫來存儲(chǔ)開關(guān)配置非常普遍；一旦引入功能標(biāo)志并開始獲得牽引力，這是一個(gè)明顯的方式。然而，現(xiàn)在有一種特殊用途的分層鍵值存儲(chǔ)更適合管理應(yīng)用程序配置 - 像 Zookeeper、etcd 或 Consul 這樣的服務(wù)。這些服務(wù)形成一個(gè)分布式集群，它為連接到集群的所有節(jié)點(diǎn)提供環(huán)境配置的共享源。可以在需要時(shí)動(dòng)態(tài)修改配置，并且集群中的所有節(jié)點(diǎn)都會(huì)自動(dòng)收到更改通知——這是一個(gè)非常方便的附加功能。
其中一些系統(tǒng)（例如 Consul）帶有一個(gè)管理 UI，它提供了一種管理開關(guān)配置的基本方法。然而，在某些時(shí)候，通常會(huì)創(chuàng)建一個(gè)用于管理開關(guān)配置的小型自定義應(yīng)用程序。
5.9 覆蓋配置
到目前為止，我們的討論假設(shè)所有配置都由單一機(jī)制提供。許多系統(tǒng)的實(shí)際情況更為復(fù)雜，配置的覆蓋層來自各種來源。使用開關(guān)配置，具有默認(rèn)配置以及特定于環(huán)境的覆蓋是很常見的。這些覆蓋可能來自像附加配置文件這樣簡(jiǎn)單的東西，也可能來自像 Zookeeper 集群這樣復(fù)雜的東西。
請(qǐng)注意，任何特定于環(huán)境的覆蓋都與持續(xù)交付的理想背道而馳，即在交付管道中始終擁有完全相同的位和配置流。通常實(shí)用主義要求使用一些特定于環(huán)境的覆蓋，但是努力使你的可部署單元和你的配置盡可能與環(huán)境無關(guān)，這將導(dǎo)致更簡(jiǎn)單、更安全的管道。當(dāng)我們談?wù)摐y(cè)試功能開關(guān)系統(tǒng)時(shí)，我們將很快重新討論這個(gè)主題。
針對(duì)每個(gè)請(qǐng)求覆蓋
六、使用帶有特征標(biāo)記的系統(tǒng)
一個(gè)好的約定是在功能標(biāo)志關(guān)閉時(shí)啟用現(xiàn)有的或舊有的行為，而在它打開時(shí)啟用新的或未來的行為。
在邊緣開關(guān)
someFile.erb
<%= if featureDecisions.showRecommendationsSection? %>
<%= render 'recommendations_section' %>
<% end %>當(dāng)你控制對(duì)尚未準(zhǔn)備好發(fā)布的面向用戶的新功能的訪問時(shí)，將開關(guān)點(diǎn)放置在邊緣也很有意義。在這種情況下，你可以再次使用簡(jiǎn)單地顯示或隱藏 UI 元素的開關(guān)來控制訪問。例如，也許你正在構(gòu)建使用 Facebook 登錄應(yīng)用程序的功能，但還沒有準(zhǔn)備好將其推廣給用戶。此功能的實(shí)現(xiàn)可能涉及架構(gòu)各個(gè)部分的更改，但你可以通過隱藏“使用 Facebook 登錄”按鈕的 UI 層的簡(jiǎn)單功能開關(guān)來控制功能的公開。有趣的是，使用其中一些類型的功能標(biāo)志，大部分未發(fā)布的功能本身可能實(shí)際上是公開的，但位于用戶無法發(fā)現(xiàn)的 url 上。
在核心開關(guān)
還有其他類型的較低級(jí)別的開關(guān)必須放置在你的架構(gòu)中更深的位置。這些開關(guān)通常在本質(zhì)上是技術(shù)性的，并且控制著某些功能如何在內(nèi)部實(shí)現(xiàn)。一個(gè)示例是發(fā)布開關(guān)，它控制是在第三方 API 前使用新的緩存基礎(chǔ)設(shè)施，還是直接將請(qǐng)求路由到該 API。在這些情況下，在功能被開關(guān)的服務(wù)中本地化這些開關(guān)決策是唯一明智的選擇。
6.6 管理功能開關(guān)的持有成本
功能標(biāo)志有快速增加的趨勢(shì)，特別是在首次引入時(shí)。它們有用且創(chuàng)建成本低，因此通常會(huì)創(chuàng)建很多。然而，開關(guān)確實(shí)會(huì)帶來持有成本。它們要求你在代碼中引入新的抽象或條件邏輯。它們還引入了顯著的測(cè)試負(fù)擔(dān)。騎士資本集團(tuán)的4.6 億美元錯(cuò)誤是一個(gè)警示故事，說明當(dāng)你沒有正確管理功能標(biāo)志時(shí)（除其他外）會(huì)出現(xiàn)什么問題。
精明的團(tuán)隊(duì)將他們的功能開關(guān)視為帶有持有成本的庫存，并努力將庫存保持在盡可能低的水平。
精明的團(tuán)隊(duì)將其代碼庫中的功能開關(guān)視為帶有持有成本的庫存，并尋求將庫存保持在盡可能低的水平。為了使功能標(biāo)志的數(shù)量保持可管理，團(tuán)隊(duì)必須主動(dòng)刪除不再需要的功能標(biāo)志。一些團(tuán)隊(duì)的規(guī)則是，每當(dāng)首次引入發(fā)布開關(guān)時(shí)，總是將開關(guān)刪除任務(wù)添加到團(tuán)隊(duì)的待辦事項(xiàng)中。其他團(tuán)隊(duì)將“到期日期”放在他們的開關(guān)按鈕上。有些人甚至?xí)圃臁岸〞r(shí)炸彈”，如果功能標(biāo)志在其到期日期之后仍然存在，它將無法通過測(cè)試（甚至拒絕啟動(dòng)應(yīng)用程序?。?。
我們還可以采用精益方法來減少庫存，對(duì)系統(tǒng)在任何時(shí)候允許擁有的功能標(biāo)志的數(shù)量進(jìn)行限制。一旦達(dá)到該限制，如果有人想要添加新的開關(guān)，他們首先需要完成刪除現(xiàn)有開關(guān)標(biāo)識(shí)的工作。
