作為國內(nèi)最大的電商平臺之一，蘇寧每天要處理數(shù)量巨大的數(shù)據(jù)。為了更快速高效地處理這些數(shù)據(jù)，蘇寧調(diào)度平臺采取了哪些措施呢?

本文是蘇寧大數(shù)據(jù)離線任務(wù)開發(fā)調(diào)度平臺實(shí)踐系列文章之上篇，詳解蘇寧的任務(wù)調(diào)度模塊。

 

 

1. 緒言

在上一篇文章《蘇寧大數(shù)據(jù)離線任務(wù)開發(fā)調(diào)度平臺實(shí)踐》中，從用戶交互功能、任務(wù)調(diào)度、任務(wù)執(zhí)行、任務(wù)運(yùn)維和對外服務(wù)等幾方面，宏觀層面進(jìn)行了理論和實(shí)踐的概述。

產(chǎn)品的用戶功能重點(diǎn)需要把握用戶實(shí)際的任務(wù)開發(fā)運(yùn)維需求，合理的規(guī)劃設(shè)計(jì)產(chǎn)品功能，在使用和運(yùn)維上便于用戶操作，降低用戶的開發(fā)使用成本。簡單的說就是主要保證用戶任務(wù)、任務(wù)流等關(guān)鍵元數(shù)據(jù)的配置信息的準(zhǔn)確性，以及任務(wù)狀態(tài)的查詢和干預(yù)能力，技術(shù)上實(shí)現(xiàn)不存在難點(diǎn)，在此不再詳細(xì)說明。

任務(wù)執(zhí)行模塊側(cè)重于任務(wù)被領(lǐng)取后，如何根據(jù)任務(wù)類型選擇不同的執(zhí)行器(Executer)提交任務(wù)執(zhí)行，并將任務(wù)的執(zhí)行狀態(tài)及時(shí)準(zhǔn)確的返回，由任務(wù)調(diào)度服務(wù)根據(jù)返回狀態(tài)做相應(yīng)的下一步處理，除此以外還涉及到任務(wù)資源加載、任務(wù)配置解析與轉(zhuǎn)換、自身健康狀態(tài)檢查與匯報(bào)、worker 進(jìn)程與任務(wù)子進(jìn)程通信、任務(wù)隔離、對外接口服務(wù)等，這塊將在后面一節(jié)再跟大家詳細(xì)分享。

任務(wù)運(yùn)維模塊主要關(guān)注平臺的自身穩(wěn)定性、健壯性等各個(gè)指標(biāo)的監(jiān)控與預(yù)警、平臺任務(wù)執(zhí)行異常的監(jiān)控、任務(wù)運(yùn)行診斷分析、動(dòng)態(tài)擴(kuò)縮容和應(yīng)急降級等方面，涉及到的內(nèi)容也很多，后續(xù)章節(jié)會(huì)陸續(xù)跟大家分享。

今天我們重點(diǎn)詳細(xì)闡述蘇寧大數(shù)據(jù)離線任務(wù)調(diào)度開發(fā)平臺的核心模塊—任務(wù)調(diào)度模塊的架構(gòu)設(shè)計(jì)以及開發(fā)實(shí)踐過程中的關(guān)鍵功能點(diǎn)。

2. 設(shè)計(jì)目標(biāo)與主要功能

調(diào)度模塊的核心目標(biāo)要保證任務(wù)能夠按照用戶配置的調(diào)度時(shí)間、依賴關(guān)系準(zhǔn)實(shí)時(shí)調(diào)度和執(zhí)行，同時(shí)也允許用戶根據(jù)實(shí)際需要隨時(shí)啟動(dòng)和停止任務(wù)調(diào)度，調(diào)整任務(wù)執(zhí)行計(jì)劃。所謂準(zhǔn)時(shí)實(shí)調(diào)度，指的是調(diào)度模塊會(huì)按照各個(gè)上線的任務(wù)流的調(diào)度時(shí)間生成調(diào)度執(zhí)行計(jì)劃，當(dāng)觸發(fā)時(shí)間到了，平臺會(huì)按照調(diào)度執(zhí)行計(jì)劃精確的生成任務(wù)流實(shí)例和任務(wù)實(shí)例。但是在任務(wù)執(zhí)行上，并不保證準(zhǔn)實(shí)時(shí)的分配機(jī)器執(zhí)行。實(shí)際上平臺以整體資源使用情況為最高原則，并按照一定的限流策略控制任務(wù)的執(zhí)行，比如：任務(wù)優(yōu)先級、任務(wù)組并發(fā)度、平臺任務(wù)并發(fā)數(shù)、任務(wù)特定執(zhí)行時(shí)間等因素。在保證平臺資源允許的情況下，盡量按時(shí)執(zhí)行任務(wù)。為了保障任務(wù)的實(shí)時(shí)性，必須保障任務(wù)資源的可用性和計(jì)劃可控性。

