一、背景

阿里云日志服務(wù)作為云原生可觀測與分析平臺。提供了一站式的數(shù)據(jù)采集、加工、查詢分析、可視化、告警、消費與投遞等功能。全面提升用戶的研發(fā)、運維、運營、安全場景的數(shù)字化能力。

日志服務(wù)平臺作為可觀測性平臺提供了數(shù)據(jù)導(dǎo)入、數(shù)據(jù)加工、聚集加工、告警、智能巡檢、導(dǎo)出等功能，這些功能在日志服務(wù)被稱為任務(wù)，并且具有大規(guī)模的應(yīng)用，接下來主要介紹下這些任務(wù)的調(diào)度框架的設(shè)計與實踐。

本次介紹主要分為四個部分：

• 任務(wù)調(diào)度背景
• 可觀測性平臺的億級任務(wù)調(diào)度框架設(shè)計
• 任務(wù)調(diào)度框架在日志服務(wù)的大規(guī)模應(yīng)用
• 展望

任務(wù)調(diào)度背景

通用調(diào)度

調(diào)度在計算機里面是一個非常常見的技術(shù)，從單機到分布式再到大數(shù)據(jù)系統(tǒng)，調(diào)度的身影無處不在。這里嘗試總結(jié)出調(diào)度的一些共同特征。

• 操作系統(tǒng)：從單機操作系統(tǒng)Linux來看，內(nèi)核通過時間片的方式來控制進程在處理器上的執(zhí)行時間，進程的優(yōu)先級與時間片掛鉤，簡單來說，進程的在單CPU或者某個CPU的執(zhí)行由調(diào)度器來掌握；K8s被稱為分布式時代的操作系統(tǒng)，在Pod創(chuàng)建后，K8s的控制面調(diào)度器通過對節(jié)點進行打分排序，最終選出適合的Node來運行Pod。
• 大數(shù)據(jù)分析系統(tǒng)：從最早的MapReduce使用公平調(diào)度器支持作業(yè)的優(yōu)先級和搶占，到SQL計算引擎Presto通過Coordinator的調(diào)度器將執(zhí)行計劃中的任務(wù)分配到適合的worker上來執(zhí)行，Spark通過DAGScheduler拆分成Stage，TaskScheduler將Stage對應(yīng)的TaskSet最終調(diào)度到適合的Worker上來執(zhí)行。
• 任務(wù)調(diào)度框架：在數(shù)據(jù)處理中常見的ETL處理任務(wù)、定時任務(wù)，這些任務(wù)具有多模的特點：定時執(zhí)行、持續(xù)運行、一次性執(zhí)行等。在任務(wù)執(zhí)行過程中需要考慮任務(wù)的編排和狀態(tài)一致性問題。

這里簡單的對調(diào)度做一個抽象，如上圖所示，調(diào)度負責(zé)將不同的Task分配到不同的Resource上執(zhí)行，Task可以是進程、Pod、子任務(wù)；Resource為具體執(zhí)行Task任務(wù)的資源，可以是處理器、線程池、節(jié)點、機器。通過這個抽象，可以看出調(diào)度在系統(tǒng)中的位置。

調(diào)度的覆蓋面很廣，本文主要集中在任務(wù)調(diào)度框架的設(shè)計與實踐，這里先通過一些例子來看下任務(wù)調(diào)度的一些特點，以下主要講任務(wù)分為定時類的任務(wù)和依賴類的任務(wù)兩種來展開。

任務(wù)調(diào)度

定時類任務(wù)

定時執(zhí)行可以理解為每個任務(wù)之間有時間先后順序，并且要在特定的時間點執(zhí)行，比如每隔1小時對日志進行監(jiān)控，00點的監(jiān)控任務(wù)需要首先執(zhí)行，01點的監(jiān)控任務(wù)需要在01點準時執(zhí)行；同樣，類似的定時場景，還有儀表盤訂閱、定時計算等。

?依賴類任務(wù)

除了定時執(zhí)行，還有另外一種編排形式，比如順序依賴，各個任務(wù)之間有先后執(zhí)行的依賴，也叫Pipeline方式，還有一種比較常見的編排形式，拓撲依賴，也稱為DAG，比如Task2/Task3需要等到Task1執(zhí)行完成才可以執(zhí)行，Task5需要等到Task3/Task4執(zhí)行完才可以執(zhí)行。

?任務(wù)調(diào)度特點

