Apache DolphinScheduler 3.x mengubah seni bina secara drastik. Pasukan yang masih menggunakan versi 1.3 perlu menyusun semula susun atur kluster dan menulis semula skema pangkalan data sebelum boleh menaik taraf. Master nod tunggal yang lama telah dihapuskan, digantikan dengan sistem terdesentralisasi berasaskan plug-in yang menjadualkan, menyimpan, dan merekod log tugasan secara berbeza.

Mengapa peralihan ini penting

Versi 1.3 bergantung kepada master berpusat yang mengendalikan setiap keputusan penjadualan dan hanya menawarkan dua belas jenis tugasan terbina dalam. 3.x menggantikannya dengan mikrokernal yang memuatkan jenis tugasan dan penyesuai storan sebagai plug-in, serta menghapuskan titik kegagalan tunggal (single point of failure) dengan membolehkan master dan worker berkomunikasi melalui perkhidmatan registry. Operator mendapat skalabiliti dan daya tahan; pembangun boleh memperluas penjadual hanya dengan memasukkan fail JAR dan bukannya mengubah suai kod teras.

Perombakan seni bina

  • Sistem plug-in mikrokernal – Definisi tugasan, pengendali sumber, dan semakan kesihatan tersuai kini berada dalam modul berasingan. Tambah jenis tugasan baharu dengan meletakkan plug-in pada classpath dan mulakan semula nod yang terlibat.
  • Penyelarasan terdesentralisasi – Master dan worker saling menemui melalui registry. Registry boleh berupa ZooKeeper (pilihan lalai sebelum ini), pangkalan data hubungan berasaskan JDBC, atau kluster Etcd. Pilih teknologi yang sesuai dengan stack sedia ada anda.
  • Katalog tugasan yang diperluas – Tugasan terbina dalam telah berkembang daripada 12 kepada lebih 30, merangkumi beban kerja cloud-native dan saluran paip pembelajaran mesin (machine-learning pipelines).
  • MasterServer vs WorkerServer – MasterServer kini mengendalikan pembahagian DAG, penghantaran, dan pemantauan kesihatan. WorkerServer bertindak sebagai enjin pelaksanaan tulen yang juga menyalurkan log. Pembahagian ini memperjelas tanggungjawab dan membolehkan anda menentukan saiz setiap lapisan secara bebas.
  • Toleransi kegagalan melalui Watcher – Watcher memantau registry untuk kegagalan nod. Apabila Master atau Worker terputus, registry akan mencetuskan failover automatik.
  • Penghantaran log gRPC – Pengambilan log jarak jauh telah berpindah daripada protokol berasaskan Netty kepada gRPC, yang menurut sumber memberikan prestasi yang lebih baik.

Refaktor pangkalan data yang tidak boleh diabaikan

Perombakan skema adalah penghalang paling nyata bagi sebarang naik taraf:

Jadual 1.3 Jadual 3.x Apa yang berubah
t_ds_process_definition t_ds_workflow_definition Istilah “process” telah ditukar kepada “workflow” untuk menyelaraskan dengan kosa kata UI dan API.
t_ds_process_instance t_ds_workflow_instance Peralihan semantik yang sama untuk rekod masa nyata (runtime).

Selain penamaan semula, 3.x mengekstrak metadata tugasan yang sebelum ini berada di dalam blob JSON ke dalam jadual hubungan khusus, menjadikan pengurusan data lebih kemas.

Senarai semak migrasi

  1. Sandarkan semuanya – Eksport dump pangkalan data 1.3 sepenuhnya dan salin direktori conf.
  2. Petakan jadual lama ke nama baharu – Jalankan skrip yang menamakan semula t_ds_process_definition kepada t_ds_workflow_definition dan t_ds_process_instance kepada t_ds_workflow_instance. Sahkan kekangan kunci asing (foreign-key constraints) selepas itu.
  3. Migrasi medan tugasan JSON – Salin data tugasan yang dikodkan JSON ke dalam jadual hubungan baharu. Uji beberapa DAG untuk mengesahkan penjadual membaca susun atur baharu tersebut.
  4. Pilih registry – Kekalkan ZooKeeper jika anda sudah menggunakannya; jika tidak, sediakan registry berasaskan JDBC atau kluster Etcd dan halakan semua nod ke alamat baharu.
  5. Pasang plug-in – Bungkus sebarang jenis tugasan tersuai yang anda gunakan dalam 1.3 sebagai plug-in yang serasi dengan 3.x dan pasangkannya pada setiap MasterServer.
  6. Lancarkan MasterServer terlebih dahulu – Mulakan instans MasterServer baharu yang menghala ke pangkalan data yang telah dimigrasi. Sahkan ia menyenaraikan aliran kerja (workflow) sedia ada dan papan pemuka kesihatan tidak menunjukkan sebarang ralat.
  7. Tambah WorkerServer – Jalankan WorkerServer satu demi satu. Pantau registry untuk pendaftaran yang berjaya dan sahkan bahawa log mengalir melalui gRPC.
  8. Jalankan ujian asap (smoke tests) – Picu beberapa DAG berisiko rendah yang merangkumi jenis tugasan paling biasa. Semak bahawa log muncul dalam UI dan kemas kini status tugasan tersebar dengan betul.
  9. Pantau failover – Simulasikan kegagalan MasterServer dan perhatikan Watcher menaik taraf (promote) pelayan sandaran (standby). Sahkan bahawa tugasan yang sedang berjalan (in-flight) diteruskan tanpa perlu dimulakan semula secara manual.

Apa yang mungkin menyulitkan anda

Model plug-in baharu ini sangat berkuasa, tetapi ia meningkatkan tahap kesukaran bagi pembangunan tersuai.

Kesimpulannya: Peralihan daripada 1.3 ke 3.x bukan sekadar peningkatan versi yang mudah; ia memerlukan penamaan semula pangkalan data yang terkoordinasi, migrasi JSON-ke-relational, dan seni bina semula kluster anda berasaskan model dipacu-pendaftar yang menyokong plug-in. Ikuti senarai semak langkah demi langkah, lakukan ujian lebih awal, dan anda akan memperoleh penjadual yang boleh diskalakan, pulih secara automatik, serta menggunakan protokol yang sama seperti perkhidmatan awan moden.