蘇寧大數(shù)據(jù)平臺任務調度模塊架構設計

1、蘇寧大數(shù)據(jù)離線任務開發(fā)調度平臺實踐:任務調度模塊架構設計2019-02-01 08:00:00 375 收藏 2作為國內(nèi)最大的電商平臺之一，蘇寧每天要處理數(shù)量巨大的數(shù)據(jù)。為了更快速高效地處理這 些數(shù)據(jù)，蘇寧調度平臺采取了哪些措施呢本文是蘇寧大數(shù)據(jù)離線任務開發(fā)調度平臺實踐系列文章之上篇，詳解蘇寧的任務調度模塊。目錄1.緒言tl2設計目標與主要功能t23.專業(yè)術語t34調度架構設計t55.服務重啟和任務狀態(tài)恢復t6Master Active 組合服務t7Master HA高可用設計t7Recover任務狀態(tài)恢復設計t7API接口服務t97.后續(xù)tl01.緒言在上一篇文章蘇寧大數(shù)據(jù)離線任務開發(fā)調度平

2、臺實踐中，從用戶交互功能、任務調度、 任務執(zhí)行、任務運維和對外服務等幾方面，宏觀層面進行了理論和實踐的概述。產(chǎn)品的用戶功能重點需要把握用戶實際的任務開發(fā)運維需求，合理的規(guī)劃設計產(chǎn)品功能，在 使用和運維上便于用戶操作，降低用戶的開發(fā)使用成本。簡單的說就是主要保證用戶任務、 任務流等關鍵元數(shù)據(jù)的配置信息的準確性，以及任務狀態(tài)的查詢和干預能力，技術上實現(xiàn)不 存在難點，在此不再詳細說明。任務執(zhí)行模塊側重于任務被領取后，如何根據(jù)任務類型選擇不同的執(zhí)行器(Executer)提交 任務執(zhí)行，并將任務的執(zhí)行狀態(tài)及時準確的返回，由任務調度服務根據(jù)返回狀態(tài)做相應的下 一步處理，除此以外還涉及到任務資源加載、任務配

3、置解析與轉換、自身健康狀態(tài)檢查與匯 報、worker進程與任務子進程通信、任務隔離、對外接口服務等，這塊將在后面一節(jié)再跟 大家詳細分享。任務運維模塊主要關注平臺的自身穩(wěn)定性、健壯性等各個指標的監(jiān)控與預警、平臺任務執(zhí)行 異常的監(jiān)控、任務運行診斷分析、動態(tài)擴縮容和應急降級等方面，涉及到的內(nèi)容也很多，后 續(xù)章節(jié)會陸續(xù)跟大家分享。今天我們重點詳細闡述蘇寧大數(shù)據(jù)離線任務調度開發(fā)平臺的核心模塊一任務調度模塊的架 構設計以及開發(fā)實踐過程中的關鍵功能點。2設計目標與主要功能調度模塊的核心目標要保證任務能夠按照用戶配置的調度時間、依賴關系準實時調度和執(zhí)行, 同時也允許用戶根據(jù)實際需要隨時啟動和停止任務調度，調整

4、任務執(zhí)行計劃。所謂準時實調 度，指的是調度模塊會按照各個上線的任務流的調度時間生成調度執(zhí)行計劃，當觸發(fā)時間到 了，平臺會按照調度執(zhí)行計劃精確的生成任務流實例和任務實例。但是在任務執(zhí)行上，并不 保證準實時的分配機器執(zhí)行。實際上平臺以整體資源使用情況為最高原則，并按照一定的限 流策略控制任務的執(zhí)行，比如：任務優(yōu)先級、任務組并發(fā)度、平臺任務并發(fā)數(shù)、任務特定執(zhí) 行時間等因素。在保證平臺資源允許的情況下，盡量按時執(zhí)行任務。為了保障任務的實時性， 必須保障任務資源的可用性和計劃可控性。調度模塊的主要核心服務功能包括以下幾點：服務重啟和任務狀態(tài)恢復功能在調度服務重啟、主備切換后，系統(tǒng)狀態(tài)以及任務運行狀態(tài)能否

