Aracılığıyla paylaş

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

Tavsiye

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

PDF'i indirin

.NET Mikro Hizmetler Mimarisi Kapsayıcılı .NET Uygulamaları için eKitabın kapak küçük resmi .

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. Etkinlik veri yolu, olaylara abone olma, abonelikten çıkma ve olayları yayınlama için gerekli API ile bir arayüz 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 idemponenslik ile ilgilenilmesi gerektiğini unutmayın. Aşağıdaki Şekil 6-18, bir etkinlik veri yolu aracılığıyla yayımlanan bir PriceUpdated olayını göstermektedir, böylece fiyat güncellemesi Sepet'e ve diğer mikro hizmetlere dağıtılmaktadır.

Asenkron olay odaklı iletişim için bir olay veri yolu diyagramı.

Şekil 6-18. Olay veri yolunu temel alan olay tabanlı 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, mesaj broker taşıma sistemi olan RabbitMQ, Azure Service Bus, NServiceBus, MassTransit veya Brighter 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, Particular Software tarafından sağlanan ek türetilmiş örnek olan NServiceBus'u 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 fazla alıcı mikro hizmete yayımlandığında (entegrasyon olayına abone olan kadar çok mikro hizmete), her alıcı mikro hizmetteki uygun olay işleyicisi bu olayı ele alır.

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. Önerilmeyen şey, ortak bir tümleştirme olayları kütüphanesini birden çok mikro hizmet arasında paylaşmaktır; çünkü bunu yapmak, bu mikro hizmetleri tek bir olay tanımı veri kütüphanesiyle bağımlı hale getirir. 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.

Etkinlik 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.

Temel yayımlama/abone olma desenini gösteren diyagram.

Ş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. Etkinlik düzenleyicisi, Gözlemci deseni ve yayımlama-abonelik 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 mesaj aracısı veya olay otobüsü olarak adlandırılan üçüncü bir bileşen bulunur. Bu nedenle, Pub/Sub desenini kullanırken yayımcı ve aboneler, belirtilen olay veri yolu veya ileti aracısı sayesinde tamamen bağımsız hale gelir.

Orta katman veya etkinlik 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. Böyle bir aracılık işlevini etkinlik otobüsü üstlenir.

Etkinlik otobüsü 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 bir Yayınlama/Abonelik 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.

Olay veri yolu soyutlama katmanının eklenmesini gösteren diyagram.

Şekil 6- 20. Birden fazla olay veri yolu 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 gelişmiş service bus özelliklerine ihtiyacınız varsa, kendi soyutlamalarınız yerine tercih ettiğiniz ticari servis veri yolu tarafından sağlanan API ve soyutlamaları kullanmalısınız.

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. Etkinlik veri yolu, kendisine geçirilen tümleştirme olayını, bu olaya abone olan herhangi bir mikro hizmete veya dış uygulamaya yayınlayacaktır. Bu yöntem, olayı yayımlayan mikro hizmet tarafından kullanılır.

Subscribe yöntemler (bağımsız değişkenlere bağlı olarak çeşitli uygulamalar gerçekleştirebilirsiniz) olayları almak isteyen mikroservisler tarafından kullanılır. Bu metodun iki argümanı 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 çalıştırılacak olan, adlandırılmış IIntegrationEventHandler<T> tümleştirme olay işleyicisi (veya geri çağırma yöntemi) olacaktır.

Ek kaynaklar

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

ÖncekiSonraki