Zaman uyumsuz ileti tabanlı iletişim

  • Makale

İ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

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

Zaman uyumsuz mesajlaşma ve olay odaklı iletişim, değişiklikleri birden çok mikro hizmete ve ilgili etki alanı modellerine dağıtırken kritik önem taşır . Daha önce tartışma mikro hizmetleri ve Sınırlanmış Bağlamlar 'da (BC) belirtildiği gibi modeller (Kullanıcı, Müşteri, Ürün, Hesap vb.) farklı mikro hizmetler veya BC'ler için farklı anlamlara gelebilir. Bu, değişiklikler gerçekleştiğinde farklı modellerdeki değişiklikleri mutabık hale getirmek için bir yönteme ihtiyacınız olduğu anlamına gelir. Çözüm, zaman uyumsuz mesajlaşmayı temel alan nihai tutarlılık ve olay odaklı iletişimdir.

Mesajlaşma kullanılırken, işlemler iletileri zaman uyumsuz olarak değişerek iletişim kurar. İstemci, bir hizmete ileti göndererek bir komut veya istekte bulunur. Hizmetin yanıtlanması gerekiyorsa istemciye farklı bir ileti gönderir. İleti tabanlı bir iletişim olduğundan istemci, yanıtın hemen alınmayacağını ve hiç yanıt alınamayacağını varsayar.

İleti bir üst bilgi (tanımlama veya güvenlik bilgileri gibi meta veriler) ve bir gövde tarafından oluşturulur. İletiler genellikle AMQP gibi zaman uyumsuz protokoller aracılığıyla gönderilir.

Mikro hizmetler topluluğunda bu tür bir iletişim için tercih edilen altyapı, SOA'da kullanılan büyük aracılardan ve düzenleyicilerden farklı olan basit bir ileti aracısıdır. Basit bir ileti aracısında altyapı genellikle yalnızca ileti aracısı olarak davranan ve RabbitMQ gibi basit uygulamalarla veya Azure Service Bus gibi bulutta ölçeklenebilir bir hizmet veri yoluyla "aptaldır". Bu senaryoda, "akıllı" düşünmenin çoğu hala iletileri üreten ve kullanan uç noktalarda(yani mikro hizmetlerde) yaşamaktadır.

