當應用程序規(guī)模比較小的時候，應用的配置可能只有短短的幾行粟瞬，配置的分發(fā)也只需要通過復制下本地文件下發(fā)即可同仆。但是隨之應用規(guī)模變大，配置變得越來越復雜裙品，如何管理不同應用的不同配置版本變得越發(fā)困難俗批，本文介紹了facebook是如何管理整個配置系統(tǒng)的。

摘要

facebook的網(wǎng)頁端和app端每天都有成千上萬次的配置變更市怎，對于活躍用戶也有上億次的配置檢查來決定下發(fā)產(chǎn)品新特性岁忘。通過配置變更，可以動態(tài)開啟產(chǎn)品的新特性区匠，對于不同的應用設備進行A/B測試干像，以及通過修改權重對不同數(shù)據(jù)中心進行負載均衡社证，同時還能下發(fā)不同的ML模型來提高feed流的的排名割坠。

簡介

軟件的開發(fā)部署周期變得越來越短，對于互聯(lián)網(wǎng)應用叠赐，頻繁的軟件更新不僅僅需要的是代碼模型的更新戚篙，對于配置也有大量的變更需求五鲫。比如對于facebook主頁，每天會進行兩次的代碼發(fā)版已球，對于配置則更頻繁臣镣，目前主頁每天有成千次的配置變更辅愿。
一大群開發(fā)人員頻繁地進行配置變更很難避免配置錯誤的發(fā)生從而導致網(wǎng)頁故障智亮。然而避免配置錯誤只是配置管理眾多挑戰(zhàn)中其中的一個忆某。配置管理還包括以下眾多的挑戰(zhàn)

配置管理收斂

facebook內部有大量的系統(tǒng)對配置管理有不同的需求，此前阔蛉，每個系統(tǒng)都有自己的一套配置存儲和分發(fā)機制弃舒，導致很難對配置進行統(tǒng)一的管理。為了避免配置擴散状原，facebook在統(tǒng)一的基礎平臺上構建了一套工具來支持不同的額用力場景聋呢。這些工具從統(tǒng)一的配置中心管理了成千上萬的配置，并將他們分發(fā)到數(shù)十萬的服務器和數(shù)億的額移動設備颠区。

配置更改及版本管理

大型系統(tǒng)中通常有許多靈活的配置開發(fā)可以動態(tài)修改削锰，在facebook，配置文件的中位數(shù)大小為1kb毕莱，有的比較大的配置達到了Mb甚至Gb級別器贩，人肉編輯修改這么大的配置犯錯是難以避免的，即便一個小小的配置 錯誤也可能導致頁面故障朋截。因此facebook才用了配置及代碼的管理方式來編譯生成配置蛹稍，并通過版本控制工具對配置生成程序和參數(shù)進行版本控制管理。

預防配置錯誤

1. 配置生成器會自動進行參數(shù)合法性校驗部服。
2. 配置變更視為與代碼變更一樣需要進行code view唆姐。
3. 影響到前端頁面的配置變更需要經(jīng)過自動集成測試。
4. 配置變更會通過金絲雀測試發(fā)布到線上進行驗證廓八。

配置依賴

一個大型的系統(tǒng)往往由許多團隊互相協(xié)作進行完成奉芦，因此不同的模塊間必然存在依賴關系，每個系統(tǒng) 有自己的配置模塊剧蹂，然而往往也對其他系統(tǒng)的配置存在依賴。例如監(jiān)控系統(tǒng)升級了新的配置來支持新的feature国夜，所有系統(tǒng)的監(jiān)控模塊也要跟著更新配置來使新feature生效减噪。facebook采用了類似c++里include的方式來聲明配置的依賴關系车吹。后面會詳細介紹依賴的具體實現(xiàn)筹裕。

可靠可拓展的配置分發(fā)

