原文：https://martinfowler.com/articles/feature-toggles.html

作者：Pete Hodgson

譯者：冬哥

功能開關(guān)Feature Toggle（通常也稱為功能標志Feature Flag）是一種強大的技術(shù)，允許團隊在不更改代碼的情況下修改系統(tǒng)行為。包括各種使用類別，在實施和管理開關(guān)時考慮該方式非常重要。開關(guān)引入了復(fù)雜性。我們可以通過使用智能開關(guān)實現(xiàn)實踐和適當?shù)墓ぞ邅砉芾砦覀兊拈_關(guān)配置來控制這種復(fù)雜性，但我們還應(yīng)該致力于限制系統(tǒng)中開關(guān)的數(shù)量。

作者 Pete Hodgson是舊金山灣區(qū)的一名獨立軟件交付顧問。他擅長幫助初創(chuàng)工程團隊改進他們的工程實踐和技術(shù)架構(gòu)。Pete 之前曾在 Thoughtworks 擔任過六年的顧問，領(lǐng)導(dǎo)其西海岸業(yè)務(wù)的技術(shù)實踐。他還曾在舊金山多家初創(chuàng)公司擔任技術(shù)主管。

內(nèi)容

一個開關(guān)的故事

開關(guān)的類別

管理不同類別的開關(guān)

實施技術(shù)

開關(guān)配置

使用帶有特征開關(guān)的系統(tǒng)

---

“功能開關(guān)”是一組模式，可以幫助團隊快速但安全地向用戶提供新功能。在這篇關(guān)于功能開關(guān)的文章中，我們將從一個簡短的故事開始，展示功能開關(guān)有用的一些典型場景。然后我們將深入研究細節(jié)，涵蓋有助于團隊通過功能開關(guān)取得成功的特定模式和實踐。

功能開關(guān)也稱為功能標志、功能位或功能翻轉(zhuǎn)器。這些都是同一組技術(shù)的同義詞。在本文中，我將交替使用功能開關(guān)和功能標志。

一、一個開關(guān)的故事

場景描繪：你隸屬于從事復(fù)雜城市規(guī)劃模擬游戲的多個團隊之一，你的團隊負責核心模擬引擎，你的任務(wù)是提高網(wǎng)絡(luò)渲染算法的效率。你知道這將需要對實施進行相當大的檢修，這將需要數(shù)周時間。同時，你團隊的其他成員將需要在代碼庫的相關(guān)領(lǐng)域繼續(xù)一些正在進行的工作。

根據(jù)過去合并長期存在的分支的痛苦經(jīng)歷，如果可能的話，你希望避免為這項工作打分支。相反，你決定整個團隊將繼續(xù)在主干上工作，但致力于網(wǎng)絡(luò)渲染算法改進的開發(fā)人員將使用功能開關(guān)來防止他們的工作影響團隊的其他成員或破壞代碼庫的穩(wěn)定性。

1.1 功能標志的誕生

以下是研究算法的兩人引入的第一個變化：

加入開關(guān)之前

