在日常的工作中通常會(huì)組合幾個(gè)系統(tǒng)的相關(guān)功能共同完成某個(gè)業(yè)務(wù)場(chǎng)景，這時(shí)候通常在一般的微服務(wù)中就需要使用分布式事務(wù)來(lái)解決，或者通過(guò)本文說(shuō)的編排的方式來(lái)解決，本文算是這個(gè)系列的入門(mén)篇，主要是介紹下筆者在實(shí)際工作中的嘗試，后續(xù)會(huì)持續(xù)更新一些內(nèi)部的原理與更好玩的生產(chǎn)實(shí)踐

1.背景

在接手的運(yùn)維平臺(tái)中之前的設(shè)計(jì)是在一個(gè)大的controller將完成某個(gè)業(yè)務(wù)場(chǎng)景的代碼全部寫(xiě)在一起，然后中間為了兼容各種之前的平臺(tái)和場(chǎng)景的問(wèn)題，充斥著大量的if else以及硬編碼，導(dǎo)致出了問(wèn)題需要就要人為介入排查，擴(kuò)展性、健壯性幾乎為零, 為了更好的理解第二部分我們的嘗試，這里先給大家介紹幾個(gè)概念

1.1 運(yùn)維中的任務(wù)編排

在傳統(tǒng)的運(yùn)維開(kāi)發(fā)中，任務(wù)編排通常是一個(gè)很常見(jiàn)的系統(tǒng)，在k8s之前的運(yùn)維系統(tǒng)中，通常是基于master-worker架構(gòu)實(shí)現(xiàn)對(duì)應(yīng)的任務(wù)的編排，也有很多的開(kāi)源產(chǎn)品，比如stackstorm、tower、jeankins等同一些業(yè)務(wù)上使用的框架并無(wú)本質(zhì)區(qū)別，我們可以通過(guò)寫(xiě)插件來(lái)實(shí)現(xiàn)對(duì)應(yīng)的接口，就可以丟給系統(tǒng)取跑任務(wù)了，任務(wù)過(guò)程中的數(shù)據(jù)、狀態(tài)都由對(duì)應(yīng)的插件自身維護(hù)，系統(tǒng)只負(fù)責(zé)任務(wù)的調(diào)度，而不負(fù)責(zé)狀態(tài)和數(shù)據(jù)的管理

1.2 運(yùn)維中的狀態(tài)

面向終態(tài)是大佬們最近這幾年引領(lǐng)的新的運(yùn)維模型，通過(guò)描述最終狀態(tài)，系統(tǒng)根據(jù)當(dāng)前狀態(tài)去決策采取的動(dòng)作然后等待對(duì)應(yīng)的反饋結(jié)果，再次進(jìn)行決策從而達(dá)到正向反饋環(huán)，直到目標(biāo)狀態(tài)。但其實(shí)日常的工作中很多業(yè)務(wù)邏輯通常都是有狀態(tài)的。比如在擴(kuò)容場(chǎng)景中，如果沒(méi)有知道當(dāng)前的Pod或者Server的狀態(tài)，本質(zhì)上你也沒(méi)辦法決策接下來(lái)該做啥操作。在一個(gè)長(zhǎng)的worfklow里面如果你不知道任務(wù)的狀態(tài)，則就無(wú)法知道當(dāng)前可以在那個(gè)步驟進(jìn)行重試

1.3 智能決策的愿景

記得在之前公司的時(shí)候大家還一起聽(tīng)大佬分享的AIOPS，根據(jù)人工智能和專(zhuān)家經(jīng)驗(yàn)在故障發(fā)生時(shí)可以自動(dòng)進(jìn)行決策，達(dá)到快速止損的目標(biāo)，什么知識(shí)圖譜、根因分析、智能機(jī)器人想想就可怕。不過(guò)作為一個(gè)程序員，我感覺(jué)我寫(xiě)的程序如果能比我先發(fā)現(xiàn)問(wèn)題，我都會(huì)懷疑是不是Bug相比智能運(yùn)維筆者更看好可落地的基于事件驅(qū)動(dòng)的運(yùn)維，通過(guò)感知對(duì)應(yīng)的事件根據(jù)專(zhuān)家經(jīng)驗(yàn)，將對(duì)應(yīng)事件的處理機(jī)制流程化自動(dòng)化，無(wú)論是從可控性、穩(wěn)定性、確定性上都可以得到保障

2.解決方案

其實(shí)也談不上方案，主要是落地的一點(diǎn)思考，其實(shí)沒(méi)有調(diào)研太長(zhǎng)時(shí)間，因?yàn)闀r(shí)間上并不允許。所以就粗暴的選型后，開(kāi)始根據(jù)我們的業(yè)務(wù)場(chǎng)景進(jìn)行系統(tǒng)設(shè)計(jì)了，這里就先介紹下選型和架構(gòu)