調(diào)度模塊的主要核心服務(wù)功能包括以下幾點(diǎn)：

服務(wù)重啟和任務(wù)狀態(tài)恢復(fù)功能

在調(diào)度服務(wù)重啟、主備切換后，系統(tǒng)狀態(tài)以及任務(wù)運(yùn)行狀態(tài)能否準(zhǔn)確的恢復(fù)。比如，主節(jié)點(diǎn)崩潰或維護(hù)期間，發(fā)生狀態(tài)變更的任務(wù)在主節(jié)點(diǎn)恢復(fù)以后，能否正確更新狀態(tài)等等。

Web API 接口服務(wù)

用戶通過 Web 控制后臺管理作業(yè)，而 Web 控制后臺與 Master 服務(wù)器之間的交互透過 Rest 服務(wù)來執(zhí)行，Rest 服務(wù)也可以給 Web 控制后臺以外的其它系統(tǒng)提供服務(wù)(用于支持外部系統(tǒng)和調(diào)度系統(tǒng)的對接)。另外為了便于監(jiān)控和調(diào)查分析調(diào)度異常和問題，提供 Master 內(nèi)存關(guān)鍵信息的查詢和人工干預(yù)的接口能力。

數(shù)據(jù)信息緩存服務(wù)

緩存上線任務(wù)流、任務(wù)、事件、系統(tǒng)配置、服務(wù)器的關(guān)鍵元數(shù)據(jù)信息，這些信息一般在任務(wù)流上線后不會(huì)經(jīng)常發(fā)生變更，沒必要實(shí)時(shí)從數(shù)據(jù)庫中讀取。并對外提供這些元數(shù)據(jù)信息的同步接口服務(wù)，保證緩存信息與數(shù)據(jù)庫的一致性。

緩存任務(wù)流實(shí)例、任務(wù)實(shí)例、事件實(shí)例等中間狀態(tài)信息，同時(shí)持久化到數(shù)據(jù)庫中。便于在任務(wù)狀態(tài)切換、任務(wù)依賴執(zhí)行快速找到對應(yīng)的運(yùn)行中的關(guān)鍵數(shù)據(jù)。并在任務(wù)實(shí)例數(shù)上升一定量級以后可以快速的從內(nèi)存中緩存的中間狀態(tài)數(shù)據(jù)完成依賴檢查和觸發(fā)執(zhí)行邏輯，降低對數(shù)據(jù)庫因?yàn)轭l繁訪問造成的壓力。

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

主要負(fù)責(zé)上線任務(wù)流的配置檢查、生成任務(wù)流執(zhí)行計(jì)劃、按照執(zhí)行計(jì)劃生成任務(wù)流與任務(wù)實(shí)例，生成任務(wù)實(shí)例狀態(tài)機(jī)和節(jié)點(diǎn)之間的依賴觸發(fā)關(guān)系。除了這些系統(tǒng)調(diào)用主要功能外，還提供人工干預(yù)任務(wù)執(zhí)行的服務(wù)功能，比如：任務(wù)流上下線、任務(wù)補(bǔ)數(shù)據(jù)、任務(wù)重跑、任務(wù)殺死、失敗重試等

任務(wù)狀態(tài)機(jī)管理任務(wù)流按照調(diào)度服務(wù)的執(zhí)行計(jì)劃會(huì)在每個(gè)調(diào)度周期內(nèi)生成需要執(zhí)行的任務(wù)流實(shí)例和任務(wù)實(shí)例信息，這些實(shí)例在調(diào)度過程中存在多種臨時(shí)狀態(tài)，并具備一定的生命周期。狀態(tài)切換的時(shí)候觸發(fā)一定的業(yè)務(wù)邏輯，比如：任務(wù)實(shí)例由新建狀態(tài)切換到待分配狀態(tài)，由待分配狀態(tài)切換到已分配狀態(tài)，由執(zhí)行中狀態(tài)切換到執(zhí)行結(jié)束狀態(tài)都可能需要完成一定的處理。這里我們采用了狀態(tài)機(jī)的管理機(jī)制來確保任務(wù)執(zhí)行狀態(tài)的持續(xù)性和完整性。

