後設資料是自動化運維的基礎，對後設資料的管理和查詢貫穿整個運維的生命週期。我們從一個後設資料的使用場景開始：

雙十一搶購火熱進行中，某電商後端例項的日誌中出現了502錯誤碼，運維平臺監測到該異常併傳送告警給相關運維。

在這個過程中，運維後設資料發揮了什麼作用？回答這個問題前，我們先回顧下後設資料是什麼。

一、後設資料的管理

運維繫統中的後設資料包括服務、機器及其關聯關係。服務後設資料有服務名稱、所屬節點、運維人員以及域名等；機器後設資料包含序列號、記憶體等資產資訊，IP、機房等網路資訊、自定義標籤資訊以及執行例項等部署資訊。這些資料由資源管理模組維護。

資源管理模組對業務以樹的形態劃分層級，形成服務樹，從上到下依次為產品線、系統和應用三類節點。

每個層級都可以關聯機器，且上層節點包含下層節點的機器。

透過新增節點的運維及研發角色，可以實現對服務和機器的許可權控制。

這種層級結構將服務與服務，服務與機器關聯起來，可以直觀的表達服務和機器的歸屬關係，便於實現許可權和配置的繼承。

二、後設資料的應用場景

智慧監控

回到上面的問題，報警流程中，服務所在機器的監控客戶端查詢自己所屬的應用，然後從配置管理模組拉取相應監控配置，實現對日誌的監控；監控業務端收到監控資料後，查詢該機器對應的節點資訊，將報警傳送給節點的運維等人員。

此外，在DevOps落地實踐中，還存在多種其他應用場景

拓撲檢視

服務間關係拓撲可由遠端過程呼叫協議（RPC）間的呼叫關係鏈自動更新或者在應用上簡單維護服務間上下游關係。根據RPC呼叫關係鏈自動更新的關係拓撲圖主要用在業務運維上，可以幫助運維人員進行故障診斷，對整個業務系統執行狀態和部署架構全域性一覽，清晰便捷. 應用上手工維護服務間上下游關係，可以用於上線版本依賴控制。上線申請單中指定上線版本依賴服務的版本，上線時系統自動檢查依賴的版本是否已經完成上線，如果依賴版本未上線，終止本次操作。

批次運維

基於應用服務樹節點及許可權，規範化批次任務執行操作。日常運維過程中，運維需要對線上機器進行一些批次操作，比如升級軟體版本、打補丁，清理日誌等。為了避免手工操作帶來的風險，只允許運維同學，選擇所屬許可權目標機器，進行操作。對於高危命令，可新增審批機制，增加流程規範。

堡壘機

當機器規模、人員規模逐漸擴大時，如何管理人、機器、許可權會變得很複雜。透過後設資料的動態管理，使用者只需要在服務樹上對人員進行角色設定，即可登入堡壘機，獲得自己有許可權的列表。透過服務樹的角色同樣可以新增哪些角色擁有su許可權等訪問策略控制。

持續交付

持續整合、自動化測試、持續交付都可以基於後設資料，實現資料的唯一性管理。研發側，提交程式碼，自動觸發服務樹應用對應的編譯任務，根據編譯規範生成部署包，放到版本庫；運維側，則對資源進行分配抽象到服務樹，將版本庫裡面的程式碼釋出到服務樹例項對應的機器上；對於使用者側，透過負載均衡的接入，可以動態的進行服務樹例項流量的開關和擴縮容；部署日誌則可以按照應用日誌服務模組進行檢索，方便排查問題。

三、後設資料的查詢

在上面的監控流程中，客戶端和業務端是機器和服務關係資料的消費方，現實的運維場景中，二者也是運維資料的主要需求方。

客戶端指安裝在機器上，用以執行特定任務的程式，其需要的資料包括當前機器相關的資訊，如機器機房、機架等裝置屬性和歸屬節點、部署服務等業務屬性。

業務端主要指運維平臺中的上層系統，比如監控、部署等，當然也有跨平臺的其他系統，其需求涵蓋服務、機器與許可權之間的相互查詢。

大規模運維場景中後設資料查詢面臨的壓力