任務(wù)調(diào)度在執(zhí)行的過程中需要盡可能均衡的將任務(wù)分派到合適的機器或者執(zhí)行器上去執(zhí)行，比如要根據(jù)執(zhí)行器的當(dāng)前負載情況，要根據(jù)任務(wù)自身的特征進行分派執(zhí)行；在執(zhí)行器執(zhí)行的過程中也可能會崩潰，退出，這時候需要將任務(wù)遷移到其他的執(zhí)行器中。整個調(diào)度過程需要考慮到調(diào)度策略、FailOver、任務(wù)遷移等。接下來來看下任務(wù)調(diào)度的一個簡單應(yīng)用。

任務(wù)調(diào)度應(yīng)用：一條日志的歷險

上圖中原始日志為一條Nginx訪問日志，其中包括IP、時間、Method、URL、UserAgent等信息，這樣一些原始日志并不利于我們進行分析，比如我們想統(tǒng)計訪問最高的Top 10 URL，通過命令處理是這樣的：

cat nginx_access.log |awk '{print $7}'| sort|uniq -c| sort -rn| head -10 | more

拋開命令的復(fù)雜性和原始日志的數(shù)據(jù)量不談，即使需求稍微變化，命令就需要大量的改動，非常不利于維護，對日志進行分析的正確方式必然是使用分布式日志平臺進行日志分析，原始日志蘊含著大量“信息”，但是這些信息的提取是需要一系列的流程。

首先是數(shù)據(jù)采集、需要通過Agent對分布在各個機器上的數(shù)據(jù)進行集中采集到日志平臺，日志采集上來后需要進行清洗，比如對于Nginx訪問日志使用正則提取，將時間、Method、URL等重要信息提取出來作為字段進行存儲并進行索引構(gòu)建，通過索引，我們可以使用類SQL的分析語法對日志進行分析、例如查看訪問的Top 10 URL，用SQL來表達就會非常簡潔清晰：

select url, count(1) as cnt from log group by url order by cnt desc limit 10

業(yè)務(wù)系統(tǒng)只要在服務(wù)，日志就會不斷產(chǎn)生，可以通過對流式的日志進行巡檢，來達到系統(tǒng)異常的檢測目的，當(dāng)異常發(fā)生時，我們可以通過告警通知到系統(tǒng)運維人員。

?通用流程提取

從這樣一個日志分析系統(tǒng)可以提取出一些通用的流程，這些通用的流程可以概括為數(shù)據(jù)攝入、數(shù)據(jù)處理、數(shù)據(jù)監(jiān)測、數(shù)據(jù)導(dǎo)出。

除了日志，系統(tǒng)還有Trace數(shù)據(jù)、Metric數(shù)據(jù)，它們是可觀測性系統(tǒng)的三大支柱。這個流程也適用于可觀測性服務(wù)平臺，接下來來看下一個典型的可觀測服務(wù)平臺的流程構(gòu)成。

?典型可觀測服務(wù)平臺數(shù)據(jù)流程

• 數(shù)據(jù)攝入：在可觀測服務(wù)平臺首先需要擴展數(shù)據(jù)來源，數(shù)據(jù)源可能包括各類日志、消息隊列Kafka、存儲OSS、云監(jiān)控數(shù)據(jù)等，也可以包括各類數(shù)據(jù)庫數(shù)據(jù)，通過豐富數(shù)據(jù)源的攝入，可以對系統(tǒng)有全方位的觀測。
• 數(shù)據(jù)處理：在數(shù)據(jù)攝入到平臺后，需要對數(shù)據(jù)進行清洗、加工，這個過程我們把他統(tǒng)稱數(shù)據(jù)處理，數(shù)據(jù)加工可以理解為數(shù)據(jù)的各種變換和富華等，聚集加工支持對數(shù)據(jù)進行定時rolling up操作，比如每天計算過去一天匯總數(shù)據(jù)，提供信息密度更高的數(shù)據(jù)。
• 數(shù)據(jù)監(jiān)測：可觀測性數(shù)據(jù)本身反應(yīng)了系統(tǒng)的運行狀態(tài)，系統(tǒng)通過對每個組件暴露特定的指標來暴露組件的健康程度，可以通過智能巡檢算法對異常的指標進行監(jiān)控，比如QPS或者Latency的陡增或陡降，當(dāng)出現(xiàn)異常時可以通過告警通知給相關(guān)運維人員，在指標的基礎(chǔ)上可以做出各種運維或者運營的大盤，在每天定時發(fā)送大盤到群里也是一種場景的需求。
• 數(shù)據(jù)導(dǎo)出：可觀測性數(shù)據(jù)的價值往往隨著時間產(chǎn)生衰減，那么對于長時間的日志類數(shù)據(jù)出于留檔的目的可以進行導(dǎo)出到其他平臺。