任務(wù)狀態(tài)分析服務(wù)

任務(wù)實(shí)例在調(diào)度過程中存在多種臨時(shí)狀態(tài)的切換，每次狀態(tài)切換必須成功才能保證狀態(tài)變化的持續(xù)性和完整性，從而保證任務(wù)實(shí)例從生成到結(jié)束的完整生命周期。如果狀態(tài)切換過程中發(fā)生意外或者長時(shí)間停滯在某個(gè)狀態(tài)不變，可能會(huì)導(dǎo)致調(diào)度異常和用戶使用恐慌，為了準(zhǔn)確及時(shí)的分析任務(wù)實(shí)例的狀態(tài)停滯原因，需要在任務(wù)狀態(tài)生成和切換的時(shí)候進(jìn)行檢查校驗(yàn)，把不能切換的原因及時(shí)記錄，便于分析問題。

任務(wù)狀態(tài)發(fā)布服務(wù)

平臺上的任務(wù)處理的是數(shù)據(jù)，數(shù)據(jù)處理的及時(shí)性和準(zhǔn)確性對業(yè)務(wù)系統(tǒng)是有極大的影響。而平臺的任務(wù)運(yùn)行狀態(tài)往往只會(huì)記錄在本平臺數(shù)據(jù)庫中，外部系統(tǒng)無法感知。在很多場景下，業(yè)務(wù)系統(tǒng)需要根據(jù)任務(wù)的執(zhí)行狀態(tài)來執(zhí)行自己的特定業(yè)務(wù)邏輯，通過傳統(tǒng)的任務(wù)狀態(tài)查詢接口又存在延遲性和性能問題，比如：任務(wù)狀態(tài)的變更，執(zhí)行時(shí)間長短會(huì)因?yàn)槎喾N因素而變得不確定;多個(gè)外部系統(tǒng)調(diào)用平臺接口可能會(huì)導(dǎo)致平臺自身壓力的不確定性�？梢栽谌蝿�(wù)實(shí)例生成和狀態(tài)切換的時(shí)候，將任務(wù)實(shí)例狀態(tài)按照用戶的配置要求，及時(shí)的發(fā)布出去，業(yè)務(wù)系統(tǒng)根據(jù)需要進(jìn)行訂閱，確保任務(wù)狀態(tài)更新的及時(shí)性，又降低對平臺的侵入和壓力。

任務(wù)分配與流控服務(wù)

主要負(fù)責(zé)滿足執(zhí)行條件的任務(wù)實(shí)例的分配，以及在任務(wù)執(zhí)行高峰、資源緊張的情況下如何智能有效的進(jìn)行相應(yīng)的流控。在以整體資源使用情況為最高原則，并按照一定的限流策略控制任務(wù)的執(zhí)行，比如：任務(wù)優(yōu)先級、任務(wù)組并發(fā)度、平臺任務(wù)并發(fā)數(shù)、任務(wù)特定執(zhí)行時(shí)間等因素。在保證平臺資源允許的情況下，盡量按時(shí)執(zhí)行任務(wù)。為了保障任務(wù)的實(shí)時(shí)性，必須保障任務(wù)資源的可用性和計(jì)劃可控性。

事件觸發(fā)服務(wù)

主要解決復(fù)雜業(yè)務(wù)場景里，跨任務(wù)流依賴、跨系統(tǒng)平臺依賴的調(diào)度執(zhí)行問題。比如：平臺內(nèi)部多個(gè)系統(tǒng)多個(gè)任務(wù)流之間的依賴調(diào)度，以及外部業(yè)務(wù)系統(tǒng)在某種條件下需要通知調(diào)度平臺執(zhí)行自己的任務(wù)。另外需要解決各種頻率之間的依賴關(guān)系，比如：天依賴天、天依賴小時(shí)、周月依賴天等.

主機(jī)健康監(jiān)控服務(wù)

負(fù)責(zé)管理可以執(zhí)行任務(wù)的機(jī)器資源, 并根據(jù)各機(jī)器的健康度合理的分配任務(wù)。主要包括：worker 機(jī)器的發(fā)現(xiàn)與管理、worker 機(jī)器的健康度評估、worker 檢活、主機(jī)黑白名單(加入黑名單的機(jī)器不能領(lǐng)取和執(zhí)行任務(wù))等