Mümkün olduğunca izlemeye çalışmanız gereken bir diğer kural da, iç hizmetler arasında yalnızca zaman uyumsuz mesajlaşmayı kullanmak ve yalnızca istemci uygulamalarından ön uç hizmetlerine (API Gateway'ler artı ilk mikro hizmet düzeyi) zaman uyumlu iletişimi (HTTP gibi) kullanmaktır.

İki tür zaman uyumsuz mesajlaşma iletişimi vardır: tek alıcılı ileti tabanlı iletişim ve birden çok alıcı ileti tabanlı iletişim. Aşağıdaki bölümlerde bunlar hakkında ayrıntılar sağlanır.

Tek alıcılı ileti tabanlı iletişim

Tek bir alıcıyla ileti tabanlı zaman uyumsuz iletişim, kanaldan okuyan tüketicilerden birine ileti teslim eden noktadan noktaya iletişim olduğu ve iletinin yalnızca bir kez işlendiği anlamına gelir. Ancak, özel durumlar vardır. Örneğin, hatalardan otomatik olarak kurtarmaya çalışan bir bulut sisteminde aynı ileti birden çok kez yeniden gönderilebilir. Ağ veya diğer hatalar nedeniyle, istemcinin iletileri göndermeyi yeniden deneyebilmesi ve sunucunun belirli bir iletiyi yalnızca bir kez işlemek için bir işlem gerçekleştirmesi gerekir.

Şekil 4-18'de gösterildiği gibi, tek alıcılı ileti tabanlı iletişim, bu yaklaşımı gösteren bir mikro hizmetten diğerine zaman uyumsuz komutlar göndermek için özellikle uygundur.

İleti tabanlı iletişim göndermeye başladıktan sonra (komutlar veya olaylarla), zaman uyumlu HTTP iletişimi ile ileti tabanlı iletişimi karıştırmaktan kaçınmanız gerekir.

A single microservice receiving an asynchronous message

Şekil 4-18. Zaman uyumsuz bir ileti alan tek bir mikro hizmet

Komutlar istemci uygulamalarından geldiğinde HTTP zaman uyumlu komutlar olarak uygulanabilir. Daha yüksek ölçeklenebilirliğe ihtiyacınız olduğunda veya zaten ileti tabanlı bir iş sürecindeyseniz ileti tabanlı komutları kullanın.

Birden çok alıcı ileti tabanlı iletişim

Daha esnek bir yaklaşım olarak, gönderenden gelen iletişiminizin ek abone mikro hizmetleri veya dış uygulamalar için kullanılabilir olması için bir yayımlama/abone olma mekanizması da kullanmak isteyebilirsiniz. Bu nedenle, gönderen hizmette açık/kapalı ilkesini izlemenize yardımcı olur. Bu şekilde, gelecekte gönderen hizmetini değiştirmeye gerek kalmadan ek aboneler eklenebilir.

Yayımlama/abone olma iletişimi kullandığınızda, olayları herhangi bir aboneye yayımlamak için olay veri yolu arabirimi kullanıyor olabilirsiniz.

Zaman uyumsuz olay odaklı iletişim

Zaman uyumsuz olay temelli iletişim kullanılırken, bir mikro hizmet etki alanında bir şey olduğunda ve ürün kataloğu mikro hizmetindeki fiyat değişikliği gibi başka bir mikro hizmetin farkında olması gerektiğinde bir tümleştirme olayı yayımlar. Ek mikro hizmetler, zaman uyumsuz olarak alabilmeleri için olaylara abone olur. Bu durumda, alıcılar kendi etki alanı varlıklarını güncelleştirebilir ve bu da daha fazla tümleştirme olayının yayımlanmasına neden olabilir. Bu yayımlama/abone olma sistemi bir olay veri yolu uygulaması kullanılarak gerçekleştirilir. Olay veri yolu, olaylara abone olmak veya aboneliği kaldırmak ve olayları yayımlamak için gereken API ile bir soyutlama veya arabirim olarak tasarlanabilir. Olay veri yolu, zaman uyumsuz iletişimi ve yayımlama/abone olma modelini destekleyen bir mesajlaşma kuyruğu veya hizmet veri yolu gibi işlemler arası ve mesajlaşma aracısını temel alan bir veya daha fazla uygulamaya da sahip olabilir.

Bir sistem tümleştirme olayları tarafından yönlendirilen nihai tutarlılığı kullanıyorsa, bu yaklaşımın son kullanıcıya açıkça açık olması önerilir. Sistem SignalR veya istemciden gelen yoklama sistemleri gibi tümleştirme olaylarını taklit eden bir yaklaşım kullanmamalıdır. Son kullanıcı ve işletme sahibi, sistemde nihai tutarlılığı açıkça benimsemeli ve açık olduğu sürece çoğu durumda işletmenin bu yaklaşımla herhangi bir sorun yaşamadığını fark etmelidir. Bu yaklaşım önemlidir çünkü kullanıcılar bazı sonuçları hemen görmeyi bekleyebilir ve bu özellik nihai tutarlılık ile gerçekleşmeyebilir.

Dağıtılmış veri yönetimi için zorluklar ve çözümler bölümünde daha önce belirtildiği gibi, birden çok mikro hizmete yayılan iş görevlerini uygulamak için tümleştirme olaylarını kullanabilirsiniz. Bu nedenle, bu hizmetler arasında nihai tutarlılık elde edersiniz. Nihai tutarlı bir işlem, dağıtılmış eylemler koleksiyonundan oluşur. Her eylemde, ilgili mikro hizmet bir etki alanı varlığını güncelleştirir ve aynı uçtan uca iş görevi içinde sonraki eylemi tetikleyen başka bir tümleştirme olayı yayımlar.

Önemli bir nokta, aynı olaya abone olan birden çok mikro hizmetle iletişim kurmak isteyebileceğinizdir. Bunu yapmak için, Şekil 4-19'da gösterildiği gibi olay temelli iletişim temelinde yayımlama/abone olma mesajlaşmasını kullanabilirsiniz. Bu yayımlama/abone olma mekanizması mikro hizmet mimarisine özel değildir. Bu, DDD'deki Sınırlanmış Bağlamlar'ın iletişim kurma yöntemine veya güncelleştirmeleri yazma veritabanından Komut ve Sorgu Sorumluluğu Ayrım (CQRS) mimari düzenindeki okuma veritabanına yayma yönteminize benzer. Amaç, dağıtılmış sisteminizdeki birden çok veri kaynağı arasında nihai tutarlılık sağlamaktır.

Diagram showing asynchronous event-driven communications.

Şekil 4-19. Zaman uyumsuz olay temelli ileti iletişimi

Zaman uyumsuz olay odaklı iletişimde, bir mikro hizmet olayları bir olay veri yolu üzerinde yayımlar ve birçok mikro hizmet bildirim almak ve bu konuda işlem yapmak için buna abone olabilir. Uygulamanız, olay odaklı, ileti tabanlı iletişimler için hangi protokolün kullanılacağını belirler. AMQP , güvenilir kuyruğa alınmış iletişimin sağlanmasına yardımcı olabilir.

Bir olay veri yolu kullandığınızda, RabbitMQ gibi bir ileti aracısından API'yi veya KonuLarla Azure Service Bus gibi bir hizmet veri yolunu kullanarak kod içeren sınıflardaki ilgili bir uygulamaya dayalı bir soyutlama düzeyi (olay veri yolu arabirimi gibi) kullanmak isteyebilirsiniz. Alternatif olarak, olay veri yolu ve yayımlama/abone olma sisteminizi ifade etmek için NServiceBus, MassTransit veya Brighter gibi daha üst düzey bir hizmet veri yolu kullanmak isteyebilirsiniz.

Üretim sistemleri için mesajlaşma teknolojileri hakkında bir not

Soyut olay veri yolunu uygulamak için kullanılabilen mesajlaşma teknolojileri farklı düzeylerdedir. Örneğin RabbitMQ (mesajlaşma aracısı taşıma) ve Azure Service Bus gibi ürünler, RabbitMQ ve Azure Service Bus üzerinde çalışabilen NServiceBus, MassTransit veya Brighter gibi diğer ürünlerden daha düşük bir düzeydedir. Seçiminiz, uygulama düzeyinde kaç zengin özelliğe ihtiyacınız olduğuna ve uygulamanız için kullanıma hazır ölçeklenebilirliğe bağlıdır. eShopOnContainers örneğinde olduğu gibi geliştirme ortamınız için yalnızca bir kavram kanıtı olay veri yolu uygulamak için, Docker kapsayıcısında çalışan RabbitMQ üzerinde basit bir uygulama yeterli olabilir.

Ancak hiper ölçeklenebilirlik gerektiren görev açısından kritik sistemler ve üretim sistemleri için Azure Service Bus'ı değerlendirmek isteyebilirsiniz. Dağıtılmış uygulamaların geliştirilmesini kolaylaştıran üst düzey soyutlamalar ve özellikler için NServiceBus, MassTransit ve Brighter gibi diğer ticari ve açık kaynak hizmet otobüslerini değerlendirmenizi öneririz. Elbette RabbitMQ ve Docker gibi alt düzey teknolojilerin üzerine kendi service-bus özelliklerinizi oluşturabilirsiniz. Ancak bu tesisat işi özel bir kurumsal uygulama için çok pahalıya mal olabilir.

Olay veri yolu için dayanıklı bir şekilde yayımlama

Birden çok mikro hizmette olay odaklı bir mimari uygularken karşılaşılan bir zorluk, özgün mikro hizmetteki durumu atomik olarak güncelleştirme ve olay veri yolu üzerinde ilgili tümleştirme olayını bir şekilde işlemlere dayalı olarak yayımlamadır. Ek yaklaşımlar da olsa, bu işlevi gerçekleştirmenin birkaç yolu aşağıdadır.

  • MSMQ gibi işlemsel (DTC tabanlı) bir kuyruk kullanma. (Ancak bu eski bir yaklaşımdır.)

  • İşlem günlüğü madenciliği kullanma.

  • Tam Olay Kaynağını Belirleme deseni kullanma.

  • Giden Kutusu düzenini kullanma: olayı oluşturup yayımlayan bir olay oluşturucu bileşeninin temeli olacak bir ileti kuyruğu olarak işlem veritabanı tablosu.

Hatalı olabilecek verilere sahip iletilerin nasıl yayımlandığı da dahil olmak üzere bu alanda karşılaşılan zorlukların daha eksiksiz bir açıklaması için bkz . Azure'da görev açısından kritik iş yükleri için veri platformu: Her ileti işlenmelidir.

Zaman uyumsuz iletişim kullanılırken dikkate alınması gereken diğer konular, ileti tekliliği ve yinelenenleri kaldırmadır. Bu konular, bu kılavuzun devamında mikro hizmetler (tümleştirme olayları) arasında olay tabanlı iletişim uygulama bölümünde ele alınmıştır.

Ek kaynaklar

Geriİleri