?這是學習筆記的第?1784篇文章

今天在飛機上整理了一個初版的元數據看板接口的設計需求，然后又以設計圖表的形式補充了一版，整體來說，這個元數據庫看板的接口邏輯就梳理差不多了。

做這個接口有什么意義，或者是對標什么場景，其實主要考慮的是面向業務和面向運維自身的需求，一般我們去查看某個實例，大多數情況下都是基于IP的方式去查看的，整個數據庫層的元數據我們規劃為幾個維度，但是鮮有人能夠把這幾個維度的信息都看個完整，需要在不同的維度信息中跳轉才可以。如果我們能夠簡化到不需要再去尋找多個維度的入口，干脆一點，給我一個全景圖，我們需要的其實就是這個信息，另外一點，如果我們設定了基本的粒度是IP+端口，那么我們輸入的時候，需要明確IP和端口才能搞定，那么這個操作體驗和使用效率是不大好的，只需要一個輸入，就絕不輸入多個條件。

元數據看板接口的初步需求整理如下：

根據IP信息查詢

• 實例維度:??

????????????????服務器有多少個實例

? ? ? ? ? ? ? ? 實例明細信息

主機維度：對應的虛擬機，宿主機基礎信息

集群維度：

? ? ? ? ????????主從映射關系

? ? ? ?????????對應的集群個數，集群明細

應用維度：關聯應用維度的屬性信息，業務簡稱，業務描述，歸屬部門等

備份維度：相關的實例備份記錄信息，顯示近3天的

工單維度：相關的工單信息

報警維度：抽取接口得到報警的相關信息

監控維度：得到概覽的監控信息

• 如果IP為主庫信息，能夠定位到從庫及集群信息

• 如果IP為從庫信息，能夠定位到主庫及集群相關信息

• 如果IP為中間件IP，能夠定位到集群信息

• 如果IP為VIP,能夠定位到實例信息

• 如果IP為多網卡附加IP，能夠定位到實例信息

• 如果IP對應的業務已下線，要明確提示出來

• 如果IP對應的業務有主機故障，實例故障，要明確給出提示信息

• 根據用戶組來鑒別權限，如果不屬于這個組，可以提示數據庫類型，但是不顯示明細信息

注：

????MySQL中間件信息不屬于實例，實例信息在其他主機和集群信息中維護

通過圖表的方式來補充完善，就會看到有很多考量的維度和策略。

??

通過這些維度的數據梳理關系和映射，對于后期的元數據生命周期管理和流程化對接都是大有幫助。

你們的元數據實現流程化操作了嗎，你怎么看？

總結

以上是生活随笔為你收集整理的元数据看板的初步设计思路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。