5、準確的恢復。比如，主節(jié)點 崩潰或維護期間，發(fā)生狀態(tài)變更的任務在主節(jié)點恢復以后，能否正確更新狀態(tài)等等。Web API接口服務用戶通過Web控制后臺管理作業(yè)，而Web控制后臺與Master服務器之間的交互透過Rest 服務來執(zhí)行，Rest服務也可以給Web控制后臺以外的其它系統(tǒng)提供服務(用于支持外部系 統(tǒng)和調度系統(tǒng)的對接)。另外為了便于監(jiān)控和調查分析調度異常和問題，提供Master內(nèi)存關 鍵信息的查詢和人工干預的接口能力。數(shù)據(jù)信息緩存服務緩存上線任務流、任務、事件、系統(tǒng)配置、服務器的關鍵元數(shù)據(jù)信息，這些信息一般在任務 流上線后不會經(jīng)常發(fā)生變更，沒必要實時從數(shù)據(jù)庫中讀取。并對外提供這些元數(shù)據(jù)信息的同

6、 步接口服務，保證緩存信息與數(shù)據(jù)庫的一致性。緩存任務流實例、任務實例、事件實例等中間狀態(tài)信息，同時持久化到數(shù)據(jù)庫中。便于在任 務狀態(tài)切換、任務依賴執(zhí)行快速找到對應的運行中的關鍵數(shù)據(jù)。并在任務實例數(shù)上升一定量 級以后可以快速的從內(nèi)存中緩存的中間狀態(tài)數(shù)據(jù)完成依賴檢查和觸發(fā)執(zhí)行邏輯，降低對數(shù)據(jù) 庫因為頻繁訪問造成的壓力。任務調度服務主要負責上線任務流的配置檢查、生成任務流執(zhí)行計劃、按照執(zhí)行計劃生成任務流與任務實 例，生成任務實例狀態(tài)機和節(jié)點之間的依賴觸發(fā)關系。除了這些系統(tǒng)調用主要功能外，還提 供人工干預任務執(zhí)行的服務功能，比如：任務流上下線、任務補數(shù)據(jù)、任務重跑、任務殺死、 失敗重試等任務狀態(tài)機管理

7、任務流按照調度服務的執(zhí)行計劃會在每個調度周期內(nèi)生成需要執(zhí)行的任務流實例和任務實 例信息，這些實例在調度過程中存在多種臨時狀態(tài)，并具備一定的生命周期。狀態(tài)切換的時 候觸發(fā)一定的業(yè)務邏輯，比如：任務實例由新建狀態(tài)切換到待分配狀態(tài)，由待分配狀態(tài)切換 到已分配狀態(tài)，由執(zhí)行中狀態(tài)切換到執(zhí)行結束狀態(tài)都可能需要完成一定的處理。這里我們釆 用了狀態(tài)機的管理機制來確保任務執(zhí)行狀態(tài)的持續(xù)性和完整性。任務狀態(tài)分析服務任務實例在調度過程中存在多種臨時狀態(tài)的切換，每次狀態(tài)切換必須成功才能保證狀態(tài)變化 的持續(xù)性和完整性，從而保證任務實例從生成到結束的完整生命周期。如果狀態(tài)切換過程中 發(fā)生意外或者長時間停滯在某個狀態(tài)不變，

