Mikro hizmetler arasında olay tabanlı iletişim uygulama (tümleştirme olayları)

İpucu

Bu içerik, .NET Docs'ta veya çevrimdışı olarak okunabilen ücretsiz indirilebilir bir PDF olarak sağlanan Kapsayıcılı .NET Uygulamaları için .NET Mikro Hizmet Mimarisi e-Kitabı'ndan bir alıntıdır.

PDF'i indirin

Daha önce açıklandığı gibi, olay tabanlı iletişimi kullandığınızda, mikro hizmet bir iş varlığını güncelleştirirken olduğu gibi önemli bir şey olduğunda bir olay yayımlar. Diğer mikro hizmetler bu olaylara abonedir. Bir mikro hizmet bir olay aldığında, kendi iş varlıklarını güncelleştirebilir ve bu da daha fazla olayın yayımlanmasına neden olabilir. Nihai tutarlılık kavramının özü budur. Bu yayımlama/abone olma sistemi genellikle bir olay veri yolu uygulaması kullanılarak gerçekleştirilir. Olay veri yolu, olaylara abone olmak ve abonelikten çıkmak ve olayları yayımlamak için gereken API ile bir arabirim olarak tasarlanabilir. Ayrıca, zaman uyumsuz iletişimi ve yayımlama/abone olma modelini destekleyen bir mesajlaşma kuyruğu veya hizmet veri yolu gibi işlemler arası veya mesajlaşma iletişimini temel alan bir veya daha fazla uygulamaya da sahip olabilir.

Birden çok hizmete yayılan ve bu hizmetler arasında nihai tutarlılık sağlayan iş işlemlerini uygulamak için olayları kullanabilirsiniz. Nihai tutarlı işlem, bir dizi dağıtılmış eylemden oluşur. Her eylemde, mikro hizmet bir iş varlığını güncelleştirir ve bir sonraki eylemi tetikleyen bir olay yayımlar. İşlemin temel kalıcılık ve olay veri yolunu kapsamadığını, bu nedenle bir kez daha etkili olunması gerektiğini unutmayın. Aşağıdaki şekil 6-18 arasında, bir olay veri yolu aracılığıyla yayımlanan PriceUpdated olayı gösterilmektedir, bu nedenle fiyat güncelleştirmesi Sepet'e ve diğer mikro hizmetlere yayılır.

Şekil 6-18. Olay veri yolunu temel alan olay odaklı iletişim

Bu bölümde, Şekil 6-18'de gösterildiği gibi genel bir olay veri yolu arabirimi kullanarak .NET ile bu tür iletişimleri nasıl uygulayabileceğiniz açıklanmaktadır. Her biri RabbitMQ, Azure Service Bus veya başka bir üçüncü taraf açık kaynak veya ticari hizmet veri yolu gibi farklı bir teknoloji veya altyapı kullanan birden çok olası uygulama vardır.

Üretim sistemleri için ileti aracılarını ve hizmet otobüslerini kullanma

Mimari bölümünde belirtildiği gibi, soyut olay veri yolunu uygulamak için birden çok mesajlaşma teknolojisi arasından seçim yapabilirsiniz. Ancak bu teknolojiler farklı düzeylerdedir. Örneğin mesajlaşma aracısı taşıması olan RabbitMQ, Azure Service Bus, NServiceBus, MassTransit veya Bright gibi ticari ürünlerden daha düşük bir düzeydedir. Bu ürünlerin çoğu RabbitMQ veya Azure Service Bus üzerinde çalışabilir. Ürün seçiminiz, kaç özelliğe ve uygulamanız için ne kadar hazır ölçeklenebilirliğe ihtiyacınız olduğuna bağlıdır.

eShopOnContainers örneğinde olduğu gibi geliştirme ortamınız için yalnızca bir olay veri yolu kavram kanıtı uygulamak için, kapsayıcı olarak çalışan RabbitMQ üzerinde basit bir uygulama yeterli olabilir. Ancak yüksek ölçeklenebilirlik gerektiren görev açısından kritik sistemler ve üretim sistemleri için Azure Service Bus'ı değerlendirmek ve kullanmak isteyebilirsiniz.