從以上四個過程我們可以抽象出各類任務(wù)，分別負責(zé)攝入、處理、檢測等，比如數(shù)據(jù)加工是一種常駐任務(wù)，需要持續(xù)對數(shù)據(jù)流進行處理，儀表盤訂閱是一種定時任務(wù)，需要定時發(fā)出儀表盤到郵件或者工作群中。接下來將要介紹對各類任務(wù)的調(diào)度框架。

可觀測性平臺的億級任務(wù)調(diào)度框架設(shè)計可觀測平臺任務(wù)特點

根據(jù)上面對可觀測平臺任務(wù)的介紹，可以總結(jié)一個典型的可觀測平臺的任務(wù)的特點：

• 業(yè)務(wù)復(fù)雜，任務(wù)類型多：數(shù)據(jù)攝入，僅數(shù)據(jù)攝入單個流程涉及數(shù)據(jù)源可能有幾十上百個之多。
• 用戶量大，任務(wù)數(shù)數(shù)量多：由于是云上業(yè)務(wù)，每個客戶都有大量的任務(wù)創(chuàng)建需求。
• SLA要求高：服務(wù)可用性要求高，后臺服務(wù)是升級、遷移不能影響用戶已有任務(wù)的運行。
• 多租戶：云上業(yè)務(wù)客戶相互直接不能有影響。?

可觀測平臺任務(wù)調(diào)度設(shè)計目標

根據(jù)平臺任務(wù)的特點，對于其調(diào)度框架，我們需要達到上圖中的目標

• 支持異構(gòu)任務(wù)：告警、儀表盤訂閱、數(shù)據(jù)加工、聚集加工每種任務(wù)的特點不一樣，比如告警是定時類任務(wù)、數(shù)據(jù)加工是常駐類任務(wù)，儀表盤訂閱預(yù)覽是一次性任務(wù)。
• 海量任務(wù)調(diào)度：對于單個告警任務(wù)，假如每分鐘執(zhí)行一次，一天就會有1440次調(diào)度，這個數(shù)量乘以用戶數(shù)再乘以任務(wù)數(shù)，將是海量的任務(wù)調(diào)度；我們需要達到的目標是任務(wù)數(shù)的增加不會對打爆機器的性能，特別是要做到水平擴縮容，任務(wù)數(shù)或者調(diào)度次數(shù)增加只需要線性增加機器即可。
• 高可用：作為云上業(yè)務(wù)，需要達到后臺服務(wù)升級或者重啟、甚至宕機對用戶任務(wù)運行無影響的目的，在用戶層面和后臺服務(wù)層面都需要具有任務(wù)運行的監(jiān)控能力。
• 簡單高效的運維：對于后臺服務(wù)需要提供可視化的運維大盤，可以直觀的展示服務(wù)的問題；同時也要對服務(wù)進行告警配置，在服務(wù)升級、發(fā)布過程中可以盡量無人值守。
• 多租戶：云上環(huán)境是天然有多租戶場景，各個租戶之間資源要做到嚴格隔離，相互之間不能有資源依賴、性能依賴。
• 可擴展性：面對客戶的新增需求，未來需要支持更多的任務(wù)類型，比如已經(jīng)有了MySQL、SqlServer的導(dǎo)入任務(wù)，在未來需要更多其他的數(shù)據(jù)庫導(dǎo)入，這種情況下，我們需要做到不修改任務(wù)調(diào)度框架，只需要修改插件即可完成。
• API化：除了以上的需求，我們還需要做到任務(wù)的API化管控，對于云上用戶，很多海外客戶是使用API、Terraform來對云上資源做管控，所以要做到任務(wù)管理的API化。?

可觀測平臺任務(wù)調(diào)度框架總體概覽

基于上述的調(diào)度設(shè)計目標，我們設(shè)計了可觀測性任務(wù)調(diào)度框架，如上圖所示，下面從下到上來介紹。

