Yayımcı abone deseniPublisher-Subscriber pattern

Bir uygulama birden çok ilgi tüketiciler aynchronously olayları Gönderenler için alıcılar eşlenmesiyle olmadan duyurmaktan etkinleştirin.Enable an application to announce events to multiple interested consumers aynchronously, without coupling the senders to the receivers.

Olarak da adlandırılan: Yayımlama/abonelik mesajıAlso called: Pub/sub messaging

Bağlam ve sorunContext and problem

Bulut tabanlı ve dağıtılmış uygulamalar, sistem bileşenlerinin genellikle olaylar meydana gibi diğer bileşenler için bilgi sağlamanız gerekir.In cloud-based and distributed applications, components of the system often need to provide information to other components as events happen.

Zaman uyumsuz Mesajlaşma tüketiciler göndericilerden ayrıştırmak ve gönderen bir yanıtı bekle engellenmesini önlemek için etkili bir yoludur.Asynchronous messaging is an effective way to decouple senders from consumers, and avoid blocking the sender to wait for a response. Ancak, her tüketici için adanmış bir mesaj kuyruğu kullanımı etkili bir şekilde birçok tüketicilere ölçeklenmez.However, using a dedicated message queue for each consumer does not effectively scale to many consumers. Ayrıca, bazı tüketici yalnızca bir bilgi alt kümesi içinde ilgilenebilecek.Also, some of the consumers might be interested in only a subset of the information. Nasıl gönderen olaylar ilgilenen tüm tüketicilere kimliklerini bilmeden duyurmaktan?How can the sender announce events to all interested consumers without knowing their identities?

ÇözümSolution

Aşağıdakileri içeren bir zaman uyumsuz Mesajlaşma alt tanıtmaktadır:Introduce an asynchronous messaging subsystem that includes the following:

  • Gönderen tarafından kullanılan bir giriş Mesajlaşma kanalı.An input messaging channel used by the sender. Gönderen, bilinen bir ileti biçimini kullanarak olayları iletilere, paketleri ve Giriş kanalı aracılığıyla bu iletiler gönderir.The sender packages events into messages, using a known message format, and sends these messages via the input channel. Bu düzen gönderici olarak da adlandırılır yayımcı.The sender in this pattern is also called the publisher.

    Not

    A ileti veri bir pakettir.A message is a packet of data. Bir olay diğer bileşenleri bir değişiklik ya da gerçekleştirilen bir eylem hakkında uyaran bir ileti.An event is a message that notifies other components about a change or an action that has taken place.

  • Bir tüketici başına gerekli olan Mesajlaşma kanalını çıkış.One output messaging channel per consumer. Tüketiciler olarak bilinen aboneleri.The consumers are known as subscribers.

  • Her iletiyi tüm aboneler bu iletiyi ilgilenen çıkış kanallara giriş kanaldan kopyalamak için bir mekanizma.A mechanism for copying each message from the input channel to the output channels for all subscribers interested in that message. Bu işlem, genellikle bir ileti Aracısı ya da olay veri yolu gibi bir aracı tarafından işlenir.This operation is typically handled by a intermediary such as a message broker or event bus.

Aşağıdaki diyagramda bu düzenin mantıksal bileşenler gösterilmiştir:The following diagram shows the logical components of this pattern:

İleti Aracısı'nı kullanarak yayımla-abone ol desen