異步更新服務(wù)

平臺中存在大量的持久化操作，比如：任務(wù)實(shí)例的生成與狀態(tài)更新、事件的觸發(fā)實(shí)例生成、任務(wù)流的啟停狀態(tài)、任務(wù)運(yùn)行狀態(tài)原因分析等。有些持久化操作需要伴隨業(yè)務(wù)邏輯同步更新，確保操作的事務(wù)完整性，比如：任務(wù)流上下線、任務(wù)實(shí)例的狀態(tài)切換，必須保證內(nèi)存和數(shù)據(jù)庫一致性。有些操作則不要求高度一致性和實(shí)時(shí)性，甚至有些數(shù)據(jù)的更新錯(cuò)誤或者丟失也可以忽略不計(jì)。同步更新在確保事務(wù)、數(shù)據(jù)的完整和一致性外，帶來了平臺性能的一定下降。而異步更新服務(wù)可以提高平臺的運(yùn)行性能和并發(fā)能力，這些低有求的操作和數(shù)據(jù)同步服務(wù)就可以采用異步更新服務(wù)來完成。比如：任務(wù)運(yùn)行狀態(tài)停滯原因分析、任務(wù)狀態(tài)的對外發(fā)布等

3. 專業(yè)術(shù)語

蘇寧大數(shù)據(jù)離線任務(wù)開發(fā)調(diào)度平臺具有和業(yè)內(nèi)同款平臺產(chǎn)品的共性，也具備自己的特殊性和專業(yè)性。在理解和使用我們的平臺之前，需要了解平臺常見的專業(yè)術(shù)語，以免造成理解和使用上的分歧。

 

 

任務(wù)流實(shí)例的中間運(yùn)行狀態(tài)，主要包括：待調(diào)度、執(zhí)行中、執(zhí)行失敗、執(zhí)行成功。

任務(wù)實(shí)例的中間運(yùn)行狀態(tài)，主要包括：待調(diào)度、待分配、已分配、已領(lǐng)取、參數(shù)檢查錯(cuò)誤、資源準(zhǔn)備失敗、執(zhí)行中、殺死、執(zhí)行失敗、失敗重試、執(zhí)行成功、忽略失敗。

4.%20調(diào)度架構(gòu)設(shè)計(jì)

從系統(tǒng)架構(gòu)的角度出發(fā)，模塊化的設(shè)計(jì)有利于功能隔離，降低組件耦合度和單個(gè)組件的復(fù)雜度，提升系統(tǒng)的可拓展性，一定程度上有利于提升系統(tǒng)穩(wěn)定性，但帶來的問題是開發(fā)調(diào)試會(huì)更加困難，從這個(gè)角度來說又不利于穩(wěn)定性的改進(jìn)。所以各個(gè)功能模塊拆不拆，怎么拆往往是需要權(quán)衡考慮的。

平臺采用常見的主從式架構(gòu)，按照功能模塊劃分清晰，職責(zé)單一而不緊耦合，避免繁重復(fù)雜的業(yè)務(wù)耦合設(shè)計(jì)。調(diào)度模塊在系統(tǒng)架構(gòu)上分為%20web%20接口服務(wù)、重啟恢復(fù)服務(wù)、數(shù)據(jù)緩存服務(wù)、任務(wù)狀態(tài)發(fā)布服務(wù)、事件觸發(fā)服務(wù)、異步更新服務(wù)、任務(wù)調(diào)度服務(wù)、任務(wù)狀態(tài)機(jī)管理、任務(wù)分配服務(wù)、主機(jī)健康監(jiān)控服務(wù)以及任務(wù)實(shí)例狀態(tài)監(jiān)聽服務(wù)等十幾個(gè)主要服務(wù)功能。每個(gè)服務(wù)模塊負(fù)責(zé)的功能清晰，互相耦合度低，具有良好的擴(kuò)展性、穩(wěn)定性和容錯(cuò)性。調(diào)度的整體架構(gòu)設(shè)計(jì)如下圖所示。

 

 

