DevOps元數據管理

元數據是自動化運維的基礎，對元數據的管理和查詢貫穿整個運維的生命週期。咱們從一個元數據的使用場景開始：

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

在這個過程當中，運維元數據發揮了什麼做用？回答這個問題前，咱們先回顧下元數據是什麼。

1、元數據的管理

運維繫統中的元數據包括服務、機器及其關聯關係。服務元數據有服務名稱、所屬節點、運維人員以及域名等；機器元數據包含序列號、內存等資產信息，IP、機房等網絡信息、自定義標籤信息以及運行實例等部署信息。這些數據由資源管理模塊維護。

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

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

經過添加節點的運維及研發角色，能夠實現對服務和機器的權限控制。

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

2、元數據的應用場景

智能監控

回到上面的問題，報警流程中，服務所在機器的監控客戶端查詢本身所屬的應用，而後從配置管理模塊拉取相應監控配置，實現對日誌的監控；監控業務端收到監控數據後，查找該機器對應的節點信息，將報警發送給節點的運維等人員。

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

拓撲視圖

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

批量運維

基於應用服務樹節點及權限，規範化批量任務執行操做。平常運維過程當中，運維須要對線上機器進行一些批量操做，好比升級軟件版本、打補丁，清理日誌等。爲了不手工操做帶來的風險，只容許運維同窗，選擇所屬權限目標機器，進行操做。對於高危命令，可添加審批機制，增長流程規範。

堡壘機

當機器規模、人員規模逐漸擴大時，如何管理人、機器、權限會變得很複雜。經過元數據的動態管理，用戶只須要在服務樹上對人員進行角色設置，便可登陸堡壘機，得到本身有權限的列表。經過服務樹的角色一樣能夠添加哪些角色擁有su權限等訪問策略控制。

持續交付

持續集成、自動化測試、持續交付均可以基於元數據，實現數據的惟一性管理。研發側，提交代碼，自動觸發服務樹應用對應的編譯任務，根據編譯規範生成部署包，放到版本庫；運維側，則對資源進行分配抽象到服務樹，將版本庫裏面的代碼發佈到服務樹實例對應的機器上；對於用戶側，經過負載均衡的接入，能夠動態的進行服務樹實例流量的開關和擴縮容；部署日誌則能夠按照應用日誌服務模塊進行檢索，方便排查問題。

3、元數據的查詢

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

客戶端指安裝在機器上，用以執行特定任務的程序，其須要的數據包括當前機器相關的信息，如機器機房、機架等設備屬性和歸屬節點、部署服務等業務屬性。

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

大規模運維場景中元數據查詢面臨的壓力

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

傳統關係型數據庫難以承受高併發的查詢壓力，簡單的緩存又難以知足條件複雜的查詢需求。

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

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

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

服務和機器數據由資源管理模塊維護，存儲到數據庫。名字服務定時從資源管理模塊同步數據，直接面向其餘業務端和客戶端提供查詢服務。爲提升響應速度，減小IO，元數據以map的形式存儲於內存中。

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

保證數據的實效性和服務的可擴展性

同步的流程以下

1. 服務啓動時：優先從本地存在緩存文件恢復數據，而後增量從資源管理模塊同步數據，以減少數據庫壓力，並快速提供服務；若是沒有緩存文件，則從資源管理模塊查詢全量數據。
2. 服務正常運行時：實時與資源管理模塊進行增量數據同步，同步的時間點以上次同步的時間戳爲準；爲進一步保證數據準確，需按期全量同步數據；按期更新緩存文件。
3. 若同步數據出現異常：不更新當前數據，僅保存異常時時間戳，之後的每次同步時間點從該時間戳開始。

因爲該模塊定時從資源管理模塊增量/全量更新數據，在保證數據的準確性的同時對數據庫的壓力是線性且可控的，而且運行過程不依賴其餘服務，所以查詢壓力增長時，能夠經過水平擴容來迅速提升請求承載量。

經過緩存熱點數據提升查詢效率

回顧下開始的那個場景：監控客戶端會按期查詢獲取最新的數據。假設每分鐘請求一次，那麼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將元數據的管理與查詢業務分開維護，元數據的變動經過資源管理實現，數據查詢經過名字服務實現。
資源管理經過層級結構維護了服務和機器的關係，並經過角色實現權限的劃分。
名字服務只依賴資源管理，便於搭建，易於擴容，能夠提供穩定的服務；結合業務場景，經過對熱數據緩存實現了較高的查詢效率；支持多條件查詢，知足複雜的業務需求。

歡迎點擊「京東雲」瞭解更多精彩內容