Yayımlama/abonelik mesajı aşağıdaki faydaları vardır:Pub/sub messaging has the following benefits:

  • Bu iletişim kurması gereken alt sistemlerin ayırır.It decouples subsystems that still need to communicate. Alt bağımsız olarak yönetilebilir ve bir veya daha fazla alıcıya çevrimdışı olsa bile, iletileri düzgün bir şekilde yönetilebilir.Subsystems can be managed independently, and messages can be properly managed even if one or more receivers are offline.

  • Bu ölçeklenebilirliği artırır ve gönderenin yanıt hızını artırır.It increases scalability and improves responsiveness of the sender. Gönderen hızla giriş kanala tek bir ileti göndermek ve ardından sorumlulukları işleme geliştirilmiştir döndürür.The sender can quickly send a single message to the input channel, then return to its core processing responsibilities. Mesajlaşma altyapısı, iletileri sağlamaktan sorumludur ilgilenen aboneye teslim edilir.The messaging infrastructure is responsible for ensuring messages are delivered to interested subscribers.

  • Güvenilirliği artırır.It improves reliability. Zaman uyumsuz Mesajlaşma, uygulamaların artan yük altında sorunsuz çalışmasını ve aralıklı hatalara daha etkili bir şekilde işlemek devam yardımcı olur.Asynchronous messaging helps applications continue to run smoothly under increased loads and handle intermittent failures more effectively.

  • Ertelenmiş veya zamanlanmış işleme için sağlar.It allows for deferred or scheduled processing. Aboneleri kadar yoğun saatler iletileri alacak şekilde bekleyebilir veya iletileri yönlendirilmesini veya belirli bir zamanlamaya göre işlenir.Subscribers can wait to pick up messages until off-peak hours, or messages can be routed or processed according to a specific schedule.

  • Bu, farklı platformları, programlama dilleri veya iletişim protokolleri kullanan sistemler arasında yanı sıra şirket içi sistemler ile bulutta çalışan uygulamalar arasında daha kolay tümleştirme sağlar.It enables simpler integration between systems using different platforms, programming languages, or communication protocols, as well as between on-premises systems and applications running in the cloud.

  • Bu zaman uyumsuz iş akışları bir kuruluş genelinde kullanılmasını kolaylaştırır.It facilitates asynchronous workflows across an enterprise.

  • Bu Test Edilebilirlik artırır.It improves testability. Kanalları izlenebilir ve iletileri inceledi ya da bir genel tümleştirme test stratejisinin bir parçası günlüğe kaydedilir.Channels can be monitored and messages can be inspected or logged as part of an overall integration test strategy.

  • Bu görev ayrımı nettir uygulamalarınız için sağlar.It provides separation of concerns for your applications. Mesajlaşma altyapısı, iletileri birden fazla tüketici için güvenilir bir şekilde yönlendirmek için gereken her şeyi işlerken her uygulama kendi temel özellikleri üzerinde odaklanabilirsiniz.Each application can focus on its core capabilities, while the messaging infrastructure handles everything required to reliably route messages to multiple consumers.

Sorunlar ve dikkat edilmesi gerekenlerIssues and considerations

