丨如何在cmdb中落地應(yīng)用的概念

這個(gè)概念應(yīng)該是從的運(yùn)維體系中借鑒出來的這里的服務(wù)實(shí)際對(duì)應(yīng)的就是我們前面提到的應(yīng)用這個(gè)概念。據(jù)我了解，在阿里和騰訊都是叫作應(yīng)用，現(xiàn)在業(yè)界比較通用的叫法也是應(yīng)用。其實(shí)叫什么并不重要，關(guān)鍵還是要學(xué)習(xí)到對(duì)這個(gè)概念的管理方式。從服務(wù)樹這個(gè)名字中，我們就可以了解到，有效組織和管理應(yīng)用的方式，就是把它組織成一個(gè)樹形的層次結(jié)構(gòu)。這種管理模式，無論是在BAT，還是在其它的互聯(lián)網(wǎng)公司，基本都是一樣的思路和模式，所以叫法雖然不同，但是思卻是相通的，可謂異曲同工?；跇I(yè)務(wù)維度的拆分，對(duì)應(yīng)產(chǎn)生了我們的應(yīng)用拆分原則。比如對(duì)于公司，大的維度會(huì)有、支付、、流量和搜索等業(yè)務(wù)領(lǐng)域；進(jìn)一步，業(yè)務(wù)領(lǐng)域里最典型的會(huì)有用戶、會(huì)員、商品、、商家、以及物流等；這里面還可以再進(jìn)一步細(xì)分，比如商品會(huì)有詳情、KU、PU、庫(kù)存、評(píng)價(jià)、等。講到這里，我們?cè)倏匆幌录夹g(shù)團(tuán)隊(duì)的組織架構(gòu)，基本上是對(duì)應(yīng)著整個(gè)業(yè)務(wù)技術(shù)架構(gòu)的拆分的。也就是業(yè)務(wù)架構(gòu)決定了技術(shù)架構(gòu)，而技術(shù)架構(gòu)又決定了一個(gè)研發(fā)團(tuán)隊(duì)的組織架構(gòu)，這個(gè)組織架構(gòu)中不同的團(tuán)隊(duì)單元分別承擔(dān)著對(duì)應(yīng)業(yè)務(wù)的需求開發(fā)職責(zé)。上面這個(gè)組織架構(gòu)建設(shè)的邏輯和思路，也是我們?cè)诮M建團(tuán)隊(duì)和職責(zé)劃分時(shí)可以參考的這樣一個(gè)邏輯講下來，我們的應(yīng)用管理思路其實(shí)也就明晰了：產(chǎn)品線務(wù)團(tuán)隊(duì)。這里舉個(gè)商品的例子就是：技術(shù)-商品團(tuán)隊(duì)-商品中心-商品詳情等。當(dāng)然因?yàn)槊總€(gè)公司對(duì)組織架構(gòu)定義的方式不同，也可以用一、二級(jí)部門這樣的方式來指代。但是具體團(tuán)隊(duì)的分工和職責(zé)，一定是來自于業(yè)務(wù)架構(gòu)決定的技術(shù)架構(gòu)，，各業(yè)務(wù)團(tuán)隊(duì)才會(huì)職責(zé)清晰，配合協(xié)作才會(huì)順暢起來。對(duì)于應(yīng)用名定義，要設(shè)定規(guī)范，比應(yīng)用名長(zhǎng)度不超過40個(gè)字符，盡量簡(jiǎn)單易懂；簡(jiǎn)單舉例，商品中心命名為itemcenter，商品詳情命名為detail這里做個(gè)小結(jié)：到了軟件運(yùn)維階段，運(yùn)維工作是否可以高效地組織開展，很大程度上，面的業(yè)務(wù)架構(gòu)拆分階段就決定了。也就是業(yè)務(wù)架構(gòu)拆分得是否合理、職責(zé)是否明晰，決定了后續(xù)團(tuán)隊(duì)組織架構(gòu)是否合理、團(tuán)隊(duì)職責(zé)是否明晰。如果這點(diǎn)沒做好，到了運(yùn)維階段必然就是的。這一點(diǎn)我在開篇詞中也提到過，運(yùn)維能力的體現(xiàn)，一定是整體技術(shù)架構(gòu)能力的體現(xiàn)，割裂兩者單獨(dú)去看，都是沒有意義的。同時(shí)，對(duì)于當(dāng)前仍然把運(yùn)維割裂建設(shè)的研發(fā)團(tuán)隊(duì)，也需要去為什么會(huì)有集群服務(wù)分組呢？我們一起來看這么幾個(gè)需求場(chǎng)場(chǎng)景一：多環(huán)境問題場(chǎng)景二：多IDC問題對(duì)于大型互聯(lián)網(wǎng)業(yè)務(wù)，會(huì)做業(yè)務(wù)單元化，或者有海外業(yè)務(wù)拓展需求的場(chǎng)景，我們會(huì)在IDC機(jī)房部署應(yīng)用，應(yīng)用代碼是相同的，但是配置可能會(huì)不同場(chǎng)景三：多服務(wù)分組問題這個(gè)場(chǎng)景就跟具體業(yè)務(wù)場(chǎng)景相關(guān)了。舉個(gè)例子，比如商品中心IC這樣一個(gè)應(yīng)用，對(duì)外會(huì)有商品詳情、下單、訂單、購(gòu)物車、評(píng)價(jià)、、秒殺活動(dòng)、會(huì)場(chǎng)活動(dòng)、商家、應(yīng)用和非應(yīng)用：比如支付鏈的應(yīng)用屬于應(yīng)用，任何時(shí)候都必須要優(yōu)出現(xiàn)故障，是不是會(huì)影響業(yè)務(wù)收入，如果影響就屬于應(yīng)用，如果不是或者影響非常小，那就屬于非應(yīng)用。所以IC這個(gè)應(yīng)用下面，就會(huì)有IC的分組，IC的分組、IC的分組等，這些分組就會(huì)相對(duì)固定和靜態(tài)。場(chǎng)景因素決定。這個(gè)對(duì)于就會(huì)比較典型，比如大促時(shí)的秒殺場(chǎng)景，對(duì)于參加秒殺活動(dòng)的商品，瞬時(shí)的量就會(huì)非常大，而不參加活動(dòng)的商品就不會(huì)有這么大的量。所以這時(shí)為了較大的流量，就需要有多個(gè)不同的秒殺IC分組，從資源層面進(jìn)行；同時(shí)上層秒殺活動(dòng)的應(yīng)用在配置中心配置依賴時(shí)，就要配置到對(duì)應(yīng)的秒殺IC集群分組上，這樣即使秒殺IC出現(xiàn)問題，也不會(huì)影響正常的商品IC。所以根據(jù)場(chǎng)景，不同階段就會(huì)有IC的大促秒殺分組，這種類型的分組就需要根據(jù)實(shí)際的業(yè)務(wù)場(chǎng)景來決定，是個(gè)動(dòng)一般情況下，集群服務(wù)分組會(huì)有以上三個(gè)維度中的一個(gè)或多個(gè)來決定。還是以商品中心為例，按照上面的介紹，就會(huì)對(duì)應(yīng)如下關(guān)至此，“應(yīng)用-集群服務(wù)分組-資源”的對(duì)應(yīng)關(guān)系就建立起來了。這里我們叫它“應(yīng)用樹”或者“服務(wù)樹”都可以，不管叫什么，這個(gè)信息是CMDB中最為關(guān)鍵和的信息。這里我們以應(yīng)用為來看，CMDB中會(huì)保存“應(yīng)用-分組-資源”的對(duì)應(yīng)關(guān)系，這個(gè)關(guān)系統(tǒng)我們需要以上的對(duì)應(yīng)關(guān)系，到每個(gè)應(yīng)用、每個(gè)集群以及每臺(tái)機(jī)器上的關(guān)鍵信息發(fā)布系統(tǒng)服務(wù)化框架框架來說，的是通過其配置的應(yīng)用名，來實(shí)現(xiàn)應(yīng)用的服務(wù)和API管理，這里要做到與CMDB統(tǒng)一。同樣，像LVS和Nginx這樣的四七層負(fù)載，以及ZK這樣的基礎(chǔ)服務(wù)中如分布式DB、分布式緩存和消息等，就需要應(yīng)用的應(yīng)用名，以及應(yīng)用與資源IP對(duì)應(yīng)關(guān)系，或者集群分組與IP的對(duì)應(yīng)關(guān)系。應(yīng)用名，是因?yàn)橐?yīng)用與分布式服務(wù)實(shí)例之間的關(guān)系。如應(yīng)用與緩存NameSpace的對(duì)應(yīng)關(guān)系，應(yīng)用與消息Topic的對(duì)應(yīng)關(guān)系等，以便于這些基礎(chǔ)服務(wù)的生命周期管理和應(yīng)用與資源的對(duì)應(yīng)關(guān)系，是因?yàn)橛行┵Y源是要做ACL控制的。比如對(duì)于用戶、過的應(yīng)用。這時(shí)就要針對(duì)應(yīng)用對(duì)應(yīng)的IP地址進(jìn)行白配置。一方面，可以通過分布式DB中間件進(jìn)行配置；另一方面，也可以通過在DB層面進(jìn)行設(shè)置，比如MySQL就可以直接配置白策略；同時(shí)也可以在機(jī)器的iptables上配置，至于如何配穩(wěn)定性保障平臺(tái)，或者叫服務(wù)治理平臺(tái)針對(duì)系統(tǒng)的穩(wěn)定性，我們會(huì)在應(yīng)用中做很多的降級(jí)限流和開關(guān)預(yù)案策略，這些都是跟應(yīng)用直接關(guān)聯(lián)的。而且按照我們前面介紹的，不同的集群分組，策略可能會(huì)有不同，所以又會(huì)跟集群分組相關(guān)。同時(shí)，這些策略最終下發(fā)到具體服務(wù)器上運(yùn)行的應(yīng)用實(shí)例上，所以這里就會(huì)需要應(yīng)用、集群分組以及對(duì)應(yīng)的資源關(guān)系?？偨Y(jié)一下，簡(jiǎn)單示意圖如下通過上述的分析，我們可以看到基于以應(yīng)用為的CMDB中，又衍生出“應(yīng)用-集群服務(wù)分組-資源”這樣一個(gè)運(yùn)維體系中的關(guān)系。經(jīng)過這三部分的分析，我們之前所說的基于應(yīng)用為的運(yùn)維視圖就可以建立出來了，我們?cè)俅问疽馊缦拢航裉煳覀冇懻摰膬?nèi)容提到了，、發(fā)布、基礎(chǔ)服務(wù)以及穩(wěn)定性平臺(tái)會(huì)依賴CMDB中“應(yīng)用、集群服務(wù)分組-資源”的對(duì)應(yīng)關(guān)系信息，但是當(dāng)CMDB中的這些關(guān)系信息發(fā)生變化，比如新增一個(gè)IP，或者下線一個(gè)IP，這些信息是如何傳遞到其它平臺(tái)的呢？這些平臺(tái)又是如果今天的內(nèi)容對(duì)你有幫助，也請(qǐng)你給身邊的朋友，我們下期見 不得售賣。頁面已增加防盜追蹤，將依 上一