調(diào)度模塊涉及到多種功能服務(wù)，這些功能服務(wù)內(nèi)部涉及到大量復(fù)雜的、交互的事件處理、狀態(tài)轉(zhuǎn)換，同時(shí)，這些事件調(diào)度和狀態(tài)轉(zhuǎn)換又對實(shí)時(shí)性和效率提出了極高的要求�？梢韵胍�，沒有一個(gè)規(guī)整的、通用型良好的調(diào)度器，平臺代碼無論是對讀者，還是對開發(fā)者，都將變成一場災(zāi)難，同時(shí)平臺的運(yùn)行效率也會(huì)變得無法忍受。統(tǒng)一的、設(shè)計(jì)良好的、通用的和共用的調(diào)度器，對于調(diào)度模塊不同組件的開發(fā)者來說是一種解脫，大大降低了平臺在事件調(diào)度、狀態(tài)轉(zhuǎn)換的底層出錯(cuò)的可能性，提高了代碼穩(wěn)定性和可讀性。

如何組裝、如何進(jìn)行有效的接口調(diào)用來支撐平臺百萬級的任務(wù)高效穩(wěn)定的執(zhí)行。在組裝設(shè)計(jì)上需要慎重選型。一般多服務(wù)調(diào)用分為函數(shù)調(diào)用和事件驅(qū)動(dòng)兩種模式。

相比于基于函數(shù)調(diào)用的編程模型，這種編程方式具有異步、并發(fā)等特點(diǎn)，更加高效，因此更加適合大型分布式系統(tǒng)。調(diào)度模塊的十幾個(gè)服務(wù)之間的大部分服務(wù)調(diào)用也基本是基于事件驅(qū)動(dòng)的編程模型進(jìn)行設(shè)計(jì)。開發(fā)實(shí)踐過程中，Hadoop 的核心調(diào)度器 AsyncDispatcher 的設(shè)計(jì)和實(shí)現(xiàn)同 Hadoop 狀態(tài)機(jī)一樣，這個(gè)通用調(diào)度器設(shè)計(jì)得十分通用，完美可擴(kuò)展可重用，我們在自己的項(xiàng)目中完全可以使用 Hadoop 的調(diào)度器實(shí)現(xiàn)我們自己的事件調(diào)度邏輯。

5. 服務(wù)重啟和任務(wù)狀態(tài)恢復(fù)

該服務(wù)主要是將調(diào)度模塊的所有服務(wù)組件進(jìn)行統(tǒng)一的注冊和管理，并按照平臺的業(yè)務(wù)邏輯順序進(jìn)行順序初始化和啟動(dòng)。并通過 HAService 服務(wù)往 ZK 搶注 Master 的服務(wù)器節(jié)點(diǎn)目錄，來完成主備 Master 的狀態(tài)切換。通過 RecoverService 服務(wù)完成 從數(shù)據(jù)庫中同步任務(wù)流、任務(wù)、事件等元數(shù)據(jù)信息和任務(wù)實(shí)例、事件實(shí)例等實(shí)例信息的內(nèi)存恢復(fù)操作。根據(jù)任務(wù)實(shí)例的數(shù)據(jù)庫和 zk 中保存的狀態(tài)進(jìn)行任務(wù)狀態(tài)機(jī)的創(chuàng)建和后續(xù)狀態(tài)的持續(xù)觸發(fā)操作。

5.1 Master Active 組合服務(wù)

如前文所述，調(diào)度模塊包括了十幾個(gè)核心功能服務(wù)，如何有效的管理和協(xié)同這些服務(wù)的起停順序、服務(wù)之間的調(diào)度關(guān)系，我們在 Java 設(shè)計(jì)模式上采用了組合模式 (Composite)，將這十幾個(gè)服務(wù)按照調(diào)度的業(yè)務(wù)關(guān)系進(jìn)行了組合包裝。

Hadoop Yarn 的 CompositeService 提供了一個(gè)比較好的組合封裝服務(wù)，包括服務(wù)的注冊(添加和移出)、服務(wù)的初始化和啟停操作，這些服務(wù)被順序的保存在一個(gè) List 對象中，各個(gè)服務(wù)會(huì)按照順序進(jìn)行逐個(gè)初始化和啟停。調(diào)度模塊的這十幾個(gè)關(guān)鍵服務(wù)統(tǒng)一打包在 MasterActiveService 中。

5.2 Master HA 高可用設(shè)計(jì)