Bu düzenin nasıl uygulanacağına karar verirken aşağıdaki noktaları göz önünde bulundurun:Consider the following points when deciding how to implement this pattern:

  • Mevcut teknolojiler için.Existing technologies. Kullanılabilir Mesajlaşma ürünlerini ve Yayımla destekleyen hizmetleri kullanmaya önemle tavsiye edilir-kendi oluşturmak yerine modeli abone olun.It is strongly recommended to use available messaging products and services that support a publish-subscribe model, rather than building your own. Azure'da kullanmayı Service Bus veya Event Grid.In Azure, consider using Service Bus or Event Grid. Redis, RabbitMQ ve Apache Kafka pub/sub iletileri için kullanılabilen diğer teknolojiler içerir.Other technologies that can be used for pub/sub messaging include Redis, RabbitMQ, and Apache Kafka.

  • Abonelik işleme.Subscription handling. Mesajlaşma altyapısı, tüketiciler bunlara abone olmanızı veya kullanılabilir kanalları aboneliği için kullanabileceğiniz bir mekanizma sağlamanız gerekir.The messaging infrastructure must provide mechanisms that consumers can use to subscribe to or unsubscribe from available channels.

  • Güvenlik.Security. Herhangi bir ileti kanal bağlama yetkisiz kullanıcılar veya uygulamalar tarafından gizlice önlemek için güvenlik ilkesi tarafından kısıtlı gerekir.Connecting to any message channel must be restricted by security policy to prevent eavesdropping by unauthorized users or applications.

  • İleti alt kümeleri.Subsets of messages. Aboneleri genellikle yalnızca alt kümesini bir yayımcı tarafından dağıtılan iletileri ilgilendiğiniz.Subscribers are usually only interested in subset of the messages distributed by a publisher. Mesajlaşma Hizmetleri genellikle aboneler tarafından alınan iletilerin kümesini daraltmak izin ver:Messaging services often allow subscribers to narrow the set of messages received by:

    • Konuları.Topics. Adanmış Çıkış kanalı her konu vardır ve her tüketici, tüm ilgili konular için abone olabilirsiniz.Each topic has a dedicated output channel, and each consumer can subscribe to all relevant topics.
    • İçerik filtreleme.Content filtering. İletiler inceledi ve dağıtılmış her ileti içeriğine göre.Messages are inspected and distributed based on the content of each message. Her abone, ilgileniyor içeriği belirtebilirsiniz.Each subscriber can specify the content it is interested in.
  • Joker karakter kullanan aboneler.Wildcard subscribers. Joker karakterler aracılığıyla birden çok konu abone olmak abonelerin göz önünde bulundurun.Consider allowing subscribers to subscribe to multiple topics via wildcards.

  • Çift yönlü iletişimi.Bi-directional communication. Kanalları bir Yayımla-abone sistem tek yönlü olarak kabul edilir.The channels in a publish-subscribe system are treated as unidirectional. Belirli bir üye bildirim göndermek veya durumu geri yayımcıya iletişim gerekiyorsa kullanmayı istek/yanıt deseni.If a specific subscriber needs to send acknowledgement or communicate status back to the publisher, consider using the Request/Reply Pattern. Bu düzen abone için bir ileti göndermek için bir kanal yanı sıra, ayrı yanıt kanalına yayımcıya iletişim kurmak için kullanılır.This pattern uses one channel to send a message to the subscriber, and a separate reply channel for communicating back to the publisher.

  • İleti sırası.Message ordering. Tüketici örnekleri iletiler aldıkları sırasını garanti yoktur ve mutlaka içinde mesajların oluşturulma sırasını yansıtmaz.The order in which consumer instances receive messages isn't guaranteed, and doesn't necessarily reflect the order in which the messages were created. İleti işleme ileti işleme sırasına bağımlılığın ortadan yardımcı olmak için etkili olmasını sağlamak için sistem tasarlayın.Design the system to ensure that message processing is idempotent to help eliminate any dependency on the order of message handling.

  • İleti önceliği.Message priority. Bazı çözümler, iletileri belirli bir sırayla işlenir gerektirebilir.Some solutions may require that messages are processed in a specific order. Öncelikli kuyruk düzeni belirli iletileri sağlamaya yönelik bir mekanizma sağlar önce teslim edilir.The Priority Queue pattern provides a mechanism for ensuring specific messages are delivered before others.

  • Zehirli iletiler.Poison messages. Hatalı biçimlendirilmiş bir ileti veya kullanılabilir durumda olmayan kaynaklara erişim gerektiren bir görev, bir hizmet örneğinin başarısız olmasına yol açabilir.A malformed message, or a task that requires access to resources that aren't available, can cause a service instance to fail. Sistem böyle iletilerin kuyruğa döndürülmesi engeller.The system should prevent such messages being returned to the queue. Bunun yerine, yakalayın ve gerekirse çözümlenebilir için bu iletilerin ayrıntıları başka bir yerde depolayın.Instead, capture and store the details of these messages elsewhere so that they can be analyzed if necessary.

  • Yinelenen iletileri.Repeated messages. Aynı mesajın birden fazla kez gönderilebilir.The same message might be sent more than once. Örneğin, gönderen bir ileti gönderdikten sonra başarısız olabilir.For example, the sender might fail after posting a message. Ardından gönderen yeni bir örneğini bir başlatma ve ileti yineleyin.Then a new instance of the sender might start up and repeat the message. Mesajlaşma altyapısı, algılama ve kaldırma (diğer adıyla XML'deki duping) ileti kimliklerine göre en çoğu kez İleti teslimini sağlamak için temel yinelenen ileti uygulamalıdır.The messaging infrastructure should implement duplicate message detection and removal (also known as de-duping) based on message IDs in order to provide at-most-once delivery of messages.

  • İleti süre sonu.Message expiration. Bir ileti, sınırlı bir ömre sahip olabilir.A message might have a limited lifetime. Bu süre içinde işlenen değil, artık ilgili olabilir ve atılmalıdır.If it isn't processed within this period, it might no longer be relevant and should be discarded. Bir gönderici experiation zaman verileri bir parçası olarak belirtebilirsiniz.A sender can specify an experiation time as part of the data in the message. Bir alıcı karar iletiyle ilişkili iş mantığını gerçekleştirmek önce bu bilgileri inceleyebilirsiniz.A receiver can examine this information before deciding whether to perform the business logic associated with the message.

  • İleti zamanlama.Message scheduling. Bir ileti geçici olarak embargoed ve belirli bir tarih ve saate kadar işlenmemesi.A message might be temporarily embargoed and should not be processed until a specific date and time. İleti bu zamana kadar için bir alıcı mevcut olmamalıdır.The message should not be available to a receiver until this time.

Bu düzenin kullanılacağı durumlarWhen to use this pattern

Bu düzeni aşağıdaki durumlarda kullanın:Use this pattern when:

  • Tüketiciler için çok sayıda bilgi yayınlamak bir uygulama gerekir.An application needs to broadcast information to a significant number of consumers.

  • Bir veya daha fazla bağımsız çalışmalarla geliştirilen uygulamalar ya da farklı platformlar ve programlama dilleri iletişim protokolleri kullanabilir Hizmetleri ile iletişim kurmak bir uygulama gerekir.An application needs to communicate with one or more independently-developed applications or services, which may use different platforms, programming languages, and communication protocols.

  • Uygulama bilgileri gerçek zamanlı yanıtlar tüketicilerden gerek kalmadan tüketicilere gönderebilirsiniz.An application can send information to consumers without requiring real-time responses from the consumers.

  • Tümleşik sistemler, veriler için bir son tutarlılık modelini desteklemek için tasarlanmıştır.The systems being integrated are designed to support an eventual consistency model for their data.

  • Farklı kullanılabilirlik gereksinimleri veya çalışma süresini zamanlamaları gönderen'den sahip olabilecek birden fazla tüketici bilgiler iletmek bir uygulama gerekir.An application needs to communicate information to multiple consumers, which may have different availability requirements or uptime schedules than the sender.

Bu düzen aşağıdaki durumlarda kullanışlı olmayabilir:This pattern might not be useful when:

  • Bir uygulama oluşturmayan uygulamasından önemli ölçüde farklı bilgi ihtiyaç duyan birkaç tüketiciler sahiptir.An application has only a few consumers who need significantly different information from the producing application.

  • Bir uygulama, neredeyse gerçek zamanlı etkileşime tüketiciler gerektirir.An application requires near real-time interaction with consumers.

ÖrnekExample

İş akışları koordine etmek için Service Bus kullanan bir kurumsal tümleştirme mimarisi Aşağıdaki diyagramda gösterilmiştir ve Event Grid, alt sistemlerde gerçekleşen olayların bildirir.The following diagram shows an enterprise integration architecture that uses Service Bus to coordinate workflows, and Event Grid notify subsystems of events that occur. Daha fazla bilgi için kullanarak Azure üzerinde Kurumsal tümleştirme ileti kuyrukları ve olayları.For more information, see Enterprise integration on Azure using message queues and events.

Kurumsal tümleştirme mimarisi

Bu düzen uygulanırken aşağıdaki düzenler ve yönergeler yararlı olabilir:The following patterns and guidance might be relevant when implementing this pattern:

  • İletileri teslim Azure hizmetleri arasında seçim.Choose between Azure services that deliver messages.

  • Olay denetimli mimari stili pub/sub Mesajlaşma deposu kullanan bir mimari stilidir.The Event-driven architecture style is an architecture style that uses pub/sub messaging.

  • Zaman Uyumsuz Mesajlaşma Temel Bilgileri.Asynchronous Messaging Primer. Mesaj kuyrukları zaman uyumsuz bir iletişim mekanizmasıdır.Message queues are an asynchronous communications mechanism. Bir tüketici hizmetinin bir uygulamaya yanıt göndermesi gerekiyorsa bir tür yanıt mesajlaşması uygulamak gerekebilir.If a consumer service needs to send a reply to an application, it might be necessary to implement some form of response messaging. Zaman Uyumsuz Mesajlaşma Temel Bilgileri sayfasında mesaj kuyrukları kullanılarak nasıl istek/yanıt mesajlaşması uygulanabileceği hakkında bilgi sağlanmaktadır.The Asynchronous Messaging Primer provides information on how to implement request/reply messaging using message queues.

  • Gözlemci deseni.Observer Pattern. Yayımlama-abone olma deseni, zaman uyumsuz Mesajlaşma aracılığıyla gözlemciler gelen konuları ayrıştırarak gözlemci deseni temel oluşturur.The Publish-Subscribe pattern builds on the Observer pattern by decoupling subjects from observers via asynchronous messaging.

  • İleti Aracısı deseni.Message Broker Pattern. Yayımla destekleyen çok sayıda ileti alt-abone ol modek bir ileti Aracısı uygulanır.Many messaging subsystems that support a publish-subscribe modek are implemented via a message broker.