Apache DolphinScheduler 3.x stravolge l'architettura. I team che utilizzano ancora la versione 1.3 devono riconfigurare il layout del cluster e riscrivere lo schema del database prima di poter effettuare l'aggiornamento. Il vecchio master a nodo singolo scompare, sostituito da un sistema decentralizzato basato su plug-in che pianifica, memorizza e registra i job in modo differente.

Perché il salto è importante

La versione 1.3 si affidava a un master centralizzato che gestiva ogni decisione di pianificazione e offriva solo dodici tipi di task integrati. La 3.x sostituisce questo modello con un microkernel che carica i tipi di task e gli adattatori di archiviazione come plugin, eliminando il singolo punto di errore (single point of failure) permettendo a master e worker di comunicare tramite un servizio di registry. Gli operatori ottengono scalabilità e resilienza; gli sviluppatori possono estendere lo scheduler semplicemente aggiungendo un file JAR invece di modificare il codice core.

La revisione architettonica

  • Sistema di plug-in a microkernel – Le definizioni dei task, i gestori delle risorse e i controlli di salute (health check) personalizzati risiedono ora in moduli separati. Aggiungi un nuovo tipo di task inserendo il relativo plug-in nel classpath e riavviando i nodi interessati.
  • Coordinamento decentralizzato – Master e worker si scambiano informazioni tramite un registry. Il registry può essere ZooKeeper (il default storico), un database relazionale basato su JDBC o un cluster Etcd. Scegli la tecnologia più adatta al tuo stack esistente.
  • Catalogo task ampliato – I task integrati sono passati da 12 a oltre 30, coprendo carichi di lavoro cloud-native e pipeline di machine learning.
  • MasterServer vs WorkerServer – Il MasterServer ora gestisce la partizione dei DAG, l'invio e il monitoraggio dello stato di salute. Il WorkerServer funge da puro motore di esecuzione che gestisce anche lo streaming dei log. Questa separazione chiarisce le responsabilità e permette di dimensionare ogni livello indipendentemente.
  • Tolleranza ai guasti tramite Watcher – Il Watcher monitora il registry per rilevare guasti ai nodi. Quando un Master o un Worker cade, il registry avvia un failover automatico.
  • Trasporto log via gRPC – Il recupero dei log remoti è passato da un protocollo basato su Netty a gRPC, che secondo le fonti garantisce prestazioni migliori.

Refactoring del database che non puoi ignorare

La revisione dello schema è l'ostacolo più concreto per qualsiasi aggiornamento:

Tabella 1.3 Tabella 3.x Cosa è cambiato
t_ds_process_definition t_ds_workflow_definition Il termine "process" è stato rinominato in "workflow" per allinearsi al vocabolario dell'interfaccia utente e delle API.
t_ds_process_instance t_ds_workflow_instance Stesso cambiamento semantico per i record di runtime.

Oltre alla rinomina, la versione 3.x estrae i metadati dei task (che precedentemente risiedevano all'interno di blob JSON) in tabelle relazionali dedicate, rendendo la gestione dei dati più pulita.

Checklist per la migrazione

  1. Esegui il backup di tutto – Esporta il dump completo del database 1.3 e copia la directory conf.
  2. Mappa le vecchie tabelle ai nuovi nomi – Esegui uno script che rinomini t_ds_process_definition in t_ds_workflow_definition e t_ds_process_instance in t_ds_workflow_instance. Verifica successivamente i vincoli di chiave esterna (foreign-key).
  3. Migra i campi JSON dei task – Copia i dati dei task codificati in JSON nelle nuove tabelle relazionali. Testa alcuni DAG per confermare che lo scheduler legga correttamente il nuovo layout.
  4. Scegli un registry – Mantieni ZooKeeper se lo stai già utilizzando; altrimenti configura un registry basato su JDBC o un cluster Etcd e punta tutti i nodi al nuovo indirizzo.
  5. Distribuisci i plug-in – Impacchetta eventuali tipi di task personalizzati utilizzati nella 1.3 come plug-in compatibili con la 3.x e distribuiscili su ogni MasterServer.
  6. Distribuisci prima il MasterServer – Avvia una nuova istanza di MasterServer che punti al database migrato. Verifica che elenchi i workflow esistenti e che la dashboard di stato non mostri errori.
  7. Aggiungi i WorkerServer – Avvia i WorkerServer uno alla volta. Monitora il registry per confermare la registrazione avvenuta con successo e verifica che i log fluiscano tramite gRPC.
  8. Esegui dei test di fumo (smoke tests) – Avvia alcuni DAG a basso rischio che coprano i tipi di task più comuni. Controlla che i log appaiano nell'interfaccia utente e che gli aggiornamenti dello stato dei task si propaghino correttamente.
  9. Monitora il failover – Simula il crash di un MasterServer e osserva il Watcher che promuove un nodo in standby. Conferma che i task in esecuzione continuino senza necessità di riavvio manuale.

Possibili criticità

Il nuovo modello a plug-in è potente, ma alza l'asticella per lo sviluppo personalizzato.

In sintesi: Passare dalla versione 1.3 alla 3.x non è un semplice aggiornamento di versione; richiede una rinomina coordinata del database, una migrazione da JSON a relazionale e una riarchitettura del cluster attorno a un modello abilitato ai plug-in e basato su registro. Segui la checklist passo dopo passo, effettua test precoci e otterrai uno scheduler che scala orizzontalmente, si ripristina automaticamente e utilizza lo stesso protocollo dei moderni servizi cloud.