WEBVTT 00:00:00.300 --> 00:00:06.740 Bereit für 10 Tage Microsoft 365, Co-Pilot, KI Azure und die Menschen, die die Zukunft der Arbeit gestalten? 00:00:07.520 --> 00:00:12.300 Diesen Januar ist die M365-Con zurück und wird noch größer. Und wird noch größer. 00:00:12.920 --> 00:00:17.900 Seien Sie dabei bei Live-Sessions, Demos aus der Praxis und praktischem Wissen von MVPs und Branchenexperten aus aller Welt. 00:00:18.720 --> 00:00:21.160 Keine generischen Folien, keine endlosen Schlagworte. 00:00:21.900 --> 00:00:28.740 Wir stellen uns den echten Herausforderungen. Co-Pilot Studio, KI Agents, Fabric, Sicherheit, Governance und Automatisierung. 00:00:28.740 --> 00:00:34.180 Ganz gleich, ob Sie IT-Experte, Entwickler oder Führungskraft sind, es gibt speziell auf Sie zugeschnittene Sessions. 00:00:35.460 --> 00:00:39.920 An 10 vollen Tagen können Sie verschiedene Technologien kennenlernen und sich mit einer globalen Community vernetzen. 00:00:40.920 --> 00:00:44.240 Sehen Sie sich die Live-Session an und nehmen Sie praktische Einblicke mit nach Hause in Ihr Unternehmen. 00:00:45.160 --> 00:00:50.580 Januar 2027, 10 Tage, eine Microsoft-Community. Die Registrierung ist ab sofort möglich. 00:00:51.680 --> 00:00:52.940 Gehen Sie noch heute zu Ihrem Standort. 00:00:53.940 --> 00:00:58.180 Das ist m3reienden516canton.net. 00:00:58.740 --> 00:01:04.420 Melden Sie sich jetzt unter m3reienden516canton.net an und wir sehen uns im Januar live. 00:01:05.060 --> 00:01:07.340 Stellen Sie sich vor, Sie müssen einem Kollegen eine Nachricht senden. 00:01:07.700 --> 00:01:11.160 Sie gehen hin, geben Ihnen eine Notiz und warten, bis Sie sie lesen und antworten. 00:01:11.480 --> 00:01:12.980 Das funktioniert gut, wenn Sie beide nebeneinander sitzen. 00:01:13.320 --> 00:01:16.260 Aber was ist, wenn Sie sich in einer Besprechung befinden, beim Mittagessen sind oder eine Woche im Urlaub? 00:01:16.560 --> 00:01:17.100 Dann stecken Sie fest. 00:01:17.420 --> 00:01:19.380 Sie können Ihre Arbeit nicht fortsetzen, bis Sie antworten. 00:01:19.820 --> 00:01:21.940 Genau das passiert, wenn zwei Apps direkt miteinander kommunizieren. 00:01:22.180 --> 00:01:23.740 Eine App sendet eine Anforderung ab. 00:01:24.020 --> 00:01:27.500 Wenn die andere App langsam ausgelastet oder abgestürzt ist, bleibt die erste App hängen. 00:01:27.500 --> 00:01:29.560 Entwickler bezeichnen dies als engekommen. 00:01:30.020 --> 00:01:31.140 Die beiden Apps sind miteinander verbunden. 00:01:31.620 --> 00:01:33.100 Wenn eine ausfällt, fällt auch die andere aus. 00:01:33.520 --> 00:01:35.960 In einem System mit Dutzenden von Diensten ist das eine Katastrophe. 00:01:36.420 --> 00:01:37.740 Die Lösung sieht vor, dass der Mittelsmann zählt wird. 00:01:38.040 --> 00:01:41.380 Ein digitaler Puffer, der Nachrichten entgegennimmt, wenn der Absender bereit ist und sie aufbewahrt, 00:01:41.420 --> 00:01:42.460 bis der Empfänger sie verarbeiten kann. 00:01:42.760 --> 00:01:44.380 Dieser Mittelsmann wird als Nachrichtenbroker bezeichnet. 00:01:44.720 --> 00:01:47.160 Und Azure Service Bus ist Microsofts Version dieses Mittelsmanns. 00:01:48.040 --> 00:01:49.320 Was ist eigentlich ein Nachrichtenbroker? 00:01:50.000 --> 00:01:51.280 Also was ist ein Nachrichtenbroker eigentlich? 00:01:51.440 --> 00:01:54.900 Es handelt sich um eine Software, die zwischen Apps sitzt und die Übermittlung von Nachrichten verarbeitet. 00:01:54.900 --> 00:01:57.260 Der Sender sendet eine Nachricht an den Broker und macht dann weiter. 00:01:57.860 --> 00:01:58.500 Keine Wartezeit. 00:01:58.800 --> 00:02:00.520 Der Empfänger holt die Nachricht ab, sobald sie fertig ist. 00:02:00.980 --> 00:02:02.460 Die beiden Seiten kommunizieren nie direkt mit einem. 00:02:02.960 --> 00:02:03.880 Sie kommunizieren mit dem Broker. 00:02:04.320 --> 00:02:06.160 Entwickler nennen das Entkopplung und genau das ist der Sinn. 00:02:06.640 --> 00:02:09.120 Wenn zwei Apps entkoppelt sind, können sie unabhängig voneinander ausfallen. 00:02:09.660 --> 00:02:11.460 Stürzt der Empfänger ab, bemerkt der Sender nicht einmal etwas. 00:02:12.000 --> 00:02:13.400 Die Nachricht liegt einfach im Broker und wartet. 00:02:13.920 --> 00:02:16.300 Wenn der Empfänger wieder online ist, wird dort fortgesetzt, wo er aufgehört hat. 00:02:16.760 --> 00:02:18.160 Kein Datenverlust, keine zu behandeln Fehler. 00:02:18.560 --> 00:02:19.920 Sie können auch unabhängig voneinander skalieren. 00:02:20.380 --> 00:02:22.400 Wenn der Sender mit einer Flut von Datenverkehr konfrontiert wird, 00:02:22.400 --> 00:02:23.960 kann er so schnell weitere Nachrichten senden, wie er möchte. 00:02:24.400 --> 00:02:25.420 Der Broker fängt die Spitze auf. 00:02:25.900 --> 00:02:27.520 Der Empfänger verarbeitet in seinem eigenen Term. 00:02:28.060 --> 00:02:29.680 Zehn Nachrichten pro Minute oder zehntausend. 00:02:30.000 --> 00:02:33.340 Und wenn Sie eine App aktualisieren müssen, können Sie das tun, ohne das gesamte System herunterzufahren. 00:02:33.620 --> 00:02:34.720 Die andere Seite bemerkt keinen Unterschied. 00:02:35.220 --> 00:02:37.100 Hier ist eine einfache Möglichkeit, sich das vorzustellen. 00:02:37.180 --> 00:02:39.860 Sie befinden sich in einem Bürogebäude und müssen ihm einen dritten Stock ein Dokument geben, 00:02:39.940 --> 00:02:41.260 aber diese Person befindet sich in einer Besprechung. 00:02:41.400 --> 00:02:45.320 Sie können vor dem Besprechungsraum warten oder das Dokument am Empfang abgeben. 00:02:45.880 --> 00:02:48.460 Der Empfangsmitarbeiter nimmt es entgegen, Sie gehen zurück an Ihren Schreibtisch 00:02:48.460 --> 00:02:50.100 und das Dokument wird zugestellt, wenn die Person frei ist. 00:02:50.100 --> 00:02:51.920 Der Empfang ist Ihr Nachrichtenvermittler. 00:02:52.660 --> 00:02:56.300 Er nimmt die Nachricht entgegen, bewahrt sie sicher auf und stellt sie zu, wenn der Empfänger bereit ist. 00:02:57.300 --> 00:03:00.660 Azure Service Bus ist die vollständig verwaltete Version dieses Empfangs von Microsoft. 00:03:01.600 --> 00:03:04.260 Vollständig verwaltet bedeutet, dass Sie sich keine Gedanken über die Infrastruktur machen. 00:03:04.440 --> 00:03:07.360 Keine Server, die gepatcht, keine Festplatten ausgetauscht oder Sicherung geplant werden müssen. 00:03:07.640 --> 00:03:08.760 Microsoft kümmert sich um all das. 00:03:09.120 --> 00:03:11.580 Sie erstellen einfach einen Namespace, richten ihre Warteschlangen und Themen ein 00:03:11.580 --> 00:03:12.840 und beginnen mit dem Senden von Nachrichten. 00:03:13.040 --> 00:03:14.040 Das ist serverloses Messaging. 00:03:14.420 --> 00:03:17.320 Sie bezahlen nur für das, was Sie nutzen und müssen sich keine Gedanken über die zugrunde liegende Handlung. 00:03:17.320 --> 00:03:19.380 Wie organisiert dieser Vermittler die Nachrichten? 00:03:19.740 --> 00:03:21.620 Er verwendet zwei Hauptstrukturen, Warteschlangen. 00:03:22.240 --> 00:03:23.240 Beginnen wir mit der einfachsten. 00:03:24.120 --> 00:03:25.040 Der Aufbau einer Nachricht. 00:03:25.500 --> 00:03:26.460 Wir haben die Strukturen behandelt. 00:03:26.840 --> 00:03:28.980 Jetzt sprechen wir darüber, was tatsächlich durch Sie übertragen wird. 00:03:29.160 --> 00:03:29.860 Die Nachricht selbst. 00:03:31.760 --> 00:03:35.360 Stellen Sie sich eine Nachricht in Azure Service Bus als einen Container mit zwei Hauptteilen vor, 00:03:35.440 --> 00:03:37.500 dem Textkörper und den Metadaten. 00:03:38.500 --> 00:03:40.900 Der Textkörper enthält die eigentlichen Daten, also das, was Sie senden. 00:03:40.900 --> 00:03:43.380 Er ist in der Regel als JSON oder XML formatiert. 00:03:43.860 --> 00:03:44.740 Nur Text funktioniert auch. 00:03:45.380 --> 00:03:46.500 Binärdaten werden unterstützt. 00:03:46.660 --> 00:03:48.600 In der Praxis ist JSON jedoch das gängigste Format. 00:03:49.000 --> 00:03:52.340 Es ist für Menschen lesbar, einfach zu bearbeiten und kann von jeder Programmiersprache verarbeitet werden. 00:03:52.740 --> 00:03:54.080 Bei den Metadaten wird es interessant. 00:03:54.820 --> 00:03:58.300 Jede Nachricht verfügt über eine Reihe von Systemeigenschaften, die Service Bus automatisch zuweist. 00:03:58.960 --> 00:04:03.520 Dazu gehören beispielsweise eine eindeutige Nachrichten-ID, ein Zeitstempel, der angeht, wann die Nachricht in der Warteschlange eingereiht wurde 00:04:03.520 --> 00:04:05.700 und eine Sequenznummer, die die Position der Nachricht in der Warteschlange. 00:04:05.960 --> 00:04:07.040 Diese werden vom System verweilt. 00:04:07.340 --> 00:04:08.720 Sie legen sie nicht fest, sie sind einfach vorhanden. 00:04:08.720 --> 00:04:11.160 Sie können aber auch eigene benutzerdefinierte Eigenschaften hinzufügen. 00:04:11.560 --> 00:04:15.620 Dies sind von ihnen definierte Schlüsselwertpaare, beispielsweise Kundenregionen mit dem Wert Europa 00:04:15.620 --> 00:04:21.060 oder Bestellsumme mit dem Wert 922.2992.90 oder Priorität mit dem Wert Hoch. 00:04:21.800 --> 00:04:24.580 Diese benutzerdefinierten Eigenschaften sind für das Filtern von Themen von entscheidender Bedeutung. 00:04:24.900 --> 00:04:26.740 Erinnern Sie sich an die Abonnementfilter, über die wir gesprochen haben? 00:04:27.080 --> 00:04:29.580 Die funktionieren, indem Sie diese benutzerdefinierten Eigenschaften abgleicht. 00:04:29.880 --> 00:04:33.940 Sie legen den Filter fest, der besagt, nur Nachrichten empfangen, bei denen die Kundenregion Europa entspricht. 00:04:34.320 --> 00:04:38.320 Das Abonnement verwendet dann die benutzerdefinierte Eigenschaft, um zu entscheiden, ob die Nachricht akzeptiert wird. 00:04:38.720 --> 00:04:40.040 Es gibt Beschränkungen für die Nachrichtengröße. 00:04:40.280 --> 00:04:43.520 Im Standardtarif kann eine Nachricht bis zu 255 Kilobyte groß sein. 00:04:44.100 --> 00:04:49.000 Das reicht für die meisten Geschäftsdaten, ein Bestelldatensatz, ein Kundenprofil, eine Zahlungsbestätigung, allesamt deutlich unter dieser Beschränkung. 00:04:49.400 --> 00:04:52.400 Wenn Sie mehr benötigen, unterstützt der Premium-Tarif Nachrichten mit einer Größe von bis zu 1. 00:04:52.760 --> 00:04:56.900 Wenn Sie jedoch regelmäßig größere Daten senden, sollten Sie diese wahrscheinlich nicht in eine Nachricht einfügen. 00:04:57.440 --> 00:05:00.140 Speichern Sie die großen Daten an einen anderen Ort und fügen Sie einen Verweis in die Nachricht. 00:05:00.380 --> 00:05:01.180 Das ist das gängige Muster. 00:05:01.180 --> 00:05:03.020 Die geplante Zustellung ist ein nützliches Feature. 00:05:03.420 --> 00:05:07.540 Sie senden jetzt eine Nachricht weisen Servicebus jedoch an, sie erst ab einem bestimmten Zeitpunkt in der Zukunft sichtbar zu machen. 00:05:07.920 --> 00:05:10.860 Stellen Sie sich vor, Sie möchten in 24 Stunden eine Erinnerungs-E-Mail senden. 00:05:11.120 --> 00:05:13.880 Sie senden die Nachricht jetzt mit einer geplanten Wartezeit von morgen. 00:05:14.540 --> 00:05:15.560 Servicebus speichert die Nachricht. 00:05:15.640 --> 00:05:17.060 Sie bleibt unsichtbar, sodass Sie niemand lesen kann. 00:05:17.400 --> 00:05:21.100 Dann wird die Nachricht genau zum geplanten Zeitpunkt in der Warteschlange angezeigt, als wäre sie gerade gesendet worden. 00:05:21.620 --> 00:05:25.120 Dies eignet sich optimal für zeitbasierte Workflows, Erinnerungen, Timeouts und verzögerte Farben. 00:05:25.540 --> 00:05:27.220 Der Lebenszyklus einer Nachricht sieht wie folgt aus. 00:05:27.220 --> 00:05:29.260 Zuerst wird die Nachricht an die Warteschlange oder das Thema gesendet. 00:05:29.620 --> 00:05:32.560 Servicebus speichert die Nachricht dauerhaft und schreibt sie in einen dreifach redundanten Speichern. 00:05:32.800 --> 00:05:34.180 Dann fordert ein Empfänger eine Nachricht an. 00:05:34.600 --> 00:05:37.040 Servicebus sperrt die Nachricht, sodass kein anderer Empfänger sie abrufen kann. 00:05:37.300 --> 00:05:38.480 Der Empfänger verarbeitet die Nachricht. 00:05:38.960 --> 00:05:40.960 Wenn alles gut geht, ruft der Empfänger komplett auf. 00:05:42.060 --> 00:05:43.040 Servicebus löscht die Nachricht. 00:05:43.600 --> 00:05:45.760 Falls etwas schief geht, kann der Empfänger aber in Dorn aufrufen. 00:05:46.260 --> 00:05:49.320 Die Sperre wird aufgehoben und die Nachricht wird für einen erneuten Versuch zurück in die Warteschlange gestellt. 00:05:49.780 --> 00:05:52.780 Falls die Nachricht weiterhin fehlschlägt, wird sie schließlich in die Warteschlange für unzustellbar erschufen. 00:05:52.780 --> 00:05:53.980 Aufgehen wir als nächstes ein. 00:05:54.400 --> 00:05:56.160 Das Wichtigste ist, dass Nachrichten dauerhaft sind. 00:05:56.560 --> 00:05:58.060 Sie verschwinden nicht, wenn ein Empfänger abstürzt. 00:05:58.340 --> 00:05:59.940 Sie gehen nicht verloren, wenn das Netzwerk ausfällt. 00:06:00.240 --> 00:06:05.420 Sie verbleiben sich ein Servicebus, bis sie erfolgreich verarbeitet oder explizit in die Warteschlange für unzustellbare Nachrichten verschoben werden. 00:06:05.640 --> 00:06:08.660 Diese Zuverlässigkeit ist der springende Punkt bei der Verwendung eines Nachrichtenbrokers. 00:06:10.060 --> 00:06:11.500 Erweiterte Features, die den Unterschied machen. 00:06:12.080 --> 00:06:16.180 Sprechen wir nun über die Features, die eine einfache Nachrichtenwarteschlange in eine zuverlässige Plattform verwandeln. 00:06:16.480 --> 00:06:18.020 Beginnen wir mit der Warteschlange für unzustellbare. 00:06:18.020 --> 00:06:22.200 Wir haben bereits erwähnt, dass Nachrichten, die immer wieder fehlschlagen, irgendwann an einen anderen Ort verschoben werden. 00:06:22.200 --> 00:06:24.440 Dieser andere Ort ist die Warteschlange für unzustellbare Nachrichten. 00:06:24.640 --> 00:06:25.940 Stellen Sie sich diese als eine artsame Stelle vor. 00:06:26.200 --> 00:06:31.280 Wenn eine Nachricht die maximale Zustellungsanzahl überschreitet oder abläuft, weil ihre Gültigkeitsdauer abgelaufen ist, verschwindet sie nicht einfach. 00:06:31.760 --> 00:06:34.900 Sie wird in eine separate Unterwarteschlange innerhalb derselben Warteschlange oder derselben Abonnungen. 00:06:35.300 --> 00:06:38.960 Sie können diese Nachrichten überprüfen, herausfinden, was schief gelaufen ist und entscheiden, was zu tun ist. 00:06:39.380 --> 00:06:41.580 Möglicherweise waren die Daten falsch formatiert und Sie müssen das Programm erheben. 00:06:41.920 --> 00:06:43.420 Möglicherweise weiß die Verarbeitungslogik ein Fehler. 00:06:43.740 --> 00:06:46.340 Möglicherweise war das nachgelagerte System ausgefallen und Sie möchten es später erneut versuchen. 00:06:46.340 --> 00:06:48.680 Die Warteschlange für unzustellbare Nachrichten bietet Ihnen ein Notfallblatt. 00:06:48.680 --> 00:06:52.620 Nichts geht unbemerkt verloren. Lassen Sie uns nun ein häufiges Missverständnis über Sitzungen ausräumen. 00:06:52.960 --> 00:06:56.660 Standardmäßig garantiert Azure Service Bus nicht, dass Nachrichten in der richtigen Reihenfolge verarbeitet werden. 00:06:57.180 --> 00:06:59.980 Da ich mir gesagt habe, dass Warteschlangen nach dem FIFO-Prinzip arbeiten, sprich first in, first out. 00:07:01.080 --> 00:07:02.580 Das gilt auch für die Art und Weise, wie eine andere Startreppe. 00:07:03.680 --> 00:07:08.420 Wenn mehrere Konsumer Daten aus derselben Warteschlange abrufen und die Verarbeitung einer Nachricht länger dauert als die einer anderen, 00:07:08.700 --> 00:07:10.600 kann es sein, dass die zweite Nachricht vor der ersten fertig ist. 00:07:10.940 --> 00:07:13.380 Die Reihenfolge geht verloren. Sitzung behebend ist das Problem. 00:07:13.380 --> 00:07:15.480 In einer Sitzung werden zusammengehörige Nachrichten gruppen. 00:07:15.880 --> 00:07:20.320 Sie weisen jeder Nachricht eine Sitzungs-ID zu, beispielsweise eine Kundenbestellnummer oder eine Workflow-Instanz-ID. 00:07:20.740 --> 00:07:25.100 Alle Nachrichten mit derselben Sitzungs-ID werden nacheinander vom selben Consumer verarbeitet. 00:07:25.920 --> 00:07:30.080 Kein anderer Consumer kann Sie berühren. Dadurch erhalten Sie innerhalb dieser Sitzung eine strikte FIFO-Verarbeitung. 00:07:30.440 --> 00:07:33.660 Verschiedene Sitzungen können weiterhin parallel von verschiedenen Consumern verarbeitet werden. 00:07:34.020 --> 00:07:36.900 So bleibt Ihr Durchsatz erhalten, während die Reihenfolge dort, wo es darauf ankommt, erhalten bleibt. 00:07:37.160 --> 00:07:38.640 Die Duplikatserkennung ist ein weiteres Feature. 00:07:39.160 --> 00:07:40.280 Manchmal kommt es zu Netzwerkausfällen. 00:07:40.280 --> 00:07:43.200 Ihre Anwendung sendet eine Nachricht, aber die Antwort geht verloren. 00:07:43.680 --> 00:07:46.400 Daher sendet Ihre App die Nachricht erneut, da sie davon ausgeht, dass die erste nie angekommen. 00:07:46.740 --> 00:07:49.240 Ohne Duplikatserkennung wird diese Nachricht zweimal verarbeitet. 00:07:50.080 --> 00:07:53.900 Mithilfe dieser Funktion merkt sich Servicebus die Nachrichten-ID für ein konfigurierbares Zeitfenster. 00:07:54.060 --> 00:07:55.100 In der Regel bis zu 30 Tage. 00:07:55.640 --> 00:07:58.760 Wenn dieselbe Nachrichten-ID erneut angezeigt wird, wird das Duplikat stillschweigend verworfen. 00:07:59.180 --> 00:08:01.040 Der Empfänger fährt zu keinem Zeitpunkt des erneuten Versuchunternum. 00:08:01.360 --> 00:08:04.460 Mithilfe von Transaktionen können Sie mehrere Vorgänge in eine atomar geordnete Einheit gruppieren. 00:08:04.780 --> 00:08:08.620 Möglicherweise müssen Sie eine Nachricht aus einer Warteschlange abrufen, verarbeiten und ein Ergebnis einer anderen Wartelange. 00:08:10.280 --> 00:08:13.060 Rollback ausgeführt werden. Die Nachricht wird dann an die erste Warteschlange zurückgegeben. 00:08:13.400 --> 00:08:15.600 Das Ergebnis wird nie gesendet. Alles bleibt konsistent. 00:08:16.060 --> 00:08:20.240 Dies ist von entscheidender Bedeutung für Finanzsysteme, bei denen eine teilweise Verarbeitung schlechter ist als gar keine Verarbeitung. 00:08:20.560 --> 00:08:22.400 Mit der automatischen Weiterleitung können Sie Warteschlangen verkennen. 00:08:22.680 --> 00:08:25.940 Nachrichten treffen in einer Warteschlange ein und werden automatisch an eine andere weitergeleitet. 00:08:26.260 --> 00:08:28.080 Dies ist nützlich für den Aufbau von Verarbeitungsbeiblen. 00:08:28.480 --> 00:08:32.340 Eine Rohnachricht geht ein, wird überprüft und dann zur eigentlichen Bearbeitung an eine andere Warteschlange weitergeleitet. 00:08:32.660 --> 00:08:33.680 Die erste Warteschlange bleibt sauber. 00:08:33.960 --> 00:08:35.480 Die zweite Warteschlange übernimmt die Schwerstarbe. 00:08:35.900 --> 00:08:38.060 Mithilfe der Verzögerung können Sie eine Nachricht vorübergehend überspringen. 00:08:38.460 --> 00:08:41.220 Möglicherweise erhalten Sie eine Nachricht, aber die darin referenzierten Daten sind noch nicht bereit. 00:08:41.380 --> 00:08:42.540 In diesem Fall können Sie sie zurückstellen. 00:08:42.840 --> 00:08:44.420 Die verbleibte in der Warteschlange ist aber unsichtbar. 00:08:44.720 --> 00:08:48.180 Später können Sie sie mithilfe der Sequenznummer abrufen und zum richtigen Zeitpunkt verarbeiten. 00:08:48.620 --> 00:08:52.280 Diese Features unterscheiden eine einfache Warteschlange von einem System, auf dem Sie Ihr Unternehmen aufbanken. 00:08:53.180 --> 00:08:54.720 Service-Boss im Vergleich zu Alternativen. 00:08:55.380 --> 00:08:57.580 Wann entscheiden Sie sich für Service-Boss anstelle von etwas anderem? 00:08:57.820 --> 00:08:58.480 Lassen Sie mich aufschlösen. 00:08:58.980 --> 00:09:02.840 Azure Storage Warteschlangen sind die einfachste Option, kostengünstig, schnell und leicht einzurichten. 00:09:02.840 --> 00:09:10.560 Sie sind jedoch begrenzt. Nachrichten sind auf 64 KB begrenzt und Sie erhalten keine Themen, Sitzungen, unzustellbare Nachrichten oder Transaktionen. 00:09:10.900 --> 00:09:14.240 Sie eignen sich hervorragend für einfache Hintergrund-Auftragswarteschlangen, bei denen Sie nur Arbeit auslangen. 00:09:14.540 --> 00:09:18.240 Wenn Sie jedoch eine der erweiterten Funktionen benötigen, über die wir gesprochen haben, werden Sie sich schnell übertreffen. 00:09:18.920 --> 00:09:22.520 Event-Hubs wurde für etwas völlig anderes entwickelt, Event-Streaming, mit hohem Durchsatz. 00:09:23.520 --> 00:09:26.940 Denken Sie an Millionen von Ereignissen pro Sekunde von IoT-Geräten oder Anwendungsprotokoll. 00:09:26.940 --> 00:09:30.100 Er handelt sich nicht um einen Nachrichtenbroker, sondern um eine Datenerfassungspipeline. 00:09:30.420 --> 00:09:32.180 Daher würden Sie sie nicht für Transaktionsworkflows erwähnen. 00:09:32.560 --> 00:09:35.400 Sie verwenden Event-Grid, wenn Sie große Datenströme erfassen und verarbeiten müssen. 00:09:36.620 --> 00:09:40.560 Event-Grid ist die einfache Option, ein Publish-Subscribe-System für ereignisgesteuerte Trigger. 00:09:41.360 --> 00:09:44.580 Wenn ein Blob in den Speicher hochgeladen wird, kann Event-Grid eine Azure-Funktion auslösen. 00:09:45.160 --> 00:09:47.940 Wenn eine Ressource erstellt wird, können andere Dienste benachrichtigt werden. 00:09:48.180 --> 00:09:51.560 Event-Grid ist schnell, kostengünstig und eignet sich perfekt für reaktive Szenarien, ist aber keine Warteschlag. 00:09:51.560 --> 00:09:53.660 Es werden keine Nachrichten zu späteren Verarbeitungen speichern. 00:09:54.000 --> 00:09:55.880 Wenn der Empfänger also ausfällt, geht das Ereignis verloren. 00:09:56.700 --> 00:09:58.020 Servicebus befindet sich genau in der Mitte. 00:09:58.440 --> 00:10:02.600 Es verfügt über die umfangreichen Features eines Enterprise-Brokers ohne die Komplexität, die mit der Verwaltung eines solchen Brokers hängt. 00:10:02.880 --> 00:10:08.680 Wenn Sie Warteschlangen für unzustellbare Nachrichten, Sitzungen, Transaktionen, Themen mit Filtern oder eine garantierte Zustellung benötigen, ist Servicebus die richtige Wahl. 00:10:09.160 --> 00:10:09.820 Wie sieht es mit Kafka aus? 00:10:10.020 --> 00:10:11.060 Das ist ein ganz anderes Thema. 00:10:11.920 --> 00:10:16.780 Servicebus ist für Befehle und Geschäftsworkflows vorgesehen, während Kafka für Ereignis-Streaming und Analysen vorgesehen ist. 00:10:17.240 --> 00:10:18.480 Viele große Systeme verwenden beides. 00:10:18.480 --> 00:10:21.480 Servicebus verarbeitet das operative Messaging Kafka die Datenpipeline. 00:10:22.520 --> 00:10:23.940 Sie ergänzen sich, sie konkurrieren nicht miteinander. 00:10:24.280 --> 00:10:25.240 Hier ist eine einfache Faustregel. 00:10:25.660 --> 00:10:28.360 Wenn Sie sich fragen, wurde diese Nachricht ordnungsgemäß verarbeitet? 00:10:28.780 --> 00:10:29.720 Verwenden Sie Servicebus. 00:10:30.380 --> 00:10:33.060 Wenn Sie sich fragen, kann ich den Ereignis-Strom der letzten Woche erneut abspielen? 00:10:33.520 --> 00:10:34.140 Verwenden Sie Kafka. 00:10:34.640 --> 00:10:35.780 Unterschiedliche Tools von unterschiedlich auf. 00:10:36.460 --> 00:10:37.320 Anwendungsfehler aus der Praxis. 00:10:37.720 --> 00:10:39.080 Verdeutlichen wir dies anhand einiger Beispiele. 00:10:39.580 --> 00:10:40.860 So funktioniert Servicebus in der Produktion. 00:10:41.260 --> 00:10:42.000 Beginnen wir mit E-Commerce. 00:10:42.700 --> 00:10:44.480 Ein Kunde gibt eine Bestellung auf einer Website auf. 00:10:44.480 --> 00:10:48.620 Der Web-Server nimmt diese Bestellung entgegen und sendet sofort eine einzelne Nachricht an eine Servicebus-Warteschlange. 00:10:48.880 --> 00:10:50.080 Anschließend wird dem Kunden mitgeteilt. 00:10:50.340 --> 00:10:51.500 Vielen Dank, Ihre Bestellung wurde bestellt. 00:10:51.840 --> 00:10:54.120 Der Kunde erhält eine schnelle Antwort, ohne warten zu müssen. 00:10:54.680 --> 00:10:57.340 Im Hintergrund ruft ein Pool von Worker-Diensten Daten aus dieser Warteschlange ab. 00:10:57.700 --> 00:11:01.760 Ein Worker verarbeitet die Zahlung, ein anderer überprüft den Lagerbestand, ein weiterer bereitet das Versandetikett vor. 00:11:02.320 --> 00:11:05.080 Jeder Worker ruft die nächste Nachricht ab, erledigt seine Aufgabe und fährt fort. 00:11:05.840 --> 00:11:06.780 Der Kunde sieht davor nichts. 00:11:07.440 --> 00:11:08.220 Er sieht nur die Bestätigung. 00:11:08.800 --> 00:11:10.640 Das ist das klassische asynchrone Verarbeitungsmuster. 00:11:11.400 --> 00:11:13.880 Sofortiges Feedback für den Benutzer, schwere Arbeit im Hintergrund. 00:11:14.640 --> 00:11:15.780 Finanzsysteme gehen noch einen Schritt weiter. 00:11:16.320 --> 00:11:18.440 Die Zahlungsverarbeitung erfordert eine garantierte Zustellung. 00:11:18.740 --> 00:11:20.680 Sie können keine Transaktion verlieren oder zweimal verarbeiten. 00:11:21.200 --> 00:11:22.520 Sie benötigen Bestellung und Transaktion. 00:11:22.920 --> 00:11:24.140 Servicebus bietet Ihnen all das. 00:11:24.480 --> 00:11:28.120 Eine Zahlungsmethode trifft ein, wird verarbeitet und das Ergebnis wird an eine andere Warteschlange gesendet. 00:11:28.480 --> 00:11:31.940 Falls ein Fehler auftritt, wird der gesamte Vorgang zurückgesetzt, sodass das Geld niemals falsch übertragen wird. 00:11:32.680 --> 00:11:33.900 Hier zeigt Servicebus seine Stärke. 00:11:33.900 --> 00:11:36.280 Sie werden nicht nur Daten verschoben, sondern Sie werden auch sicher verschoben. 00:11:36.700 --> 00:11:38.220 Denken Sie nun an die Verteilung mehrerer Dienste. 00:11:38.600 --> 00:11:40.120 Ein neuer Kunde registriert sich auf der Plattform. 00:11:40.460 --> 00:11:45.080 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. 00:11:45.300 --> 00:11:49.380 Anstatt drei verschiedene Dienste anzurufen, senden Sie eine Nachricht an ein Thema mit dem Namen Kunde registriert. 00:11:50.160 --> 00:11:51.700 Jeder Dienst verfügt über ein eigenes Abonnement. 00:11:52.200 --> 00:11:54.220 Das CRM-Abonnement akzeptiert alle Nachrichten. 00:11:54.340 --> 00:11:59.100 Das Marketing-Abonnement filtert nur nach Neukunden und das Support-Abonnement nur nach Premium-Kunden. 00:11:59.860 --> 00:12:00.880 Eine Nachricht-3-Reaktion. 00:12:00.880 --> 00:12:04.080 Und wenn Sie später einen vierten Dienst hinzufügen, erstellen Sie einfach ein neues Abonnement. 00:12:04.500 --> 00:12:05.300 Absender ändert sich nie. 00:12:06.080 --> 00:12:07.500 Logistikunternehmen verwenden dies in großem Umfang. 00:12:07.940 --> 00:12:13.080 Stellen Sie sich ein Paketverfolgungssystem vor, bei dem hunderttausende von Lieferwagen alle paar Sekunden Standort Aktualisierungen senden. 00:12:13.540 --> 00:12:17.120 Jede Aktualisierung ist eine Nachricht und die Aktualisierung jedes Pakets muss in der Reihe nach verarbeitet werden. 00:12:17.500 --> 00:12:20.480 Sie können das ausgelieferte Update nicht vor dem zur Auslieferung freigegebenen Update fahren. 00:12:20.880 --> 00:12:21.600 Dies wird über Sitzungen. 00:12:21.600 --> 00:12:27.240 Jedes Paket erhält eine eigene Sitzungs-ID und alle Updates für dieses Paket durchlaufen dieselbe Sitzung der Reihe nach. 00:12:27.740 --> 00:12:29.720 Verschiedene Pakete können weiterhin parallel verarbeitet werden. 00:12:30.340 --> 00:12:33.200 Millionen von Paketen und Milliarden von Updates werden zuverlässig verarbeitet. 00:12:33.760 --> 00:12:37.080 Microservice-Architekturen verwenden Servicebus als Kommunikations-Backbone. 00:12:37.080 --> 00:12:39.600 Dienste rufen sich nicht direkt gegenseitig auf. 00:12:39.980 --> 00:12:40.880 Wir tauschen Nachrichten aus. 00:12:41.920 --> 00:12:43.540 Dienst A sendet einem Befehl eine Wartschlange. 00:12:43.800 --> 00:12:45.420 Dienst B holt ihn ab und erledigt die Arbeit. 00:12:46.140 --> 00:12:50.840 Dienst C veröffentlicht ein Ereignis zu einem Thema und die Dienste D und E reagieren jeweils auf ihre eigene Weise. 00:12:51.320 --> 00:12:52.820 Keine direkten Aufrufe, keine enge Kopplung. 00:12:53.260 --> 00:12:56.680 Jeder Dienst kann aktualisiert, skaliert oder ersetzt werden, ohne dass die anderen davon betroffen sind. 00:12:57.000 --> 00:12:58.420 Hier ist ein Muster, das Sie in älteren Unternehmen beobachten. 00:12:58.560 --> 00:13:03.360 Sie haben ein Legacy-System lokal ausgeführt, das nicht einfach ersetzt werden kann, aber Sie möchten moderne Cloud-Dienste verwenden. 00:13:04.080 --> 00:13:05.660 Daher schließen Sie die Lücke mit Servicebus. 00:13:05.660 --> 00:13:09.500 Das Legacy-System sendet Nachrichten an eine Warteschlange und Cloud-Anwendungen nutzen diese. 00:13:10.000 --> 00:13:14.480 Das alte System weiß nie, dass es mit der Cloud kommuniziert und die Cloud weiß nie, dass sie mit einem alten System kommuniziert. 00:13:15.040 --> 00:13:17.260 Servicebus ist in der Mitte und übersetzt und leitet weiter. 00:13:17.540 --> 00:13:19.580 Die geplante Zustellung verarbeitet die zeltbasierten Aufträge. 00:13:20.200 --> 00:13:21.880 Senden Sie innerhalb von 24 Stunden eine Erinnerungsschule. 00:13:22.340 --> 00:13:24.920 Lassen Sie die Sorte-Servierung nach 30 Minuten ablaufen, wenn sie nicht bestätigt wird. 00:13:25.680 --> 00:13:27.960 Generieren Sie jeden Montag um 8 Uhr einen wöchentlichen Bericht. 00:13:28.300 --> 00:13:33.320 Sie senden die Nachricht jetzt mit einer zukünftigen Zustellungszeit und Servicebus speichert Sie und gibt Sie genau zum richtigen Zeitpunkt frei. 00:13:33.320 --> 00:13:36.520 Keine Kronaufträge, keine Hintergrundtimer, nur eine Nachricht mit einem Timer. 00:13:36.920 --> 00:13:38.860 Der rote Faden all diesen Beispielen ist der Silber. 00:13:39.720 --> 00:13:43.940 Der Absender wartet nicht auf den Empfänger und der Empfänger muss nicht online sein, wenn die Nachricht gesendet wird. 00:13:44.380 --> 00:13:48.980 Sie sind entkoppelt und diese Entkoppelung macht das gesamte System widerstandsfähiger, skalierbarer und leichter zu ändern. 00:13:49.900 --> 00:13:51.720 Das große Ganze, warum alles zusammenpasst. 00:13:51.720 --> 00:13:53.480 Was genau ist Servicebus? 00:13:53.980 --> 00:13:58.140 Es ist das Rückgrat, über das unabhängige Dienste zuverlässig kommunizieren können, ohne voneinander abhängig zu sein. 00:13:59.080 --> 00:14:01.660 Drei Wörter fassen dies zusammen. Entkoppeln, Puffern und Weiterleiten. 00:14:02.340 --> 00:14:04.540 Entkoppeln bedeutet, dass Dienste nichts voneinander wissen müssen. 00:14:05.200 --> 00:14:06.500 Sie kennen nur die Warteschlange oder das Thema. 00:14:06.840 --> 00:14:13.920 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. 00:14:13.920 --> 00:14:17.180 Puffer bedeutet, dass die Warteschlange die Last aufnimmt, wenn der Datenverkehrsspitzen aufweist. 00:14:17.540 --> 00:14:22.800 Der Sender sendet mit voller Geschwindigkeit weiter, während der Empfänger in seinem eigenen Tempo verarbeitet, sodass niemand abstürzt oder überlastet wird. 00:14:23.040 --> 00:14:25.340 Der Puffer gleicht die Spitzen aus und füllt die Täler auf. 00:14:26.200 --> 00:14:30.040 Rote bedeutet, dass Warteschlangen Nachrichten an Verbraucher senden, während Themen an viele Verbraucher senden. 00:14:30.640 --> 00:14:33.000 Filter stellen sicher, dass jeder Verbraucher nur das erhält, was er benötigt. 00:14:33.480 --> 00:14:35.920 So findet die Nachricht automatisch den Weg an den richtigen Ort. 00:14:36.920 --> 00:14:40.840 Warteschlangen übernehmen die Punkt-zu-Punkt-Arbeitsverteilung und heben die Übertragung an viele Verbraucher. 00:14:41.760 --> 00:14:43.380 Erweiterte Funktionen behandeln Sonderfälle. 00:14:43.920 --> 00:14:50.120 Fehler werden in die Warteschlange für unzustellbare Nachrichten verschoben, Benutzersitzungen werden sortiert, Duplikate werden erkannt, Transaktionen sorgen für die Konsistenz.