Cronflower, Spring Boot uygulamalarını dağıtık cron ve DAG workflow kümelerine dönüştürüyor

İki yazı, tek proje

dev.to'da yayımlanan iki duyuru yazısına göre, Cronflower adlı açık kaynak proje tanıdık bir Spring Boot sorununu hedefliyor: @Scheduled tek bir JVM içinde çalışır, bu yüzden ikinci bir instance'a ölçeklendiğinde job iki kez tetiklenir ve yerleşik scheduler retry, timeout ve neyin çalıştığına dair bir kayıt sunmaz. Ekipler bunu genellikle Quartz, bir veritabanı, bir lock tablosu ve elle yapılmış bir dashboard ile çözümler. Cronflower bu yığının tamamını tek pakette sunuyor — ve yazılar projenin kendi geliştiricisinden geliyor gibi göründüğünden, iddialar henüz bağımsız olarak doğrulanmış değil.

Projenin iki yarısı var: cronsmith, dağıtık bir task scheduler; cronflow ise bir DAG workflow orkestratörü. İkisi aynı kümeyi ve aynı web konsolunu paylaşıyor ve sistem harici bir veritabanı, broker veya koordinatör gerektirmeden kendi kümesini oluşturuyor. Kalıcılık deposu, uygulamanın datasource'undan otomatik olarak algılanıyor: veritabanı yoksa bellek içi, tanımlıysa H2, SQLite, MySQL veya PostgreSQL.

cronsmith ile dağıtık zamanlama

Mimari iki role ayrılıyor. Scheduler süreçleri schedule'ların sahibidir, task durumunu tutar ve gossip üzerinden bir leader seçer; executor'lar ise uygulamanızın JVM'leridir ve task'ları @Task ile işaretlenmiş bean metotları olarak tanımlayıp gönderildiğinde kodu çalıştırır. Executor'lar kayıt olur ve heartbeat gönderir, böylece scheduler kodun nerede çalışabileceğini her zaman bilir.

Schedule'lar cron ifadeleri, sabit aralıklar, cron'un kapsayamadığı boşluklar için ISO-8601 süreleri veya "yılın 200. günü öğlen" gibi tarihler için YCRON adlı yıl tabanlı bir varyant olarak ifade edilebilir. Task parametreleri sabit olabilir ya da her tetiklemede yeniden değerlendirilen SpEL şablonları olabilir.

Operasyonel ayarlar özel kod yerine annotation niteliklerinde yaşıyor: kayıt altına alınan denemelerle retry için maxRetryCount ve retryInterval, asılı job'ları yakalamak için run başına timeout, kesinti sonrası toparlanma için bir misfire politikası (atla, şimdi bir kez çalıştır veya kaçırılan tüm çalıştırmaları işlet) ve sınırlı task'lar için repeatCount veya stopAt. Sadece bir URL'yi çağıran job'lara hiç executor gerekmez — HTTP task'ları scheduler düğümünde çalışır ve yeniden deploy gerektirmeden konsoldan veya REST API'den oluşturulup düzenlenebilir.

Ölçek için depolama modu önemli. Düğüme yerel H2 veya SQLite depolarıyla leader düğümleri senkronize tutar; paylaşımlı bir MySQL veya PostgreSQL veritabanı ayrıca group sharding'i etkinleştirir; her düğüm yalnızca kendisine hashlenen task gruplarını tetikler.

cronflow ile DAG workflow'ları

İkinci dev.to yazısı zincirlenmiş cron job'larını ele alıyor: biri 02:00'de, diğeri genellikle yeterli olacak süreden dolayı 02:15'te çalışan job'lar. Cronflow, saat tabanlı bu bağlantıyı bildirilen graph'larla değiştirir. Bir workflow bir Spring bean'idir: @Dag onu adlandırır, @DagNode metotları adımlardır ve kenar listeleri şekli tanımlar.

Veri düğümler arasında adlandırılmış kanallar üzerinden hareket eder ve her kanal bir reducer bildirir — sum, max, boolean fold'ları, liste veya map birleştirme, join-CSV, last-wins ve daha fazlası; özel reducer bean'leri de desteklenir. Aynı kanala yapılan eşzamanlı yazımlar otomatik birleştirilir; yazar bunu, elle yazacağınız race'leri ve lock'ları ortadan kaldırmak olarak sunuyor.

Kontrol akışı; SpEL ifadeleriyle koşullu yönlendirme, ALL ve ANY join modları, bir DAG'ı başka bir DAG'ın düğümü olarak gömen subgraph'lar ve bir listedeki her öğe için bir adımı bir kez çalıştıran run-time fan-out için @Shard'ı kapsıyor. Workflow'lar konsoldan elle tetiklenebilir, dönüş değeri girdiyi tohumlayan zamanlanmış bir task tarafından başlatılabilir veya doğrudan trigger-DAG task tipi olarak zamanlanabilir. Motor düğümleri küme genelindeki canlı executor'lara dağıttığından, geniş bir fan-out gerçekten paralel çalışır ve her run görünümü hangi executor'ın hangi düğümü ele aldığını ve ne ürettiğini gösterir.

Başlarken

Duyuruya göre, depoyu klonlayıp paketten çıkan deploy script'ini çalıştırmak; sağlanması gereken hiçbir şey olmadan gömülü bir depo üzerinde bir scheduler, konsol ve executor ayağa kaldırıyor; komut satırı bayrakları aynı kurulumu birden çok scheduler ve executor'a ölçekler ve bir Docker script'i sağlanır. Konsol 7200 portunu dinler ve pakete dahil executor, tetiklenmeye hazır örnek workflow'larla gelir.

Neden önemli

Zamanlanmış işler, tek instance varsayımlarının sessizce kırıldığı yerdir: job'lar iki kez ateşlenir ya da hiç ateşlenmez ve gece özeti eksik kalana kadar kimse fark etmez. Cronflower'un iddiası, bunu düzeltmenin Quartz, bir lock tablosu, bir broker ve ev yapımı bir dashboard birleştirmeyi gerektirmemesi gerektiği. Retry'ları, timeout'ları, misfire yönetimini, çalıştırma geçmişini, leader election'ı ve DAG orkestrasyonunu — zorunlu harici altyapı olmadan — sıradan Spring bean'lerindeki annotation'lara katarak, "cron job'lı bir uygulama" ile "bir workflow platformu" arasındaki eşiği düşürüyor. Belirgin uyarı ise şu: her iki kaynak da projenin yazarının tanıtım yazıları; exactly-once tetikleme ve failover davranışı bağımsız üretim kullanımından geçer sınavı bekleyecek.