• 存儲層：主要包括任務(wù)的元數(shù)據(jù)存儲和任務(wù)運行時的狀態(tài)和快照存儲。任務(wù)的元數(shù)據(jù)主要包括任務(wù)類型，任務(wù)配置、任務(wù)調(diào)度信息，都存儲在了關(guān)系型數(shù)據(jù)庫；任務(wù)的運行狀態(tài)、快照存儲在了分布式文件系統(tǒng)中。
• 服務(wù)層：提供了任務(wù)調(diào)度的核心功能，主要包括任務(wù)調(diào)度和任務(wù)執(zhí)行兩部分，分別對應(yīng)前面講的任務(wù)編排和任務(wù)執(zhí)行模塊。任務(wù)調(diào)度主要針對三種任務(wù)類型進行調(diào)度，包括常駐任務(wù)、定時任務(wù)、按需任務(wù)。任務(wù)執(zhí)行支持多種執(zhí)行引擎，包括presto、restful接口、K8s引擎和內(nèi)部自研的ETL 2.0系統(tǒng)。
• 業(yè)務(wù)層：業(yè)務(wù)層包括用戶直接在控制臺可以使用到的功能，包括告警監(jiān)控、數(shù)據(jù)加工、重建索引、儀表盤訂閱、聚集加工、各類數(shù)據(jù)源導(dǎo)入、智能巡檢任務(wù)、和日志投遞等。
• 接入層：接入層使用Nginx和CGI對外提供服務(wù)，具有高可用，地域化部署等特性。
• API/SDK/Terraform/控制臺：在用戶側(cè)，可以使用控制臺對各類任務(wù)進行管理，對于不同的任務(wù)提供了定制化的界面和監(jiān)控，同時也可以使用API、SDK、Terraform對任務(wù)進行增刪改查。
• 任務(wù)可視化：在控制臺我們提供了任務(wù)執(zhí)行的可視化和任務(wù)監(jiān)控的可視化，通過控制臺用戶可以看出看到任務(wù)的執(zhí)行狀態(tài)、執(zhí)行歷史等，還可以開啟內(nèi)置告警對任務(wù)進行監(jiān)控。

任務(wù)調(diào)度框架設(shè)計要點

接下來從幾方面對任務(wù)調(diào)度框的設(shè)計要點進行介紹，主要包括以下幾方面來介紹：

• 異構(gòu)任務(wù)模型抽象
• 調(diào)度服務(wù)框架
• 大規(guī)模任務(wù)支持
• 服務(wù)高可用設(shè)計
• 穩(wěn)定性建設(shè)

任務(wù)模型抽象

接下來看下任務(wù)模型的抽象：

• 對于告警監(jiān)控、儀表盤訂閱、聚集加工等需要定時執(zhí)行的任務(wù)，抽象為定時任務(wù)，支持定時和Cron表達式設(shè)置。
• 對于數(shù)據(jù)加工、索引重建、數(shù)據(jù)導(dǎo)入等需要持續(xù)運行的任務(wù)，抽象為常駐任務(wù)，這類任務(wù)往往只需要運行一次，可以有也可以沒有結(jié)束狀態(tài)。
• 對于數(shù)據(jù)加工的預(yù)覽、儀表盤訂閱的預(yù)覽等功能，是在用戶點擊時才會需要創(chuàng)建一個任務(wù)來執(zhí)行，執(zhí)行完成即可退出，不需要保存任務(wù)狀態(tài)，這類任務(wù)抽象為DryRun類型，或者按需任務(wù)。

調(diào)度服務(wù)框架

服務(wù)基礎(chǔ)框架使用了Master-Worker架構(gòu)，Master負責(zé)任務(wù)的分派和Worker的管控，Master將數(shù)據(jù)抽象為若干Partitions，然后將這些Partitions分派給不同的Worker，實現(xiàn)了對任務(wù)的分而治之，在Worker執(zhí)行的過程中Master還也可以根據(jù)Worker的負載進行Partitions的動態(tài)遷移，同時在Worker重啟升級過程中，Master也會對Partition進行移出和移入；

任務(wù)的調(diào)度主要在Worker層來實現(xiàn)，每個Worker負責(zé)拉取對應(yīng)Partitions的任務(wù)，然后通過JobLoader對任務(wù)進行加載，注意：這里只會加載當(dāng)前Worker對應(yīng)Partitions的任務(wù)列表，然后Scheduler對任務(wù)進行調(diào)度的編排，這里會涉及常駐任務(wù)、定時任務(wù)、按需任務(wù)的調(diào)度，Scheduler將編排好的任務(wù)發(fā)送到JobExecutor進行執(zhí)行，JobExecutor在執(zhí)行的過程中需要實時對任務(wù)的狀態(tài)進行持久化保存到RedoLog中,在下次Worker升級重新啟動的過程中，需要從RedoLog中加載任務(wù)的狀態(tài)，從而保證任務(wù)狀態(tài)的準確性。