function reticulateSplines () {// 當前的實現(xiàn)在這里}

這些示例都使用 JavaScript ES2015

加入開關(guān)之后

function reticulateSplines(){var useNewAlgorithm = false;// useNewAlgorithm = true; // UNCOMMENT IF YOU ARE WORKING ON THE NEW SR ALGORITHMif( useNewAlgorithm ){return enhancedSplineReticulation();}else{return oldFashionedSplineReticulation();}}function oldFashionedSplineReticulation(){// current implementation lives here}function enhancedSplineReticulation(){// TODO: implement better SR algorithm}function oldFashionedSplineReticulation () {// 當前的實現(xiàn)在這里}function enhancedSplineReticulation () {// TODO：實現(xiàn)更好的 SR 算法}

這對已經(jīng)將當前的算法實現(xiàn)移動到一個?oldFashionedSplineReticulation?函數(shù)中，并將?reticulateSplines設(shè)置為一個開關(guān)點。現(xiàn)在，如果有人正在研究新算法，他們可以通過取消注釋來啟用“使用新算法” 功能useNewAlgorithm = true?。

1.2 使標志動態(tài)化

幾個小時過去了，這對搭檔準備好通過一些模擬引擎的集成測試來運行他們的新算法。他們還想在同一集成測試運行中使用舊算法。他們需要能夠動態(tài)地啟用或禁用該功能，這意味著是時候擺脫注釋或取消注釋該useNewAlgorithm = true?行的笨拙機制了：

function reticulateSplines () {if ( featureIsEnabled( "use-new-SR-algorithm" ) ){return enhancedSplineReticulation();} else {return oldFashionedSplineReticulation();} }

我們現(xiàn)在介紹了一個featureIsEnabled功能，一個開關(guān)路由器，它可以用來動態(tài)控制哪個代碼路徑是活動的。實現(xiàn)開關(guān)路由器的方法有很多，從簡單的內(nèi)存存儲到具有精美 UI 的高度復(fù)雜的分布式系統(tǒng)。

現(xiàn)在我們將從一個非常簡單的系統(tǒng)開始：

function createToggleRouter(featureConfig){return {setFeature(featureName,isEnabled){featureConfig[featureName] = isEnabled;},featureIsEnabled(featureName){return featureConfig[featureName];}}; }

請注意，我們使用的是 ES2015 的方法簡寫

我們可以基于一些默認配置創(chuàng)建一個新的開關(guān)路由器——也許從配置文件中讀取——但我們也可以動態(tài)地打開或關(guā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(){// GiventoggleRouter.setFeature("use-new-SR-algorithm",false);// Whenconst result = simulationEngine.doSomethingWhichInvolvesSplineReticulation();// ThenverifySplineReticulation(result);});it('works correctly with new algorithm', function(){// GiventoggleRouter.setFeature("use-new-SR-algorithm",true);// Whenconst result = simulationEngine.doSomethingWhichInvolvesSplineReticulation();// ThenverifySplineReticulation(result);}); });

1.3 準備發(fā)布

更多的時間過去了，團隊相信他們的新算法功能齊全。為了確認這一點，他們一直在修改他們的更高級別的自動化測試，以便他們在功能關(guān)閉和打開的情況下運行系統(tǒng)。該團隊還希望進行一些手動探索性測試，以確保一切按預(yù)期工作——畢竟，樣條網(wǎng)狀結(jié)構(gòu)是系統(tǒng)行為的關(guān)鍵部分。

要對尚未被驗證為可用于一般用途的功能執(zhí)行手動測試，我們需要能夠為生產(chǎn)中的一般用戶群關(guān)閉該功能，但能夠為內(nèi)部用戶打開它。有很多不同的方法可以實現(xiàn)這個目標：

• 讓開關(guān)路由器根據(jù)開關(guān)設(shè)置做出決策，并針對特定環(huán)境進行配置。僅在預(yù)生產(chǎn)環(huán)境中啟用新功能。

• 允許通過某種形式的管理 UI 在運行時修改開關(guān)配置。使用該管理 UI 在測試環(huán)境中啟用新功能。

• 教開關(guān)路由器如何根據(jù)請求做出動態(tài)的開關(guān)決策。這些決策將開關(guān)上下文考慮在內(nèi)，例如通過查找特殊的 cookie 或 HTTP 標頭。通常開關(guān)上下文用作識別發(fā)出請求的用戶的代理。

（稍后我們將更詳細地研究這些方法，所以如果其中一些概念對你來說是新的，請不要擔心。）

團隊決定使用按請求開關(guān)路由器，因為它為他們提供了很大的靈活性。該團隊特別感激，這將使他們能夠在不需要單獨的測試環(huán)境的情況下測試他們的新算法。相反，他們可以在生產(chǎn)環(huán)境中簡單地打開算法，但僅限于內(nèi)部用戶（通過特殊 cookie 檢測到）。團隊現(xiàn)在可以自己打開該 cookie 并驗證新功能是否按預(yù)期執(zhí)行。

1.4 金絲雀發(fā)布

基于迄今為止所做的探索性測試，新的網(wǎng)絡(luò)渲染算法看起來不錯。然而，由于它是游戲模擬引擎的重要組成部分，因此仍然有些人不愿意為所有用戶啟用此功能。團隊決定使用他們的功能開關(guān)基礎(chǔ)設(shè)施來執(zhí)行金絲雀發(fā)布，只為他們總用戶群的一小部分——“金絲雀”群組開啟新功能。

該團隊通過向開關(guān)路由器傳授用戶群組的概念來增強開關(guān)路由器 - 用戶群組始終體驗始終開啟或關(guān)閉的功能。一組金絲雀用戶是通過 1% 的用戶群的隨機抽樣創(chuàng)建的——可能使用用戶 ID 的模數(shù)。這個金絲雀隊列將始終啟用該功能，而其他 99% 的用戶群仍使用舊算法。監(jiān)控兩組的關(guān)鍵業(yè)務(wù)指標（用戶參與度、總收入等），以確保新算法不會對用戶行為產(chǎn)生負面影響。一旦團隊確信新功能沒有不良影響，他們就會修改他們的開關(guān)配置，以便為整個用戶群啟用它。

1.5 A/B 測試

團隊的產(chǎn)品經(jīng)理了解到這種方法，非常興奮。她建議團隊使用類似的機制來執(zhí)行一些 A/B 測試。關(guān)于修改犯罪率算法以考慮污染水平是否會增加或降低游戲的可玩性，一直存在長期爭論。他們現(xiàn)在有能力使用數(shù)據(jù)來解決爭論。他們計劃推出一個廉價的實現(xiàn)，它可以捕捉到這個想法的本質(zhì)，并通過一個功能標志來控制。他們將為相當多的用戶群啟用該功能，然后研究這些用戶與“控制”群相比的行為方式。這種方法將允許團隊根據(jù)數(shù)據(jù)解決有爭議的產(chǎn)品辯論，

這個簡短的場景旨在說明功能開關(guān)的基本概念，同時也強調(diào)該核心功能可以有多少不同的應(yīng)用程序。現(xiàn)在我們已經(jīng)看到了這些應(yīng)用程序的一些示例，讓我們更深入地研究一下。我們將探索不同類別的開關(guān)，看看是什么讓它們與眾不同。我們將介紹如何編寫可維護的開關(guān)代碼，最后分享實踐以避免功能開關(guān)系統(tǒng)的一些陷阱。

二、開關(guān)的類別

我們已經(jīng)看到了功能開關(guān)提供的基本功能 - 能夠在一個可部署單元中提供替代代碼路徑并在運行時在它們之間進行選擇。上述場景還表明，該工具可以在各種情況下以各種方式使用。將所有功能開關(guān)集中到同一個桶中可能很誘人，但這是一條危險的道路。不同類別開關(guān)的設(shè)計驅(qū)動是完全不同的，并且以相同的方式管理它們可能會導(dǎo)致痛苦。

功能開關(guān)可以分為兩個主要維度：功能開關(guān)將存在多長時間，以及開關(guān)決策必須有多動態(tài)。還有其他因素需要考慮——例如，誰來管理功能開關(guān)——但我認為生存周期和動態(tài)性是兩個重要因素，可以幫助指導(dǎo)如何管理開關(guān)。

讓我們通過這兩個維度的視角考慮各種類別的開關(guān)，看看它們適合什么。

2.1 發(fā)布開關(guān)

發(fā)布開關(guān)允許將不完整和未經(jīng)測試的代碼路徑作為可能永遠不會打開的潛在代碼交付到生產(chǎn)環(huán)境。

這些是用于為實踐持續(xù)交付的團隊啟用基于主干的開發(fā)的功能標志。它們允許將正在進行的功能檢入到共享集成分支（例如 master 或trunk）中，同時仍然允許隨時將該分支部署到生產(chǎn)中。發(fā)布開關(guān)允許將不完整和未經(jīng)測試的代碼路徑作為可能永遠不會打開的潛在代碼交付到生產(chǎn)環(huán)境。

產(chǎn)品經(jīng)理也可以使用同樣方法的以產(chǎn)品為中心的版本來防止半成品的產(chǎn)品功能暴露給最終用戶。例如，電子商務(wù)網(wǎng)站的產(chǎn)品經(jīng)理可能不想讓用戶看到僅適用于網(wǎng)站的一物流合作伙伴的新預(yù)計物流日期功能，而是希望等到該功能已為所有物流合作伙伴實施。產(chǎn)品經(jīng)理可能有其他原因不想公開功能，即使它們已經(jīng)完全實現(xiàn)和測試。例如，功能發(fā)布可能與營銷活動相協(xié)調(diào)。以這種方式使用發(fā)布開關(guān)是實現(xiàn)“將 [功能] 發(fā)布與 [代碼] 部署分開”的持續(xù)交付原則的最常見方式。

發(fā)布開關(guān)本質(zhì)上是過渡的。盡管以產(chǎn)品為中心的開關(guān)可能需要保留更長的時間，但它們通常不應(yīng)停留超過一兩周。發(fā)布開關(guān)的開關(guān)決定通常是非常靜態(tài)的。給定發(fā)布版本的每個開關(guān)決策都是相同的，通過推出具有開關(guān)配置更改的新版本來更改開關(guān)決策通常是完全可以接受的。

2.2 實驗開關(guān)

實驗開關(guān)用于執(zhí)行多變量或 A/B 測試。系統(tǒng)的每個用戶都被放置在一個群組中，并且在運行時，開關(guān)路由器將根據(jù)他們所在的群組始終如一地將給定的用戶發(fā)送到一個或另一個代碼路徑。通過跟蹤不同群組的聚合行為，我們可以比較效果不同的代碼路徑。這種技術(shù)通常用于對電子商務(wù)系統(tǒng)的購買流程或按鈕上的宣傳性用語等事物進行數(shù)據(jù)驅(qū)動的優(yōu)化。

實驗開關(guān)需要在相同配置下保持足夠長的時間以產(chǎn)生具有統(tǒng)計意義的結(jié)果。取決于可能意味著生命周期數(shù)小時或數(shù)周的流量模式。更長的時間不太可能有用，因為對系統(tǒng)的其他更改可能會使實驗結(jié)果無效。就其性質(zhì)而言，實驗開關(guān)是高度動態(tài)的 - 每個傳入請求都可能代表不同的用戶，因此可能會以不同于上一個的方式路由。

2.3 運維開關(guān)

這些標志用于控制我們系統(tǒng)行為的操作方面。我們可能會在推出具有不確定性能影響的新功能時引入運維開關(guān)，以便系統(tǒng)操作員可以在需要時在生產(chǎn)中快速禁用或降級該功能。

大多數(shù)運維開關(guān)的壽命都相對較短——一旦對新功能的操作方面獲得信心，就應(yīng)該停用該標志。然而，系統(tǒng)擁有少量長壽命的“終止開關(guān)”并不少見，它們允許生產(chǎn)環(huán)境的操作員在系統(tǒng)承受異常高負載時優(yōu)雅地降低非重要系統(tǒng)功能。

例如，當我們處于繁重的負載下時，我們可能希望禁用我們主頁上的推薦面板，該面板的生成成本相對較高。我咨詢了一家維護運維開關(guān)的在線零售商，這可能會在高需求產(chǎn)品發(fā)布之前故意禁用其網(wǎng)站主要采購流程中的許多非關(guān)鍵功能。這種長期存在的運維開關(guān)可以視作是一種手工管理的斷路器。

如前所述，這些標志中的許多只存在很短的時間，但一些關(guān)鍵控件可能幾乎無限期地保留給操作員。由于這些標志的目的是讓操作員對生產(chǎn)問題做出快速反應(yīng)，因此他們需要非常快速地重新配置 - 需要推出新版本以翻轉(zhuǎn)運維開關(guān)，不太可能讓操作人員滿意。

2.4 許可開關(guān)

這些標志用于更改某些用戶收到的功能或產(chǎn)品體驗。例如，我們可能有一組“高級”功能，只為付費客戶啟用。或者，也許我們有一組僅供內(nèi)部用戶使用的“alpha”功能和另一組僅供內(nèi)部用戶和 beta 用戶使用的“beta”功能。我將這種為一組內(nèi)部或測試版用戶打開新功能的技術(shù)稱為香檳早午餐 - 一個“喝自己的香檳”的早期機會。

香檳早午餐在很多方面與金絲雀發(fā)布相似。兩者之間的區(qū)別在于，金絲雀發(fā)布的功能面向隨機選擇的一組用戶，而香檳早午餐功能面向一組特定用戶。

當用作管理僅向高級用戶公開的功能時，與其他類別的功能開關(guān)相比，許可開關(guān)的壽命可能非常長 - 以多年為規(guī)模。由于權(quán)限是特定于用戶的，因此許可開關(guān)的開關(guān)決定將始終按請求進行，因此這是一個非常動態(tài)的開關(guān)。

三、管理不同類別的開關(guān)

現(xiàn)在我們有了一個開關(guān)分類方案，我們可以討論動態(tài)性和壽命這兩個維度如何影響我們使用不同類別的特征標志的方式。

3.1 靜態(tài)與動態(tài)開關(guān)

做出運行時路由決策的開關(guān)必然需要更復(fù)雜的開關(guān)路由器，以及這些路由器的更復(fù)雜配置。

對于簡單的靜態(tài)路由決策，開關(guān)配置可以是每個功能的簡單開或關(guān)，開關(guān)路由器僅負責將靜態(tài)開/關(guān)狀態(tài)中繼到開關(guān)點。正如我們之前所討論的，其他類別的開關(guān)更加動態(tài)并且需要更復(fù)雜的開關(guān)路由器。例如，實驗開關(guān)的路由器為給定用戶動態(tài)地做出路由決策，可能使用某種基于該用戶 id 的一致群組算法。這個開關(guān)路由器不需要從配置中讀取靜態(tài)開關(guān)狀態(tài)，而是需要讀取某種隊列配置，定義諸如實驗隊列和控制隊列應(yīng)該有多大。

稍后我們將深入探討管理此開關(guān)配置的不同方法。

3.2 長期開關(guān)與瞬態(tài)開關(guān)

我們還可以將開關(guān)類別劃分為本質(zhì)上是短暫的類別與長期存在且可能存在多年的類別。這種區(qū)別應(yīng)該對我們實現(xiàn)功能的開關(guān)點的方法有很大的影響。如果我們要添加一個將在幾天后刪除的發(fā)布開關(guān)，那么我們可能會使用一個開關(guān)點，它對 開關(guān)路由器進行簡單的 if/else 檢查。這就是我們之前使用樣條網(wǎng)格示例所做的：

function reticulateSplines () {if ( featureIsEnabled( "use-new-SR-algorithm" ) ){return enhancedSplineReticulation();} else {return oldFashionedSplineReticulation();} }

但是，如果我們要創(chuàng)建一個帶有開關(guān)點的新許可開關(guān)，我們希望它會持續(xù)很長時間，那么我們當然不希望通過不加選擇地散布 if/else 檢查來實現(xiàn)這些開關(guān)點。我們需要使用更易于維護的實現(xiàn)技術(shù)。

四、實施技術(shù)

功能標志似乎會產(chǎn)生相當混亂的開關(guān)點代碼，并且這些開關(guān)點也有在整個代碼庫中擴散的趨勢。保持這種趨勢檢查代碼庫中的任何功能標志很重要，如果標志將長期存在，這一點至關(guān)重要。有一些實現(xiàn)模式和實踐有助于減少這個問題。

4.1 將決策點與決策邏輯解耦

功能開關(guān)的一個常見錯誤是將做出開關(guān)決策的位置（開關(guān)點）與決策背后的邏輯（開關(guān)路由器）結(jié)合起來。

讓我們看一個例子。我們正在開發(fā)下一代電子商務(wù)系統(tǒng)。我們的一項新功能將允許用戶通過單擊訂單確認電子郵件（又稱發(fā)票電子郵件）中的鏈接輕松取消訂單。我們正在使用功能標志來管理我們所有下一代功能的推出。我們最初的特征標記實現(xiàn)如下所示：

invoiceEmailer.jsconst features = fetchFeatureTogglesFromSomewhere();function generateInvoiceEmail(){const baseEmail = buildEmailForInvoice(this.invoice);if( features.isEnabled("next-gen-ecomm") ){ return addOrderCancellationContentToEmail(baseEmail);}else{return baseEmail;}}

在生成發(fā)票電子郵件時，我們的 InvoiceEmailler 會檢查該next-gen-ecomm功能是否已啟用。如果是，那么電子郵件發(fā)送者會在電子郵件中添加一些額外的訂單取消內(nèi)容。

雖然這看起來是一種合理的方法，但它非常脆弱。關(guān)于是否在我們的發(fā)票電子郵件中包含訂單取消功能的決定直接與next-gen-ecomm功能綁定 - 使用魔術(shù)字符串。為什么發(fā)票電子郵件代碼需要知道訂單取消內(nèi)容是下一代功能集的一部分？如果我們想在不暴露訂單取消的情況下打開下一代功能的某些部分會怎樣？或反之亦然？如果我們決定只向某些用戶推出訂單取消功能怎么辦？隨著功能的開發(fā)，這種“開關(guān)范圍”更改很常見。還要記住，這些開關(guān)點往往會在整個代碼庫中激增。?

令人高興的是，軟件中的任何問題都可以通過添加一個間接層來解決。我們可以將開關(guān)決策點與該決策背后的邏輯解耦，如下所示：

featureDecisions.jsfunction createFeatureDecisions(features){return {includeOrderCancellationInEmail(){return features.isEnabled("next-gen-ecomm");}// ... additional decision functions also live here ...};} invoiceEmailer.jsconst features = fetchFeatureTogglesFromSomewhere();const featureDecisions = createFeatureDecisions(features);function generateInvoiceEmail(){const baseEmail = buildEmailForInvoice(this.invoice);if( featureDecisions.includeOrderCancellationInEmail() ){return addOrderCancellationContentToEmail(baseEmail);}else{return baseEmail;}}

我們引入了一個FeatureDecisions對象，它充當任何功能開關(guān)決策邏輯的收集點。我們?yōu)榇a中的每個特定開關(guān)決策在此對象上創(chuàng)建一個決策方法 - 在這種情況下，“我們是否應(yīng)該在發(fā)票電子郵件中包含訂單取消功能”由?includeOrderCancellationInEmail決策方法表示。

現(xiàn)在，決策“邏輯”是微不足道的通過傳遞next-gen-ecomm檢查狀態(tài)，但現(xiàn)在隨著邏輯的發(fā)展，我們有一個統(tǒng)一的地方來管理它。每當我們想修改特定開關(guān)決策的邏輯時，我們只需要去一個地方。

我們可能想要修改決策的范圍——例如哪個特定的功能標志控制決策。或者，我們可能需要修改做出決定的原因——從由靜態(tài)開關(guān)配置驅(qū)動到由 A/B 實驗驅(qū)動，或者由操作問題驅(qū)動，例如我們的一些訂單取消基礎(chǔ)設(shè)施的中斷。在所有情況下，我們的發(fā)票電子郵件發(fā)送者都可能會很高興地不知道如何或為什么做出該開關(guān)決定。

4.2 反轉(zhuǎn)決定

在前面的示例中，我們的發(fā)票電子郵件發(fā)送器負責詢問功能標記基礎(chǔ)設(shè)施應(yīng)該如何執(zhí)行。這意味著我們的發(fā)票電子郵件發(fā)送器有一個需要注意的額外概念 - 功能標記 - 以及與之耦合的額外模塊。這使得發(fā)票電子郵件更難單獨使用和思考，包括使其更難測試。隨著功能標記在系統(tǒng)中變得越來越普遍，我們將看到越來越多的模塊作為全局依賴項與功能標記系統(tǒng)耦合。不是理想的情況。

在軟件設(shè)計中，我們通常可以通過應(yīng)用控制反轉(zhuǎn)來解決這些耦合問題。在這種情況下確實如此。以下是我們?nèi)绾螌⑽覀兊陌l(fā)票電子郵件與我們的功能標記基礎(chǔ)設(shè)施分離：

invoiceEmailer.jsfunction createInvoiceEmailler(config){return {generateInvoiceEmail(){const baseEmail = buildEmailForInvoice(this.invoice);if( config.includeOrderCancellationInEmail ){return addOrderCancellationContentToEmail(email);}else{return baseEmail;}},// ... other invoice emailer methods ...};} featureAwareFactory.jsfunction createFeatureAwareFactoryBasedOn(featureDecisions){return {invoiceEmailler(){return createInvoiceEmailler({includeOrderCancellationInEmail: featureDecisions.includeOrderCancellationInEmail()});},// ... other factory methods ...};}

現(xiàn)在，不是我們InvoiceEmailler接觸它，而是在構(gòu)建時通過一個對象?FeatureDecisions將這些決定注入它。現(xiàn)在對功能標記一無所知。它只知道可以在運行時配置其行為的某些方面。這也使得 testing的行為更容易 - 我們可以通過在測試期間傳遞不同的配置選項來測試它生成帶有和不帶有訂單取消內(nèi)容的電子郵件的方式：configInvoiceEmaillerInvoiceEmailler

describe( 'invoice emailling', function(){it( 'includes order cancellation content when configured to do so', function(){// Given const emailler = createInvoiceEmailler({includeOrderCancellationInEmail:true});// Whenconst email = emailler.generateInvoiceEmail();// ThenverifyEmailContainsOrderCancellationContent(email);};it( 'does not includes order cancellation content when configured to not do so', function(){// Given const emailler = createInvoiceEmailler({includeOrderCancellationInEmail:false});// Whenconst email = emailler.generateInvoiceEmail();// ThenverifyEmailDoesNotContainOrderCancellationContent(email);}; });

我們還引入了一個FeatureAwareFactory集中創(chuàng)建這些決策注入對象的方法。這是一般依賴注入模式的應(yīng)用。如果控制反轉(zhuǎn)系統(tǒng)在我們的代碼庫中發(fā)揮作用，那么我們可能會使用該系統(tǒng)來實現(xiàn)這種方法。

4.3 避免條件

到目前為止，在我們的示例中，我們的開關(guān)點是使用 if 語句實現(xiàn)的。這對于一個簡單的、短暫的開關(guān)可能是有意義的。但是，在某個功能需要多個開關(guān)點或你希望開關(guān)點長期存在的地方，不建議使用點條件。一種更易于維護的替代方法是使用某種策略模式來實現(xiàn)替代代碼路徑：

invoiceEmailler.jsfunction createInvoiceEmailler(additionalContentEnhancer){return {generateInvoiceEmail(){const baseEmail = buildEmailForInvoice(this.invoice);return additionalContentEnhancer(baseEmail);},// ... other invoice emailer methods ...};} featureAwareFactory.jsfunction 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)容增強功能來應(yīng)用策略模式。FeatureAwareFactory在創(chuàng)建發(fā)票電子郵件時選擇一種策略，由FeatureDecision. 如果訂單取消應(yīng)該在電子郵件中，它會傳遞一個增強功能，將內(nèi)容添加到電子郵件中。否則，它會傳入一個identityFn增強器——它沒有任何效果，只是簡單地將電子郵件傳回而不做任何修改。

五、開關(guān)配置

5.1 動態(tài)路由與動態(tài)配置

早些時候，我們將功能開關(guān)分為對于給定的代碼部署而言開關(guān)路由決策基本上是靜態(tài)的，與那些決策在運行時動態(tài)變化的。需要注意的是，標志的決定可能會在運行時以兩種方式發(fā)生變化，這一點很重要。

• 首先，像運維開關(guān)這樣的東西可能會被動態(tài)重新配置從 On 到 Off 以響應(yīng)系統(tǒng)中斷。

• 其次，某些類別的開關(guān)（例如許可開關(guān)和實驗開關(guān)）根據(jù)某些請求上下文（例如哪個用戶發(fā)出請求）為每個請求做出動態(tài)路由決策。

前者是通過重新配置動態(tài)實現(xiàn)的，而后者則在本質(zhì)上就是動態(tài)的。這些固有的動態(tài)開關(guān)可能會做出高度動態(tài)的決策，但仍然具有配置動作，這是相當靜態(tài)的，也許只能通過重新部署來改變。實驗開關(guān)是此類功能標志的一個示例——我們實際上并不需要能夠在運行時修改實驗的參數(shù)。事實上，這樣做可能會使實驗在統(tǒng)計上無效。

5.2 首選靜態(tài)配置

如果特性標志的性質(zhì)允許的話，最好通過源代碼控制和重新部署來管理開關(guān)配置。通過源代碼控制管理開關(guān)配置給我們帶來的好處，與我們通過將源代碼控制用于基礎(chǔ)設(shè)施即代碼之類的東西所獲得的好處相同。

它可以允許開關(guān)配置與正在開關(guān)的代碼庫一起存在，這提供了一個非常大的好處：開關(guān)配置將以與代碼更改或基礎(chǔ)架構(gòu)更改完全相同的方式在你的持續(xù)交付流水線中移動。這可以充分發(fā)揮 CD 的優(yōu)勢 - 可重復(fù)的構(gòu)建，這些構(gòu)建以一致的方式跨環(huán)境進行驗證。它還大大減少了功能標志的測試負擔。很少需要驗證版本將如何通過開關(guān)關(guān)閉和打開來執(zhí)行，因為該狀態(tài)已被打包到版本中并且不會更改（至少對于較少動態(tài)的標志）。開關(guān)配置在源代碼控制中并行存在的另一個好處是，我們可以輕松查看以前版本中開關(guān)的狀態(tài)，并在需要時輕松重新創(chuàng)建以前的版本。

5.3 管理開關(guān)配置的方法

雖然靜態(tài)配置更可取，但在某些情況下，例如運維開關(guān)，需要更動態(tài)的方法。讓我們看一下用于管理開關(guān)配置的一些選項，從簡單但動態(tài)性較低的方法到一些高度復(fù)雜但具有許多額外復(fù)雜性的方法。

5.4 硬編碼開關(guān)配置

最基本的技術(shù)——也許基本到不被認為是功能標志——是簡單地注釋或取消注釋代碼塊。例如：

function reticulateSplines(){//return oldFashionedSplineReticulation();return enhancedSplineReticulation(); }

比注釋方法稍微復(fù)雜一點的是使用預(yù)處理器的#ifdef功能，如果可用的話。?

因為這種類型的硬編碼不允許動態(tài)重新配置開關(guān)，它僅適用于我們愿意遵循部署代碼模式以重新配置標志的功能標志。

5.5 參數(shù)化開關(guān)配置

硬編碼配置提供的構(gòu)建時配置對于許多用例（包括許多測試場景）來說不夠靈活。至少允許在不重新構(gòu)建應(yīng)用程序或服務(wù)的情況下，重新配置功能標志的簡單方法，是通過命令行參數(shù)或環(huán)境變量指定開關(guān)配置。這是一種簡單且歷史悠久的開關(guān)方法，早在有人將該技術(shù)稱為功能開關(guān)或特征標記之前就已經(jīng)存在。但是，它有局限性。跨大量進程協(xié)調(diào)配置可能會變得不方便，而且開關(guān)配置的更改需要重新部署或者至少重新啟動進程（并且可能需要重新配置開關(guān)的人對服務(wù)器進行特權(quán)訪問）。

5.6 開關(guān)配置文件

另一種選擇是從某種結(jié)構(gòu)化文件中讀取開關(guān)配置。這種開關(guān)配置的方法很常見，它作為更通用的應(yīng)用程序配置文件的一部分開始使用。

使用開關(guān)配置文件，你現(xiàn)在可以通過簡單地更改該文件而不是重新構(gòu)建應(yīng)用程序代碼本身來重新配置功能標志。但是，盡管在大多數(shù)情況下你不需要重新構(gòu)建應(yīng)用程序來開關(guān)功能，但你可能仍需要執(zhí)行重新部署以重新配置標志。

5.7 開關(guān)應(yīng)用數(shù)據(jù)庫中的配置

一旦達到一定規(guī)模，使用靜態(tài)文件來管理開關(guān)配置可能會變得很麻煩。通過文件修改配置相對繁瑣。確保一組服務(wù)器的一致性成為一項挑戰(zhàn)，使更改始終如一地更是如此。作為對此的回應(yīng)，許多組織將開關(guān)配置轉(zhuǎn)移到某種類型的集中式存儲中，通常是現(xiàn)有的應(yīng)用程序數(shù)據(jù)庫。這通常伴隨著某種形式的管理 UI 的構(gòu)建，它允許系統(tǒng)操作員、測試人員和產(chǎn)品經(jīng)理查看和修改功能標志及其配置。

5.8 分布式開關(guān)配置

使用已經(jīng)是系統(tǒng)架構(gòu)一部分的通用數(shù)據(jù)庫來存儲開關(guān)配置非常普遍；一旦引入功能標志并開始獲得牽引力，這是一個明顯的方式。然而，現(xiàn)在有一種特殊用途的分層鍵值存儲更適合管理應(yīng)用程序配置 - 像 Zookeeper、etcd 或 Consul 這樣的服務(wù)。這些服務(wù)形成一個分布式集群，它為連接到集群的所有節(jié)點提供環(huán)境配置的共享源。可以在需要時動態(tài)修改配置，并且集群中的所有節(jié)點都會自動收到更改通知——這是一個非常方便的附加功能。

其中一些系統(tǒng)（例如 Consul）帶有一個管理 UI，它提供了一種管理開關(guān)配置的基本方法。然而，在某些時候，通常會創(chuàng)建一個用于管理開關(guān)配置的小型自定義應(yīng)用程序。

5.9 覆蓋配置

到目前為止，我們的討論假設(shè)所有配置都由單一機制提供。許多系統(tǒng)的實際情況更為復(fù)雜，配置的覆蓋層來自各種來源。使用開關(guān)配置，具有默認配置以及特定于環(huán)境的覆蓋是很常見的。這些覆蓋可能來自像附加配置文件這樣簡單的東西，也可能來自像 Zookeeper 集群這樣復(fù)雜的東西。

請注意，任何特定于環(huán)境的覆蓋都與持續(xù)交付的理想背道而馳，即在交付管道中始終擁有完全相同的位和配置流。通常實用主義要求使用一些特定于環(huán)境的覆蓋，但是努力使你的可部署單元和你的配置盡可能與環(huán)境無關(guān)，這將導(dǎo)致更簡單、更安全的管道。當我們談?wù)摐y試功能開關(guān)系統(tǒng)時，我們將很快重新討論這個主題。

• 針對每個請求覆蓋

環(huán)境特定配置覆蓋的另一種方法是允許通過特殊 cookie、查詢參數(shù)或 HTTP 標頭在每個請求的基礎(chǔ)上覆蓋開關(guān)的開/關(guān)狀態(tài)。與完整的配置覆蓋相比，這有一些優(yōu)勢。如果服務(wù)是負載平衡的，你仍然可以確信無論你點擊哪個服務(wù)實例，都會應(yīng)用覆蓋。你還可以在生產(chǎn)環(huán)境中覆蓋功能標志而不影響其他用戶，并且你不太可能意外地留下覆蓋。

這種按請求方法的缺點是它引入了一種風險，即好奇或惡意的最終用戶可能會自己修改功能開關(guān)狀態(tài)。一些組織可能對某些未發(fā)布的功能可能對足夠堅定的一方公開訪問的想法感到不舒服。對覆蓋配置進行加密簽名是緩解這種擔憂的一種選擇，但無論如何這種方法都會增加功能開關(guān)系統(tǒng)的復(fù)雜性和攻擊面。

六、使用帶有特征標記的系統(tǒng)

雖然功能開關(guān)絕對是一種有用的技術(shù)，但它也帶來了額外的復(fù)雜性。在使用帶有特征標記的系統(tǒng)時，有一些技術(shù)可以幫助簡化你的生活。

6.1 公開當前功能開關(guān)配置

將構(gòu)建/版本號嵌入到已部署的工件中并在某處公開該元數(shù)據(jù)一直是一種有用的做法，以便開發(fā)人員、測試人員或操作員可以找出在給定環(huán)境中運行的特定代碼。相同的想法應(yīng)該應(yīng)用于功能標志。任何使用功能標志的系統(tǒng)都應(yīng)該為操作員提供某種方式來發(fā)現(xiàn)開關(guān)配置的當前狀態(tài)。在面向 HTTP 的 SOA 系統(tǒng)中，這通常是通過某種元數(shù)據(jù) API 端點或端點來完成的。參見例如 Spring Boot 的 Actuator endpoints。

6.2 利用結(jié)構(gòu)化的開關(guān)配置文件

通常將基本開關(guān)配置存儲在某種結(jié)構(gòu)化的、人類可讀的文件（通常為 YAML 格式）中，通過源代碼控制進行管理，我們可以從此類文件中獲得額外的好處。為每個開關(guān)包含人類可讀的描述非常有用，特別是對于由核心交付團隊以外的人管理的開關(guān)。

在嘗試決定是否在生產(chǎn)中斷事件期間啟用運維開關(guān)時，你希望看到什么：basic-rec-algo，還是“使用簡單的推薦算法。這很快并且在后端系統(tǒng)上產(chǎn)生的負載更少，但更少比我們的標準算法準確。”? 一些團隊還選擇在他們的開關(guān)配置文件中包含額外的元數(shù)據(jù)，例如創(chuàng)建日期、主要開發(fā)人員聯(lián)系人，甚至是短期開關(guān)的到期日期。

6.3 以不同方式管理不同的開關(guān)

如前所述，具有不同特征的功能開關(guān)有多種類別。應(yīng)該接受這些差異，并以不同的方式管理不同的開關(guān)，即使所有不同的開關(guān)都可以使用相同的技術(shù)機器進行控制。

讓我們回顧一下我們之前的電子商務(wù)網(wǎng)站示例，該網(wǎng)站在主頁上有一個推薦產(chǎn)品部分。最初，我們可能會在開發(fā)時將該部分放在發(fā)布開關(guān)后面。然后，我們可能會將其移至實驗開關(guān)的背后，以驗證它是否有助于增加收入。最后，我們可能會將它移到運維開關(guān) 后面，以便在我們處于極端負載下時可以將其關(guān)閉。如果我們遵循先前關(guān)于從開關(guān)點中解耦決策邏輯的建議，那么開關(guān)類別中的這些差異應(yīng)該對開關(guān)點代碼沒有任何影響。

然而，從功能標志管理的角度來看，這些轉(zhuǎn)換絕對應(yīng)該產(chǎn)生影響。作為從 發(fā)布開關(guān)過渡到實驗開關(guān)的一部分，配置開關(guān)的方式會發(fā)生變化，并且可能會移動到不同的區(qū)域 - 可能會進入管理 UI 而不是源代碼管理中的 yaml 文件。產(chǎn)品人員現(xiàn)在可能會管理配置而不是開發(fā)人員。同樣，從實驗開關(guān)過渡到運維開關(guān) 將意味著開關(guān)的配置方式、配置所在的位置以及誰管理配置的另一個變化。

6.4 功能開關(guān)引入驗證復(fù)雜性

使用帶有功能標記的系統(tǒng)，我們的持續(xù)交付過程變得更加復(fù)雜，尤其是在測試方面。當同一個工件通過 CD 管道時，我們經(jīng)常需要測試多個代碼路徑。為了說明原因，假設(shè)我們正在交付一個系統(tǒng)，該系統(tǒng)可以在啟用開關(guān)時使用新的優(yōu)化稅收計算算法，或者繼續(xù)使用我們現(xiàn)有的算法。在給定的可部署工件正在通過我們的 CD 管道移動時，我們無法知道開關(guān)是否會在生產(chǎn)中的某個時候打開或關(guān)閉 - 畢竟這就是功能標志的全部意義所在。因此，為了驗證可能最終在生產(chǎn)中運行的所有代碼路徑，我們必須在兩種狀態(tài)：開關(guān)打開并關(guān)閉。

我們可以看到，通過一個單一的開關(guān)，這引入了至少在我們的一些測試中加倍的要求。隨著多個開關(guān)的發(fā)揮，我們有可能開關(guān)狀態(tài)的組合爆炸。驗證每個狀態(tài)的行為將是一項艱巨的任務(wù)。這可能會導(dǎo)致以測試為重點的人們對功能標志產(chǎn)生一些健康的懷疑。

令人高興的是，情況并沒有一些測試人員最初想象的那么糟糕。雖然帶有功能標記的候選版本確實需要使用一些開關(guān)配置進行測試，但沒有必要測試“每個”可能的組合。大多數(shù)功能標志不會相互交互，并且大多數(shù)版本不會涉及對多個功能標志的配置進行更改。

一個好的約定是在功能標志關(guān)閉時啟用現(xiàn)有的或舊有的行為，而在它打開時啟用新的或未來的行為。

那么，團隊應(yīng)該測試哪些功能開關(guān)配置？測試你希望在生產(chǎn)中生效的開關(guān)配置是最重要的，這意味著當前的生產(chǎn)開關(guān)配置加上你打算發(fā)布的所有開關(guān)都已打開。測試回退配置也是明智之舉，你打算釋放的那些開關(guān)也會被關(guān)閉。為了避免在未來的版本中出現(xiàn)任何意外的回歸，許多團隊還會在所有開關(guān)都打開的情況下執(zhí)行一些測試。請注意，僅當你堅持開關(guān)語義的約定時，此建議才有意義，其中在功能關(guān)閉時啟用現(xiàn)有或舊有行為，而在功能開啟時啟用新行為或未來行為。

如果你的功能標志系統(tǒng)不支持運行時配置，那么你可能必須重新啟動你正在測試的進程才能觸發(fā)開關(guān)，或者更糟糕的是，將工件重新部署到測試環(huán)境中。這會對驗證過程的周期時間產(chǎn)生非常不利的影響，進而影響 CI/CD 提供的所有重要反饋循環(huán)。為避免此問題，請考慮公開一個端點，該端點允許對功能標志進行動態(tài)內(nèi)存重新配置。當你使用諸如實驗開關(guān)之類的東西時，這些類型的覆蓋變得更加必要，在這種情況下，使用開關(guān)的兩個路徑更加繁瑣。

這種動態(tài)重新配置特定服務(wù)實例的能力是一個非常鋒利的工具。如果使用不當，可能會在共享環(huán)境中造成很多痛苦和混亂。這個工具應(yīng)該只被自動化測試使用，并且可能作為手動探索性測試和調(diào)試的一部分。如果需要在生產(chǎn)環(huán)境中使用更通用的開關(guān)控制機制，最好使用真正的分布式配置系統(tǒng)構(gòu)建，如上面開關(guān)配置部分所述。

6.5 在哪里放置你的開關(guān)

• 在邊緣開關(guān)

對于需要每個請求上下文的開關(guān)類別（實驗開關(guān)、許可開關(guān)），將開關(guān)點放置在系統(tǒng)的邊緣服務(wù)中是有意義的——即向最終用戶展示功能的公開 Web 應(yīng)用程序。這是你的用戶的個人請求首先進入你的域的地方，因此你的開關(guān)路由器有最多的上下文可用于根據(jù)用戶及其請求做出開關(guān)決策。將開關(guān)點放置在系統(tǒng)邊緣的一個附帶好處是，它可以將繁瑣的條件開關(guān)邏輯排除在系統(tǒng)核心之外。在許多情況下，你可以將開關(guān)點放置在你正在呈現(xiàn) HTML 的位置，如以下 Rails 示例所示：

someFile.erb<%= if featureDecisions.showRecommendationsSection? %><%= render 'recommendations_section' %><% end %>

當你控制對尚未準備好發(fā)布的面向用戶的新功能的訪問時，將開關(guān)點放置在邊緣也很有意義。在這種情況下，你可以再次使用簡單地顯示或隱藏 UI 元素的開關(guān)來控制訪問。例如，也許你正在構(gòu)建使用 Facebook 登錄應(yīng)用程序的功能，但還沒有準備好將其推廣給用戶。此功能的實現(xiàn)可能涉及架構(gòu)各個部分的更改，但你可以通過隱藏“使用 Facebook 登錄”按鈕的 UI 層的簡單功能開關(guān)來控制功能的公開。有趣的是，使用其中一些類型的功能標志，大部分未發(fā)布的功能本身可能實際上是公開的，但位于用戶無法發(fā)現(xiàn)的 url 上。

• 在核心開關(guān)

還有其他類型的較低級別的開關(guān)必須放置在你的架構(gòu)中更深的位置。這些開關(guān)通常在本質(zhì)上是技術(shù)性的，并且控制著某些功能如何在內(nèi)部實現(xiàn)。一個示例是發(fā)布開關(guān)，它控制是在第三方 API 前使用新的緩存基礎(chǔ)設(shè)施，還是直接將請求路由到該 API。在這些情況下，在功能被開關(guān)的服務(wù)中本地化這些開關(guān)決策是唯一明智的選擇。

6.6 管理功能開關(guān)的持有成本

功能標志有快速增加的趨勢，特別是在首次引入時。它們有用且創(chuàng)建成本低，因此通常會創(chuàng)建很多。然而，開關(guān)確實會帶來持有成本。它們要求你在代碼中引入新的抽象或條件邏輯。它們還引入了顯著的測試負擔。騎士資本集團的4.6 億美元錯誤是一個警示故事，說明當你沒有正確管理功能標志時（除其他外）會出現(xiàn)什么問題。

精明的團隊將他們的功能開關(guān)視為帶有持有成本的庫存，并努力將庫存保持在盡可能低的水平。

精明的團隊將其代碼庫中的功能開關(guān)視為帶有持有成本的庫存，并尋求將庫存保持在盡可能低的水平。為了使功能標志的數(shù)量保持可管理，團隊必須主動刪除不再需要的功能標志。一些團隊的規(guī)則是，每當首次引入發(fā)布開關(guān)時，總是將開關(guān)刪除任務(wù)添加到團隊的待辦事項中。其他團隊將“到期日期”放在他們的開關(guān)按鈕上。有些人甚至會制造“定時炸彈”，如果功能標志在其到期日期之后仍然存在，它將無法通過測試（甚至拒絕啟動應(yīng)用程序！）。

我們還可以采用精益方法來減少庫存，對系統(tǒng)在任何時候允許擁有的功能標志的數(shù)量進行限制。一旦達到該限制，如果有人想要添加新的開關(guān)，他們首先需要完成刪除現(xiàn)有開關(guān)標識的工作。

總結(jié)

以上是生活随笔為你收集整理的万字长文 - 解读功能开关 | IDCF的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。