Biraz daha araştırma yaptıktan sonra, yapmak istediğim şey için (ve gelecekteki herhangi bir okuyucu için) yararlı olduğunu düşündüğüm bazı alıntılar çıkardığım bu makaleye tökezledim . Bu, zorunlu bir programlama modeli üzerinden reaktif bir programlama modeli benimsemenin bir yolunu sunar.
Olay kaynak
Buradaki fikir, her uygulamanın devlet geçişini değişmez bir olay biçiminde temsil etmektir. Olaylar daha sonra meydana geldiklerinde bir günlük veya günlük biçiminde saklanır ('olay deposu' olarak da adlandırılır). Ayrıca, uygulamanın durumunun bir bütün olarak zaman içinde nasıl geliştiğini temsil etmeyi amaçlayan süresiz olarak sorgulanabilir ve saklanabilir.
Bunun gerçekleştirilmesine yardımcı olan şey, bir mikro hizmetin çökmesi ve bununla ilgili diğer etkinliklerin yayınlanması ve söz konusu mikro hizmetin diğer örnekleri tarafından tüketilmesinin, bu mikro hizmetin geri gelmesi durumunda buna işaret edebilmesidir.event store tüm düştüğü dönemde kaçırdığı olaylar.
Etkinlik Brokeri olarak Apache Kafka
Saniyede binlerce olayı depolayıp gönderebilen ve yerleşik çoğaltma ve hata tolerans mekanizmalarına sahip Apache Kafka'nın kullanımını düşünün. Süresiz olarak diskte saklanabilen ve herhangi bir zamanda (Kafka'nın süslü kuyruğu) teslim edilen Konudan (ancak kaldırılmadan) tüketilebilen kalıcı bir olay deposuna sahiptir.
Olaylara daha sonra bunları Konu içinde tek tek tanımlayan ofsetler atanır - Kafka ofsetleri kendisi yönetebilir, kolayca "en fazla bir kez" veya "en az bir kez" teslim semantiği sağlayabilir, ancak bir etkinlik tüketicisi bir Konuya katıldığında da müzakere edilebilir mikro hizmetlerin zaman içinde herhangi bir keyfi yerden - genellikle tüketicinin kaldığı yerden - olayları tüketmeye başlamasına izin verir. Son tüketilen olay ofseti, 'başarıyla tamamlandığında' kullanıldığında hizmetlerin yerel depolamasında işlemsel olarak devam ederse, bu ofset "tam olarak bir" olay teslim semantiği elde etmek için kolayca kullanılabilir.
Aslında, tüketiciler kendilerini Kafka'ya tanıttıklarında, Kafka hangi tüketicilere hangi mesajların teslim edildiğini kaydedecek ve böylece tekrar hizmet vermeyecektir.
Sagalar
Farklı hizmetler arasındaki iletişimin gerçekten gerekli olduğu daha karmaşık kullanımlar için, kullanıcı tabanını bitirme sorumluluğu iyi bilinmelidir - kullanım alanı merkezi değildir ve yalnızca ilgili tüm hizmetler görevlerini başarıyla tamamlandığını kabul ettiğinde biter, aksi takdirde tüm kullanım hatası başarısız olmalıdır geçersiz yerel durumları geri almak için düzeltici tedbirler alınmalıdır.
İşte destan devreye giriyor. Destan, bir dizi yerel işlemdir. Her yerel işlem veritabanını günceller ve destandaki bir sonraki yerel işlemi tetiklemek için bir mesaj veya olay yayınlar. Yerel bir işlem, bir iş kuralını ihlal ettiği için başarısız olursa, destan, önceki yerel işlemler tarafından yapılan değişiklikleri geri alan bir dizi telafi işlemi yürütür. Daha fazla bilgi için bunu okuyun .