隨着有贊規模的增加, 運維的事務也日益複雜, 如何能更加高效的協調好開發, 運維, 工具與流程之間的關係, 把運維人員從低效率, 高強度, 易犯錯的人工操做中完全解放出來,讓他們的能力與精力有更大程度的發揮, 是一個很大的挑戰.前端
有贊 DevOps 平臺的工做流引擎 Opsflow 通過兩年時間的演進, 從最開始的僅支持簡易的固定順序加定製腳本的系統, 慢慢演化到能夠經過 GUI 操做的, 無需編碼的, 高度定製化的, 可視化的, 可感知進度的工做流引擎, 支撐着天天數百上千的包括但不限於各類權限申請, 應用組件申請, 大數據相關審批, 發佈審批, 持續集成與交付等千差萬別的流程.react
本文將從如下幾個主要方面分別闡述有贊 DevOps 工做流引擎 Opsflow 的建設與演進:git
在 Opsflow 完善以前面臨一系列的問題:github
Opsflow 的系統設計以及在有讚的落地狀況, 內容包括:算法
Opsflow 的實現由管理有限狀態機的 Opsflow-FSM 模塊, 與外界交互的 Opsflow-Web 模塊, 驅動插件的 Opsflow-Plugins 模塊和執行具體任務的 Worker 模塊和用來監控任務消費狀況的監控模塊組成, 下文逐一對這些模塊進行介紹.segmentfault
截止本文發佈, 有贊 DevOps 平臺已有 60+ 流程接入 Opsflow, 每一個流程在 Opsflow 看來上都是一個有限狀態機 ( Finite-state machine ), 當管理員在 Opsflow 管理後臺經過 GUI 界面生成一個新流程, 本質上是在 Opsflow 上建立了一個新的 FSM, 例以下圖的 "新建 ES 申請" 就是一個 Opsflow-FSM 管理的一個 FSM. Opsflow-FSM 做爲 Opsflow 的核心, 驅動工單往前推動, 例如, 當一個 "新建 ES 申請" 工單運行到 "ES 管理員審批" 狀態時, Opsflow-FSM 經過持久化在 RDS 中的工單實例能夠獲得當前審批人能夠觸發的三個流轉 "贊成" / "駁回" / "關閉工單", 任何一個流轉經過頁面被觸發以後又由 Opsflow-FSM 驅動至 "審批駁回腳本執行" / "審批完成腳本執行" / "審批拒絕腳本執行" 狀態之一, 以此類推, 最終 Opsflow-FSM 驅動工單 ( 也即特定 FSM 的實例 ) 至 "結束" 狀態, 完成一個工單的生命週期.後端
Opsflow-FSM 僅僅對 FSM 進行管理, 沒法與外界交互, Opsflow-Web 則封裝了 Opsflow-FSM, 增長了權限驗證 ( 某我的是否有權限處理特定工單, 某個應用是否能夠操做某類工做流 ( FSM ) 等 ) 等模塊, 以 RESTful API 的方式對外界提供服務, 與有贊 DevOps 平臺下的其餘各個系統(發佈系統, CI & CD 系統, 水位系統等 ) 進行交互. 之前文的 "新建 ES 申請" 流程爲例, 工單在 "ES 管理員審批" 節點時 Opsflow-Web 根據 Opsflow-FSM 給到的三個流轉信息在前端渲染出相應的三個按鈕, 審批人按下其中一個按鈕以後, 動做又由 Opsflow-Web 提供的 RESFful API 與前端交互, 觸發 Opsflow-FSM 將 FSM 實例往相應的分支進行流轉, FSM 向着 "結束" 狀態推動.微信
基於可擴展性的考慮, Opsflow 提供插件系統 Opsflow-Plugins, 插件系統發送 Opsflow-FSM 在 FSM 在不一樣狀態間流轉的過程當中的各類事件, 例如, "工單設置了新的參與人" 事件, 得益於 Opsflow-Plugins, 運維開發同窗一旦接到諸如 "在工單設置新的參與人的時候通知一下 xxx" 等需求的時候, 實現起來不費吹灰之力, 只須要提供一個實現起來很是簡單的插件便可, 具體來講就是訂閱相應事件, 提供回調接口便可. 目前有企業微信通知, Ops 待辦事項等插件經過 Opsflow-Plugins 接入 Opsflow, 在保持 Opsflow 核心精簡的同時豐富了 Opsflow 的功能.數據結構
工單通過審批節點後一般會流轉到狀態機中設定好的 "腳本" 節點 ( 節點的參與人屬性是 "腳本" 的 FSM 節點 ), Opsflow-Web 將會推送相應的任務 ( 例如前文 "新建 ES 申請" 流程的具體負責新建 ES 相關資源的任務 ) 到消息隊列中, Worker 則從消息隊列中獲取任務執行, 執行完具體任務後, 觸發 Opsflow-FSM 繼續流轉. Worker 的實現使用分佈式任務隊列 Celery 隊列堆積時可快速水平擴展.架構
Opsflow 前端爲全部工做流提供了默認的頁面展現, 包括 "流程圖" / "工單進度" / "工單詳情" ( key / value 的形式呈現工單實例的信息) / "工單操做" 等組件, 管理員能夠在管理後臺對這些組件進行是否顯示以及順序等進行方便地配置.
不一樣的工做流極可能須要定製本身的前端, 例如前文的 "新建 ES 申請" 流程就須要在頁面上展現 "字段信息" / "SLA" 等信息, Opsflow 對自定義工做流前端提供了豐富的支持, 對於 "新建 ES 申請" 這個流程而言, 負責開發的同窗僅需提供一個 React 組件, Opsflow 在渲染工單詳情頁面的時候會根據配置動態加載 ( 經過 react-loadable ) 相應的前端組件渲染在上圖所示的位置, Opsflow 提供給自定義組件提供豐富的 properties, 這些 properties 涵蓋當前工單的全部信息, 自定義組件能夠根據這些 properties, 在相應後端拉取相應的數據進行渲染, 如上圖的各個例子.
Opsflow-FSM 維護的有限狀態機在數據結構上是 Directed acyclic graph (DAG), Opsflow 使用了很是優秀的基於 A Technique for Drawing Directed Graphs 中介紹的基於 rank 分層佈局算法的 DAG 流程圖繪製庫 dagre-d3 繪製很是飄逸的流程, 見下圖中的例子.
Opsflow 提供了 GUI 界面對 FSM 進行管理, 流程管理員能夠在頁面上配置 FSM 中的節點和邊的各類屬性, 流程中不合理的地方能夠經過實時呈現的流程圖暴露出來, 管理員可當即作出調整, 前文減小的前端結構解決了 2, 4 兩個問題.
有贊 DevOps 平臺中的絕大多數流程已經遷移到 Opsflow, 基於老的工做流系統的流程已經下線, 衆多流程中的共性需求都會在 Opsflow 實現, 避免重複造輪子.
Opsflow 提供 "條件表達式" 功能, 具體來講, 工單管理員在配置一個 FSM "流轉" 的時候能夠指定一個 "條件表達式" 例如 Hive 語句審批流程中的
{row_count} >= 1000000 and not {upload}
Opsflow-FSM 在決定工單下一個狀態的時候會根據該表達式動態的計算下一個流程節點, 例子中花括號 row_count
和 upload
分別是該工單實例的的不一樣屬性, 例如 row_count
表明 "Hive 語句審批流程" 流程工單實例中 SQL 影響的行數, 上面的表達式翻譯成 "人話" 就是: "行數大於 1000000 且用戶進行了上傳則到 XXX 節點", 其中 "XXX 節點" 多是某個有 Hive 管理權限的人, 不然多是 TL 等等.
Opsflow 與有贊內部其餘例如 OA 等系統緊密結合, Opsflow 在根據 FSM 配置計算下一個節點參與人的時候會自動根據 OA 中的請假代理人信息將節點審批人替換爲請假代理人 ( 若是原審批人在度假 ).
Opsflow 目前支持的節點參與人包括:
基本覆蓋了各類審批流程中的參與人類型需求.
Opsflow 支持的節點參與人:
Opsflow 經過週期性地運行統計任務產生統計圖, 管理員能夠直觀瞭解到不一樣流程的運營狀況.
Opsflow 上線一年多以來, 通過不斷的迭代, 在易用性, 功能, 擴展性, 穩定性上都有顯著的提高, 截止目前有 60+ 流程截圖, 涉及到 DevOps 中的方方面面, 有贊 DevOps 平臺之外也已有大數據平臺和美業等部門的流程接入.
Opsflow 後續將會實現環境間流程同步 ( 例如用於測試的 QA 環境到生產環境 Prod 等 ), 容許全部開發進行流程新建 / 編輯的開放管理後臺等功能, 進一步加速新流程的接入, 另外還有複製工做流, 更加好用的移動端快速審批等功能, 更好的服務於有贊運維和開發同窗.
有贊基礎保障 DevOps 團隊榮譽出品 🏆