再談特性切換

據thoughtworks顧問pete hodgson介紹，按照使用時長和動態性進行分類，並以此為基礎實現恰當的特性切換，有助於應對運維複雜性。他在博文中擴充套件了martin fowler的特性切換模式，並提出了發布、ops、試驗和許可權四類特性切換實現策略。在大型專案中，持續交付的困難需要特性切換來克服。

\\ pete寫道，「特性切換是一項功能強大的技術，允許團隊修改系統行為，而無需改變**」。他提供了乙個動態特性切換的簡單示例：

\function reticulatesplines()  else \}\

在上面的例子中，featureisenabled()方法呼叫的位置就是pete所說的決策點或切換點，該方法實現了乙個簡單的切換路由，通常是基於乙個簡單的配置檔案（切換配置）來實現。高階特性切換可能會考慮切換上下文，並實現「使用者群（將使用者分組，一項特性對有的組總是開啟，對有的組總是關閉）的概念」。

作者提出了以下幾種不同的切換型別：\\

下面基於使用時長和動態性兩個維度繪製的切換分類圖：

此外，martin fowler將特性切換分為構建時切換和執行時切換。構建時切換可以作為執行時發布類切換的一種靜態替代方案，藉此，哪一項特性進入發布是在編譯期間決定的。在各種agile release trains中，發布構建遵循乙個固定的時間表。測試過的特性可以進入發布序列，而未完成或不穩定的特性在構建時會被排除在外。金絲雀微服務部署是另一種可以實現分離的可選方法。

\\ pete認為，「隨著時間的推移，特性切換有一種越來越普及的趨勢」。他提出了以下幾項特性切換實現原則：\\

pete繼續討論了不同的切換配置選項。雖然有些發布類切換可以在應用程式啟動時啟用或禁用，但其他切換需要在執行時重新進行配置，比如ops類切換，同時，試驗類切換和許可權類切換則在每個使用者會話甚或每次請求時發揮作用。作者建議使用靜態配置作為特性切換配置的首選模式，因為一旦配置作為**正確完成，就可以對它進行版本控制，並將其視為**（審查、部署等等）。對於高階設定，他建議使用諸如consul、etcd或zookeeper這樣的分布式鍵-值儲存。

\\ 特性切換在大型專案持續交付管道中變得越來越重要，因為它們有助於將部署從發布中分離出來。協調分支合併以及並行向公共環境發布特性使團隊必須序列化任務，導致速度下降。通過消除全是或全否的發布策略，特性切換幫助恢復了團隊所需要的速度，雖然這是有成本的。除了會增加運維複雜度外，特性切換還會廣泛引入其他的風險，尤其是使用發布類切換遮蔽未完成的**時。據jim bird介紹，特性切換會導致「**更脆弱、更難測試、更難理解和維護、更難提供技術支援，而且更不安全。」他的主要論據是，將未經測試的**引入生產環境是乙個糟糕的主意，它們可能會在無意間暴露出來。他舉了一家金融機構因為這種情況破產的案例。「特性切換需要乙個魯棒的工程過程、可靠的技術設計和成熟的特性切換生命週期管理。不具備這三個關鍵的條件，使用特性切換就是反生產力的。」

\\ 風險暫且擱置，facebook在最近的一篇**中**了特性切換在web規模下的應用。facebook的實現嚴重依賴特性切換。他們使用的不是基於配置的切換，而是基於規則的切換。一款名為gatekeeper的ui管理工具用於啟用特性，它運用一種靈活的選擇過濾方法劃分使用者群。那樣，特性就可以暴露給根據人口統計學和其他引數選出的使用者：「起初，gatekeeper可以只對開發這個特性的工程師開放該產品特性。然後，gatekeeper可以向更大比例的facebook員工開發該特性，比如從1%到10%再到100%。在內部測試成功後，它可以向某個特定區域內5%的使用者開放。最後，該特性可以逐步在全球推出，比如，覆蓋範圍從1%到10%再到100%。」，**作者這樣解釋道。

檢視英文原文：feature toggles revisited

再談特性切換

再談特性切換

再談建構函式

再談位元組對齊

再談特性切換

再談特性切換

再談建構函式

再談位元組對齊

相關推薦