8、可能會導致調度異常和用戶使用恐慌，為了準確 及時的分析任務實例的狀態(tài)停滯原因，需要在任務狀態(tài)生成和切換的時候進行檢查校驗，把 不能切換的原因及時記錄，便于分析問題。任務狀態(tài)發(fā)布服務平臺上的任務處理的是數(shù)據(jù)，數(shù)據(jù)處理的及時性和準確性對業(yè)務系統(tǒng)是有極大的影響。而平 臺的任務運行狀態(tài)往往只會記錄在本平臺數(shù)據(jù)庫中，外部系統(tǒng)無法感知。在很多場景下，業(yè) 務系統(tǒng)需要根據(jù)任務的執(zhí)行狀態(tài)來執(zhí)行自己的特定業(yè)務邏輯，通過傳統(tǒng)的任務狀態(tài)查詢接口 又存在延遲性和性能問題，比如：任務狀態(tài)的變更，執(zhí)行時間長短會因為多種因素而變得不 確定；多個外部系統(tǒng)調用平臺接口可能會導致平臺自身壓力的不確定性?？梢栽谌蝿諏嵗?成和狀態(tài)切

9、換的時候，將任務實例狀態(tài)按照用戶的配置要求，及時的發(fā)布出去，業(yè)務系統(tǒng)根 據(jù)需要進行訂閱，確保任務狀態(tài)更新的及時性，又降低對平臺的侵入和壓力。任務分配與流控服務主要負責滿足執(zhí)行條件的任務實例的分配，以及在任務執(zhí)行高峰、資源緊張的情況下如何智 能有效的進行相應的流控。在以整體資源使用情況為最高原則，并按照一定的限流策略控制 任務的執(zhí)行，比如：任務優(yōu)先級、任務組并發(fā)度、平臺任務并發(fā)數(shù)、任務特定執(zhí)行時間等因 素。在保證平臺資源允許的情況下，盡量按時執(zhí)行任務。為了保障任務的實時性，必須保障 任務資源的可用性和計劃可控性。事件觸發(fā)服務主要解決復雜業(yè)務場景里，跨任務流依賴、跨系統(tǒng)平臺依賴的調度執(zhí)行問題。比如

10、：平臺內(nèi) 部多個系統(tǒng)多個任務流之間的依賴調度，以及外部業(yè)務系統(tǒng)在某種條件下需要通知調度平臺 執(zhí)行自己的任務。另外需要解決各種頻率之間的依賴關系，比如：天依賴天、天依賴小時、 周月依賴天等.主機健康監(jiān)控服務負責管理可以執(zhí)行任務的機器資源，并根據(jù)各機器的健康度合理的分配任務。主要包括： worker機器的發(fā)現(xiàn)與管理、worker機器的健康度評估、worker檢活、主機黑白名單（加入 黑名單的機器不能領取和執(zhí)行任務）等異步更新服務平臺中存在大量的持久化操作，比如：任務實例的生成與狀態(tài)更新、事件的觸發(fā)實例生成、 任務流的啟停狀態(tài)、任齊運行狀態(tài)原因分析等。有些持久化操作需要伴隨業(yè)務邏輯同步更新, 確保操

11、作的事務完整性，比如：任務流上下線、任務實例的狀態(tài)切換，必須保證內(nèi)存和數(shù)據(jù) 庫一致性。有些操作則不要求高度一致性和實時性，甚至有些數(shù)據(jù)的更新錯誤或者丟失也可 以忽略不計。同步更新在確保事務、數(shù)據(jù)的完整和一致性外，帶來了平臺性能的一定下降。 而異步更新服務可以提高平臺的運行性能和并發(fā)能力，這些低有求的操作和數(shù)據(jù)同步服務就 可以采用異步更新服務來完成。比如：任務運行狀態(tài)停滯原因分析、任務狀態(tài)的對外發(fā)布等3.專業(yè)術語蘇寧大數(shù)據(jù)離線任務開發(fā)調度平臺具有和業(yè)內(nèi)同款平臺產(chǎn)品的共性，也具備自己的特殊性和 專業(yè)性。在理解和使用我們的平臺之前，需要了解平臺常見的專業(yè)術語，以免造成理解和使 用上的分歧。任務流實例