高可用性 H.A.(High Availability)指的是通過盡量縮短因日常維護(hù)操作(計(jì)劃)和突發(fā)的系統(tǒng)崩潰(非計(jì)劃)所導(dǎo)致的停機(jī)時(shí)間，以提高系統(tǒng)和應(yīng)用的可用性。HA 系統(tǒng)是目前企業(yè)防止核心計(jì)算機(jī)系統(tǒng)因故障停機(jī)的最有效手段。

在 HA 方面，按照準(zhǔn)實(shí)時(shí)的設(shè)計(jì)目標(biāo)，平臺并沒有打算做到秒級別的崩潰恢復(fù)速度，系統(tǒng)崩潰時(shí)，只要能在分鐘級別范圍內(nèi)，重建系統(tǒng)狀態(tài)，就基本能滿足系統(tǒng)的設(shè)計(jì)目標(biāo)需求。

所以其實(shí)高可用性設(shè)計(jì)的重點(diǎn)，關(guān)鍵在于重建的過程中，系統(tǒng)的狀態(tài)能否準(zhǔn)確的恢復(fù)。比如，主節(jié)點(diǎn)崩潰或維護(hù)期間，發(fā)生狀態(tài)變更的任務(wù)在主節(jié)點(diǎn)恢復(fù)以后，能否正確更新狀態(tài)等等。而雙機(jī)熱備份無縫切換，目前來看實(shí)現(xiàn)難度較大(太多流程需要考慮原子操作，數(shù)據(jù)同步和避免競爭沖突)，實(shí)際需求也不強(qiáng)烈，通過監(jiān)控，自動(dòng)重啟和雙機(jī)冷備的方式來加快系統(tǒng)重建速度，基本也就足夠了。

本平臺在設(shè)計(jì)的時(shí)候采用了“主從方式”實(shí)現(xiàn) HA，主要設(shè)計(jì)要點(diǎn)：

(1) 一個(gè)狀態(tài)管理功能模塊

實(shí)現(xiàn)一個(gè) zkFailover，常駐在每一個(gè) Master 服務(wù)節(jié)點(diǎn)內(nèi)，每一個(gè) failover 負(fù)責(zé)監(jiān)聽自己所在節(jié)點(diǎn)，利用 zk 進(jìn)行狀態(tài)標(biāo)識。當(dāng)需要進(jìn)行狀態(tài)切換時(shí)，由 zkFailover 實(shí)現(xiàn)狀態(tài)切換，切換時(shí)需要注意防止 brain split 現(xiàn)象發(fā)生。

(2) 對外服務(wù)方式

除了 HAService 服務(wù)外，只能有一個(gè) Master 節(jié)點(diǎn)可以托管和執(zhí)行其他所有服務(wù)。另外一個(gè)節(jié)點(diǎn)只能啟動(dòng) HAService 監(jiān)聽主節(jié)點(diǎn)的狀態(tài)。只有主節(jié)點(diǎn)停止服務(wù)后，才能啟動(dòng)其他服務(wù)進(jìn)行工作。

5.3 Recover 任務(wù)狀態(tài)恢復(fù)設(shè)計(jì)在調(diào)度服務(wù)重啟、主備切換后，系統(tǒng)狀態(tài)以及任務(wù)運(yùn)行狀態(tài)能否準(zhǔn)確的恢復(fù)。比如，主節(jié)點(diǎn)崩潰或維護(hù)期間，發(fā)生狀態(tài)變更的任務(wù)在主節(jié)點(diǎn)恢復(fù)以后，能否正確更新狀態(tài)等等是一個(gè)任務(wù)調(diào)度平臺的重要功能和考核指標(biāo)。

