يقلب Apache DolphinScheduler 3.x بنية النظام رأساً على عقب. يجب على الفرق التي لا تزال تستخدم الإصدار 1.3 إعادة هيكلة تخطيط العنقود (cluster layout) وإعادة كتابة مخطط قاعدة البيانات (database schema) قبل التمكن من الترقية. يختفي الـ single-node master القديم، ليحل محله نظام لامركزي يعتمد على الإضافات (plug-in-driven)، يقوم بجدولة المهام وتخزينها وتسجيلها بطريقة مختلفة.

لماذا تهم هذه القفزة

تمسك الإصدار 1.3 بـ master مركزي يتولى كل قرارات الجدولة ولا يوفر سوى اثني عشر نوعاً مدمجاً من المهام. أما الإصدار 3.x فيستبدل ذلك بـ microkernel يقوم بتحميل أنواع المهام ومحولات التخزين (storage adapters) كإضافات (plugins)، كما أنه يقضي على نقطة الفشل الواحدة (single point of failure) من خلال السماح للـ masters والـ workers بالتواصل عبر خدمة سجل (registry service). يحصل المشغلون (Operators) على قابلية للتوسع ومرونة أكبر؛ بينما يمكن للمطورين توسيع المجدول ببساطة عن طريق إضافة ملف JAR بدلاً من تعديل الكود الأساسي.

الإصلاح الهيكلي الشامل

  • نظام إضافات الـ Microkernel – أصبحت تعريفات المهام، ومعالجات الموارد (resource handlers)، وفحوصات الحالة المخصصة (custom health checks) تعيش الآن في وحدات (modules) منفصلة. يمكنك إضافة نوع مهمة جديد عن طريق وضع الإضافة الخاصة بها في الـ classpath وإعادة تشغيل العقد (nodes) المتأثرة.
  • التنسيق اللامركزي – يكتشف الـ masters والـ workers بعضهم البعض عبر سجل (registry). يمكن أن يكون السجل ZooKeeper (الافتراضي تاريخياً)، أو قاعدة بيانات علاقية مدعومة بـ JDBC، أو عنقود Etcd. اختر التقنية التي تتوافق مع مجموعتك التقنية (stack) الحالية.
  • كتالوج مهام موسع – نمت المهام المدمجة من 12 إلى أكثر من 30 مهمة، لتغطي أعباء العمل السحابية الأصلية (cloud-native workloads) ومسارات تعلم الآلة (machine-learning pipelines).
  • MasterServer مقابل WorkerServer – يتولى الـ MasterServer الآن تقسيم الـ DAG، وعمليات الإرسال، ومراقبة الحالة. بينما يعمل الـ WorkerServer كمحرك تنفيذ بحت يقوم أيضاً ببث السجلات (logs). هذا الفصل يوضح المسؤوليات ويسمح لك بتحديد حجم كل طبقة بشكل مستقل.
  • تحمل الأخطاء عبر الـ Watcher – يقوم الـ Watcher بمراقبة السجل بحثاً عن فشل العقد. عندما يسقط Master أو Worker، يقوم السجل بتفعيل عملية تجاوز الفشل (failover) تلقائياً.
  • نقل السجلات عبر gRPC – انتقلت عملية استرداد السجلات عن بُعد من بروتوكول يعتمد على Netty إلى gRPC، والذي يشير المصدر إلى أنه يوفر أداءً أفضل.

إعادة هيكلة قاعدة البيانات التي لا يمكنك تجاهلها

يعد الإصلاح الشامل للمخطط (schema) هو العائق الأكثر ملموسية لأي عملية ترقية:

جدول 1.3 جدول 3.x ما الذي تغير
t_ds_process_definition t_ds_workflow_definition تم تغيير اسم المصطلح “process” إلى “workflow” ليتوافق مع مفردات واجهة المستخدم (UI) والـ API.
t_ds_process_instance t_ds_workflow_instance نفس التحول الدلالي لسجلات وقت التشغيل (runtime records).

بالإضافة إلى إعادة التسمية، يقوم الإصدار 3.x باستخراج البيانات الوصفية للمهام (task metadata) التي كانت تعيش سابقاً داخل كتل JSON إلى جداول علاقية مخصصة، مما يجعل إدارة البيانات أكثر نظافة.

قائمة التحقق من الهجرة (Migration checklist)

  1. قم بعمل نسخة احتياطية لكل شيء – قم بتصدير نسخة كاملة (dump) من قاعدة بيانات 1.3 وانسخ دليل conf.
  2. قم بربط الجداول القديمة بالأسماء الجديدة – قم بتشغيل سكربت يعيد تسمية t_ds_process_definition إلى t_ds_workflow_definition و t_ds_process_instance إلى t_ds_workflow_instance. تحقق من قيود المفاتيح الخارجية (foreign-key constraints) بعد ذلك.
  3. قم بترحيل حقول مهام JSON – انسخ بيانات المهام المشفرة بتنسيق JSON إلى الجداول العلاقية الجديدة. اختبر عدداً قليلاً من الـ DAGs للتأكد من أن المجدول يقرأ التخطيط الجديد.
  4. اختر سجلاً (registry) – احتفظ بـ ZooKeeper إذا كنت تشغله بالفعل؛ وإلا فقم بإعداد سجل مدعوم بـ JDBC أو عنقود Etcd ووجه جميع العقد إلى العنوان الجديد.
  5. قم بنشر الإضافات – قم بتغليف أي أنواع مهام مخصصة استخدمتها في 1.3 كإضافات متوافقة مع 3.x وانشرها في كل MasterServer.
  6. ابدأ بنشر MasterServer أولاً – ابدأ مثيل (instance) MasterServer جديد يشير إلى قاعدة البيانات المهاجرة. تحقق من أنه يسرد سير العمل (workflows) الموجودة وأن لوحة معلومات الحالة لا تظهر أي أخطاء.
  7. أضف WorkerServers – قم بتشغيل WorkerServers واحداً تلو الآخر. راقب السجل للتأكد من نجاح عملية التسجيل وتأكد من تدفق السجلات عبر gRPC.
  8. قم بإجراء اختبارات الدخان (smoke tests) – قم بتشغيل عدد قليل من الـ DAGs منخفضة المخاطر التي تغطي أكثر أنواع المهام شيوعاً. تحقق من ظهور السجلات في واجهة المستخدم ومن انتشار تحديثات حالة المهام بشكل صحيح.
  9. راقب عملية تجاوز الفشل – قم بمحاكاة تعطل MasterServer وراقب الـ Watcher وهو يقوم بترقية خادم احتياطي (standby). تأكد من استمرار المهام قيد التنفيذ (in-flight tasks) دون الحاجة إلى إعادة تشغيل يدوية.

ما الذي قد يسبب لك المتاعب

نموذج الإضافات الجديد قوي، ولكنه يرفع مستوى الصعوبة فيما يتعلق بالتطوير المخصص.

الخلاصة: الانتقال من الإصدار 1.3 إلى 3.x ليس مجرد ترقية بسيطة للإصدار؛ بل يتطلب إعادة تسمية منسقة لقاعدة البيانات، وهجرة من JSON إلى النموذج العلائقي، وإعادة هيكلة لعنقودك (cluster) حول نموذج يعتمد على السجل (registry-driven) ويدعم الإضافات (plug-in-enabled). اتبع قائمة التحقق خطوة بخطوة، واختبر مبكراً، وستحصل على مجدول (scheduler) يتميز بالقدرة على التوسع (scales out)، والتعافي التلقائي، واستخدام نفس البروتوكول الذي تعتمده الخدمات السحابية الحديثة.