Dağıtılmış geliştirmeyi kolaylaştıran uzun süre çalışan süreçler için Sagas gibi üst düzey soyutlamalara ve daha zengin özelliklere ihtiyacınız varsa, NServiceBus, MassTransit ve Brighter gibi diğer ticari ve açık kaynak hizmet otobüsleri değerlendirmeye değer. Bu durumda, kullanılacak soyutlamalar ve API genellikle kendi soyutlamalarınız (eShopOnContainers'da sağlanan basit olay veri yolu soyutlamaları gibi) yerine doğrudan bu üst düzey hizmet otobüsleri tarafından sağlananlar olacaktır. Bu nedenle, NServiceBus (Özel Yazılım tarafından uygulanan ek türetilmiş örnek) kullanarak çatallanmış eShopOnContainers'ı araştırabilirsiniz.

Elbette, RabbitMQ ve Docker gibi alt düzey teknolojilerin üzerine her zaman kendi servis veri yolu özelliklerinizi oluşturabilirsiniz, ancak "tekerleği yeniden icat etmek" için gereken iş özel bir kurumsal uygulama için çok maliyetli olabilir.

Tekrar etmek için: eShopOnContainers örneğinde gösterilen örnek olay veri yolu soyutlamaları ve uygulaması yalnızca kavram kanıtı olarak kullanılmak üzere tasarlanmıştır. Geçerli bölümde açıklandığı gibi zaman uyumsuz ve olay odaklı iletişime sahip olmak istediğinize karar verdikten sonra, üretim gereksinimlerinize en uygun service bus ürününü seçmeniz gerekir.

Tümleştirme olayları

Tümleştirme olayları, etki alanı durumunu birden çok mikro hizmet veya dış sistem arasında eşitlemeye getirmek için kullanılır. Bu işlev, mikro hizmet dışında tümleştirme olayları yayımlanarak gerçekleştirilir. Bir olay birden çok alıcı mikro hizmette yayımlandığında (tümleştirme olayına abone olunan kadar mikro hizmete), her alıcı mikro hizmetindeki uygun olay işleyicisi olayı işler.

Tümleştirme olayı, aşağıdaki örnekte olduğu gibi temel olarak bir veri tutma sınıfıdır:

public class ProductPriceChangedIntegrationEvent : IntegrationEvent
{
    public int ProductId { get; private set; }
    public decimal NewPrice { get; private set; }
    public decimal OldPrice { get; private set; }

    public ProductPriceChangedIntegrationEvent(int productId, decimal newPrice,
        decimal oldPrice)
    {
        ProductId = productId;
        NewPrice = newPrice;
        OldPrice = oldPrice;
    }
}

Tümleştirme olayları her mikro hizmetin uygulama düzeyinde tanımlanabilir, bu nedenle diğer mikro hizmetlerden, ViewModel'lerin sunucuda ve istemcide nasıl tanımlandığına benzer bir şekilde birbirinden ayrılmıştır. Önerilen şey, ortak tümleştirme olayları kitaplığını birden çok mikro hizmet arasında paylaşmaktır; bunu yapmak, bu mikro hizmetleri tek bir olay tanımı veri kitaplığıyla birleştirilebilir. Bunu birden çok mikro hizmette ortak bir etki alanı modelini paylaşmak istemediğiniz nedenlerle yapmak istemezsiniz: mikro hizmetler tamamen otonom olmalıdır. Daha fazla bilgi için olaylara konulacak veri miktarıyla ilgili bu blog gönderisine bakın. Bu diğer blog gönderisinde veri yetersiz iletilerinin üretebileceği sorun anlatıldığı için bu konuyu çok ileri götürmemeye dikkat edin. Etkinliklerinizin tasarımı, tüketicilerinin ihtiyaçları için "doğru" olmayı hedeflemelidir.

Mikro hizmetlerde paylaşmanız gereken yalnızca birkaç tür kitaplık vardır. Bunlardan biri, eShopOnContainers'da olduğu gibi Event Bus istemci API'si gibi son uygulama blokları olan kitaplıklardır. Bir diğeri de JSON seri hale getiricileri gibi NuGet bileşenleri olarak paylaşılabilen araçları oluşturan kitaplıklardır.

Olay veri yolu

Olay veri yolu, Şekil 6-19'da gösterildiği gibi bileşenlerin birbirini açıkça tanımasını gerektirmeden mikro hizmetler arasında yayımlama/abone olma stili iletişim sağlar.

Şekil 6-19. Olay veri yolu ile temel bilgileri yayımlama/abone olma

Yukarıdaki diyagramda, A mikro hizmetinin, yayımcının aboneleri tanımasına gerek kalmadan B ve C mikro hizmetleri abonelerine dağıtan Event Bus'ta yayımlandığı gösterilmektedir. Olay veri yolu Gözlemci deseni ve yayımlama-abone olma deseni ile ilgilidir.

Gözlemci deseni

Gözlemci düzeninde, birincil nesneniz (Gözlemlenebilir olarak bilinir) ilgili diğer nesnelere (Gözlemciler olarak bilinir) ilgili bilgiler (olaylar) bildirir.

Yayımla/Abone Ol (Pub/Sub) deseni

Yayımla/Abone Ol deseninin amacı Gözlemci deseni ile aynıdır: belirli olaylar gerçekleştiğinde diğer hizmetlere bildirmek istiyorsunuz. Ancak Gözlemci ile Pub/Sub desenleri arasında önemli bir fark vardır. Gözlemci düzeninde, yayın doğrudan gözlemlenebilirden gözlemcilere gerçekleştirilir, böylece birbirlerini "tanırlar". Ancak Pub/Sub deseni kullanılırken, hem yayımcı hem de abone tarafından bilinen aracı, ileti aracısı veya olay veri yolu adlı üçüncü bir bileşen vardır. Bu nedenle, Pub/Sub desenini kullanırken yayımcı ve aboneler belirtilen olay veri yolu veya ileti aracısı sayesinde kesin olarak ayrılır.

Aracı veya olay veri yolu

Yayımcı ve abone arasında anonimliği nasıl elde edebilirsiniz? Kolay bir yol, bir aracının tüm iletişimi halletmesine izin vermektir. Olay veri yolu böyle bir aracıdır.

Olay veri yolu genellikle iki bölümden oluşur:

• Soyutlama veya arabirim.

• Bir veya daha fazla uygulama.

Şekil 6-19'da, uygulama açısından olay veri yolunun pub/sub kanalından başka bir şey olmadığını görebilirsiniz. Bu zaman uyumsuz iletişimi uygulama şekliniz farklılık gösterebilir. Ortam gereksinimlerine (örneğin, üretim ve geliştirme ortamları) bağlı olarak bunlar arasında geçiş yapabileceğiniz birden çok uygulaması olabilir.

Şekil 6-20'de RabbitMQ, Azure Service Bus veya başka bir olay/ileti aracısı gibi altyapı mesajlaşma teknolojilerini temel alan birden çok uygulama içeren bir olay veri yolunun özetini görebilirsiniz.

Şekil 6- 20. Bir olay veri yolunun birden çok uygulaması

RabbitMQ, Azure Service bus veya diğerleri gibi çeşitli teknolojilerle uygulanabilmesi için olay veri yolunun bir arabirim aracılığıyla tanımlanması iyi bir seçenektir. Ancak ve daha önce de belirtildiği gibi, kendi soyutlamalarınızı (olay veri yolu arabirimi) kullanmak, yalnızca özetleriniz tarafından desteklenen temel olay veri yolu özelliklerine ihtiyacınız varsa iyidir. Daha zengin service bus özelliklerine ihtiyacınız varsa, kendi soyutlamalarınız yerine tercih ettiğiniz ticari hizmet veri yolu tarafından sağlanan API'yi ve soyutlamaları kullanmanız gerekir.

Olay veri yolu arabirimi tanımlama

Olay veri yolu arabirimi için bazı uygulama kodları ve araştırma amacıyla olası uygulamalarla başlayalım. Arabirim, aşağıdaki arabirimde olduğu gibi genel ve basit olmalıdır.

public interface IEventBus
{
    void Publish(IntegrationEvent @event);

    void Subscribe<T, TH>()
        where T : IntegrationEvent
        where TH : IIntegrationEventHandler<T>;

    void SubscribeDynamic<TH>(string eventName)
        where TH : IDynamicIntegrationEventHandler;

    void UnsubscribeDynamic<TH>(string eventName)
        where TH : IDynamicIntegrationEventHandler;

    void Unsubscribe<T, TH>()
        where TH : IIntegrationEventHandler<T>
        where T : IntegrationEvent;
}

Yöntemi Publish basittir. Olay veri yolu, herhangi bir mikro hizmete, hatta bu olaya abone olan bir dış uygulamaya geçirilen tümleştirme olayını yayınlar. Bu yöntem, olayı yayımlayan mikro hizmet tarafından kullanılır.

Yöntemler Subscribe (bağımsız değişkenlere bağlı olarak çeşitli uygulamalarınız olabilir) olayları almak isteyen mikro hizmetler tarafından kullanılır. Bu yöntemin iki bağımsız değişkeni vardır. Birincisi, abone olunacak tümleştirme olayıdır (IntegrationEvent). İkinci bağımsız değişken, alıcı mikro hizmeti bu tümleştirme olay iletisini aldığında yürütülecek adlı IIntegrationEventHandler<T>tümleştirme olay işleyicisidir (veya geri çağırma yöntemi).

Ek kaynaklar

Üretime hazır bazı mesajlaşma çözümleri:

• Azure Service Bus
  https://learn.microsoft.com/azure/service-bus-messaging/

• NServiceBus
  https://particular.net/nservicebus

• MassTransit
  https://masstransit-project.com/

Geriİleri