Tugas HTTP dijalankan melalui protokol HTTP atau HTTPS, sehingga MSE XXL-JOB dapat menjadwalkan workload yang ditulis dalam bahasa apa pun di platform apa pun tanpa perlu mengintegrasikan software development kit (SDK). Bergantung pada lokasi eksekusi workload, MSE XXL-JOB mengakses layanan target baik melalui Kubernetes Service maupun melalui gateway.
Mengapa menggunakan tugas HTTP
Beberapa alasan untuk menjadwalkan workload Anda sebagai tugas HTTP:
Workload yang sudah ada — Hubungkan layanan yang sudah ada tanpa perlu memodifikasinya.
Berbagai Bahasa — Gunakan satu metode koneksi untuk tugas yang diimplementasikan dalam berbagai bahasa.
Agen AI dan alur kerja — Jadwalkan tugas agen AI dan alur kerja melalui HTTP.
Metode koneksi tugas HTTP
MSE XXL-JOB mendukung dua metode koneksi untuk tugas HTTP, yang menentukan apakah pusat penjadwalan MSE XXL-JOB mengarahkan permintaan langsung ke instans backend individual atau mendelegasikan perutean ke gateway.
Lingkungan Kubernetes — Bind Service di kluster Kubernetes ke aplikasi. Pilih metode ini untuk layanan terkontainerisasi yang jumlah instansnya berubah seiring skalabilitas workload.
Lingkungan non-Kubernetes — Bind nama domain HTTP ke aplikasi dan akses layanan melalui gateway. Pilih metode ini untuk layanan yang berjalan di luar Kubernetes atau di belakang sistem gateway yang sudah ada.
Anda memilih metode koneksi pada tingkat aplikasi, sehingga semua tugas dalam aplikasi tersebut menggunakan metode yang sama. Tinjau perbandingan berikut sebelum membuat aplikasi dan tugas.
Perbandingan metode koneksi
Tabel berikut membandingkan dua metode koneksi untuk tugas HTTP.
| Dimensi | Lingkungan Kubernetes: koneksi melalui Service | Lingkungan non-Kubernetes: koneksi melalui gateway |
| Mode koneksi | Mengakses pod backend secara langsung berdasarkan Kubernetes Service. | Meneruskan permintaan melalui gateway terpadu dan meneruskannya ke layanan dengan nama domain target. |
| Mekanisme penemuan layanan | Secara aktif mendengarkan perubahan endpoint dan memelihara daftar pod secara dinamis. | Tidak mendukung penemuan layanan dan tidak mengetahui status node backend. |
| Granularitas target eksekusi | Dapat menjadwalkan tugas ke alamat IP dan port pod tertentu untuk mengimplementasikan panggilan langsung titik-ke-titik. | Permintaan dikirim ke gateway, yang melakukan load balancing internal dan perutean instans. Pusat penjadwalan tidak mengetahui node backend aktual. |
| Kebijakan perutean | Mendukung kebijakan perutean single-instance dan broadcast sharding. | Tidak mendukung kebijakan perutean dan menggunakan kebijakan perutean gateway. |
| Broadcast sharding | Secara native mendukung mode broadcast sharding, yang cocok untuk skenario pemrosesan batch paralel berskala besar. | Tidak mendukung broadcast sharding. Semua tugas dijalankan di satu titik, dan pemrosesan kolaboratif lintas node tidak dapat diimplementasikan. |
| Manajemen status kesehatan | Menyinkronkan status endpoint secara real time dan secara otomatis menghapus pod yang belum siap atau telah dihentikan. | Mengandalkan Anda untuk memelihara ketersediaan nama domain secara manual. |
| Ekstensibilitas dan fleksibilitas | Beradaptasi dengan lingkungan cloud-native dan mendukung skenario seperti elastic scaling dan rolling deployment. | Lebih cocok untuk arsitektur tradisional atau integrasi sistem heterogen. Menyediakan kompatibilitas kuat dan mudah diintegrasikan ke sistem gateway yang sudah ada. |
| Skenario Umum | Layanan mikro terkontainerisasi, eksekusi pekerjaan batch ter-shard, dan tugas terjadwal dengan konkurensi tinggi. | Lingkungan non-kontainer, arsitektur deployment hibrida, koneksi sistem warisan, dan penjadwalan API tingkat perusahaan yang memerlukan governance gateway terpadu. |
Broadcast sharding memerlukan metode koneksi Kubernetes. Jika Anda terhubung melalui gateway, semua tugas dijalankan di satu titik, dan Anda bertanggung jawab memelihara ketersediaan nama domain yang di-bind.
Lingkungan Kubernetes: koneksi melalui Service
Di lingkungan Kubernetes, Anda bind Service di kluster Kubernetes ke aplikasi agar tugas HTTP dapat dijadwalkan. Setelah binding selesai, semua tugas dalam aplikasi berbagi sumber daya pod yang terkait dengan Service tersebut.
Setelah Anda mengonfigurasi Kubernetes Service dalam aplikasi, pusat penjadwalan secara otomatis memperoleh informasi tentang pod terkait. Saat mengonfigurasi tugas, Anda hanya perlu menentukan path permintaan HTTP, bukan alamat pod spesifik. Ketika tugas dipicu sesuai jadwal, pusat penjadwalan mengirim permintaan HTTP ke pod target berdasarkan kebijakan perutean yang telah ditentukan. Hasil eksekusi tugas direkam dan didorong ke Simple Log Service (SLS) untuk dilihat dan dianalisis nanti.
Pusat penjadwalan menggunakan thread penemuan layanan untuk mendeteksi secara berkala event scale-out dan scale-in pod serta status abnormal, lalu secara otomatis menyinkronkan informasi pod terbaru ke manajer pod. Hal ini mencapai pemantauan dinamis dan pemeliharaan status kluster pod.
Manajer pod memelihara alamat jaringan dan status kesehatan pod serta mendukung berbagai kebijakan perutean tugas. Selain perutean single-instance, tersedia juga mode perutean broadcast sharding. Ketika tugas dipicu sekali dalam mode ini, permintaan disiarkan ke semua pod di bawah layanan target. Pusat penjadwalan menyuntikkan konteks sharding—termasuk indeks shard dan jumlah total shard—ke dalam header permintaan HTTP. Hal ini memungkinkan Anda mengimplementasikan kontrol logika detail halus dan partisi data selama eksekusi tugas. Untuk nama header yang disuntikkan, lihat Header permintaan tugas HTTP.
Lingkungan non-Kubernetes: koneksi melalui gateway
Di lingkungan non-Kubernetes, Anda bind nama domain HTTP target ke aplikasi untuk mencapai manajemen nama domain terpadu dan kontrol kebijakan perutean pada tingkat aplikasi. Setelah beberapa nama domain di-bind ke aplikasi, semua tugas dalam aplikasi berbagi konfigurasi nama domain tersebut.
Pusat penjadwalan memelihara informasi nama domain melalui manajer nama domain. Saat membuat tugas, Anda hanya mengonfigurasi path permintaan, bukan nama domain. Ketika tugas dipicu, pusat penjadwalan secara otomatis memilih nama domain yang sesuai berdasarkan kebijakan perutean yang telah ditentukan dan mengirim permintaan ke gateway. Setelah gateway menyelesaikan otentikasi, pengendalian traffic, dan load balancing, permintaan diteruskan ke layanan target. Hasil eksekusi akhirnya disinkronkan ke Simple Log Service (SLS).
Manajer nama domain memelihara informasi nama domain. Fitur ini mendukung penambahan, penghapusan, dan modifikasi nama domain serta konfigurasi perutean berbasis tag. Fitur ini dapat mendistribusikan traffic berdasarkan tag bisnis dan mendukung berbagai kebijakan perutean untuk memenuhi kebutuhan penjadwalan dan load balancing yang berbeda.
Prasyarat
Versi engine instans Anda adalah 2.3.0 atau lebih baru. Jika versi engine saat ini lebih lama dari 2.3.0, lakukan upgrade ke versi 2.3.0 atau lebih baru.
Instans akan restart selama proses upgrade.
Prosedur koneksi
Masuk ke Konsol MSE XXL-JOB dan pilih wilayah di bilah menu atas.
Di panel navigasi kiri, pilih Task Scheduling > XXL-JOB Version.
Klik instans target. Di panel navigasi kiri, klik Application Management, lalu klik Create Application. Atur tipe aplikasi menjadi HTTP application dan klik OK.
Hubungkan executor HTTP. Untuk petunjuknya, lihat Connect an HTTP application to an executor.
Di panel navigasi kiri, klik Task Management, lalu klik Create Task. Untuk aplikasi terkait, pilih aplikasi yang Anda buat pada langkah 3. Untuk tipe tugas, pilih HTTP. Anda juga dapat menentukan informasi seperti Task description, Priority, Task weight, dan Input parameters (format JSON didukung) sesuai kebutuhan bisnis Anda.
Konfigurasikan nama domain permintaan, path, metode permintaan, dan periode timeout untuk tugas HTTP. Untuk Request method, pilih metode HTTP seperti GET atau POST. Nilai Timeout diukur dalam detik.
Konfigurasikan parameter permintaan untuk tugas HTTP. Tentukan Header, Query, dan Body sesuai kebutuhan Anda. Body mendukung tiga format data: form-data, x-www-form-urlencoded, dan raw-json. Untuk menambahkan beberapa grup parameter, klik + Add.
Konfigurasikan definisi respons tugas HTTP, termasuk mode parsing respons sukses dan mode parsing hasil sukses. Mode parsing menyediakan tiga jenis parsing: kode respons, konten respons, dan badan respons. Misalnya, jika Anda memilih HTTP response code sebagai mode parsing, masukkan kode respons yang diharapkan, seperti 200, di bidang HTTP response code sebagai kriteria keberhasilan.
Konfigurasikan retry kegagalan untuk tugas HTTP, termasuk jumlah retry dan interval retry. Jumlah retry lebih dari 0 berarti tugas akan diulang setelah gagal. Dalam kasus ini, Anda juga dapat mengonfigurasi nama domain retry dan path antarmuka agar tugas yang gagal dikirim ke nama domain dan path tersebut. Nilai retry interval diukur dalam detik.
Header permintaan tugas HTTP
Saat MSE XXL-JOB menjalankan tugas HTTP, sistem menambahkan parameter sistem berikut ke header permintaan:
| Nama | Deskripsi | Nilai contoh |
| schedulerx-appId | ID Aplikasi | 12 |
| schedulerx-jobId | ID Tugas | 35 |
| schedulerx-jobName | Nama tugas | http-test-job |
| schedulerx-scheduleTimestamp | Timestamp penjadwalan (dalam milidetik) | 1760164985000 |
| schedulerx-dataTimestamp | Timestamp data (dalam milidetik) | 1760164980000 |
| schedulerx-user | Informasi pengguna | 1344371792 |
| schedulerx-maxAttempt | Jumlah maksimum retry | 3 |
| schedulerx-attempt | Jumlah retry saat ini | 1 |
| schedulerx-jobExecutionId | ID eksekusi tugas | 1417474640397221891 |
| schedulerx-logId | ID Shard (broadcast sharding) | 1417474640531439619 |
| schedulerx-shardingIndex | Indeks shard (broadcast sharding) | 0 |
| schedulerx-shardingTotal | Jumlah total shard (broadcast sharding) | 3 |