運維行業發展至今，從最初的人肉運維、腳本時代，到後期的平臺化階段、以及現在很火的AIOps的概念。都繞不過一個主題——資源管理。
無論是健全而人性化的發佈體系、靈敏強大的監控體系、還是穩定高效的服務發現，都需要我們有一種可以很靈活的管理資源的模型。
這個模型，應該有如下兩個特點：
- 支持業務分級，可以與業務形態靈活對應
- 篩選能力靈活，可以支持多個維度靈活精確的匹配與篩選
這就是服務樹概念的由來。接下來筆者會將我們在服務樹的建設過程中的一些思考和遇到的問題，分享給大家。
此篇文章專注介紹服務樹模型的設計與實現。用於資源管理的CMDB系統，機器上下線、報修、借用歸還相關的資源全流程閉環，此篇文章不做探討。
什麼是服務樹
服務樹，一言以蔽之，是一個將業務映射成樹形結構，然後與資源對應起來的模型。
通俗且狹義地講，服務樹維護着，哪個業務線下有哪幾臺機器、哪幾個VIP等資源。
與傳統意義的CMDB系統不同的是，服務樹專注於解決業務與資源的映射關係，而傳統的CMDB系統更多的關注於資源本身的屬性與狀態。
比如，一個公司下有N個事業羣，每個事業羣下有N個部門，每個部門內有N個服務，每個服務有N個模塊，每個模塊又有N個集羣。邊說着，是不是你的腦中，就已經出現了一棵樹？
接着我們可以想，每一個樹節點，都是一個單獨的空間，可以放一些機器、VIP之類的資源。當我們把所有的資源，根據使用情況分別放置到樹的不同節點上時，這就是一棵服務樹啦。
樹的節點之間，天然就有繼承的關係，正好與業務的組織架構對應。
每一個樹的節點，我們稱之爲 NS（NameSpace）。是不是有點類似編程語言的命名空間？
服務樹的由來
最初的時候，我們只有一個CMDB系統，當然這個系統可能只是一個excel表格。
後來我們要對機器進行批量操作，可能是某個服務的一批機器，可能是某個集羣的一批機器，也有可能是某個產品線的所有機器，於是我們開始維護各種各樣的資源列表。
再後來，大家想，能不能搞個平臺，把所有的資源列表都管理起來。也就是，分組功能服務化。
然後就有了服務樹。
其實服務樹的發展過程，與運維繫統平臺化的發展是基本同步的。因爲越先進的運維繫統，就要求越強大越高效的資源管理系統。
服務樹的日常應用
在我看來，服務樹的作用只有一個：靈活的篩選業務與資源的關聯關係。
在服務樹接管資源的管理之後，我們來看下如何利用服務樹更好的進行運維操作：
- 發佈一個服務的時候，我可以指定將此服務發佈至【服務樹某個節點】。
- 監控一個進程是否存活，我可以指定，只採集【服務樹某個節點】的進程數據並報警。
- 一臺機器是混部的，很多業務線在共用。我可以查詢【該機器存在於哪幾個服務樹節點】，就能知道哪幾個業務線在使用。
- 我要給某個人授權，可以不需要指定機器列表，可以只給他服務樹節點的權限即可。
上述這些情況，使用服務樹節點代替機器列表，帶來的好處有：
- 無需關心瑣碎的資源列表，所有操作對節點生效，簡潔明瞭，提高人員效率。
- 無需人工指定機器列表，由服務樹來補全，減少誤操作。
- 當節點下機器發生變更，將直接在所有周邊系統生效，不需要人爲干預。
服務樹節點規範的制定
服務樹的模型，說來並不算複雜。但是確實整個運維平臺最核心的地方。
當我們做服務樹的時候，更多的，是做一個規範。
規範的制定，一定要非常慎重，因爲規範一旦確定，模型就確定了，再改起來就會非常困難。
首先是層級的劃分，要根據公司的實際情況，與業務緊密關聯起來。最好有對公司體系架構非常熟悉的人來幫忙review。
其次要考慮如何同時滿足各種靈活的篩選和調整。考慮當前公司的各種系統對資源的檢索需求，設計模型是否可以滿足。
最後，服務樹模型的設計者一定要想明白這個模型，要在最大程度滿足業務需求的前提下，保留服務樹的靈活性。不要完全被業務所左右，要給我們的想象和未來留一點空間。
一般來講，服務樹規範分爲命名規範和使用規範兩方面。
命名規範
命名規範主要是用來約束節點的命名。這些規則，是構建一棵服務樹的具體規則。根據公司業務情況的不同所不同。
比如：
- 服務樹的節點必須有層級的概念，必須從上到下有【公司】【部門】【產品線】【service】不能缺省、其他的【servicegroup】可以缺省。
- 【servicegroup】層級可以嵌套和級聯。
- 【idc】【status】等在一臺機器上，必須唯一。
使用規範
使用規範用來約束服務樹的使用，同時約束周邊系統的行爲。
可以與各個周邊系統的負責人來商量敲定。
比如：
- 監控系統指標只允許上報至葉子節點。
- 部署服務必須在【service】節點維度進行。
服務樹的實踐
這一部分，分享一個筆者老東家的一個服務樹的實踐，可謂是小巧靈活、彈性十足。
小巧，從邏輯上，核心的服務樹模型與機器全流程的運轉，做了隔離。服務樹可以更好地專注於映射關係的處理。
靈活，這棵服務樹的層級之間的關係並不是固定的，而是由一個一個的標籤組合而來。比如，我一臺機器，在【部門A-業務線B-集羣C】，並不是做了這樣的綁定關係。而是分別給這臺機器打了【部門A】【業務線B】【集羣C】三個關聯標籤。
這樣，就可以隨意的組合各種標籤，用來篩選資源，比如：【部門A-集羣C】所有機器，可以篩選出【部門A】下所有業務線【集羣C】的機器。
彈性，除了維護邏輯的關係之外，同時支持另一類標籤，用來標示資源的屬性。比如【機器狀態】【機器idc】等。可以支持更多維度的篩選。
並且，允許用戶自定義服務樹視圖。比如，一個sys主機組的同學，並不關心機器的所屬部門和業務情況，只關心壞掉的機器。那就可以將視圖設置爲【公司X-狀態trouble】，這樣，看到的樹，只有兩級，並且可以完全的滿足他的篩選需求。
這棵樹的實現方式，比較簡單：一張資源表，一張節點表，一張關聯表。
節點表存的是排過序的tag組合串。平時的tag篩選，通過數據庫的like操作來實現。
資源相關的屬性標籤，直接放在資源表裏。
說來這個實現方式其實比較trick，只是打擦邊球實現了服務樹的各種功能。
不過服務樹的數據體量一般不會太大，因此這個問題暴露的也不算太明顯。有查詢的瓶頸也可以通過加cache來解決。不過一旦機器量到達10W+，很可能就要從模型上來重構了。
服務樹模型當前的問題與瓶頸
問題一：與周邊的關聯
周邊系統要與服務樹打通，有兩種方式：
- 節點串關聯：與周邊系統弱耦合。如果節點改名，需要有一個觸發式的通知機制，由周邊系統來訂閱。不利於解耦。
- ID關聯：與周邊系統強耦合。使用服務樹的節點串唯一ID來做關聯，改名可以不用通知。但是周邊系統每次都需要用ID向服務樹動態解析，一旦服務樹出現故障，很可能導致大量周邊系統不可用。
上述已知的兩種方式，都存在問題，目前也沒有很好的解決方式。筆者公司目前是使用的第一種方式，一旦服務樹出現問題，起碼可以保證周邊系統可用。
問題二：關聯了節點，卻失去了對資源本身的關注
筆者公司目前遇到了這樣的一種情況，機器A同時掛載到了兩個節點，監控與服務樹是弱關聯。因此監控數據分爲兩份，分別與兩個節點關聯。如果是業務數據，那沒問題。但是由於我們監控系統根據服務樹節點做了分片。基礎指標，也分了兩份，推往了不同的節點。
當我配置一條大節點的策略：cpu.idle小於10的時候，報警出來。但是卻同時收到了兩條報警，因爲節點不同，監控系統認爲，這是兩條監控數據。
那麼問題來了，用戶視角：“爲什麼，同一臺機器，同一條監控策略，你要給我發兩條報警？？”
啞口無言。
雖然這個問題，通過報警的收斂可以解決。但是模型的不支持，卻讓我們耿耿於懷。
腦洞 & 思考
服務樹的本質
服務樹，本質上應該只是一種視圖，而不應該是一個實體。
關於資源本身的屬性，更多的應該回歸到資源的本身。
周邊系統也是如此，應當對資源本身的屬性與正常的服務樹節點有所區分。
節點標籤化
這篇文章介紹的一個實踐，仍然是有樹的實體的。在我的構想裏，整個系統應該以資源爲主體。
所有的服務樹信息，都以標籤的形式，標記在資源上。
只是標籤需要分兩類：
- 一類標籤，可以無限制標記到資源。（比如：部門、產品線、服務、集羣）
- 另一類標籤，對應資源屬性，必須唯一。（比如：IP、IDC、狀態）
這樣一來，樹只是一種視圖，每次對樹的查詢，都可以動態的從海量的標籤中組合出一棵樹。非常靈活。
只是這種設計，資源太多，海量的標籤，計算與定製樹的速度將大大變慢。
對性能是一個比較大的考驗。筆者已經不做服務樹很久了，一直也沒有好的機會來實踐，因此這個設想也一直沒有落實。
功能拓展
服務樹的職能其實很簡單，基本也不用拓展。能做好最核心的映射工作已經非常好了。
在功能拓展的時候，更多的是要做減法。不能太過影響服務樹的靈活性，服務樹一旦變得臃腫，整個運維平臺都會感覺很亂。
本文腦圖
最後附上思考本文的思維導圖，供大家參考：