2.1 選型

根據(jù)運(yùn)維場(chǎng)景分析出來(lái)，我們需要的是一個(gè)有狀態(tài)的、可編程的、支持workflow、帶容錯(cuò)、無(wú)限擴(kuò)展的分布式任務(wù)編排框架。當(dāng)前云原生里面的任務(wù)編排貌似是一個(gè)冷門(mén)方向，于是筆者就看了下業(yè)務(wù)上解決分布式事務(wù)場(chǎng)景的框架，最終我們選定uber的cadence框架來(lái)實(shí)現(xiàn)，不過(guò)Candance的作者對(duì)DSL貌似很反感，并沒(méi)有實(shí)現(xiàn)默認(rèn)的DSL編排功能。為什么選型沒(méi)有按照常規(guī)的選擇一些比如airflow之類(lèi)的，主要原因其實(shí)跟筆者環(huán)境有關(guān)。公司當(dāng)前的基礎(chǔ)服務(wù)大多數(shù)要么是基于開(kāi)源的改造，要么就是自研。所以對(duì)開(kāi)源的默認(rèn)集成的對(duì)筆者來(lái)說(shuō)其實(shí)意義不大，反正都得自己寫(xiě)Provider。其二筆者現(xiàn)在的平臺(tái)有Java、Go兩種語(yǔ)言，為了方便集成，一定要選擇一個(gè)夸語(yǔ)言的。

2.2 系統(tǒng)架構(gòu)

基于開(kāi)源的candance我們直接設(shè)計(jì)了我們的上層業(yè)務(wù)層v0.1版本，為了實(shí)現(xiàn)上面提到的兩大核心功能：編排和決策，我們?cè)O(shè)計(jì)了6個(gè)業(yè)務(wù)模塊，其功能如下：

可以看出candance幫我們解決很分布式底層的很多問(wèn)題，只需要構(gòu)建上層業(yè)務(wù)模塊就可以了，等業(yè)務(wù)功能寫(xiě)完，抽時(shí)間看看對(duì)應(yīng)的實(shí)現(xiàn)，到時(shí)候再分享給大家

2.3 工作流程

系統(tǒng)的運(yùn)行分為兩個(gè)大的階段：編排期與運(yùn)行時(shí)

編排期

1.平臺(tái)研發(fā)負(fù)責(zé)將各種平臺(tái)功能分裝成原子組件接入到系統(tǒng)中2.運(yùn)維專(zhuān)家根據(jù)業(yè)務(wù)場(chǎng)景，組合下層的原子任務(wù)，并構(gòu)建對(duì)應(yīng)的DSL流程，對(duì)應(yīng)的worfklow作為決策分支供決策模塊使用，同時(shí)設(shè)置對(duì)應(yīng)的互斥策略

運(yùn)行時(shí)

1.當(dāng)對(duì)應(yīng)的運(yùn)維對(duì)象發(fā)生狀態(tài)變更時(shí)，則會(huì)產(chǎn)生對(duì)應(yīng)的事件2.決策模塊接收到事件之后，根據(jù)事件類(lèi)型和決策分支進(jìn)行決策，生成決策結(jié)果3.然后調(diào)用管控模塊，確認(rèn)決策結(jié)果是否可以下發(fā)到生產(chǎn)環(huán)境4.管控模塊根據(jù)當(dāng)前的運(yùn)行中的工作任務(wù)確定是否可以進(jìn)行對(duì)應(yīng)的決策5.下發(fā)workflow給Candance，然后由candance進(jìn)行workflow和原子任務(wù)的編排6.原子操作最終紅會(huì)觸發(fā)運(yùn)維對(duì)象的狀態(tài)變更，然后再進(jìn)行對(duì)應(yīng)的操作，直到達(dá)到目標(biāo)狀態(tài)

3.心得

先寫(xiě)到這吧，最近還是比較忙，周末在家看了一天service catalog的代碼，晚上想想還是得總結(jié)下，因?yàn)楹镁脹](méi)寫(xiě)文章了，想了好幾個(gè)小時(shí)，也沒(méi)咋寫(xiě)，感覺(jué)亂亂的。等后面代碼寫(xiě)完了在給大家分享下里面的一些代碼級(jí)別的設(shè)計(jì)。明天再給大家分享下service manager里面好玩的東西。大佬們幫我分享分享，要吃土了。。。

 點(diǎn)擊屏末 | 閱讀原文 | 即刻學(xué)習(xí)