在平常的工做中一般會組合幾個系統的相關功能共同完成某個業務場景，這時候一般在通常的微服務中就須要使用分佈式事務來解決，或者經過本文說的編排的方式來解決，本文算是這個系列的入門篇，主要是介紹下筆者在實際工做中的嘗試，後續會持續更新一些內部的原理與更好玩的生產實踐程序員
1.背景
在接手的運維平臺中以前的設計是在一個大的controller將完成某個業務場景的代碼所有寫在一塊兒，而後中間爲了兼容各類以前的平臺和場景的問題，充斥着大量的if else以及硬編碼，致使出了問題須要就要人爲介入排查，擴展性、健壯性幾乎爲零, 爲了更好的理解第二部分咱們的嘗試，這裏先給你們介紹幾個概念編程
1.1 運維中的任務編排
在傳統的運維開發中，任務編排一般是一個很常見的系統，在k8s以前的運維繫統中，一般是基於master-worker架構實現對應的任務的編排，也有不少的開源產品，好比stackstorm、tower、jeankins等 
同一些業務上使用的框架並沒有本質區別，咱們能夠經過寫插件來實現對應的接口，就能夠丟給系統取跑任務了，任務過程當中的數據、狀態都由對應的插件自身維護，系統只負責任務的調度，而不負責狀態和數據的管理微信
1.2 運維中的狀態
面向終態是大佬們最近這幾年引領的新的運維模型，經過描述最終狀態，系統根據當前狀態去決策採起的動做而後等待對應的反饋結果，再次進行決策從而達到正向反饋環，直到目標狀態。 但其實平常的工做中不少業務邏輯一般都是有狀態的。好比在擴容場景中，若是沒有知道當前的Pod或者Server的狀態，本質上你也沒辦法決策接下來該作啥操做。在一個長的worfklow裏面若是你不知道任務的狀態，則就沒法知道當前能夠在那個步驟進行重試架構
1.3 智能決策的願景
記得在以前公司的時候你們還一塊兒聽大佬分享的AIOPS，根據人工智能和專家經驗在故障發生時能夠自動進行決策，達到快速止損的目標，什麼知識圖譜、根因分析、智能機器人想一想就可怕。不過做爲一個程序員，我感受我寫的程序若是能比我先發現問題，我都會懷疑是否是Bug 相比智能運維筆者更看好可落地的基於事件驅動的運維，經過感知對應的事件根據專家經驗，將對應事件的處理機制流程化自動化，不管是從可控性、穩定性、肯定性上均可以獲得保障框架
2.解決方案
其實也談不上方案，主要是落地的一點思考，其實沒有調研太長時間，由於時間上並不容許。因此就粗暴的選型後，開始根據咱們的業務場景進行系統設計了，這裏就先介紹下選型和架構運維
2.1 選型
根據運維場景分析出來，咱們須要的是一個有狀態的、可編程的、支持workflow、帶容錯、無限擴展的分佈式任務編排框架。當前雲原生裏面的任務編排貌似是一個冷門方向，因而筆者就看了下業務上解決分佈式事務場景的框架，最終咱們選定uber的cadence框架來實現，不過Candance的做者對DSL貌似很反感，並無實現默認的DSL編排功能。 爲何選型沒有按照常規的選擇一些好比airflow之類的，主要緣由其實跟筆者環境有關。公司當前的基礎服務大多數要麼是基於開源的改造，要麼就是自研。因此對開源的默認集成的對筆者來講其實意義不大，反正都得本身寫Provider。其二筆者如今的平臺有Java、Go兩種語言，爲了方便集成，必定要選擇一個誇語言的。分佈式
2.2 系統架構
基於開源的candance咱們直接設計了咱們的上層業務層v0.1版本，爲了實現上面提到的兩大核心功能：編排和決策，咱們設計了6個業務模塊，其功能以下：ide
| 模塊 | 說明 |
|---|---|
| 原子組件 | 封裝各類原子任務，提供workflow和dsl作任務編排 |
| DSL編排 | 系統提供基礎的workflow決策，而且支持DSL編排 |
| 事件 | 用於監聽或者接受外部系統傳遞的事件觸發對應的決策模塊 |
| 決策 | 實現基礎的業務分級、機器分批等決策功能，決策會觸發對應的workflow或者原子組件 |
| 服務目錄 | 經過服務目錄對外提供原子操做和worfklow使用 |
| 管控模塊 | 管控模塊主要是對決策的結果進行管理，避免多個決策模塊進行相同做業的下發，實現統一的控制 |
能夠看出candance幫咱們解決很分佈式底層的不少問題，只須要構建上層業務模塊就能夠了，等業務功能寫完，抽時間看看對應的實現，到時候再分享給你們微服務
2.3 工做流程
系統的運行分爲兩個大的階段：編排期與運行時源碼分析
編排期
1.平臺研發負責將各類平臺功能分裝成原子組件接入到系統中 2.運維專家根據業務場景，組合下層的原子任務，並構建對應的DSL流程，對應的worfklow做爲決策分支供決策模塊使用，同時設置對應的互斥策略
運行時
1.當對應的運維對象發生狀態變動時，則會產生對應的事件 2.決策模塊接收到事件以後，根據事件類型和決策分支進行決策，生成決策結果 3.而後調用管控模塊，確認決策結果是否能夠下發到生產環境 4.管控模塊根據當前的運行中的工做任務肯定是否能夠進行對應的決策 5.下發workflow給Candance，而後由candance進行workflow和原子任務的編排 6.原子操做最終紅會觸發運維對象的狀態變動，而後再進行對應的操做，直到達到目標狀態
3.心得
先寫到這吧，最近仍是比較忙，週末在家看了一天service catalog的代碼，晚上想一想仍是得總結下，由於很久沒寫文章了，想了好幾個小時，也沒咋寫，感受亂亂的。等後面代碼寫完了在給你們分享下里面的一些代碼級別的設計。明天再給你們分享下service manager裏面好玩的東西。大佬們幫我分享分享，要吃土了。。。
雲原生學習筆記地址: https://www.yuque.com/baxiaoshi/tyado3 微信號：baxiaoshi2020 公共號: 圖解源碼
微信號：baxiaoshi2020