從后端應用到移動設備，配置的大小從字節(jié)到Gb都有窄驹，對于地理位置分布 廣泛的應用朝卒，配置下發(fā) 失敗是在所難免的，如何保證配置的及時可靠乐埠，以及如何避免因為配置系統(tǒng)成為瓶頸從來帶來可用性問題是一個巨大的挑戰(zhàn)抗斤，本文后續(xù)將介紹如何應對這些挑戰(zhàn)囚企。主要包括

• 運行時配置管理
• 配置管理系統(tǒng)站，包括P2P分發(fā)
• 對大規(guī)模配置系統(tǒng)的使用經(jīng)驗以及分析

使用案例和解決方法

• 特性開關

facebook使用快速迭代發(fā)布的方法來快速獲取用戶反饋進行迭代瑞眼。當一個產(chǎn)品還在 開發(fā)階段的使用龙宏，他的代碼就會被發(fā)布到線上，只不過是禁用了特性開關伤疙。facebook使用了 一個叫Gatekeeper的組件來慢慢開啟新的feature银酗。如果出現(xiàn)了問題Gatekeeper可以迅速關閉新特性，同時它還能決定該特性對哪些用戶生效徒像，例如內部員工或者1%的用戶設備黍特。

• 產(chǎn)品實驗

通過A/B測試來進行決策驅動，例如锯蛀，由于硬件差異灭衷，F(xiàn)acebook的Messenger上的VoIP的 回聲消除參數(shù)需要針對不同的設備進行調整，通過配置變更可以進行不同參數(shù)的測試實驗旁涤。

• 應用層流量控制

配置管理可以方便地管理不同的站點流量流向翔曲。自動化工具會自動修改流量進行區(qū)域間的流量遷移，以便在 生產(chǎn)環(huán)境進行負載測試拭抬，影子測試時部默，則可以通過鏡像流量復制到測試服務進行測試。

• 負載均衡

facebook將用戶數(shù)據(jù)存儲在TAO系統(tǒng)里造虎，當 新集群上線或者舊集群故障時傅蹂，系統(tǒng)會自動根據(jù)集群新的拓撲結構進行流量的均衡和數(shù)據(jù)的遷移。

• 監(jiān)控報警

通過動態(tài)修改配置算凿，可以動態(tài)修改：

1. 監(jiān)控數(shù)據(jù)采集
2. 修改監(jiān)控面板
3. 報警規(guī)則檢測
4. 報警規(guī)則訂閱
5. 根據(jù)報警信息自動進行修復份蝴，例如服務重啟

• 更新ML模型

根據(jù)最新的數(shù)據(jù)生產(chǎn)最新的ML模型，通過下發(fā)更新模型來更新搜索排名和feeds流排名氓轰，ML模型的大小從kb到Gb都有

• 控制應用內部行為

這可能是最普遍的 一個使用場景了婚夫，生生產(chǎn)系統(tǒng)通常擁有許多的開關來管理內部的行為。例如存儲服務會配置使用多少內部署鸡，定義如何批量刷盤案糙，如何進行預讀提升性能等。

工具鏈概覽

configuration management tools

• Configerator 所有組件的基石靴庆，包括版本管理 編輯 配置review和 自動金絲雀測試以及配置分發(fā)时捌。其他的所有 工具都是構建于此之上以提供特殊的方法需求。
• Gatekeeper 產(chǎn)品特性功能開關炉抒，也可以通過A/B測試來獲取最佳參數(shù)奢讨。
• Package Vessel P2P的 配置傳輸工具，主要用來傳輸GB量級的配置模型
• Sitevars 為 前端PHP提供的簡單易用的適配API
• MobileConfig 管理安卓 IOS的配置焰薄，對后端的存儲系統(tǒng)進行了解耦拿诸，

Configerator, Sitevars, and PackageVessel

配置修改

首先先假設: 1. 大多數(shù)開發(fā)人員更加傾向于通過寫代碼生成配置 2. 配置生成腳本比配置本身更容易維護扒袖。這兩個假設在后面會有數(shù)據(jù)支撐驗證。

