【論文閱讀】Holistic Configuration Management at Facebook

當應用程序規(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

?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末蒲犬,一起剝皮案震驚了整個濱河市朱监,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌原叮,老刑警劉巖赫编,帶你破解...
    沈念sama閱讀 211,042評論 6 490
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異奋隶,居然都是意外死亡擂送,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 89,996評論 2 384
  • 文/潘曉璐 我一進店門达布,熙熙樓的掌柜王于貴愁眉苦臉地迎上來团甲,“玉大人,你說我怎么就攤上這事黍聂。” “怎么了身腻?”我有些...
    開封第一講書人閱讀 156,674評論 0 345
  • 文/不壞的土叔 我叫張陵产还,是天一觀的道長。 經(jīng)常有香客問我嘀趟,道長脐区,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 56,340評論 1 283
  • 正文 為了忘掉前任她按,我火速辦了婚禮牛隅,結果婚禮上,老公的妹妹穿的比我還像新娘酌泰。我一直安慰自己媒佣,他們只是感情好,可當我...
    茶點故事閱讀 65,404評論 5 384
  • 文/花漫 我一把揭開白布陵刹。 她就那樣靜靜地躺著默伍,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上也糊,一...
    開封第一講書人閱讀 49,749評論 1 289
  • 那天炼蹦,我揣著相機與錄音,去河邊找鬼狸剃。 笑死掐隐,一個胖子當著我的面吹牛,可吹牛的內容都是我干的钞馁。 我是一名探鬼主播虑省,決...
    沈念sama閱讀 38,902評論 3 405
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼指攒!你這毒婦竟也來了慷妙?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 37,662評論 0 266
  • 序言:老撾萬榮一對情侶失蹤允悦,失蹤者是張志新(化名)和其女友劉穎膝擂,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體隙弛,經(jīng)...
    沈念sama閱讀 44,110評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡架馋,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 36,451評論 2 325
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了全闷。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片叉寂。...
    茶點故事閱讀 38,577評論 1 340
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖总珠,靈堂內的尸體忽然破棺而出屏鳍,到底是詐尸還是另有隱情,我是刑警寧澤局服,帶...
    沈念sama閱讀 34,258評論 4 328
  • 正文 年R本政府宣布钓瞭,位于F島的核電站,受9級特大地震影響淫奔,放射性物質發(fā)生泄漏山涡。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 39,848評論 3 312
  • 文/蒙蒙 一唆迁、第九天 我趴在偏房一處隱蔽的房頂上張望鸭丛。 院中可真熱鬧,春花似錦唐责、人聲如沸鳞溉。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,726評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽穿挨。三九已至月弛,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間科盛,已是汗流浹背帽衙。 一陣腳步聲響...
    開封第一講書人閱讀 31,952評論 1 264
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留贞绵,地道東北人厉萝。 一個月前我還...
    沈念sama閱讀 46,271評論 2 360
  • 正文 我出身青樓,卻偏偏與公主長得像榨崩,于是被迫代替她去往敵國和親谴垫。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 43,452評論 2 348

推薦閱讀更多精彩內容