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