帶著這些假設亩码，configerator逐步推行了配置及代碼的策略季率。

Figure2 Configerator complier

如圖二，通過依賴引用蟀伸，配置編譯器進行校驗生成了最終的配置信息蚀同。通過將配置模塊化以及導入復用缅刽，大大降低了配置的維護成本啊掏。配置編譯器自動生成配置更新并推送到git倉庫。

通過UI和sitavars提高易用性

configerator被設計成了所有案例場景的基石衰猛，因此必須具有足夠的靈活性和拓展性迟蜜。但是過于靈活也帶來了一些問題。好比殺雞焉用牛刀啡省，對于一些復雜的配置信息娜睛，模塊化依賴導入會提升可維護性，但是對于一些簡單的配置卦睹，過于靈活就顯得有些臃腫了畦戒。此外通過UI 生成無需寫任何代碼就生成配置骨架，然后在通過configerator進一步生成配置文件结序。sitavars主要為 前端的的php提供了簡易的kv配置存儲信息障斋。

預防配置錯誤

配置錯誤會導致服務故障，facebook通過以下方法來 避免配置錯誤:

1. config validator 保證變量的有效性
2. 對配置生成程序和配置文件進行code review
3. 人肉配置測試
4. 自動化集成測試
5. 自動化金絲雀測試

圖三詳細介紹了這個流程

Figure 3: Architecture of Configerator

1. 首先徐鹤，開發(fā) 人員修改完配置以后 垃环，會通過腳本使用新配置構建一套測試環(huán)境，當測試驗證通過后會提交配置變更信息以及測試結果到Phabriacator返敬。

2. 如果配置的變更與前端有關聯(lián)遂庄，則會觸發(fā) sandcastle工具使用 新 配置自動部署允許集成測試。sandcastle會將測試結果提交給phaboacator然后交給reviewers進行 review劲赠。

3. 當review獲得approve的時候開發(fā)人員會將變更推送到遠程的 金絲雀服務涛目。

4. 金絲雀服務自動部署新配置新線上環(huán)境進行驗證，彌補了人肉測試和集成測試覆蓋不足的問題

5. 生產(chǎn)環(huán)境的金絲雀測試分為多個階段凛澎。例如

   a. 先發(fā)布到20臺服務器
   b. 將配置變更發(fā)送到集群的所有節(jié)點霹肝。

   對于每一個階段，會對指定的測試節(jié)點進行監(jiān)控檢測以及指標收集预厌。

6. 當新配置通過所有階段的測試以后阿迈，金絲雀服務會將配置提交到遠程的 Landing strip服務并將配置提交到主倉庫。

可靠可拓展的配置分發(fā)

將配置分發(fā)給成千上萬的服務轧叽，中間出現(xiàn)異常是 在所難免的苗沧。因此要求configerator 必須具備以下能力刊棕。

1. 可用性（配置下發(fā)失敗不能影響服務的運行）
2. 數(shù)據(jù)一致性： 應用的不同節(jié)點必須保證配置下發(fā)最終一致，盡管沒法保證 強一致待逞。

facebook通過 git tailer持續(xù)從倉庫中獲取配置變更信息并推送到 zeus甥角。 zeus是zookeeper的for可多版本并做了一些拓展和性能增強從而來滿足facebook的規(guī)模。通過一致性協(xié)議保證服務的可用性识樱。

zeus使用三層高扇出的樹模型來推送配置變更嗤无。 leader → observer → proxy. 每個 leader的子樹中有上百個observers。數(shù)據(jù)中心具有較大的額帶寬怜庸，并且只有少量數(shù)據(jù)從數(shù)節(jié)點進行 扇出当犯，因此高扇出模型在數(shù)據(jù)中心是可行的。數(shù)據(jù)量大的配置則通過P2P進行分發(fā)割疾。

