Olay odaklı bir mikro hizmet mimarisindeki değişiklikleri ele almak için seçenekleri araştırdığım bir araştırma projesi yapıyorum.

Diyelim ki dört farklı hizmet aldığımız bir uygulama var. Bu hizmetlerin her birinin yerel verileri depolamak için kendi veritabanı vardır.

Bu kurulumda, dört hizmet bir Olay Veri Yolu kullanarak birbirleriyle iletişim kurar. Bir hizmette bir şey olduğunda, bir olay yayınlar. Bu etkinlikle ilgilenen diğer tüm hizmetler, etkinliği kendi yöntemleriyle işleyecektir.

Bu durumda mimarideki farklı hizmetlerin bu olayların içeriği (nitelikler vb.) Hakkında "sözleşmeleri" olması gerekir. Dolayısıyla hizmetlerin bu olaylara "gevşek bağlı bağımlılıkları" var

Sorum şu: Bu olaylardaki değişiklikleri nasıl ele alabiliriz?

Diyelim ki A hizmeti uygulamadaki yeni kullanıcıları kaydetti. Bu yüzden bir "" UserRegistered "olayı gönderir. Service B bu olayı alır ve işler. C hizmeti ekibindeki bazı geliştiriciler de kayıtlı kullanıcının cinsiyetine ihtiyaç duyduklarına karar verdiler. "UserRegistered" etkinliğine eklenir.

Hizmet B'nin yeniden konuşlandırmadan aynı etkinliği bu ekstra özellikle almaya devam etmesini nasıl sağlayabiliriz?

Ve bu soruna yaklaştıktan sonra bu olayları versiyonlamanın başka yolları var mı?

Olaylar neyin değiştiği ile ilgili değil. Bir şey değiştiğinde.

Değişen içerikten tamamen ayrılmış bir olay sistemi oluşturabilirim. Bu şekilde bir olaydan öğrendiğim tek şey bir nesnenin güncellendiğidir. Nesnenin güncellendiğini umursam bile, o nesneyle nasıl konuşulacağını bilenlere ne değiştiğini soracağım.

Bu, bu değişiklikleri iletme sorununu çözmez. Sadece olay sisteminin bir parçası olmasını engelliyor.

Farklı veri versiyonları problemini çözmenin bir yolunun bir örneği, gözlemcinin gözlemlenen nesneyi bir koleksiyon oluşturması ve teslim etmesidir. Gözlemlenen nesne koleksiyonu en son verileriyle doldurur ve kontrol döndüğünde (gözlemci) ihtiyacınız olan şeye sahiptir. Eğer umursamadığınız ekstralar varsa, onu hiç duymadınız, görmezden gelirsiniz.

O kediyi cilde sürmenin başka birçok yolu var ama tam da bu durumda çalıştım.

NServiceBus gibi çerçeveler bunu polimorfik mesaj gönderimi ile olay sürümlendirme kullanarak işler.

Örneğin, Hizmet A'nın 1. sürümü IUserRegistered_v1 olarak bir olay yayınlayabilir. Hizmet 1.1 sürümünün ek bir alan içermesi gerektiğinde, IUserRegistered_v1_1 arabirimini, IUserRegistered_v1'den devralacak ve bazı ek alanları bildirebilir.

Hizmet A bir IUserRegistered_v1_1 olayı yayımladığında, NServiceBus iletiyi IUserRegistered_v1 veya IUserRegistered_v1_1 ile ilgilenen tüm uç noktalara gönderir.

Marjinal gelişim

Modeldeki basit bir değişiklik, dinleyiciler bir gözlemci olarak kaydolduklarında, bilmek istedikleri veri öğelerinin bir listesini veya başka bir yapısını içerdikleri şeklindedir. Hizmetten döndürülen veriler basitse, ancak makul miktarda hiyerarşik verileriniz varsa, bu gerçekten uygulanması karmaşıklaşabilir.

Kaya gibi sağlam

Bu tasarımı yapmak için gerçekten sağlam bir yol istiyorsanız, hizmeti depoladığı verilerde yapılan değişikliklerin geçmişini tutacak şekilde yapın. Esasen, veritabanınızdaki kayıtları asla güncellemezsiniz, her birinin değişikliği temsil ettiği yeni kayıtlar eklersiniz. Bu yeni kayıtların her biri, eylemi tanımlayan bir olay kimliğiyle ilişkilendirilir. Değişiklikle ilgili tüm bilgileri içeren bir çift kayıt (kim, ne, ne zaman, vb.) Saklanır .

Bir değişiklik yapıldığında, olay kaydını oluşturur ve tüm yeni verileri veritabanınıza eklersiniz. Ardından, dinleyicilere olay kimliğini (en az) içeren bir olay yayınlarsınız. Dinleyiciler daha sonra o kimlikle ilişkili verileri isteyebilir ve onunla ilişkili verilerin sürümünü alabilir. Böylece her dinleyici, diğer farklı dinleyicilerin ihtiyaçlarını bir araya getirmeden ihtiyaç duydukları her şeyi elde edebilir. Olay iletisine en sık kullanılan veri alanlarının bir alt kümesini eklemenizi öneririm, böylece dinleyiciler ilgilenmedikleri olayları filtreleyebilir. Bu işlemin sohbetini azaltabilir ve bazı dinleyicilerin hiçbir zaman araması gerekmeyebilir geri döndü. Bu sizi zamanlama sorunlarından da korur. Sadece servisi geri arar ve verilere göre anahtar alırsanız, etkinliği alma ve etkinlik verilerini alma arasında başka değişiklikler olabilir. Bu, tüm dinleyiciler için önemli olmayabilir, ancak tüm değişiklikler hakkında bilgi sahibi olmanız gerekiyorsa büyük sorunlar oluşturabilir. Gerçekten 11'e çevirmek istiyorsanız, yukarıdaki artımlı tasarım iyileştirmesi bu yaklaşımla uyumludur.

Bunlardan bazıları yapmanız gerekenler için aşırıya kaçabilir, ancak bir kaydın zaman içinde nasıl değiştiğine bakmak için kesin bir yolunuz yoksa, siz veya verilerinizle çalışan bir kişi sonunda isteyecektir.

@CandiedOrange, xml gibi genişletilebilir veri biçimleriyle ilgili kendi cevabına yaptığı bir yorumda geçerli bir noktaya işaret eder.

Veri eklediğiniz sürece önemli değil. Ancak, eski etkinlikler / zorunlu olmayan alanlar için makul varsayılanlar sağlayın.

Sadece bu durumda Cinsiyeti önemseyen hizmetleri güncellemelisiniz. Bir xml / json ayrıştırıcısı, diğer hizmetler için ek verileri yok sayabilmelidir. Bu, ayrıştırıcı ve olay veri formatı seçiminize bağlıdır.

Yine de ilgili verilere sahip olmayan olayları kabul etmiyorum. Olay kaynağı oluşturmak için, olaylar neyin değiştiğini tanımlamalıdır. Bir olay alınırken, diğer hizmetlerin olayın kaynağından veri alması gerekmez.