生產環境中，客戶端需要頻繁發起查詢請求，以保證其資料的準確性。持續增長的機器規模給系統帶來的壓力不容小覷。業務端由於複雜多樣的業務場景，其查詢條件多種多樣，查詢頻率和規模無法估量、難以控制，對系統可靠性和可用性提出了較高的要求。

傳統關係型資料庫難以承受高併發的查詢壓力，簡單的快取又難以滿足條件複雜的查詢需求。

如何面對以上壓力，提供高效高可用的查詢服務，是亟需解決的問題。

實現高可用查詢--名字服務

為了應對以上兩種場景的挑戰，Devops引入了專注於提供資料查詢的名字服務，既可以實現服務的解耦，防止外部查詢影響資源管理模組的效能，又可以提供高效穩定的查詢功能。

服務和機器資料由資源管理模組維護，儲存到資料庫。名字服務定時從資源管理模組同步資料，直接面向其他業務端和客戶端提供查詢服務。為提高響應速度，減少IO，後設資料以map的形式儲存於記憶體中。

名字服務有三個邏輯層級，分別是同步、儲存和查詢，我們從這三個方面瞭解下其如何實現高可用：

保證資料的實效性和服務的可擴充套件性

同步的流程如下

服務啟動時：優先從本地存在快取檔案恢復資料，然後增量從資源管理模組同步資料，以減小資料庫壓力，並快速提供服務；如果沒有快取檔案，則從資源管理模組查詢全量資料。
服務正常執行時：實時與資源管理模組進行增量資料同步，同步的時間點以上次同步的時間戳為準；為進一步保證資料準確，需定期全量同步資料；定期更新快取檔案。
若同步資料出現異常：不更新當前資料，僅儲存異常時時間戳，以後的每次同步時間點從該時間戳開始。

由於該模組定時從資源管理模組增量/全量更新資料，在保證資料的準確性的同時對資料庫的壓力是線性且可控的，並且執行過程不依賴其他服務，因此查詢壓力增加時，可以透過水平擴容來迅速提高請求承載量。

透過快取熱點資料提高查詢效率

回顧下開始的那個場景：監控客戶端會定期查詢獲取最新的資料。假設每分鐘請求一次，那麼10萬臺機器就帶來了上千的 qps，如果每個客戶端請求多個介面或者每個機器部署多種客戶端，這個數值就會翻倍。

針對這種常用的查詢場景，名字服務透過快取熱點資料來提高查詢效能。

假設客戶端需要透過 ip（也可能是uuid）查詢例項列表，而記憶體中例項是以id為key儲存的。如果依次遍歷全部例項進行ip匹配，會有一定的效能開銷。此時如果有一份ip與例項id的關聯關係的快取，即可首先定位到對應例項的id，然後直接獲取id對應例項的詳情。

諸如此類的快取，可以是產品線與機器的歸屬關係、機房與機器的關聯關係以及應用與例項從屬關係等。

由於資料同步環節是由名字服務主動發起的，所以該索引可以在每次更新之後重新生成，來保證其準確性。

支援多維度資料查詢

上述快取不能窮舉所有查詢資訊，服務節點和機器的屬性（如機房、執行環境等）和標籤（如報警策略和其他運維自定義的標識等）都可能成為資料查詢的條件。針對此種情況，名字服務在快取資料時將屬性和標籤解析為key-value模型，使用規定的請求格式便可實現查詢。

格式定義為Key1_value1.Keys_value2.keyN_valueN，其中常規屬性的key以大寫字母開頭，自定義標籤的 key以小寫字母開頭。例如，當名字服務收到格式為Product_trade.Idc_huabei.env_pre的查詢請求時，會先根據Product獲取trade產品線的機器ID集合，然後與huabei機房的機器ID集合取交集，再根據該ID集合獲取機器集合，最後在機器集合中根據標籤匹配出pre環境的機器集合。

DevOps將後設資料的管理與查詢業務分開維護，後設資料的變更透過資源管理實現，資料查詢透過名字服務實現。
資源管理透過層級結構維護了服務和機器的關係，並透過角色實現許可權的劃分。
名字服務只依賴資源管理，便於搭建，易於擴容，可以提供穩定的服務；結合業務場景，透過對熱資料快取實現了較高的查詢效率；支援多條件查詢，滿足複雜的業務需求。

歡迎點選“ 京東雲 ”瞭解更多精彩內容

DevOps後設資料管理