每個數(shù)據(jù)中心有 多個集群組成嚎卫，每個集群又包含數(shù)千臺服務器，并且有多臺的服務被指定為observers宏榕，每個 observer保存leader的全量只讀數(shù)據(jù)副本拓诸。當 用戶提交寫入以后，leader會將寫同步給follower麻昼，然后在 異步同步給observers奠支。如果 observer失敗之后重連了，會發(fā)送本地保存的最新的transaction id然后獲取未同步的寫操作抚芦，zookeeper的一致性協(xié)議保證了commit消息是有序的倍谜。

每個服務會運行一個 proxy進程，并從集群中 隨機選擇 一個observer節(jié)點進行連接燕垃。如果observer故障 了枢劝，proxy會自動連接其他的observer節(jié)點，于observer節(jié)點不同的是卜壕，proxy不會保存所有的配置副本信息您旁，而是只會保存應用服務所需的配置數(shù)據(jù)。

應用啟動的時候轴捎，會通過鏈接的configerator client library去獲取配置鹤盒。啟動階段，會直接請求proxy去來獲取配置信息侦副。proxy從observer讀取數(shù)據(jù)并將數(shù)據(jù)緩存到 本地磁盤侦锯，如果 proxy故障 了，那么應用程序會直接從本地的磁盤緩存直接讀取數(shù)據(jù)秦驯。通過本地磁盤緩存尺碰，提高了配置服務的可用性。

configerator使用push的方式進行配置變更的通知。pull模型最大的優(yōu)點是實現(xiàn)簡單亲桥，因為服務端可以實現(xiàn)為無狀態(tài)的洛心。然而pull模型卻不怎么高效: 1. pull的間隔不好定義控制，2. 每次pull需要返回全量數(shù)據(jù)對于請求量過大的場景不太適合题篷。（此處不敢茍同词身，pull模型也能做增量返回的。

使用Package Vessel進行大配置分發(fā)

像ML模型這么大的配置信息番枚，如果使用 zeus進行分發(fā)法严，會嚴重受限于帶寬的吞吐導致可拓展性的問題。

Package Vessel使用 元數(shù)據(jù)于內容分離對的方式來 管理這些大配置信息葫笼。當配置 變更的時候深啤，配置的內容會被存儲到 存儲系統(tǒng)，configerator只會保存更新 配置的metadata版本信息渔欢，以及存儲配置內容的地址信息墓塌。當收到配置變更時，應用程序使用bt協(xié)議從存儲服務拉取配置奥额，使用相同配置的服務則可以直接用P2P進行分發(fā)共享。

當配置大小 超過1M的時候访诱，推薦使用Package Vessel進行管理.

提升commit吞吐

當往git提交配置時垫挨，需要檢查遠端 是否有變更，如果有變更触菜，則需要拉取變更到 本隊然后進行合并提交九榔，盡管變更和本地修改并無沖突。

Landing Strip簡化了這一修改流程:

1. 從不同的committers結束commit信息涡相。
2. 按照FIFO的方式進行處理
3. 將提交推送到共享倉庫而無需commit拉取到本地進行resolve哲泊，只有真的有數(shù)據(jù)沖突的時候才需要人為進行處理。

雖然該組件解決了提交沖突的問題催蝗，但是沒法解決以下問題:

1. 一個倉庫每次只能接受 一次提交
2. 倉庫變大以后git操作會變慢

為了提升吞吐切威，facebook將一個統(tǒng)一的大倉庫遷移成多個小倉庫，通過命名空間進行區(qū)分丙号，不同的路徑前綴提交到不同的倉庫先朦，從而提升了整個的提交吞吐。

Gatekeeper

快速迭代發(fā)版 有助于快速獲取用戶反饋進行優(yōu)化犬缨，同時也讓問題定位變得簡單喳魏， 因為每次版本的修改都較小從而較容易定位。