12、的中間運行狀態(tài)，主要包括：待調度、執(zhí)行中、執(zhí)行失敗、執(zhí)行成功。任務實例的中間運行狀態(tài)，主要包括：待調度、待分配、已分配、已領取、參數(shù)檢查錯誤、 資源準備失敗、執(zhí)行中、殺死、執(zhí)行失敗、失敗重試、執(zhí)行成功、忽略失敗。4調度架構設計）從系統(tǒng)架構的角度出發(fā)，模塊化的設計有利于功能隔離，降低組件耦合度和單個組件的復雜 度，提升系統(tǒng)的可拓展性，一定程度上有利于提升系統(tǒng)穩(wěn)定性，但帶來的問題是開發(fā)調試會 更加困難，從這個角度來說又不利于穩(wěn)定性的改進。所以各個功能模塊拆不拆，怎么拆往往 是需要權衡考慮的。平臺釆用常見的主從式架構，按照功能模塊劃分清晰，職責單一而不緊耦合，避免繁重復雜 的業(yè)務耦合設計。調度模塊在

13、系統(tǒng)架構上分為web接口服務、重啟恢復服務、數(shù)據(jù)緩存服務、 任務狀態(tài)發(fā)布服務、事件觸發(fā)服務、異步更新服務、任務調度服務、任務狀態(tài)機管理、任務 分配服務、主機健康監(jiān)控服務以及任務實例狀態(tài)監(jiān)聽服務等十幾個主要服務功能。每個服務 模塊負責的功能清晰，互相耦合度低，具有良好的擴展性、穩(wěn)定性和容錯性。調度的整體架 構設計如下圖所示。調度模塊涉及到多種功能服務，這些功能服務內(nèi)部涉及到大量復雜的、交互的事件處理、狀 態(tài)轉換，同時，這些事件調度和狀態(tài)轉換又對實時性和效率提出了極高的要求?？梢韵胍? 沒有一個規(guī)整的、通用型良好的調度器，平臺代碼無論是對讀者，還是對開發(fā)者，都將變成 一場災難，同時平臺的運行效率也

14、會變得無法忍受。統(tǒng)一的、設計良好的、通用的和共用的 調度器，對于調度模塊不同組件的開發(fā)者來說是一種解脫，大大降低了平臺在事件調度、狀 態(tài)轉換的底層出錯的可能性，提高了代碼穩(wěn)定性和可讀性。如何組裝、如何進行有效的接口調用來支撐平臺百萬級的任務高效穩(wěn)定的執(zhí)行。在組裝設計 上需要慎重選型。一般多服務調用分為函數(shù)調用和事件驅動兩種模式。相比于基于函數(shù)調用的編程模型，這種編程方式具有異步、并發(fā)等特點，更加高效，因此更 加適合大型分布式系統(tǒng)。調度模塊的十幾個服務之間的大部分服務調用也基本是基于事件驅 動的編程模型進行設計。開發(fā)實踐過程中，血doop的核心調度器AsyncDispatcher的設計 和實現(xiàn)同

15、Hadoop狀態(tài)機一樣，這個通用調度器設計得十分通用，完美可擴展可重用，我們 在自己的項目中完全可以使用Hadoop的調度器實現(xiàn)我們自己的事件調度邏輯。5.服務重啟和任箏狀態(tài)恢復該服務主要是將調度模塊的所有服務組件進行統(tǒng)一的注冊和管理，并按照平臺的業(yè)務邏輯順 序進行順序初始化和啟動。并通過HAService服務往ZK搶注Master的服務器節(jié)點目錄，來 完成主備Master的狀態(tài)切換。通過RecoverService服務完成從數(shù)據(jù)庫中同步任務流、任 務、事件等元數(shù)據(jù)信息和任務實例、事件實例等實例信息的內(nèi)存恢復操作。根據(jù)任務實例的 數(shù)據(jù)庫和zk中保存的狀態(tài)進行任務狀態(tài)機的創(chuàng)建和后續(xù)狀態(tài)的持續(xù)觸發(fā)

