Latest / M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch / Azure Service Bus einfach erklärt: Warteschlangen, Themen, Dead-Letter und zuverlässiges Messaging (KI-Synchronfassung)

Transcript

Azure Service Bus einfach erklärt: Warteschlangen, Themen, Dead-Letter und zuverlässiges Messaging (KI-Synchronfassung) · M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch

0:00
Bereit für 10 Tage Microsoft 365, Co-Pilot, KI Azure und die Menschen, die die Zukunft der Arbeit gestalten?
0:07
Diesen Januar ist die M365-Con zurück und wird noch größer. Und wird noch größer.
0:12
Seien Sie dabei bei Live-Sessions, Demos aus der Praxis und praktischem Wissen von MVPs und Branchenexperten aus aller Welt.
0:18
Keine generischen Folien, keine endlosen Schlagworte.
0:21
Wir stellen uns den echten Herausforderungen. Co-Pilot Studio, KI Agents, Fabric, Sicherheit, Governance und Automatisierung.
0:28
Ganz gleich, ob Sie IT-Experte, Entwickler oder Führungskraft sind, es gibt speziell auf Sie zugeschnittene Sessions.
0:35
An 10 vollen Tagen können Sie verschiedene Technologien kennenlernen und sich mit einer globalen Community vernetzen.
0:40
Sehen Sie sich die Live-Session an und nehmen Sie praktische Einblicke mit nach Hause in Ihr Unternehmen.
0:45
Januar 2027, 10 Tage, eine Microsoft-Community. Die Registrierung ist ab sofort möglich.
0:51
Gehen Sie noch heute zu Ihrem Standort.
0:53
Das ist m3reienden516canton.net.
0:58
Melden Sie sich jetzt unter m3reienden516canton.net an und wir sehen uns im Januar live.
1:05
Stellen Sie sich vor, Sie müssen einem Kollegen eine Nachricht senden.
1:07
Sie gehen hin, geben Ihnen eine Notiz und warten, bis Sie sie lesen und antworten.
1:11
Das funktioniert gut, wenn Sie beide nebeneinander sitzen.
1:13
Aber was ist, wenn Sie sich in einer Besprechung befinden, beim Mittagessen sind oder eine Woche im Urlaub?
1:16
Dann stecken Sie fest.
1:17
Sie können Ihre Arbeit nicht fortsetzen, bis Sie antworten.
1:19
Genau das passiert, wenn zwei Apps direkt miteinander kommunizieren.
1:22
Eine App sendet eine Anforderung ab.
1:24
Wenn die andere App langsam ausgelastet oder abgestürzt ist, bleibt die erste App hängen.
1:27
Entwickler bezeichnen dies als engekommen.
1:30
Die beiden Apps sind miteinander verbunden.
1:31
Wenn eine ausfällt, fällt auch die andere aus.
1:33
In einem System mit Dutzenden von Diensten ist das eine Katastrophe.
1:36
Die Lösung sieht vor, dass der Mittelsmann zählt wird.
1:38
Ein digitaler Puffer, der Nachrichten entgegennimmt, wenn der Absender bereit ist und sie aufbewahrt,
1:41
bis der Empfänger sie verarbeiten kann.
1:42
Dieser Mittelsmann wird als Nachrichtenbroker bezeichnet.
1:44
Und Azure Service Bus ist Microsofts Version dieses Mittelsmanns.
1:48
Was ist eigentlich ein Nachrichtenbroker?
1:50
Also was ist ein Nachrichtenbroker eigentlich?
1:51
Es handelt sich um eine Software, die zwischen Apps sitzt und die Übermittlung von Nachrichten verarbeitet.
1:54
Der Sender sendet eine Nachricht an den Broker und macht dann weiter.
1:57
Keine Wartezeit.
1:58
Der Empfänger holt die Nachricht ab, sobald sie fertig ist.
2:00
Die beiden Seiten kommunizieren nie direkt mit einem.
2:02
Sie kommunizieren mit dem Broker.
2:04
Entwickler nennen das Entkopplung und genau das ist der Sinn.
2:06
Wenn zwei Apps entkoppelt sind, können sie unabhängig voneinander ausfallen.
2:09
Stürzt der Empfänger ab, bemerkt der Sender nicht einmal etwas.
2:12
Die Nachricht liegt einfach im Broker und wartet.
2:13
Wenn der Empfänger wieder online ist, wird dort fortgesetzt, wo er aufgehört hat.
2:16
Kein Datenverlust, keine zu behandeln Fehler.
2:18
Sie können auch unabhängig voneinander skalieren.
2:20
Wenn der Sender mit einer Flut von Datenverkehr konfrontiert wird,
2:22
kann er so schnell weitere Nachrichten senden, wie er möchte.
2:24
Der Broker fängt die Spitze auf.
2:25
Der Empfänger verarbeitet in seinem eigenen Term.
2:28
Zehn Nachrichten pro Minute oder zehntausend.
2:30
Und wenn Sie eine App aktualisieren müssen, können Sie das tun, ohne das gesamte System herunterzufahren.
2:33
Die andere Seite bemerkt keinen Unterschied.
2:35
Hier ist eine einfache Möglichkeit, sich das vorzustellen.
2:37
Sie befinden sich in einem Bürogebäude und müssen ihm einen dritten Stock ein Dokument geben,
2:39
aber diese Person befindet sich in einer Besprechung.
2:41
Sie können vor dem Besprechungsraum warten oder das Dokument am Empfang abgeben.
2:45
Der Empfangsmitarbeiter nimmt es entgegen, Sie gehen zurück an Ihren Schreibtisch
2:48
und das Dokument wird zugestellt, wenn die Person frei ist.
2:50
Der Empfang ist Ihr Nachrichtenvermittler.
2:52
Er nimmt die Nachricht entgegen, bewahrt sie sicher auf und stellt sie zu, wenn der Empfänger bereit ist.
2:57
Azure Service Bus ist die vollständig verwaltete Version dieses Empfangs von Microsoft.
3:01
Vollständig verwaltet bedeutet, dass Sie sich keine Gedanken über die Infrastruktur machen.
3:04
Keine Server, die gepatcht, keine Festplatten ausgetauscht oder Sicherung geplant werden müssen.
3:07
Microsoft kümmert sich um all das.
3:09
Sie erstellen einfach einen Namespace, richten ihre Warteschlangen und Themen ein
3:11
und beginnen mit dem Senden von Nachrichten.
3:13
Das ist serverloses Messaging.
3:14
Sie bezahlen nur für das, was Sie nutzen und müssen sich keine Gedanken über die zugrunde liegende Handlung.
3:17
Wie organisiert dieser Vermittler die Nachrichten?
3:19
Er verwendet zwei Hauptstrukturen, Warteschlangen.
3:22
Beginnen wir mit der einfachsten.
3:24
Der Aufbau einer Nachricht.
3:25
Wir haben die Strukturen behandelt.
3:26
Jetzt sprechen wir darüber, was tatsächlich durch Sie übertragen wird.
3:29
Die Nachricht selbst.
3:31
Stellen Sie sich eine Nachricht in Azure Service Bus als einen Container mit zwei Hauptteilen vor,
3:35
dem Textkörper und den Metadaten.
3:38
Der Textkörper enthält die eigentlichen Daten, also das, was Sie senden.
3:40
Er ist in der Regel als JSON oder XML formatiert.
3:43
Nur Text funktioniert auch.
3:45
Binärdaten werden unterstützt.
3:46
In der Praxis ist JSON jedoch das gängigste Format.
3:49
Es ist für Menschen lesbar, einfach zu bearbeiten und kann von jeder Programmiersprache verarbeitet werden.
3:52
Bei den Metadaten wird es interessant.
3:54
Jede Nachricht verfügt über eine Reihe von Systemeigenschaften, die Service Bus automatisch zuweist.
3:58
Dazu gehören beispielsweise eine eindeutige Nachrichten-ID, ein Zeitstempel, der angeht, wann die Nachricht in der Warteschlange eingereiht wurde
4:03
und eine Sequenznummer, die die Position der Nachricht in der Warteschlange.
4:05
Diese werden vom System verweilt.
4:07
Sie legen sie nicht fest, sie sind einfach vorhanden.
4:08
Sie können aber auch eigene benutzerdefinierte Eigenschaften hinzufügen.
4:11
Dies sind von ihnen definierte Schlüsselwertpaare, beispielsweise Kundenregionen mit dem Wert Europa
4:15
oder Bestellsumme mit dem Wert 922.2992.90 oder Priorität mit dem Wert Hoch.
4:21
Diese benutzerdefinierten Eigenschaften sind für das Filtern von Themen von entscheidender Bedeutung.
4:24
Erinnern Sie sich an die Abonnementfilter, über die wir gesprochen haben?
4:27
Die funktionieren, indem Sie diese benutzerdefinierten Eigenschaften abgleicht.
4:29
Sie legen den Filter fest, der besagt, nur Nachrichten empfangen, bei denen die Kundenregion Europa entspricht.
4:34
Das Abonnement verwendet dann die benutzerdefinierte Eigenschaft, um zu entscheiden, ob die Nachricht akzeptiert wird.
4:38
Es gibt Beschränkungen für die Nachrichtengröße.
4:40
Im Standardtarif kann eine Nachricht bis zu 255 Kilobyte groß sein.
4:44
Das reicht für die meisten Geschäftsdaten, ein Bestelldatensatz, ein Kundenprofil, eine Zahlungsbestätigung, allesamt deutlich unter dieser Beschränkung.
4:49
Wenn Sie mehr benötigen, unterstützt der Premium-Tarif Nachrichten mit einer Größe von bis zu 1.
4:52
Wenn Sie jedoch regelmäßig größere Daten senden, sollten Sie diese wahrscheinlich nicht in eine Nachricht einfügen.
4:57
Speichern Sie die großen Daten an einen anderen Ort und fügen Sie einen Verweis in die Nachricht.
5:00
Das ist das gängige Muster.
5:01
Die geplante Zustellung ist ein nützliches Feature.
5:03
Sie senden jetzt eine Nachricht weisen Servicebus jedoch an, sie erst ab einem bestimmten Zeitpunkt in der Zukunft sichtbar zu machen.
5:07
Stellen Sie sich vor, Sie möchten in 24 Stunden eine Erinnerungs-E-Mail senden.
5:11
Sie senden die Nachricht jetzt mit einer geplanten Wartezeit von morgen.
5:14
Servicebus speichert die Nachricht.
5:15
Sie bleibt unsichtbar, sodass Sie niemand lesen kann.
5:17
Dann wird die Nachricht genau zum geplanten Zeitpunkt in der Warteschlange angezeigt, als wäre sie gerade gesendet worden.
5:21
Dies eignet sich optimal für zeitbasierte Workflows, Erinnerungen, Timeouts und verzögerte Farben.
5:25
Der Lebenszyklus einer Nachricht sieht wie folgt aus.
5:27
Zuerst wird die Nachricht an die Warteschlange oder das Thema gesendet.
5:29
Servicebus speichert die Nachricht dauerhaft und schreibt sie in einen dreifach redundanten Speichern.
5:32
Dann fordert ein Empfänger eine Nachricht an.
5:34
Servicebus sperrt die Nachricht, sodass kein anderer Empfänger sie abrufen kann.
5:37
Der Empfänger verarbeitet die Nachricht.
5:38
Wenn alles gut geht, ruft der Empfänger komplett auf.
5:42
Servicebus löscht die Nachricht.
5:43
Falls etwas schief geht, kann der Empfänger aber in Dorn aufrufen.
5:46
Die Sperre wird aufgehoben und die Nachricht wird für einen erneuten Versuch zurück in die Warteschlange gestellt.
5:49
Falls die Nachricht weiterhin fehlschlägt, wird sie schließlich in die Warteschlange für unzustellbar erschufen.
5:52
Aufgehen wir als nächstes ein.
5:54
Das Wichtigste ist, dass Nachrichten dauerhaft sind.
5:56
Sie verschwinden nicht, wenn ein Empfänger abstürzt.
5:58
Sie gehen nicht verloren, wenn das Netzwerk ausfällt.
6:00
Sie verbleiben sich ein Servicebus, bis sie erfolgreich verarbeitet oder explizit in die Warteschlange für unzustellbare Nachrichten verschoben werden.
6:05
Diese Zuverlässigkeit ist der springende Punkt bei der Verwendung eines Nachrichtenbrokers.
6:10
Erweiterte Features, die den Unterschied machen.
6:12
Sprechen wir nun über die Features, die eine einfache Nachrichtenwarteschlange in eine zuverlässige Plattform verwandeln.
6:16
Beginnen wir mit der Warteschlange für unzustellbare.
6:18
Wir haben bereits erwähnt, dass Nachrichten, die immer wieder fehlschlagen, irgendwann an einen anderen Ort verschoben werden.
6:22
Dieser andere Ort ist die Warteschlange für unzustellbare Nachrichten.
6:24
Stellen Sie sich diese als eine artsame Stelle vor.
6:26
Wenn eine Nachricht die maximale Zustellungsanzahl überschreitet oder abläuft, weil ihre Gültigkeitsdauer abgelaufen ist, verschwindet sie nicht einfach.
6:31
Sie wird in eine separate Unterwarteschlange innerhalb derselben Warteschlange oder derselben Abonnungen.
6:35
Sie können diese Nachrichten überprüfen, herausfinden, was schief gelaufen ist und entscheiden, was zu tun ist.
6:39
Möglicherweise waren die Daten falsch formatiert und Sie müssen das Programm erheben.
6:41
Möglicherweise weiß die Verarbeitungslogik ein Fehler.
6:43
Möglicherweise war das nachgelagerte System ausgefallen und Sie möchten es später erneut versuchen.
6:46
Die Warteschlange für unzustellbare Nachrichten bietet Ihnen ein Notfallblatt.
6:48
Nichts geht unbemerkt verloren. Lassen Sie uns nun ein häufiges Missverständnis über Sitzungen ausräumen.
6:52
Standardmäßig garantiert Azure Service Bus nicht, dass Nachrichten in der richtigen Reihenfolge verarbeitet werden.
6:57
Da ich mir gesagt habe, dass Warteschlangen nach dem FIFO-Prinzip arbeiten, sprich first in, first out.
7:01
Das gilt auch für die Art und Weise, wie eine andere Startreppe.
7:03
Wenn mehrere Konsumer Daten aus derselben Warteschlange abrufen und die Verarbeitung einer Nachricht länger dauert als die einer anderen,
7:08
kann es sein, dass die zweite Nachricht vor der ersten fertig ist.
7:10
Die Reihenfolge geht verloren. Sitzung behebend ist das Problem.
7:13
In einer Sitzung werden zusammengehörige Nachrichten gruppen.
7:15
Sie weisen jeder Nachricht eine Sitzungs-ID zu, beispielsweise eine Kundenbestellnummer oder eine Workflow-Instanz-ID.
7:20
Alle Nachrichten mit derselben Sitzungs-ID werden nacheinander vom selben Consumer verarbeitet.
7:25
Kein anderer Consumer kann Sie berühren. Dadurch erhalten Sie innerhalb dieser Sitzung eine strikte FIFO-Verarbeitung.
7:30
Verschiedene Sitzungen können weiterhin parallel von verschiedenen Consumern verarbeitet werden.
7:34
So bleibt Ihr Durchsatz erhalten, während die Reihenfolge dort, wo es darauf ankommt, erhalten bleibt.
7:37
Die Duplikatserkennung ist ein weiteres Feature.
7:39
Manchmal kommt es zu Netzwerkausfällen.
7:40
Ihre Anwendung sendet eine Nachricht, aber die Antwort geht verloren.
7:43
Daher sendet Ihre App die Nachricht erneut, da sie davon ausgeht, dass die erste nie angekommen.
7:46
Ohne Duplikatserkennung wird diese Nachricht zweimal verarbeitet.
7:50
Mithilfe dieser Funktion merkt sich Servicebus die Nachrichten-ID für ein konfigurierbares Zeitfenster.
7:54
In der Regel bis zu 30 Tage.
7:55
Wenn dieselbe Nachrichten-ID erneut angezeigt wird, wird das Duplikat stillschweigend verworfen.
7:59
Der Empfänger fährt zu keinem Zeitpunkt des erneuten Versuchunternum.
8:01
Mithilfe von Transaktionen können Sie mehrere Vorgänge in eine atomar geordnete Einheit gruppieren.
8:04
Möglicherweise müssen Sie eine Nachricht aus einer Warteschlange abrufen, verarbeiten und ein Ergebnis einer anderen Wartelange.
8:10
Rollback ausgeführt werden. Die Nachricht wird dann an die erste Warteschlange zurückgegeben.
8:13
Das Ergebnis wird nie gesendet. Alles bleibt konsistent.
8:16
Dies ist von entscheidender Bedeutung für Finanzsysteme, bei denen eine teilweise Verarbeitung schlechter ist als gar keine Verarbeitung.
8:20
Mit der automatischen Weiterleitung können Sie Warteschlangen verkennen.
8:22
Nachrichten treffen in einer Warteschlange ein und werden automatisch an eine andere weitergeleitet.
8:26
Dies ist nützlich für den Aufbau von Verarbeitungsbeiblen.
8:28
Eine Rohnachricht geht ein, wird überprüft und dann zur eigentlichen Bearbeitung an eine andere Warteschlange weitergeleitet.
8:32
Die erste Warteschlange bleibt sauber.
8:33
Die zweite Warteschlange übernimmt die Schwerstarbe.
8:35
Mithilfe der Verzögerung können Sie eine Nachricht vorübergehend überspringen.
8:38
Möglicherweise erhalten Sie eine Nachricht, aber die darin referenzierten Daten sind noch nicht bereit.
8:41
In diesem Fall können Sie sie zurückstellen.
8:42
Die verbleibte in der Warteschlange ist aber unsichtbar.
8:44
Später können Sie sie mithilfe der Sequenznummer abrufen und zum richtigen Zeitpunkt verarbeiten.
8:48
Diese Features unterscheiden eine einfache Warteschlange von einem System, auf dem Sie Ihr Unternehmen aufbanken.
8:53
Service-Boss im Vergleich zu Alternativen.
8:55
Wann entscheiden Sie sich für Service-Boss anstelle von etwas anderem?
8:57
Lassen Sie mich aufschlösen.
8:58
Azure Storage Warteschlangen sind die einfachste Option, kostengünstig, schnell und leicht einzurichten.
9:02
Sie sind jedoch begrenzt. Nachrichten sind auf 64 KB begrenzt und Sie erhalten keine Themen, Sitzungen, unzustellbare Nachrichten oder Transaktionen.
9:10
Sie eignen sich hervorragend für einfache Hintergrund-Auftragswarteschlangen, bei denen Sie nur Arbeit auslangen.
9:14
Wenn Sie jedoch eine der erweiterten Funktionen benötigen, über die wir gesprochen haben, werden Sie sich schnell übertreffen.
9:18
Event-Hubs wurde für etwas völlig anderes entwickelt, Event-Streaming, mit hohem Durchsatz.
9:23
Denken Sie an Millionen von Ereignissen pro Sekunde von IoT-Geräten oder Anwendungsprotokoll.
9:26
Er handelt sich nicht um einen Nachrichtenbroker, sondern um eine Datenerfassungspipeline.
9:30
Daher würden Sie sie nicht für Transaktionsworkflows erwähnen.
9:32
Sie verwenden Event-Grid, wenn Sie große Datenströme erfassen und verarbeiten müssen.
9:36
Event-Grid ist die einfache Option, ein Publish-Subscribe-System für ereignisgesteuerte Trigger.
9:41
Wenn ein Blob in den Speicher hochgeladen wird, kann Event-Grid eine Azure-Funktion auslösen.
9:45
Wenn eine Ressource erstellt wird, können andere Dienste benachrichtigt werden.
9:48
Event-Grid ist schnell, kostengünstig und eignet sich perfekt für reaktive Szenarien, ist aber keine Warteschlag.
9:51
Es werden keine Nachrichten zu späteren Verarbeitungen speichern.
9:54
Wenn der Empfänger also ausfällt, geht das Ereignis verloren.
9:56
Servicebus befindet sich genau in der Mitte.
9:58
Es verfügt über die umfangreichen Features eines Enterprise-Brokers ohne die Komplexität, die mit der Verwaltung eines solchen Brokers hängt.
10:02
Wenn Sie Warteschlangen für unzustellbare Nachrichten, Sitzungen, Transaktionen, Themen mit Filtern oder eine garantierte Zustellung benötigen, ist Servicebus die richtige Wahl.
10:09
Wie sieht es mit Kafka aus?
10:10
Das ist ein ganz anderes Thema.
10:11
Servicebus ist für Befehle und Geschäftsworkflows vorgesehen, während Kafka für Ereignis-Streaming und Analysen vorgesehen ist.
10:17
Viele große Systeme verwenden beides.
10:18
Servicebus verarbeitet das operative Messaging Kafka die Datenpipeline.
10:22
Sie ergänzen sich, sie konkurrieren nicht miteinander.
10:24
Hier ist eine einfache Faustregel.
10:25
Wenn Sie sich fragen, wurde diese Nachricht ordnungsgemäß verarbeitet?
10:28
Verwenden Sie Servicebus.
10:30
Wenn Sie sich fragen, kann ich den Ereignis-Strom der letzten Woche erneut abspielen?
10:33
Verwenden Sie Kafka.
10:34
Unterschiedliche Tools von unterschiedlich auf.
10:36
Anwendungsfehler aus der Praxis.
10:37
Verdeutlichen wir dies anhand einiger Beispiele.
10:39
So funktioniert Servicebus in der Produktion.
10:41
Beginnen wir mit E-Commerce.
10:42
Ein Kunde gibt eine Bestellung auf einer Website auf.
10:44
Der Web-Server nimmt diese Bestellung entgegen und sendet sofort eine einzelne Nachricht an eine Servicebus-Warteschlange.
10:48
Anschließend wird dem Kunden mitgeteilt.
10:50
Vielen Dank, Ihre Bestellung wurde bestellt.
10:51
Der Kunde erhält eine schnelle Antwort, ohne warten zu müssen.
10:54
Im Hintergrund ruft ein Pool von Worker-Diensten Daten aus dieser Warteschlange ab.
10:57
Ein Worker verarbeitet die Zahlung, ein anderer überprüft den Lagerbestand, ein weiterer bereitet das Versandetikett vor.
11:02
Jeder Worker ruft die nächste Nachricht ab, erledigt seine Aufgabe und fährt fort.
11:05
Der Kunde sieht davor nichts.
11:07
Er sieht nur die Bestätigung.
11:08
Das ist das klassische asynchrone Verarbeitungsmuster.
11:11
Sofortiges Feedback für den Benutzer, schwere Arbeit im Hintergrund.
11:14
Finanzsysteme gehen noch einen Schritt weiter.
11:16
Die Zahlungsverarbeitung erfordert eine garantierte Zustellung.
11:18
Sie können keine Transaktion verlieren oder zweimal verarbeiten.
11:21
Sie benötigen Bestellung und Transaktion.
11:22
Servicebus bietet Ihnen all das.
11:24
Eine Zahlungsmethode trifft ein, wird verarbeitet und das Ergebnis wird an eine andere Warteschlange gesendet.
11:28
Falls ein Fehler auftritt, wird der gesamte Vorgang zurückgesetzt, sodass das Geld niemals falsch übertragen wird.
11:32
Hier zeigt Servicebus seine Stärke.
11:33
Sie werden nicht nur Daten verschoben, sondern Sie werden auch sicher verschoben.
11:36
Denken Sie nun an die Verteilung mehrerer Dienste.
11:38
Ein neuer Kunde registriert sich auf der Plattform.
11:40
Sie möchten, dass das CRM-System darüber informiert wird, dass das Marketing-System eine Willkommens-E-Mail sendet und dass das Support ihm ein Ticket ist.
11:45
Anstatt drei verschiedene Dienste anzurufen, senden Sie eine Nachricht an ein Thema mit dem Namen Kunde registriert.
11:50
Jeder Dienst verfügt über ein eigenes Abonnement.
11:52
Das CRM-Abonnement akzeptiert alle Nachrichten.
11:54
Das Marketing-Abonnement filtert nur nach Neukunden und das Support-Abonnement nur nach Premium-Kunden.
11:59
Eine Nachricht-3-Reaktion.
12:00
Und wenn Sie später einen vierten Dienst hinzufügen, erstellen Sie einfach ein neues Abonnement.
12:04
Absender ändert sich nie.
12:06
Logistikunternehmen verwenden dies in großem Umfang.
12:07
Stellen Sie sich ein Paketverfolgungssystem vor, bei dem hunderttausende von Lieferwagen alle paar Sekunden Standort Aktualisierungen senden.
12:13
Jede Aktualisierung ist eine Nachricht und die Aktualisierung jedes Pakets muss in der Reihe nach verarbeitet werden.
12:17
Sie können das ausgelieferte Update nicht vor dem zur Auslieferung freigegebenen Update fahren.
12:20
Dies wird über Sitzungen.
12:21
Jedes Paket erhält eine eigene Sitzungs-ID und alle Updates für dieses Paket durchlaufen dieselbe Sitzung der Reihe nach.
12:27
Verschiedene Pakete können weiterhin parallel verarbeitet werden.
12:30
Millionen von Paketen und Milliarden von Updates werden zuverlässig verarbeitet.
12:33
Microservice-Architekturen verwenden Servicebus als Kommunikations-Backbone.
12:37
Dienste rufen sich nicht direkt gegenseitig auf.
12:39
Wir tauschen Nachrichten aus.
12:41
Dienst A sendet einem Befehl eine Wartschlange.
12:43
Dienst B holt ihn ab und erledigt die Arbeit.
12:46
Dienst C veröffentlicht ein Ereignis zu einem Thema und die Dienste D und E reagieren jeweils auf ihre eigene Weise.
12:51
Keine direkten Aufrufe, keine enge Kopplung.
12:53
Jeder Dienst kann aktualisiert, skaliert oder ersetzt werden, ohne dass die anderen davon betroffen sind.
12:57
Hier ist ein Muster, das Sie in älteren Unternehmen beobachten.
12:58
Sie haben ein Legacy-System lokal ausgeführt, das nicht einfach ersetzt werden kann, aber Sie möchten moderne Cloud-Dienste verwenden.
13:04
Daher schließen Sie die Lücke mit Servicebus.
13:05
Das Legacy-System sendet Nachrichten an eine Warteschlange und Cloud-Anwendungen nutzen diese.
13:10
Das alte System weiß nie, dass es mit der Cloud kommuniziert und die Cloud weiß nie, dass sie mit einem alten System kommuniziert.
13:15
Servicebus ist in der Mitte und übersetzt und leitet weiter.
13:17
Die geplante Zustellung verarbeitet die zeltbasierten Aufträge.
13:20
Senden Sie innerhalb von 24 Stunden eine Erinnerungsschule.
13:22
Lassen Sie die Sorte-Servierung nach 30 Minuten ablaufen, wenn sie nicht bestätigt wird.
13:25
Generieren Sie jeden Montag um 8 Uhr einen wöchentlichen Bericht.
13:28
Sie senden die Nachricht jetzt mit einer zukünftigen Zustellungszeit und Servicebus speichert Sie und gibt Sie genau zum richtigen Zeitpunkt frei.
13:33
Keine Kronaufträge, keine Hintergrundtimer, nur eine Nachricht mit einem Timer.
13:36
Der rote Faden all diesen Beispielen ist der Silber.
13:39
Der Absender wartet nicht auf den Empfänger und der Empfänger muss nicht online sein, wenn die Nachricht gesendet wird.
13:44
Sie sind entkoppelt und diese Entkoppelung macht das gesamte System widerstandsfähiger, skalierbarer und leichter zu ändern.
13:49
Das große Ganze, warum alles zusammenpasst.
13:51
Was genau ist Servicebus?
13:53
Es ist das Rückgrat, über das unabhängige Dienste zuverlässig kommunizieren können, ohne voneinander abhängig zu sein.
13:59
Drei Wörter fassen dies zusammen. Entkoppeln, Puffern und Weiterleiten.
14:02
Entkoppeln bedeutet, dass Dienste nichts voneinander wissen müssen.
14:05
Sie kennen nur die Warteschlange oder das Thema.
14:06
Das bedeutet, dass Sie einen Dienst ändern können, ohne die anderen zu beschädigen, einskalieren können, ohne die Übrigen zu beeinträchtigen und Updates für einen Dienst bereitstellen können, während die anderen weiterlaufen.
14:13
Puffer bedeutet, dass die Warteschlange die Last aufnimmt, wenn der Datenverkehrsspitzen aufweist.
14:17
Der Sender sendet mit voller Geschwindigkeit weiter, während der Empfänger in seinem eigenen Tempo verarbeitet, sodass niemand abstürzt oder überlastet wird.
14:23
Der Puffer gleicht die Spitzen aus und füllt die Täler auf.
14:26
Rote bedeutet, dass Warteschlangen Nachrichten an Verbraucher senden, während Themen an viele Verbraucher senden.
14:30
Filter stellen sicher, dass jeder Verbraucher nur das erhält, was er benötigt.
14:33
So findet die Nachricht automatisch den Weg an den richtigen Ort.
14:36
Warteschlangen übernehmen die Punkt-zu-Punkt-Arbeitsverteilung und heben die Übertragung an viele Verbraucher.
14:41
Erweiterte Funktionen behandeln Sonderfälle.
14:43
Fehler werden in die Warteschlange für unzustellbare Nachrichten verschoben, Benutzersitzungen werden sortiert, Duplikate werden erkannt, Transaktionen sorgen für die Konsistenz.