Recover 不僅需要恢復(fù)各種實(shí)例信息的元數(shù)據(jù)信息和狀態(tài)信息，確保每個(gè)任務(wù)實(shí)例狀態(tài)切換的連續(xù)性、完整性和正確性，還要保證每個(gè)任務(wù)流內(nèi)部各個(gè)節(jié)點(diǎn)之間按照依賴關(guān)系及時(shí)的觸發(fā)和正確執(zhí)行。在某些場景下， 還需要對因?yàn)檎{(diào)度服務(wù)停止期間遺漏的任務(wù)流和任務(wù)實(shí)例進(jìn)行補(bǔ)償。

第一步完成任務(wù)配置相關(guān)的元數(shù)據(jù)信息的恢復(fù)。

即從數(shù)據(jù)庫中同步必要的元數(shù)據(jù)信息到調(diào)度內(nèi)存中。元數(shù)據(jù)信息在數(shù)據(jù)庫中不是存放了一份，為什么還要從數(shù)據(jù)庫中同步一份到調(diào)度的內(nèi)存中呢?在任務(wù)量很少的情況下每次讀寫數(shù)據(jù)庫不會(huì)對數(shù)據(jù)庫造成壓力。但是在任務(wù)量上升，任務(wù)實(shí)例的生成量和狀態(tài)切換的量成幾何級上升，隨著對數(shù)據(jù)庫的讀寫 TPS 也會(huì)上升。這樣一方面可能會(huì)造成數(shù)據(jù)庫的壓力偏大，另一方面如果數(shù)據(jù)庫服務(wù)不穩(wěn)定、網(wǎng)絡(luò)抖動(dòng)等外部因素而導(dǎo)致調(diào)度服務(wù)卡住。

在大多數(shù)情況下，任務(wù)流一旦上線后不會(huì)輕易發(fā)生變更。如果有部分變動(dòng)，可以通過 Master 的 web 接口同步內(nèi)存和數(shù)據(jù)庫的配置信息。為了保證狀態(tài)的一致統(tǒng)一，和任務(wù)相關(guān)的信息變更，無論是用戶發(fā)起的作業(yè)配置修改，還是執(zhí)行器反饋的作業(yè)狀態(tài)變更，都會(huì)提交給 Master 節(jié)點(diǎn)同步寫入到數(shù)據(jù)庫。具體參考下圖。

 

 

第二步完成實(shí)例信息和任務(wù)狀態(tài)的恢復(fù)。

實(shí)例信息的恢復(fù)主要包括：任務(wù)流實(shí)例、任務(wù)實(shí)例、事件實(shí)例的狀態(tài)恢復(fù)，已經(jīng)結(jié)束的任務(wù)流實(shí)例信息不作為恢復(fù)的對象。這一步不僅僅的單純同步實(shí)例的信息到調(diào)度內(nèi)存里，更重要的是要恢復(fù)任務(wù)實(shí)例的狀態(tài)，確保任務(wù)執(zhí)行按照計(jì)劃和依賴關(guān)系正確的執(zhí)行下去。任務(wù)流實(shí)例是按照任務(wù)流的執(zhí)行計(jì)劃不斷生成的運(yùn)行個(gè)體。當(dāng)重啟掃描數(shù)據(jù)中“未執(zhí)行結(jié)束”的任務(wù)流實(shí)例時(shí)，可能會(huì)存在大量的實(shí)例個(gè)體，執(zhí)行恢復(fù)的時(shí)候，智能根據(jù)“未執(zhí)行結(jié)束”的任務(wù)流實(shí)例個(gè)數(shù)啟動(dòng)一定數(shù)量的線程，按照任務(wù)流實(shí)例進(jìn)行切分，進(jìn)行批量恢復(fù)。

第三步補(bǔ)償丟失的任務(wù)實(shí)例批次

Master 調(diào)度重啟或者服務(wù)器宕機(jī)等因素造成任務(wù)調(diào)度計(jì)劃被打斷，再次恢復(fù)后需要對服務(wù)終止期間的丟失的任務(wù)實(shí)例進(jìn)行補(bǔ)償，否則會(huì)造成某些任務(wù)執(zhí)行計(jì)劃被錯(cuò)過而沒有得到調(diào)度執(zhí)行，引發(fā)數(shù)據(jù)故障。根據(jù)故障恢復(fù)的時(shí)間長短，結(jié)合每個(gè)頻率的任務(wù)做出不同的補(bǔ)償措施。下表是根據(jù)不同頻率類型按照對應(yīng)策略進(jìn)行補(bǔ)償。

 

 

對于一些復(fù)雜的業(yè)務(wù)場景的任務(wù)，也不是必須要把所有遺漏的批次都補(bǔ)償完畢，可以適當(dāng)補(bǔ)償一些遺漏批次，其他遺漏批次在服務(wù)重啟后人工補(bǔ)償。如果把歷史遺漏批次都補(bǔ)償，可能會(huì)因?yàn)檠a(bǔ)償?shù)膶?shí)例數(shù)過多而導(dǎo)致當(dāng)前批次被延后執(zhí)行。

6.Web API 接口服務(wù)