16、操作。Master Active組合服務如前文所述，調度模塊包括了十幾個核心功能服務，如何有效的管理和協(xié)同這些服務的起停 順序、服務之間的調度關系，我們在Java設計模式上采用了組合模式（Composite）,將這十 幾個服務按照調度的業(yè)務關系進行了組合包裝。Hadoop Yarn的CompositeService提供了 一個比較好的組合封裝服務，包括服務的注冊（添 加和移出）、服務的初始化和啟停操作，這些服務被順序的保存在一個List對象中，各個服 務會按照順序進行逐個初始化和啟停。調度模塊的這十幾個關鍵服務統(tǒng)一打包在 MasterActiveService 中。Master HA高可用設計

17、高可用性.（HighAvailability）指的是通過盡量縮短因日常維護操作（計劃）和突發(fā)的系 統(tǒng)崩潰（非計劃）所導致的停機時間，以提高系統(tǒng)和應用的可用性。HA系統(tǒng)是目前企業(yè)防 止核心計算機系統(tǒng)因故障停機的最有效手段。在HA方面，按照準實時的設計目標，平臺并沒有打算做到秒級別的崩潰恢復速度，系統(tǒng)崩 潰時，只要能在分鐘級別范圍內(nèi)，重建系統(tǒng)狀態(tài)，就基本能滿足系統(tǒng)的設計目標需求。所以其實高可用性設計的重點，關鍵在于重建的過程中，系統(tǒng)的狀態(tài)能否準確的恢復。比如， 主節(jié)點崩潰或維護期間，發(fā)生狀態(tài)變更的任務在主節(jié)點恢復以后，能否正確更新狀態(tài)等等。 而雙機熱備份無縫切換，目前來看實現(xiàn)難度較大(太多流程需要

18、考慮原子操作，數(shù)據(jù)同步和 避免競爭沖突)，實際需求也不強烈，通過監(jiān)控，自動重啟和雙機冷備的方式來加快系統(tǒng)重 建速度，基本也就足夠了。本平臺在設計的時候采用了 主從方式”實現(xiàn)HA,主要設計要點：(1) 一個狀態(tài)管理功能模塊實現(xiàn)一個zkFailover,常駐在每一個Master服務節(jié)點內(nèi)，每一個failover負責監(jiān)聽自己 所在節(jié)點，利用zk進行狀態(tài)標識。當需要進行狀態(tài)切換時，由zkFailover實現(xiàn)狀態(tài)切換, 切換時需要注意防止brain split現(xiàn)象發(fā)生。(2)對外服務方式除了 HAService服務外，只能有一個Master節(jié)點可以托管和執(zhí)行其他所有服務。另外一個 節(jié)點只能啟動HASer

19、vice監(jiān)聽主節(jié)點的狀態(tài)。只有主節(jié)點停止服務后，才能啟動其他服務進 行工作。Recover任務狀態(tài)恢復設計在調度服務重啟、主備切換后，系統(tǒng)狀態(tài)以及任務運行狀態(tài)能否準確的恢復。比如，主節(jié)點 崩潰或維護期間，發(fā)生狀態(tài)變更的任務在主節(jié)點恢復以后，能否正確更新狀態(tài)等等是一個任 務調度平臺的重要功能和考核指標。Recover不僅需要恢復各種實例信息的元數(shù)據(jù)信息和狀態(tài)信息，確保每個任務實例狀態(tài)切換 的連續(xù)性、完整性和正確性，還要保證每個任務流內(nèi)部各個節(jié)點之間按照依賴關系及時的觸 發(fā)和正確執(zhí)行。在某些場景下，還需要對因為調度服務停止期間遺漏的任務流和任務實例 進行補償。第一步完成任務配置相關的元數(shù)據(jù)信息的恢