當應用還在開發(fā)的過程中怀薛，新feature的代碼就會被提交到生產(chǎn)環(huán)境只不過是被設置為禁用狀態(tài)刺彩，通過gatekeeper可以動態(tài)控制儀新feature的灰度比例，如果出現(xiàn)故障，則可以快速 關閉feature创倔。

gatekeeper的控制邏輯通常在configerator中被 存儲為 一個json文件三热，通過解析json配置信息執(zhí)行對應的控制流。但是對于一些復雜的場景三幻，則沒法通過簡單配置進行管理就漾，例如maprerduce任務，因此gatek暴露了 laser的 kv接口用于與 外部系統(tǒng)進行集成念搬。任何 系統(tǒng)可以實現(xiàn)laser接口于gatek進行進行從而控制訪問邏輯抑堡。

移動端配置

由于復雜的額移動網(wǎng)絡環(huán)境，移動端的配置管理和服務端有相當多不一樣的地方朗徊。首先移動網(wǎng)絡嚴格受限首妖，其次移動端有各種各樣的平臺個各種不同的適配版本。

mobileConfig通過最大程度復用數(shù)據(jù)中心的工具鏈解決了這些挑戰(zhàn)爷恳。

Mobile architecture

通過 translation layer進行了適配轉化避免了耦合有缆，同時通過跨平臺的c++庫進行適配調用轉換。

由于推送通知是不可靠的温亲，一次sdk還通過周期性的拉起來獲取變更信息棚壁，為了減少帶寬的開銷，每次客戶端會發(fā)送配置的hash值栈虚，只有 hash值變更的時候袖外，服務端才會返回新的配置信息。

使用經(jīng)驗與數(shù)據(jù)分析

這一章節(jié)主要介紹了一些經(jīng)驗和使用數(shù)據(jù)的分析魂务，具體的數(shù)據(jù)分析不做詳細說明可以參考原文曼验。簡單 做下概括:

1. 對于復雜的配置，開發(fā)人員更愿意使用代碼進行配置生成
2. 當配置發(fā)生變更時粘姜，大概需要10min進行金絲雀測試
3. 配置錯誤主要由幾種情況造成
   1. 版本兼容鬓照，舊代碼無法解析新配置
   2. 新配置導致代碼觸發(fā)了異常路徑bug
   3. 邊界值錯誤

通過代碼review可以有效降低這些配置錯誤，同時金絲雀測試也能有效降低配置錯誤的出現(xiàn)孤紧。
經(jīng)驗告訴我們豺裆，無論是代碼還是配置，都需要詳細的review坛芽。

結論

本文介紹了facebook的 配置管理技術棧留储，主要包含以下幾個方面:

1. 定于了問題域以及用戶場景
2. 描述了全局的解決方案
3. 對線上的使用場景做了詳細的數(shù)據(jù)分析
   未來的主要工作方向是提高configerator的可拓展性，增強自動金絲雀測試咙轩，提升app的覆蓋率获讳，以及提高配置的抽象化。

這一套系統(tǒng)不但適用于大規(guī)幕詈埃互聯(lián)網(wǎng)系統(tǒng)丐膝，也適用于小型系統(tǒng)。以下為簡要的總結，想要詳細的了解最好仔細看原文帅矗。

• 敏捷配置管理才能支持敏捷開發(fā)
• 沒有最好的只有最合適的偎肃，只要有合適的工具，大型公司也能 進行開放式的配置管理
• 在數(shù)據(jù)中心內部浑此，push模型可能更高效 累颂？
• 推拉結合的方式可以提高可靠性
• 使用meta與數(shù)據(jù)內容分離的方式進行P2P的配置分發(fā)，同時保證了數(shù)據(jù)的 一致性凛俱。
• 單個 git倉庫難以滿足大規(guī)模的配置服務紊馏，可以通過命名空間的方式進行拆分管理。

Holistic Configuration Management at Facebook
TAO: Facebook’s Distributed Data Store for the Social Graph