數人云|關於分佈式任務調度平臺，數人云的經驗都在這裏了

分佈式任務調度平臺是目前不少公司研究的方向，今天小數就給你們分享一下數人云分佈式任務調度平臺（Octopus）的一些思考與實踐。

今天主要分享下批量處理平臺的技術心得，批量處理從片面的角度講相似於Linux系統中的Cron Table，從大方向去看屬於批量業務的調度平臺，這次依託數人云3年來對容器技術的積累和對批量處理開源項目的整合過程，在這裏和你們探討一下實踐分佈式任務調度的心路歷程。

從理論上來講，作分佈式系統並不是企圖加快單一任務處理速度，而是經過並行的方式合理利用資源，經過加大對任務的同時批量處理業務容量來加快業務的運營速度，舉個典型的例子：當前視頻直播中須要的視頻文件解碼，就是一種典型的批量處理業務。

原本，批量處理業務和容器技術的關係並不緊密，咱們經過跨領域的交叉設計，但願經過容器技術的封裝能力幫助批處理系統快速創建更多的高密度批量處理運行時環境，更高效地利用資源。

定時任務無處不在，在多任務處理時如何進行秒級調度？與容器如何碰撞？這是我比較關注的主題，我的的角度來看，批量處理系統的痛點有四個維度是用戶比較關注的：

• 彈性伸縮
• 故障處理
• 運維體系
• 性能指標

以金融行業爲例，在金融行業高速發展的今天，業務規模快速擴展，隨着業務的發展，需處理的數據量愈來愈大，後臺批量處理業務佔60%以上，如數據接口導入、數據預處理、估值表生成、憑證生成、對帳、日終批處理、報表生成等。

從用戶關注的4個維度切入問題主要表如今：

彈性擴縮：批量處理做業只能運行在一個服務節點上，沒法適應業務發展，這是目前業務系統的最大性能瓶頸點。

故障處理：看成業發生故障時，未實現故障自動轉移，嚴重時影響業務進展。

性能指標：

1. 做業調度與做業執行線程耦合在一塊兒，隨着做業規模的增加，嚴重影響系統性能，也給開發和運維帶來了必定的難度。
2. 聯機業務和批量處理業務耦合，當在進行比較消耗資源的批處理或批量處理服務發生嚴重故障時直接影響到了在線業務。

運維體系：不便於定位做業運行時問題，不便於瞭解做業運行進展、負載狀況、也缺乏做業運行時的性能指標，不便於對做業進行調優等。

有了這些分析，在設計豎線數人云分佈式任務調度平臺過程當中，採用做業調度與做業執行分離的架構來簡化業務系統批量處理的開發和運維工做；採用中間件和平臺化的思路提高其應用的範圍及價值；採用Java系統做業的調度，執行與管控；最後產生的效果是實現了以分佈式調度爲理念而設計的——多服務節點協同並行處理能力及運行環境的適用能力。

在彈性伸縮方面，數人云採用了基於容器平臺目的是快速構建多節點的任務執行節點，容器的好處是封裝了一整套完整的任務執行環境，而且能夠快速擴容服務節點數量，這個批處理設計模型如何本身實現會須要大量的測試和業務打磨，因此在技術選型上，選用了Mesos做爲企業級環境的底座，畢竟Apple、MS、Netflix、Uber等大廠都在基於此技術上構建了本身的業務平臺。

尤爲國內開源項目噹噹的Elastic-Job批量處理平臺（https://github.com/dangdangdo...）受到不少廠家的採用，爲數人云提供了一手的學習實踐經驗。

數人云在此之上又進行了一些優化，從設計理念中，更多考慮了業務實際場景中的一種情況：即每次任務處理完畢後，是重置當前進程環境仍是退出，雖然容器的額快速啓停確實能夠解決這個小問題，但仍然不夠快。畢竟一個任務的環境初始化是須要消耗時間的，即便容器啓動也有那麼幾十毫秒的損耗。另外，咱們對Mesos集羣的使用，在於提供能夠FailOver的高容錯環境，並無直接讓Mesos來調度批量處理任務，實際上，做業節點註冊到ZK後，任務的分發和結果收集都是在JVM裏面解決，和Mesos集羣自己沒有關係，減小了對集羣系統的直接依賴，後面，咱們還會對Kuberentes集羣作支持。