?大規(guī)模任務(wù)支持

通過任務(wù)服務(wù)框架的介紹，我們知道Partitions是Master與Worker溝通的橋梁，也是對大規(guī)模任務(wù)進行分而治之的介質(zhì)。如上圖所示，假設(shè)有N個任務(wù)，按照一定的哈希算法將N個任務(wù)映射到對應(yīng)的Partition，因為Worker關(guān)聯(lián)特定的Partition，這樣Worker就可以跟任務(wù)關(guān)聯(lián)起來，比如任務(wù)j1、j2對應(yīng)的partition是p1，而p1對應(yīng)的Worker是worker1，這樣j1、j2就可以在worker1上執(zhí)行。需要說明的如下：

• Worker與Partition的對應(yīng)關(guān)系并非一成不變，是一個動態(tài)的映射，在Worker重啟或者負載較高時，其對應(yīng)的Partition會遷移到其他的Worker上，所以Worker需要實現(xiàn)Partition的移入和移出操作。
• 任務(wù)數(shù)量增加的時候，因為有Partition這個中間層，只需要增加Worker的數(shù)量就可以滿足任務(wù)增長時的需求，達到水平擴展的目的。增加新Worker后，可以分擔(dān)更多的Partition
  

服務(wù)高可用設(shè)計

服務(wù)的高可用主要是服務(wù)的可用性時間，作為后臺服務(wù)肯定有重啟、升級的需求，高可用場景主要涉及到Partition遷移的處理，在Worker重啟、Worker負載較高時、Worker異常時，都會有Partition遷移的需求，在Partition遷移的過程中，任務(wù)也需要進行遷移，任務(wù)的遷移就涉及到狀態(tài)的保留，類似CPU上進程的航線文切換。

對于任務(wù)的切換，我們使用了RedoLog的方式來保存任務(wù)的狀態(tài)，一個任務(wù)可以被分為多個階段，對應(yīng)任務(wù)執(zhí)行的狀態(tài)機，在每個階段執(zhí)行時都對其進行內(nèi)存Checkpoint的更新和RedoLog的更新，RedoLog是持久化到之前提到的分布式文件系統(tǒng)中，使用高性能的Append的方式進行順序?qū)懭?，在Partition遷移到新的Worker后，新的Worker在對RedoLog進行加載，就可以完成任務(wù)狀態(tài)的恢復(fù)。

這里涉及一個優(yōu)化，RedoLog如果一直使用Append的方式進行寫入，勢必會造成RedoLog越來越膨脹，也會造成Worker加載Partition時速度變慢，對于這種情況，我們使用了Snapshot的方式，將過去一段時間的RedoLog進行合并，這樣只需要在加載Partition時，加載Snapshot和Snaphost之后的RedoLog就可以減少文件讀取的次數(shù)和開銷，提高加載速度。

穩(wěn)定性建設(shè)

穩(wěn)定性建設(shè)主要涉及以下幾方面內(nèi)容：

• 發(fā)布流程：
• 從編譯到發(fā)布全Web端白屏化操作，模板化發(fā)布，每個版本都可跟蹤、回退。
• 支持集群粒度、任務(wù)類型粒度的灰度控制，在發(fā)布時可以進行小范圍驗證，然后全量發(fā)布。
• 運維流程：
• 提供內(nèi)部運維API、Web端操作，對于異常Job進行修復(fù)、處理。減少人工介入運維。
• On-Call：
• 在服務(wù)內(nèi)部，我們開發(fā)了內(nèi)部巡檢功能，查找異常任務(wù)，例如某些任務(wù)啟動時間過長、停止時間過長都會打印異常日志，可以對異常日志進行跟蹤和監(jiān)控。
• 通過異常日志，使用日志服務(wù)告警進行監(jiān)控，出現(xiàn)問題可以及時通知運維人員。
• 任務(wù)監(jiān)控：
• 用戶側(cè)：在控制臺我們針對各類任務(wù)提供了監(jiān)控儀表盤和內(nèi)置告警配置。
• 服務(wù)側(cè)：在后臺，可以看到集群粒度任務(wù)的運行狀態(tài)，便于后臺運維人員進行服務(wù)的監(jiān)控。
• 同時，對于任務(wù)的執(zhí)行狀態(tài)和歷史都會存入特定的日志庫中，以便出現(xiàn)問題時進行追溯和診斷。