用戶通過 Web 控制后臺管理作業(yè)，而 Web 控制后臺與 Master 服務(wù)器之間的交互透過 Rest 服務(wù)來執(zhí)行，Rest 服務(wù)也可以給 Web 控制后臺以外的其它系統(tǒng)提供服務(wù)(用于支持外部系統(tǒng)和調(diào)度系統(tǒng)的對接)。另外為了便于監(jiān)控和調(diào)查分析調(diào)度異常和問題，提供 Master 內(nèi)存關(guān)鍵信息的查詢和人工干預(yù)的接口能力。

考慮到調(diào)度模塊的代碼部署不依賴外部容器，比如：Tomcat、JBoss 等，又要對外提供 Web 接口服務(wù)，因此在技術(shù)選型上需要注意這一點(diǎn)。目前市場上流行的 SpringBoot、內(nèi)嵌 Jettty 等其他 Servlet 容器方案都可以解決這個(gè)問題。我們的平臺使用的架構(gòu)是 Jersey+Guice+Jetty+ Mybatis，jersey 作為 Rest 服務(wù)框架，Guice 作為 DI 框架，使用內(nèi)嵌 Jetty 作為應(yīng)用容器，Mybatis 負(fù)責(zé)數(shù)據(jù)庫的持久化操作，并舍棄 web.xml 配置，這樣使得開發(fā)和部署十分輕量和簡單。

下圖是調(diào)度模塊里各個(gè)服務(wù)、容器、上下文之間的訪問交互圖。

 

 

Master 上下文承載了配置文件、注冊服務(wù)的查找與發(fā)現(xiàn)、元數(shù)據(jù)和實(shí)例數(shù)據(jù)信息以及各個(gè)服務(wù)的調(diào)用轉(zhuǎn)發(fā)器(Dispatcher)。其他服務(wù)組件通過 Master 上下文可以很方便的獲取系統(tǒng)配置信息，調(diào)用其他組件接口。Guice 框架目前主要托管了數(shù)據(jù)庫相關(guān)操作類以及 web 服務(wù)接口類，被托管的服務(wù)類以單例的形式保存。整個(gè)調(diào)度模塊內(nèi)嵌了 Jetty 容器，部署和啟動(dòng)了 WebServer 服務(wù)，提供外部與 Master 內(nèi)部服務(wù)的交互入口。

7. 后續(xù)

上述文章講述了調(diào)度模塊的架構(gòu)設(shè)計(jì)、恢復(fù)和 web 服務(wù)，后續(xù)文章會(huì)接著講述調(diào)度服務(wù)的設(shè)計(jì)細(xì)節(jié)。調(diào)度服務(wù)是整個(gè)調(diào)度模塊非常核心的服務(wù)組件，涉及到任務(wù)流上下線、任務(wù)狀態(tài)機(jī)管理、任務(wù)重跑補(bǔ)數(shù)據(jù)等運(yùn)維操作，限于篇幅和時(shí)間問題，本次的調(diào)度模塊的分享先寫這么多，后續(xù)會(huì)陸續(xù)對其他服務(wù)組件進(jìn)行詳細(xì)闡述，敬請期待。

作 者桑強(qiáng)：蘇寧易購 IT 總部大數(shù)據(jù)平臺研發(fā)中心離線計(jì)算工具研發(fā)部經(jīng)理。10 年軟件行業(yè)從業(yè)背景，13 年開始接觸大數(shù)據(jù)，有著 5 年多的大數(shù)據(jù)應(yīng)用和平臺開發(fā)經(jīng)驗(yàn)�，F(xiàn)在負(fù)責(zé)蘇寧大數(shù)據(jù)基礎(chǔ)工具平臺的研發(fā)工作，主要包括離線計(jì)算工具、實(shí)時(shí)計(jì)算工具、數(shù)據(jù)資產(chǎn)與質(zhì)量平臺的架構(gòu)、研發(fā)和項(xiàng)目管理等工作。在對接大數(shù)據(jù)底層和大數(shù)據(jù)業(yè)務(wù)線之間，如何做好平臺工具化，降低用戶使用難度，支撐大數(shù)據(jù)應(yīng)用的實(shí)踐和研發(fā)上有著豐富的研發(fā)經(jīng)驗(yàn)。

標(biāo)簽： isp 大數(shù)據(jù) 大數(shù)據(jù)基礎(chǔ) 大數(shù)據(jù)平臺 大數(shù)據(jù)應(yīng)用 代碼 電商 電商平臺 服務(wù)器 開發(fā)者 數(shù)據(jù)庫 通信 網(wǎng)絡(luò)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。