在故障處理方面，重要的並非讓任務永遠不出錯，在建立任務時，能提供當即執行一次的操做，讓執行結果能即刻體現出來，這樣給任務指定的時間去跑纔不會出錯，在建立任務的細節上，好比把跑批時間參入如：0/5 ? 預測出固定的時間，讓用戶看到直接的時間會更好。

對於過後的歷史結果留存也須要作到詳細完整，保證故障拍錯，這塊使用統計面板來監控便可。

以及做業預警面板也是須要的。

在性能指標方面，大量的工做主要是定義好性能指標並大量壓測並調優系統，好比數人云的產品定義：

調度頻率：定時做業最快支持5S的時間間隔，對比：公有云如阿里ScheduleX，都是分鐘級間隔。

支持做業容量：最多支持管理100個Zookeeper集羣，做業總量支持到500K+。

消息做業併發量：支持單節點100K TPS的併發。

經過這個目標，根據本地搭建的做業系統環境就能夠壓測了，壓測數據經過Grafana展示出來，測試樣例以下：

在運維體系中，能不能經過一個管理平臺就囊括全部運維須要管理的事情，將其都考慮進去，好比組織關係的體現，暫停時間的管理，配置數據的備份和查詢，ZK元數據的處處備份工做，調用鏈的跟蹤設計實現，各類監控面板的實現，這個難度不大，但須要考慮的細節很是多，咱們也是在參考和落地實踐中摸索這些問題如何解決。

最後，分佈式任務調度平臺在企業架架構體系裏面必不可少少的組件，國內企業在通過這幾年雲計算的高速發展，開始意識到數字化轉型過程當中必需要經歷架構方面的變革，傳統的批處理系統已經不能適應業務發現的須要，不妨參考業內開源領域的最佳實踐構建本身的分佈式調度平臺。

QA

Q：是否開源？

A： 數人云任務調度基於開源基礎構建擴展了企業級功能。目前暫不開源，後續是否開源視社區反饋決定。

Q：無中心化設計（由任務執行者獲取執行計劃，並本身觸發執行）和集中式調度設計（由一個調度中心統一經過遠程調用的方式觸發執行者）有什麼考慮，更偏向於哪個？

A：數人云任務調度包括控制檯都在內都基於無中心化設計，中心控制是ZooKeeper集羣。此種設計從分佈式角度考慮，避免單點故障。

Q：可否詳細介紹下並行執行、分片、日誌，終端處理的設計實現思路？

A：
l 並行基於分片粒度執行，目前支持幾種粒度：多機器節點執行、同個節點多個進程執行、同個進程多個線程執行。進程粒度的並行執行基於ZooKeeper進行分佈式協調處理。多線程基於Java Executors作線程池調度處理。
l 日誌支持寫入ZK，同時支持對接LogStash將日誌放入ELK。因爲任務執行控制都在平臺側，因此平臺能夠獲取攔截日誌流，並將日誌進行查處記錄。Java和消息做業是攔截LogBack，Shell做業基於Apache Commons Exec的LogOutputStream進行進程輸出流的攔截。

Q：任務積壓如何考慮？如何標記任務執行中或執行完成，具體如何實現？

A：
l 任務支持超時告警和Kill的配置控制。任務積壓時能夠對接告警系統，Dashboard也支持顯示。
l 當任務開始執行和結束時，會由平臺側將狀態寫入ZK。

Q：選擇平臺獨立調度系統主要基於哪些考慮？支持K8S後會考慮自帶的Scheduler嗎？另「任務結果收集」是如何實現的？