下面是一些服務(wù)側(cè)的部分大盤示例，展示的是告警的一些執(zhí)行狀態(tài)。

下面是用戶側(cè)的任務(wù)監(jiān)控狀態(tài)和告警的展示。

大規(guī)模應(yīng)用

在日志服務(wù)，任務(wù)的調(diào)度已經(jīng)有了大規(guī)模的應(yīng)用，下面是某地域單集群的任務(wù)的運行狀態(tài)，因為告警是定時執(zhí)行且使用場景廣泛，其單日調(diào)度次數(shù)達到了千萬級別，聚集加工在Rolling up場景中有很高場景的應(yīng)用，也達到了百萬級別；對于數(shù)據(jù)加工任務(wù)因為是常駐任務(wù)，調(diào)度頻率低于類似告警類的定時任務(wù)。

接下來以一個聚集加工為例來看下任務(wù)的調(diào)度場景。

典型任務(wù)：聚集加工

聚集加工是通過定時對一段時間的數(shù)據(jù)進行聚集查詢，然后將結(jié)果存入到另一個庫中，從而將高信息密度的信息進行提取，相對于原始數(shù)據(jù)具有降維、低存儲、高信息密度的特點。適合于定時分析、全局聚合的場景。

這里是一個聚集加工的執(zhí)行狀態(tài)示例，可以看到每個時間區(qū)間的執(zhí)行情況，包括處理行數(shù)、處理數(shù)據(jù)量、處理結(jié)果情況，對于執(zhí)行失敗的任務(wù)，還可以進行手動重試。

對于聚集加工并非定時執(zhí)行這么簡單的邏輯，在過程中需要處理超時、失敗、延遲等場景，接下來對每種場景進行一個簡單介紹。

?調(diào)度場景一：實例延遲執(zhí)行

無論實例是否延遲執(zhí)行，實例的調(diào)度時間都是根據(jù)調(diào)度規(guī)則預(yù)先生成的。雖然前面的實例發(fā)生延遲時，可能導(dǎo)致后面的實例也延遲執(zhí)行，但通過追趕執(zhí)行進度，可逐漸減少延遲，直到恢復(fù)準時運行。 

調(diào)度場景二：從某個歷史時間點開始執(zhí)行聚集加工作業(yè)

在當(dāng)前時間點創(chuàng)建聚集加工作業(yè)后，按照調(diào)度規(guī)則對歷史數(shù)據(jù)進行處理，從調(diào)度的開始時間創(chuàng)建補運行的實例，補運行的實例依次執(zhí)行直到追上數(shù)據(jù)處理進度后，再按照預(yù)定計劃執(zhí)行新實例。 

調(diào)度場景三：固定時間內(nèi)執(zhí)行聚集加工作業(yè)

如果需要對指定時間段的日志做調(diào)度，則可設(shè)置調(diào)度的時間范圍。如果設(shè)置了調(diào)度的結(jié)束時間，則最后一個實例（調(diào)度時間小于調(diào)度結(jié)束時間）執(zhí)行完成后，不再產(chǎn)生新的實例。

調(diào)度場景四：修改調(diào)度配置對生成實例的影響

修改調(diào)度配置后，下一個實例按照新配置生成。一般建議同步修改SQL時間窗口、調(diào)度頻率等配置，使得實例之間的SQL時間范圍可以連續(xù)。 

調(diào)度場景五：重試失敗的實例

• 自動重試
• 如果實例執(zhí)行失?。ɡ鐧?quán)限不足、源庫不存在、目標庫不存在、SQL語法不合法），系統(tǒng)支持自動重試
• 手動重試
• 當(dāng)重試次數(shù)超過您配置的最大重試次數(shù)或重試時間超過您配置的最大運行時間時，重試結(jié)束，該實例狀態(tài)被置為失敗，然后系統(tǒng)繼續(xù)執(zhí)行下一個實例。

展望

• 動態(tài)任務(wù)類型：增加對于動態(tài)任務(wù)類型的支持，例如更復(fù)雜的具有任務(wù)間依賴關(guān)系的任務(wù)調(diào)度。
• 多租戶優(yōu)化：目前對于任務(wù)使用簡單的Quota限制，未來對多租戶的QoS進行的進一步細化，以支持更大的Quota設(shè)置。
• API優(yōu)化、完善：目前的任務(wù)類型也在快速更新中，任務(wù)API的迭代速度還有些差距，需要增強任務(wù)API的優(yōu)化，達到增加一種任務(wù)類型，不需要修改或者少量更新API的目的。