Apache DolphinScheduler 3.x thay đổi hoàn toàn kiến trúc của mình. Các đội ngũ vẫn đang sử dụng phiên bản 1.3 phải cấu trúc lại bố cục cụm (cluster) và viết lại lược đồ cơ sở dữ liệu (database schema) trước khi có thể nâng cấp. Master đơn nút cũ biến mất, được thay thế bằng một hệ thống phi tập trung dựa trên plug-in, giúp lập lịch, lưu trữ và ghi log các công việc theo cách khác.
Tại sao bước nhảy vọt này lại quan trọng
Phiên bản 1.3 bám sát mô hình master tập trung, nơi xử lý mọi quyết định lập lịch và chỉ cung cấp mười hai loại tác vụ (task types) tích hợp sẵn. 3.x thay thế mô hình đó bằng một microkernel cho phép tải các loại tác vụ và bộ điều hợp lưu trữ (storage adapters) dưới dạng plug-in, đồng thời loại bỏ điểm lỗi duy nhất (single point of failure) bằng cách cho phép các master và worker giao tiếp thông qua một dịch vụ registry. Người vận hành có được khả năng mở rộng và tính phục hồi; các nhà phát triển có thể mở rộng bộ lập lịch chỉ bằng cách thêm một tệp JAR thay vì phải can thiệp vào mã nguồn lõi.
Sự đại tu về kiến trúc
- Hệ thống plug-in microkernel – Các định nghĩa tác vụ, trình xử lý tài nguyên và kiểm tra sức khỏe tùy chỉnh hiện nằm trong các module riêng biệt. Thêm một loại tác vụ mới bằng cách đặt plug-in của nó vào classpath và khởi động lại các nút bị ảnh hưởng.
- Điều phối phi tập trung – Các master và worker tự tìm thấy nhau thông qua một registry. Registry có thể là ZooKeeper (mặc định trước đây), một cơ sở dữ liệu quan hệ dựa trên JDBC, hoặc một cụm Etcd. Hãy chọn công nghệ phù hợp với ngăn xếp (stack) hiện có của bạn.
- Danh mục tác vụ mở rộng – Các tác vụ tích hợp sẵn đã tăng từ 12 lên hơn 30, bao gồm các khối lượng công việc cloud-native và các luồng xử lý (pipelines) học máy.
- MasterServer so với WorkerServer – MasterServer hiện đảm nhận việc phân vùng DAG, gửi tác vụ và giám sát sức khỏe. WorkerServer đóng vai trò là một công cụ thực thi thuần túy, đồng thời thực hiện truyền luồng (stream) log. Sự phân tách này làm rõ trách nhiệm và cho phép bạn điều chỉnh quy mô cho từng lớp một cách độc lập.
- Khả năng chịu lỗi thông qua Watcher – Watcher theo dõi registry để phát hiện các lỗi nút. Khi một Master hoặc Worker gặp sự cố, registry sẽ kích hoạt quá trình chuyển vùng dự phòng (failover) tự động.
- Truyền tải log qua gRPC – Việc truy xuất log từ xa đã chuyển từ giao thức dựa trên Netty sang gRPC, điều mà nguồn tin cho biết sẽ mang lại hiệu suất tốt hơn.
Tái cấu trúc cơ sở dữ liệu mà bạn không thể bỏ qua
Việc đại tu lược đồ là rào cản cụ thể nhất đối với bất kỳ quá trình nâng cấp nào:
| Bảng 1.3 | Bảng 3.x | Thay đổi gì |
|---|---|---|
t_ds_process_definition |
t_ds_workflow_definition |
Thuật ngữ “process” đã được đổi tên thành “workflow” để phù hợp với từ vựng trên UI và API. |
t_ds_process_instance |
t_ds_workflow_instance |
Sự thay đổi ngữ nghĩa tương tự cho các bản ghi runtime. |
Ngoài việc đổi tên, phiên bản 3.x còn trích xuất siêu dữ liệu (metadata) của tác vụ – vốn trước đây nằm trong các khối JSON – vào các bảng quan hệ chuyên dụng, giúp việc quản lý dữ liệu trở nên gọn gàng hơn.
Danh sách kiểm tra di trú
- Sao lưu mọi thứ – Xuất bản sao lưu (dump) toàn bộ cơ sở dữ liệu 1.3 và sao chép thư mục
conf. - Ánh xạ các bảng cũ sang tên mới – Chạy một tập lệnh để đổi tên
t_ds_process_definitionthànht_ds_workflow_definitionvàt_ds_process_instancethànht_ds_workflow_instance. Sau đó, hãy xác minh các ràng buộc khóa ngoại. - Di trú các trường tác vụ JSON – Sao chép dữ liệu tác vụ được mã hóa JSON vào các bảng quan hệ mới. Kiểm tra một vài DAG để xác nhận bộ lập lịch đọc được bố cục mới.
- Chọn một registry – Giữ lại ZooKeeper nếu bạn đang chạy nó; nếu không, hãy thiết lập một registry dựa trên JDBC hoặc cụm Etcd và trỏ tất cả các nút đến địa chỉ mới.
- Triển khai các plug-in – Đóng gói bất kỳ loại tác vụ tùy chỉnh nào bạn đã sử dụng trong bản 1.3 thành các plug-in tương thích với bản 3.x và triển khai chúng tới từng MasterServer.
- Triển khai MasterServer trước – Khởi chạy một thực thể (instance) MasterServer mới trỏ tới cơ sở dữ liệu đã di trú. Xác minh rằng nó liệt kê được các workflow hiện có và bảng điều khiển sức khỏe (health dashboard) không hiển thị lỗi.
- Thêm các WorkerServer – Khởi động các WorkerServer lần lượt từng cái một. Theo dõi registry để đảm bảo việc đăng ký thành công và xác nhận rằng log được truyền qua gRPC.
- Chạy smoke test – Kích hoạt một vài DAG ít rủi ro bao gồm các loại tác vụ phổ biến nhất. Kiểm tra xem log có xuất hiện trên UI không và trạng thái tác vụ có được cập nhật chính xác hay không.
- Theo dõi quá trình failover – Mô phỏng sự cố sập MasterServer và quan sát Watcher chuyển đổi một node dự phòng (standby) lên thay thế. Xác nhận rằng các tác vụ đang chạy (in-flight tasks) tiếp tục mà không cần khởi động lại thủ công.
Những điều có thể gây khó khăn cho bạn
Mô hình plug-in mới rất mạnh mẽ, nhưng nó cũng đặt ra tiêu chuẩn cao hơn cho việc phát triển tùy chỉnh.
Tóm lại: Việc chuyển đổi từ 1.3 sang 3.x không chỉ đơn thuần là một bước nâng cấp phiên bản; nó đòi hỏi việc đổi tên cơ sở dữ liệu một cách có phối hợp, chuyển đổi từ JSON sang mô hình quan hệ, và tái cấu trúc cụm (cluster) của bạn xoay quanh một mô hình hỗ trợ plug-in và vận hành dựa trên registry. Hãy thực hiện theo danh sách kiểm tra từng bước một, kiểm thử sớm, và bạn sẽ có được một bộ lập lịch (scheduler) có khả năng mở rộng, tự động phục hồi và sử dụng cùng giao thức với các dịch vụ đám mây hiện đại.