A：任務調度能夠當即爲容器Scheduler上的另一層獨立調度，然後經過Kubernetes/Marathon等API啓動容器，任務結果收集能夠考慮ELK方式或對接APM系統。

Q：分佈式任務系統中，如何根據機器系統負載及當前執行任務列表進行任務動態負載？

A：目前作法是給任務設定一個邏輯的負載，在調度的時儘量作到各個機器的總體負載均衡。

Q：若機器掛掉，如何進行有狀態任務的故障轉移？

A: 利用Zookeeper特性，當一臺機器掉線後，它上面的做業會被調度到其它機器來完成。

Q：任務間可能存在一些依賴，如何解決這些任務間的傳遞問題？

A: 目前經過配置的方式設置任務依賴，當中止、啓動做業時會給予提醒。任務間的消息傳遞可利用消息做業的方式進行。

Q：當用戶上傳的是危險操做，平臺如何進行自我保護？

A:目前利用容器作隔離，固然也能夠經過Chroot的方式將做業運行目錄隔離。

Q：若任務堵住了Hang 任務進程會表現正常，但實際業務沒有處理，如何解決？

A：須要平臺級別超時控制，超過必定閾值時發送告警，再過必定閥值殺掉任務。

Q：消息做業支持哪些平臺，消息做業的性能表現如何？

A：目前支持Kafka，後續也會支持RabbitMQ。至於性能，內部測試能夠達到20W的TPS。機器的配置爲Mem:48G，CPU:16C*2.2G。

Q：是否支持在容器化的平臺運行？

A：支持，目前支持發佈到Marathon、數人云SWAN、以及Kubernetes平臺。

Q：開源版本如EJ和Saturn，不支持認證或提供BASIC認證。企業難以使用，如何處理？

A：數人云調度平臺提供基於角色的標準認證，也支持對接LDAP的方式。

Q：針對開源版本，數人云調度平臺提供哪些企業級功能？

A：提供認證受權、審計、對接Prometheus的Metrics、歷史配置與版本恢復。

關於數人云分佈式任務調度平臺Octopus

數人云Octopus基於噹噹Elastic Job和惟品會的Saturn以及數人云DM/OS和容器雲平臺，打造的高效易用定時任務調度系統。支持多種任務類型和模式，具備資源動態平衡以及框架、業務隔離的功能，並且無縫融合物理機、虛擬機以及容器，從而實現調度任務統一監控管理，全面高可用。

〓 應用場景

無縫代替 Linux Cron Job：完美代替 Linux Cron Job，作到全局統一配置、統一管理、統一監控。

分佈式任務調度：分佈式並行任務處理，如分庫分表的批處理等。

本地任務調度：能夠根據任務量，任意調整處理資源。如電商商品圖片掃描處理等。

消息任務調度：經過消息調度做業處理。如日誌處理、消息驅動數據庫同步等。

〓 功能特性

• 資源動態平衡：人工指定運行節點，系統自動平衡負載，靈活的運維配置與部署，高效資源利用，簡便的管理。
• 認證與受權：提供 LDAP 集成，以及多角色權限管理。
• 框架與業務隔離：框架代碼與業務代碼隔離，集中化動態增長與刪除任務，簡化開發，避免衝突，業務無侵入，易於發佈與維護，框架升級與業務脫離，框架版本統一升級。
• 分組以及依賴管理：嚴謹的管理模式以及靈活的設置。
• 秒級調度：提供任務秒級觸發。
• 簡單易用的 SDK：快速開發業務。
• 資源混搭：支持物理機、虛擬機以及容器。
• 優美的監控臺：提供多維度 Dashboard 以及監控視圖。
• 多種任務類型與任務模式：
  1）Shell 任務：提供任意腳本語言，無縫遷移 Linux Cron Job；

2）JAVA 任務：提供靈活編程模式，知足不一樣的業務需求；3）消息任務：提供消息驅動，支持任務間串接；4）分佈式運行與本地任務模式：提供分片、分區處理模式，以及 Daemon 模式，知足業務靈活並行處理。