阿里巴巴是如何打通 CMDB,实现就近访问的?
CMDB在企業(yè)中,一般用于存放與機器設(shè)備、應(yīng)用、服務(wù)等相關(guān)的元數(shù)據(jù)。當企業(yè)的機器及應(yīng)用達到一定規(guī)模后就需要這樣一個系統(tǒng)來存儲和管理它們的元數(shù)據(jù)。有一些廣泛使用的屬性,例如機器的IP、主機名、機房、應(yīng)用、region等,這些數(shù)據(jù)一般會在機器部署時錄入到CMDB,運維或者監(jiān)控平臺會使用這些數(shù)據(jù)進行展示或者相關(guān)的運維操作。
在服務(wù)進行多機房或者多地域部署時,跨地域的服務(wù)訪問往往延遲較高,一個城市內(nèi)的機房間的典型網(wǎng)絡(luò)延遲在1ms左右,而跨城市的網(wǎng)絡(luò)延遲,例如上海到北京大概為30ms。此時自然而然的一個想法就是能不能讓服務(wù)消費者和服務(wù)提供者進行同地域訪問。
我們在集團內(nèi)部的實踐中,這樣的需求是通過和CMDB打通來實現(xiàn)的。Nacos的服務(wù)發(fā)現(xiàn)組件中,對接CMDB,然后通過配置的訪問規(guī)則,來實現(xiàn)服務(wù)消費者到服務(wù)提供者的同地域優(yōu)先。
圖1 服務(wù)的同地域優(yōu)先訪問這實際上就是一種負載均衡策略,在Nacos的規(guī)劃中,豐富的服務(wù)端的可配置負載均衡策略是我們的重要發(fā)展方向,這與當前已有的注冊中心產(chǎn)品不太一樣。在設(shè)計如何在開源的場景中,支持就近訪問的時候,與企業(yè)自帶的CMDB集成是我們考慮的一個核心問題。除此之外,我們也在考慮將Nacos自身擴展為一個實現(xiàn)基礎(chǔ)功能的CMDB。無論如何,我們都需要能夠從某個地方獲取IP的環(huán)境信息,這些信息要么是從企業(yè)的CMDB中查詢而來,要么是從自己內(nèi)置的存儲中查詢而來。
CMDB插件機制
先不考慮如何將CMDB的數(shù)據(jù)應(yīng)用于負載均衡,我們需要首先在Nacos里將CMDB的數(shù)據(jù)通過某種方法獲取。在實際使用中,基本上每個公司都會通過購買或者自研搭建自己的CMDB,那么為了能夠解耦各個企業(yè)的CMDB具體實現(xiàn),一個比較好的策略是使用SPI機制,約定CMDB的抽象調(diào)用接口,由各個企業(yè)添加自己的CMDB插件,無需任何代碼上的重新構(gòu)建,即可在運行狀態(tài)下對接上企業(yè)的CMDB。
圖2 Nacos CMDB SPI機制原理如圖2所示,Nacos定義了一個SPI接口,里面包含了與第三方CMDB約定的一些方法。用戶依照約定實現(xiàn)了相應(yīng)的SPI接口后,將實現(xiàn)打成jar包放置到Nacos安裝目錄下,重啟Nacos即可讓Nacos與CMDB的數(shù)據(jù)打通。整個流程并不復雜,但是理解CMDB SPI接口里方法和相應(yīng)概念的含義不太簡單。在這里對CMDB機制的相關(guān)概念和接口含義做一個詳細說明。
CMDB抽象概念
實體(Entity)
實體是作為CMDB里數(shù)據(jù)的承載方,在一般的CMDB中,一個實體可以指一個IP、應(yīng)用或者服務(wù)。而這個實體會有很多屬性,例如IP的機房信息,服務(wù)的版本信息等。
實體類型(Entity Type)
我們并不限定實體一定是IP、應(yīng)用或者服務(wù),這取決于實際的業(yè)務(wù)場景。Nacos有計劃在未來支持不同的實體類型,不過就目前來說,服務(wù)發(fā)現(xiàn)需要的實體類型是IP。
標簽(Label)
Label是我們抽象出的Entity屬性,Label定義為一個描述Entity屬性的K-V鍵值對。Label的key和value的取值范圍一般都是預(yù)先定義好的,當需要對Label進行變更,如增加新的key或者value時,需要調(diào)用單獨的接口并觸發(fā)相應(yīng)的事件。一個常見的Label的例子是IP的機房信息,我們認為機房(site)是Label的key,而機房的集合(site1, site2, site3)是Label的value,這個Label的定義就是:site: {site1, site2, site3}。
實體事件(Entity Event)
實體的標簽的變更事件。當CMDB的實體屬性發(fā)生變化,需要有一個事件機制來通知所有訂閱方。為了保證實體事件攜帶的變更信息是最新準確的,這個事件里只會包含變更的實體的標識以及變更事件的類型,不會包含變更的標簽的值。
CMDB約定接口
在設(shè)計與CMDB交互接口的時候,我們參考了內(nèi)部對CMDB的訪問接口,并與若干個外部客戶進行了討論。我們最終確定了以下要求第三方CMDB插件必須實現(xiàn)的接口:
獲取標簽列表
Set<String> getLabelNames();這個方法將返回CMDB中需要被Nacos識別的標簽名集合,CMDB插件可以按需決定返回什么標簽個Nacos。不在這個集合的標簽將會被Nacos忽略,即使這個標簽出現(xiàn)在實體的屬性里。我們允許這個集合會在運行時動態(tài)變化,Nacos會定時去調(diào)用這個接口刷新標簽集合。
獲取實體類型
Set<String> getEntityTypes();獲取CMDB里的實體的類型集合,不在這個集合的實體類型會被Nacos忽略。服務(wù)發(fā)現(xiàn)模塊目前需要的實體類似是ip,如果想要通過打通CMDB數(shù)據(jù)來實現(xiàn)服務(wù)的高級負載均衡,請務(wù)必在返回集合里包含“ip”。
獲取標簽詳情
Label getLabel(String labelName);獲取標簽的詳細信息。返回的Label類里包含標簽的名字和標簽值的集合。如果某個實體的這個標簽的值不在標簽值集合里,將會被視為無效。
查詢實體的標簽值
String getLabelValue(String entityName, String entityType, String labelName); Map<String, String> getLabelValues(String entityName, String entityType);這里包含兩個方法,一個是獲取實體某一個標簽名對應(yīng)的值,一個是獲取實體所有標簽的鍵值對。參數(shù)里包含實體的值和實體的類型。注意,這個方法并不會在每次在Nacos內(nèi)部觸發(fā)查詢時去調(diào)用,Nacos內(nèi)部有一個CMDB數(shù)據(jù)的緩存,只有當這個緩存失效或者不存在時,才會去訪問CMDB插件查詢數(shù)據(jù)。為了讓CMDB插件的實現(xiàn)盡量簡單,我們在Nacos內(nèi)部實現(xiàn)了相應(yīng)的緩存和刷新邏輯。
查詢實體
Map<String, Map<String, Entity>> getAllEntities(); Entity getEntity(String entityName, String entityType);查詢實體包含兩個方法:查詢所有實體和查詢單個實體。查詢單個實體目前其實就是查詢這個實體的所有標簽,不過我們將這個方法與獲取所有標簽的方法區(qū)分開來,因為查詢單個實體方法后面可能會進行擴展,比查詢所有標簽獲取的信息要更多。
查詢所有實體則是一次性將CMDB的所有數(shù)據(jù)拉取過來,該方法可能會比較消耗性能,無論是對于Nacos還是CMDB。Nacos內(nèi)部調(diào)用該方法的策略是通過可配置的定時任務(wù)周期來定時拉取所有數(shù)據(jù),在實現(xiàn)該CMDB插件時,也請關(guān)注CMDB服務(wù)本身的性能,采取合適的策略。
查詢實體事件
List<EntityEvent> getEntityEvents(long timestamp);這個方法意在獲取最近一段時間內(nèi)實體的變更消息,增量的去拉取變更的實體。因為Nacos不會實時去訪問CMDB插件查詢實體,需要這個拉取事件的方法來獲取實體的更新。參數(shù)里的timestamp為上一次拉取事件的時間,CMDB插件可以選擇使用或者忽略這個參數(shù)。
CMDB插件開發(fā)流程
參考 https://github.com/nacos-group/nacos-examples,這里已經(jīng)給出了一個示例plugin實現(xiàn)。
具體步驟如下:
plain <dependency> <groupId>com.alibaba.nacos</groupId> <artifactId>nacos-api</artifactId> <version>0.7.0</version> </dependency>
plain <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-assembly-plugin</artifactId> <configuration> <descriptorRefs> <descriptorRef>jar-with-dependencies</descriptorRef> </descriptorRefs> </configuration> </plugin>
plain mvn package assembly:single -Dmaven.test.skip=true
plain {nacos.home}/plugins/cmdb
plain nacos.cmdb.loadDataAtStart=true
使用Selector實現(xiàn)同機房優(yōu)先訪問
在拿到CMDB的數(shù)據(jù)之后,就可以運用CMDB數(shù)據(jù)的強大威力來實現(xiàn)多種靈活的負載均衡策略了,下面舉例來說明如何使用CMDB數(shù)據(jù)和Selector來實現(xiàn)就近訪問。
假設(shè)目前Nacos已經(jīng)通過CMDB拿到了一些IP的機房信息,且它們對應(yīng)的標簽信息如下:
11.11.11.11site: x1122.22.22.22site: x1233.33.33.33site: x1144.44.44.44site: x1255.55.55.55site: x1311.11.11.11、22.22.22.22、33.33.33.33、44.44.44.44和55.55.55.55.55都包含了標簽site,且它們對應(yīng)的值分別為x11、x12、x11、x12、x13。我們先注冊一個服務(wù),下面掛載IP11.11.11.11和22.22.22.22。
圖3 服務(wù)詳情然后我們修改服務(wù)的“服務(wù)路由類型”,并配置為基于同site優(yōu)先的服務(wù)路由:
圖4 編輯服務(wù)路由類型這里我們將服務(wù)路由類型選擇為標簽,然后輸入標簽的表達式:
CONSUMER.label.site = PROVIDER.label.site這個表達式的格式和我們抽象的Selector機制有關(guān),具體將會在另外一篇文章中介紹。在這里您需要記住的就是,任何一個如下格式的表達式:
CONSUMER.label.labelName = PROVIDER.label.labelName將能夠?qū)崿F(xiàn)基于同labelName優(yōu)先的負載均衡策略。
然后假設(shè)服務(wù)消費者的IP分別為33.33.33.33、44.44.44.44和55.55.55.55,它們在使用如下接口查詢服務(wù)實例列表:
naming.selectInstances("nacos.test.1", true)那么不同的消費者,將獲取到不同的實例列表。33.33.33.33獲取到11.11.11.11,44.44.44.44將獲取到22.22.22.22,而55.55.55.55將同時獲取到11.11.11.11和22.22.22.22。
以上,便是我們在Nacos中通過打通CMDB,實現(xiàn)就近訪問的實踐。Nacos是阿里巴巴開源的服務(wù)注冊與配置管理產(chǎn)品,參考:《阿里啟動新項目:Nacos,比 Eureka 更強!》。
本文原創(chuàng)首發(fā)于微信公眾號:Java技術(shù)棧(id:javastack),關(guān)注公眾號在后臺回復 "架構(gòu)" 可獲取更多,轉(zhuǎn)載請原樣保留本信息。
轉(zhuǎn)載于:https://www.cnblogs.com/javastack/p/10256401.html
總結(jié)
以上是生活随笔為你收集整理的阿里巴巴是如何打通 CMDB,实现就近访问的?的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: react-native-Cocoapo
- 下一篇: 梦到别人生病住院是什么意思