20、復。即從數(shù)據(jù)庫中同步必要的元數(shù)據(jù)信息到調度內(nèi)存中。元數(shù)據(jù)信息在數(shù)據(jù)庫中不是存放了 一份, 為什么還要從數(shù)據(jù)庫中同步一份到調度的內(nèi)存中呢在任務量很少的情況下每次讀寫數(shù)據(jù)庫 不會對數(shù)據(jù)庫造成壓力。但是在任務量上升，任務實例的生成量和狀態(tài)切換的量成幾何級上 升，隨著對數(shù)據(jù)庫的讀寫TPS也會上升。這樣一方面可能會造成數(shù)據(jù)庫的壓力偏大，另一方 面如果數(shù)據(jù)庫服務不穩(wěn)定、網(wǎng)絡抖動等外部因素而導致調度服務卡住。在大多數(shù)情況下，任務流一旦上線后不會輕易發(fā)生變更。如果有部分變動，可以通過辰ster 的web接口同步內(nèi)存和數(shù)據(jù)庫的配置信息。為了保證狀態(tài)的一致統(tǒng)一，和任務相關的信息變 更，無論是用戶發(fā)起的作業(yè)配置修改

21、，還是執(zhí)行器反饋的作業(yè)狀態(tài)變更，都會提交給Master 節(jié)點同步寫入到數(shù)據(jù)庫。具體參考下圖。第二步完成實例信息和任務狀態(tài)的恢復。實例信息的恢復主要包括：任務流實例、任務實例、事件實例的狀態(tài)恢復，已經(jīng)結束的任務 流實例信息不作為恢復的對象。這一步不僅僅的單純同步實例的信息到調度內(nèi)存里，更重要 的是要恢復任務實例的狀態(tài)，確保任務執(zhí)行按照計劃和依賴關系正確的執(zhí)行下去。任務流實例是按照任務流的執(zhí)行計劃不斷生成的運行個體。當重啟掃描數(shù)據(jù)中未執(zhí)行結束” 的任務流實例時，可能會存在大量的實例個體，執(zhí)行恢復的時候，智能根據(jù)“未執(zhí)行結束” 的任務流實例個數(shù)啟動一定數(shù)量的線程，按照任務流實例進行切分，進行批量恢復

22、。第三步補償丟失的任務實例批次Master調度重啟或者服務器宕機等因素造成任務調度計劃被打斷，再次恢復后需要對服務 終止期間的丟失的任務實例進行補償，否則會造成某些任務執(zhí)行計劃被錯過而沒有得到調度 執(zhí)行，引發(fā)數(shù)據(jù)故障。）根據(jù)故障恢復的時間長短，結合每個頻率的任務做出不同的補償措施。下表是根據(jù)不同頻率 類型按照對應策略進行補償。對于一些復雜的業(yè)務場景的任務，也不是必須要把所有遺漏的批次都補償完畢，可以適當補 償一些遺漏批次，其他遺漏批次在服務重啟后人工補償。如果把歷史遺漏批次都補償，可能 會因為補償?shù)膶嵗龜?shù)過多而導致當前批次被延后執(zhí)行。API接口服務用戶通過Web控制后臺管理作業(yè)，而Web控制后臺與Master服務器之間的交互透過Rest 服務來執(zhí)行，Rest服務也可以給Web控制后臺以外的其它系統(tǒng)提供服務（用于支持外部系 統(tǒng)和調度系統(tǒng)的對接）。另外為了便于監(jiān)控和調查分析調度異常和問題，提供Master內(nèi)存關 鍵信息的查詢和人工干預的接口能力?？紤]到調度模塊的代碼部署不依賴外部容器，比如：Tomcat, JBoss等，又要對外提供Web 接口服務，因此在技術選型上需要注意這一點。目前市場上流行的SpringBoot.內(nèi)嵌Jettty 等其他Serv