Siparişten çalışana uzanan yol
Bir iade isteğini modelden ödeme servisine kadar takip edelim. Model müşteriye iade yapılmasını öneriyor; uygulama siparişin durumunu değiştirip yapılacak işi bir çalışana gönderiyor. Google’ın genel kullanıma açtığı Spanner queues, bu yolun veri tabanı içindeki iki yazmasını birleştiriyor. Siparişin iade onayına geçmesi ve iade görevinin oluşması aynı işlemde tamamlanıyor. İşlem başarısızsa ikisi de uygulanmıyor. Geliştirici için işe yarayan yapı taşı bu: kararın saklanmasıyla görevin oluşturulması arasında ayrı bir mesaj hizmetine yazma boşluğu kalmıyor.[1]
Bu bağlantı yalnızca hemen çalışacak görevlerle sınırlı değil. Google’ın örneğinde insan onayı bekleyen iş için dört saatlik zaman aşımı görevi ekleniyor. Onay geldiğinde sipariş değişikliği ve henüz teslim edilmemiş görevin silinmesi aynı işlemde yapılıyor. SQL koşulu, silmenin beklenen sayıda satırı değiştirdiğini denetliyor. Küçük bir ekip açısından bunun pratik tarafı, bekleyen işi ve sipariş durumunu aynı sorgu düzeniyle inceleyebilmek. İşin niçin beklediğini aramak için uygulama verisi ile ayrı bir kuyruk panosu arasında gidip gelmek gerekmiyor.[1]
Çalışan sürece geçince başka bir adım görüyoruz. Görev akışlı SQL ile alınıyor, kiralanıyor ve tamamlandığında onaylanıyor. Google teslimatı en az bir kez, onayı en fazla bir kez olarak tanımlıyor. Bu iki terimi iade örneğinin üzerinde tutmak faydalı: teslimat tekrar edebilir, onayın veri tabanındaki sonucu ise ayrı yönetiliyor. Böylece uygulamayı devralan geliştirici hangi aşamanın tekrarlandığını somut olarak sorabilir. Aynı görevin yeniden görünmesiyle ödeme servisinin ikinci bir iade gerçekleştirmesi farklı hata noktalarıdır.[1]
Deneyi ödeme yanıtına taşıyalım
Bence daralan boşluk, yeni denemenin yerini de gösteriyor. Sipariş güncellemesi ve görev ekleme aynı işlemde olduğuna göre deneyi ödeme yanıtının çevresine kurardım: çalışan, dış servis iadeyi kabul ettikten sonra ve görevi onaylamadan önce durursa ne oluyor? Bu soru Google’ın açıkladığı teslimat ve onay davranışından çıkıyor. Ödeme servisinin yinelenen isteği nasıl ele aldığı, Spanner içindeki iki yazmanın atomik olmasından ayrı uygulama bilgisidir. Kuyruk tasarımı, bu sınırdaki hatayı görünür bir test vakasına çevirmeye yardımcı olabilir; kazanç uygulamanın kullandığı dış servise bağlıdır.[1]
Aynı deney için ayrı kuyruk ve işlem içi görev tablosuyla kurulan mevcut uygulamayı karşılaştırma noktası olarak tutardım. Önce onay bekleme, iptal ve tekrar teslim yollarındaki bakım işini ölçmek gerekir. Spanner’ın SQL üzerinden bekleyen görevleri ve yürütme geçmişini açması bu incelemeyi kolaylaştıran somut özellik. Daha iyi model seçimi burada ilk değişken değil: aynı model ve aynı iade kuralıyla görev akışının nasıl incelendiği karşılaştırılabilir. Kazanç, ekibin gerçekten daha az eşleştirme ve hata araştırma işi yapmasıyla gösterilebilir.[1]
Bunun karşılığında görev akışı Spanner’ın veri modeline ve GoogleSQL kuyruk işlemlerine bağlanıyor. Kuyruğu sipariş tablosunun yanına koymak, küçük ekibin yönettiği ayrı bileşen sayısını azaltabilir; dış servis çağrısını ve tekrar davranışını yine uygulama tasarlıyor. Ben bu özelliği deneyen ekipten tek bir gösterim isterdim: ödeme kabulünden hemen sonra çalışanı durdurup yeniden başlatmak ve sipariş, görev, ödeme sonuçlarını birlikte incelemek. O akış rahatça açıklanabiliyorsa veri tabanına taşınan kuyruk, geliştirme işini gerçekten daha izlenebilir bir yere toplamış demektir.[1]