WEBVTT 00:00:01.460 --> 00:00:02.340 Bonne journée à tous. 00:00:04.930 --> 00:00:05.880 Comment les gens font ? 00:00:08.810 --> 00:00:14.600 Bonne ? Vous l'avez guys ont fait presque à la fin de la conférence. 00:00:15.630 --> 00:00:17.150 Quelle est l'expérience été jusqu'ici ? 00:00:17.160 --> 00:00:19.360 [Applaudissements] 00:00:19.520 --> 00:00:20.120 >> Bon. 00:00:20.170 --> 00:00:24.940 Isard. Hé bien, comme on dit, ils enregistrez toujours le meilleur pour la fin. 00:00:26.240 --> 00:00:32.190 Et j'espère que je vous déçoit pas vous guys. J'apprécie vraiment 00:00:32.240 --> 00:00:34.450 votre rendant cet après-midi. 00:00:35.200 --> 00:00:40.360 Je suis Abhishek penser. Gestionnaire de programmes avec l'équipe de la plateforme Azure. 00:00:41.090 --> 00:00:45.840 C'est l'équipe qui génère PaaS services tels que les Services mobiles, 00:00:45.890 --> 00:00:48.550 Bus des services, cache Azure. 00:00:49.240 --> 00:00:51.080 Services et de support. 00:00:51.720 --> 00:00:54.320 Ces services sont les responsable de l'équipe. 00:00:54.830 --> 00:00:58.940 Et en particulier, j'ai travaillé pour les trois dernières plus ans 00:00:58.990 --> 00:01:05.100 sur la création d'échanges contemporains pièces. Par conséquent, il s'agit de files d'attente, 00:01:05.150 --> 00:01:08.720 rubriques, sont sub pub, les parties de qui. 00:01:09.470 --> 00:01:15.150 Aujourd'hui, que nous allons examiner messagerie à grande échelle. 00:01:17.010 --> 00:01:22.030 Files d'attente et des rubriques. Personnes sont maintenant familiarisé avec Bus de Service. 00:01:22.840 --> 00:01:26.920 Il englober le relais. C'est le cas englober le concentrateur de notification, 00:01:27.780 --> 00:01:29.010 files d'attente et des rubriques. 00:01:29.560 --> 00:01:34.840 Il s'agit donc d'un nombre entier des services liés à la messagerie. 00:01:35.710 --> 00:01:39.560 Cette session particulière va se concentrer principalement sur les files d'attente 00:01:39.610 --> 00:01:46.260 et c'est le serveur principal zone. Mais si vous avez des questions 00:01:46.310 --> 00:01:50.120 ou tout ce que vous voulez savoir en particulier sur les relais ou 00:01:50.170 --> 00:01:55.150 concentrateurs de notification, je suis enchanté répondre à cette question ou pointez au moins 00:01:55.200 --> 00:01:57.410 vous avez la bonne direction. 00:01:58.820 --> 00:02:00.930 Il y a beaucoup de choses Je souhaite parler aujourd'hui. 00:02:01.710 --> 00:02:04.730 Parler à tous les aspects différents de l'échelle. Je souhaite communiquer avec 00:02:04.780 --> 00:02:08.490 à propos des expéditeurs et les récepteurs et débit, toutes les différentes 00:02:08.540 --> 00:02:11.630 modèles, ainsi que les caractéristiques de l'objet de code. 00:02:12.390 --> 00:02:14.870 De la façon dont vous pouvez obtenir échelle. 00:02:15.810 --> 00:02:19.040 Donc, je vais essayer de conserver un bon rythme. 00:02:19.640 --> 00:02:24.190 Questions sont très utiles. Si vous voyez me démarrage couper court aux questions 00:02:24.240 --> 00:02:27.780 juste un peu plus tard, afin que je peut couvrir toutes les choses que je veux 00:02:27.830 --> 00:02:31.490 à la page de garde. Je ne sera disponible après le la session et vous pouvez toujours 00:02:31.540 --> 00:02:36.200 Atteindre me mais conservez interactive. Tout ce que vous possédez, 00:02:36.250 --> 00:02:41.270 les microphones sont disponibles ici. Remonter tout et je vais appeler. 00:02:43.930 --> 00:02:48.720 Nous allons commencer par parler de ce que du nouveau. Trier uniquement une mise à jour 00:02:48.770 --> 00:02:51.210 sur ce que nous avons annoncée dans le SDK 2.3. 00:02:52.250 --> 00:02:56.290 Nous allons passer à parler les dimensions de l'échelle. 00:02:56.340 --> 00:03:00.420 Nous allons parler des expéditeurs, des destinataires, débit, comment vous effectuer cette opération. 00:03:01.800 --> 00:03:05.770 Et puis nous allons passer quelque temps sur Considérations relatives à la disponibilité. 00:03:05.820 --> 00:03:07.850 Disponibilité suffit largement ce qui signifie que 00:03:09.190 --> 00:03:14.340 tolérance aux pannes, meilleur SLA et comment concevoir votre application 00:03:14.390 --> 00:03:19.520 être toujours, toujours, en cours d'exécution Dans cet emplacement afin que nous allons consacrer une partie 00:03:19.570 --> 00:03:20.510 heure de qui. 00:03:22.060 --> 00:03:25.780 Dans ce Kit de développement logiciel 2.3. 00:03:26.330 --> 00:03:28.310 Que simplement publier ? 00:03:29.070 --> 00:03:32.540 Session de message. Des membres etc. les jurys sont un « push » 00:03:32.590 --> 00:03:36.970 API de style. Il prend supprimer tous les efforts de votre part 00:03:37.020 --> 00:03:42.960 écrire les boucles C ou quoi que ce soit de cette complexité et 00:03:43.010 --> 00:03:46.420 vous donne un très événement-autre modèle à consommer des messages. 00:03:46.470 --> 00:03:50.110 Il s'agit de l'API de côté récepteur. Par conséquent ce que nous avons des sessions. 00:03:50.160 --> 00:03:52.680 Nous traiterons sans aucun doute que plus en détail aujourd'hui. 00:03:53.890 --> 00:03:58.440 Mode de connectivité, la détection automatique. Par conséquent, comme vous le savez, un des réel 00:03:58.490 --> 00:04:02.520 valeur de clé de Bus des services Azure a été que lorsque vous vous connectez 00:04:02.950 --> 00:04:07.700 files d'attente et de rubriques dans le nuage derrière le pare-feu à partir de 00:04:07.750 --> 00:04:11.450 vos propres centres de données ou à partir de votre centres de données de clients qui 00:04:11.500 --> 00:04:16.230 sont assis derrière très bien protégées sorte de pare-feux, Service 00:04:16.280 --> 00:04:19.660 Bus a la possibilité d'établir des connexions sortantes non seulement sur le port TCP 00:04:19.710 --> 00:04:22.110 mais le port 443 et 83 00:04:23.670 --> 00:04:25.860 tandis que les ports TCP sont bloqués. 00:04:26.700 --> 00:04:30.790 Cette fonction sera toujours désormais disponible uniquement si vous définissez directement 00:04:30.840 --> 00:04:34.230 le répertoire avec le mode TCP, Par conséquent, vous jamais eu le choix. 00:04:34.910 --> 00:04:38.730 Désormais dans votre code vous pouvez définir il automatiquement détecter et nous vous 00:04:38.780 --> 00:04:42.910 Pour afficher automatiquement si le port TCP est disponible, nous les utiliserons. 00:04:42.960 --> 00:04:48.410 Si le pare-feu bloque, nous allons déposez-le sur HTTP. Dans ce Kit de développement logiciel 00:04:48.460 --> 00:04:51.560 2.3, qui est disponible pour la messagerie également. 00:04:54.390 --> 00:04:57.980 CORS prend en charge. Combien de gens connaître la CORS ? 00:05:00.360 --> 00:05:04.200 La plupart des gens savent qu'il. Il essentiellement Permet d'envoyer/recevoir facile 00:05:04.250 --> 00:05:09.370 à partir de navigateurs. L'idée est donc vous peut toujours avoir terminé, vous disposez 00:05:09.420 --> 00:05:14.320 STPI avec SCTP. Vous pouvez faire envoyer messages, recevoir des messages, 00:05:14.370 --> 00:05:18.920 mais avec CORS maintenant cela facilite beaucoup les navigateurs et les sites Web plus facilement 00:05:18.970 --> 00:05:23.650 intégration back et nous entrerons à cela en détail aujourd'hui. 00:05:25.010 --> 00:05:29.530 De même, le tri d'à aider avec performances ainsi que d'échelle 00:05:29.580 --> 00:05:34.760 pour les expéditeurs HTTP, nous avons le traitement par lots maintenant disponibles. 00:05:35.200 --> 00:05:43.980 Et puis deux perf du côté client Lorsque vous utilisez des compteurs 00:05:44.030 --> 00:05:46.900 vraiment mettre une application qui est complexe ou que vous soyez 00:05:46.950 --> 00:05:50.450 allez à s'exécuter dans différents environnements, Vous devrez peut-être 00:05:50.500 --> 00:05:53.340 déboguer et vous devrez peut-être profil Il donc nous avons ajouté le client 00:05:53.390 --> 00:05:57.890 compteurs de performance de côté de messages envoyés par seconde, lettres par seconde 00:05:57.940 --> 00:06:01.460 et notamment celui qui peut vraiment, vraiment vous aider à profil 00:06:01.510 --> 00:06:05.250 vous êtes messagerie couche est ainsi vous êtes globalement opposé 00:06:05.300 --> 00:06:09.020 effectue une occasion. Par conséquent, ceux sera puis le manifeste pour les performances 00:06:09.070 --> 00:06:14.230 compteurs en tant que partie du package NuGet de telle sorte qu'il permet réellement 00:06:14.280 --> 00:06:17.550 vous permet d'effectuer certains bons de débogage. 00:06:20.550 --> 00:06:23.340 Et enfin, ForwardTo pour les files d'attente de lettres mortes. 00:06:23.880 --> 00:06:27.380 Deadlettering est une très, très puissante fonction où il protège 00:06:27.430 --> 00:06:30.820 vous êtes back-ends s'il y a poison messages. Il s'agit en général 00:06:30.870 --> 00:06:34.620 appelées files d'attente de poison où vous essayez Pour recevoir un message et le 00:06:34.670 --> 00:06:38.600 message n'est pas formé ou il y a un bogue dans votre code quelque part 00:06:38.650 --> 00:06:42.080 sur de le civilizer de quelque part Lorsque vous n'êtes pas en mesure d'ouvrir 00:06:42.130 --> 00:06:44.560 le message et votre tombe en panne du serveur principal. 00:06:45.780 --> 00:06:50.390 Bus de service vous offre la possibilité de de la définition d'une remise max 00:06:50.440 --> 00:06:54.420 nombre qui par défaut est 10 et que Il signifie que si nous voir 00:06:54.470 --> 00:06:57.660 que nous avons remis le message vous avez 10 fois et que vous 00:06:57.710 --> 00:07:01.310 pas terminé le message, nous le déplacerons à partir de 00:07:01.360 --> 00:07:03.240 la file d'attente principale dans le file d'attente de lettres mortes. 00:07:03.870 --> 00:07:07.930 Par conséquent, cela permet littéralement de vos applications être résilient par défaut 00:07:08.190 --> 00:07:12.840 sans avoir à écrire une seule ligne de code et de protection 00:07:12.890 --> 00:07:18.660 vos serveurs principaux. C'est le cas ForwardTo est la capacité de canal 00:07:18.710 --> 00:07:23.810 messages automatiquement la création flux de message et maintenant vous 00:07:23.860 --> 00:07:30.000 peut prendre une application susceptible d'avoir 6, 8, 10 de files d'attente et de ForwardTo 00:07:30.050 --> 00:07:34.450 pour toutes les files d'attente de lettres mortes en une seule file d'attente qui signifie 00:07:34.500 --> 00:07:38.530 vous avez à présent un seul emplacement pour aller maintenant recevoir tous les messages poison 00:07:38.980 --> 00:07:42.340 quel que soit le nombre de files d'attente ou abonnements ou rubriques vous 00:07:42.390 --> 00:07:46.280 Utilisez ce cas d'une fonction doit également ajouter. 00:07:47.180 --> 00:07:49.910 Nous allons aborder dans un peu plus en détail. 00:07:51.740 --> 00:07:57.570 Je ne voulait récapituler rapidement sur les actions Nous avons effectué depuis avril dernier 00:07:57.620 --> 00:08:01.400 Étant donné que lorsque nous parlons aujourd'hui dans conditions d'évolutivité et de performances 00:08:01.450 --> 00:08:05.780 et vous verrez beaucoup d'un débit Ces fonctionnalités en cours de référencement 00:08:06.180 --> 00:08:08.570 Par conséquent, je voulais juste appeler les en termes de si elles sont 00:08:08.620 --> 00:08:12.370 disponible aujourd'hui déjà et avez sont disponibles depuis quelque temps, mais 00:08:12.420 --> 00:08:16.250 ils sont toujours là. 00:08:18.520 --> 00:08:22.290 La seule chose à voir ici sert au-dessous de la ligne, le premier 00:08:22.340 --> 00:08:26.310 bus de Service sur la promesse du dernier donc année, que nous avons fait le Bus des services 00:08:26.360 --> 00:08:28.900 1.1 pour la version de Windows server. 00:08:29.580 --> 00:08:33.210 Cela est complètement symétrique pour file d'attente et les rubriques qui signifie 00:08:33.260 --> 00:08:37.450 Si vous allez chercher 2.1 SDK, par exemple, qui fut le dernier Kit de développement 00:08:38.470 --> 00:08:42.010 Vous pourrez soit atteint le service ou sur premise, tous les 00:08:42.060 --> 00:08:45.070 les fonctionnalités qui sont disponibles. 00:08:46.760 --> 00:08:51.600 Cette cadence de tri de version de nuage tous les trois mois vous 00:08:51.650 --> 00:08:55.290 voyez tous les trois à quatre mois et sur site à 00:08:55.340 --> 00:08:59.520 au moins une fois par an est ce que nous essayons de Pour mettre à jour puis rétablir les deux 00:08:59.570 --> 00:09:02.680 la fonctionnalité de jeux à parité. 00:09:05.540 --> 00:09:08.740 Si cette option est disponible pour vous référence plus loin en termes de 00:09:08.790 --> 00:09:10.010 les fonctionnalités. 00:09:12.110 --> 00:09:13.310 Pour toute question jusqu'ici ? 00:09:15.820 --> 00:09:16.720 Oui, veuillez. 00:09:16.730 --> 00:09:19.730 [Indiscernible] 00:09:19.950 --> 00:09:23.560 >> Donc la question est : quand être la prochaine mise à jour et de l'emplacement 00:09:23.610 --> 00:09:28.920 nous apportera 2.3, la dernière il les fonctionnalités. 00:09:28.970 --> 00:09:33.240 Pour le moment, je n'ai pas toutes les dates partager pour le Service suivant 00:09:33.290 --> 00:09:36.320 Version de bus, mais qu'il n'y être un 2.2 ou un 1.2. 00:09:37.800 --> 00:09:42.620 Mais vous pouvez généralement considérer ceci Cette date de version particulière 00:09:43.340 --> 00:09:46.900 correspond à la version de Windows Server afin que la plupart du temps qu'ils essaient 00:09:46.950 --> 00:09:51.580 pour s'aligner avec les versions serveur donc Nous obtenons la plate-forme maximale 00:09:51.630 --> 00:09:55.010 avantage pour nous assurer que nous avons serveur plus grand à plus tard 00:09:55.060 --> 00:09:59.310 gestion de clusters avec la dernière gestion et défigure et tous les éléments. 00:09:59.360 --> 00:10:03.610 Généralement simplement les instructions supposent que le même type de cadence 00:10:03.660 --> 00:10:05.820 sera suivie. Bonne question. 00:10:08.920 --> 00:10:13.130 Mettre à l'échelle de l'expéditeur. Commençons par Ceci en premier 00:10:13.180 --> 00:10:14.210 hauteur d'échelle. 00:10:15.570 --> 00:10:18.650 Pourquoi expéditeurs est nothing mais un endroit où vous êtes 00:10:18.660 --> 00:10:20.040 [Indiscernible] 00:10:20.000 --> 00:10:22.830 Vous pouvez penser à beaucoup de scénarios ici. Vous pouvez envisager de périphérique 00:10:22.880 --> 00:10:24.970 télémesure, les actions de l'utilisateur. 00:10:26.630 --> 00:10:31.030 Et vos systèmes de génération d'événements et B à B type de scénario. 00:10:31.080 --> 00:10:32.910 Les événements générés. 00:10:33.640 --> 00:10:37.660 Comment vous prendre en charge des scénarios Lorsque vous avez un grand nombre de ces 00:10:37.710 --> 00:10:41.620 ou peut-être que quelques-uns d'entre eux avec un grand nombre des événements ou un grand nombre d'expéditeurs 00:10:41.670 --> 00:10:45.250 un grand nombre d'événements ? Tous ceux scénarios sont possibles. 00:10:46.830 --> 00:10:50.480 Afin que nous veillerons concrète. Nous allons Démarrer avec un scénario réel 00:10:50.530 --> 00:10:54.510 les clients qui sont utilisés pour aujourd'hui qui est où vous devez 00:10:54.560 --> 00:10:58.850 collecter les événements d'analyse à partir de un grand nombre de périphériques. 00:11:00.370 --> 00:11:05.900 Ces périphériques peuvent vous paraître familiers mais il s'agit d'une coïncidence qui 00:11:05.950 --> 00:11:11.000 Je ne sera ni confirmer ni refuser. Par conséquent, il pourrait être n'importe quel périphérique. 00:11:11.050 --> 00:11:12.350 Il pourrait être n'importe quel périphérique. 00:11:13.160 --> 00:11:18.850 Maintenant tout ceci commence par le Dispositif de pouvoir dans la file d'attente 00:11:18.900 --> 00:11:24.250 messages, sont en mesure de prendre quelques rubriques ou une rubrique et diffusion 00:11:24.300 --> 00:11:28.090 dans un grand nombre d'informations Dans ce canal 00:11:29.520 --> 00:11:33.640 une fois que vous avez un message dans une rubrique Vous pouvez penser que vous pouvez 00:11:34.710 --> 00:11:39.370 avoir plusieurs scénarios dans lesquels vous souhaitez le consommer. 00:11:39.420 --> 00:11:43.330 Analyse en temps réel ou ce que vous Procédez avec votre propre code est 00:11:43.380 --> 00:11:48.570 réellement devenir beaucoup plus courant et les plus courants. Sont a fait des gens 00:11:48.620 --> 00:11:53.840 à la session d'Orléans qui a-t-il été effectué hier ? Ainsi, si 00:11:53.890 --> 00:11:57.080 vous l'avez fait, pièce Isard, Isard de la technologie parce qu'elle essaie 00:11:57.130 --> 00:12:02.580 Pour résoudre ce problème d'exécution votre code à grande échelle dans un distribués 00:12:02.630 --> 00:12:06.190 mode si vous avez affaire à événements qui sont générés 00:12:06.240 --> 00:12:10.830 par un grand nombre d'expéditeurs et sont mis en corrélation dans tous les sens. 00:12:12.020 --> 00:12:15.930 Par conséquent, comment s'assurer que ces systèmes back-end sont dissociés ? 00:12:15.980 --> 00:12:18.590 Comment vous assurer que ces systèmes back-end sont en mesure de 00:12:18.640 --> 00:12:24.640 consommer des messages à ce taux et d'agir de manières dans lequel ils sont souple ? 00:12:25.950 --> 00:12:29.560 Et pour que vous placez les rubriques dans le milieu. Rubriques ainsis non seulement 00:12:29.610 --> 00:12:33.440 vous donnez à la mise en mémoire tampon, comme une file d'attente serait, ce qui signifie que 00:12:33.490 --> 00:12:35.950 votre principal peut être effectuée quelques heures et que vous ne 00:12:36.000 --> 00:12:39.060 tous les événements de perdre. Les événements toujours y restent mais ils 00:12:39.110 --> 00:12:40.490 vous donnent également sub pub. 00:12:41.470 --> 00:12:45.530 Ce qui signifie que si vous disposez d'autres systèmes qui font seulement 00:12:45.580 --> 00:12:51.310 suivi de l'état, par exemple placer valeurs en câbles Azure, ou 00:12:51.360 --> 00:12:56.520 qu'ils rédigent des analyses de lots avec lier votre structure de fichiers 00:12:56.570 --> 00:13:00.330 TRÈS puis exécutez Hadoop travaux sur elle. 00:13:01.400 --> 00:13:05.850 Ou ils hauteur mise en vous êtes données dans un entrepôt de données SQL 00:13:05.900 --> 00:13:09.170 et exécuter les requêtes décisionnelles BI en outre. 00:13:09.790 --> 00:13:13.980 Tous ces systèmes peuvent consulter dans le même flux d'événements. 00:13:15.280 --> 00:13:18.350 Et non seulement le même flux d'événements, ils peuvent examiner il événement 00:13:18.400 --> 00:13:21.780 flux trop. Peut-être la BI de travail entrepôt, Vous ne souhaitez pas consommer 00:13:21.830 --> 00:13:25.870 tous les événements. De l'action liée les événements n'appartiennent pas il. 00:13:25.920 --> 00:13:29.420 Ils appartiennent uniquement pour les éléments de code. Vous pouvez fractionner les flux de données 00:13:29.470 --> 00:13:30.210 de cette façon. 00:13:32.750 --> 00:13:36.990 Puis, depuis votre back-end, si vous êtes en train de lire votre Azure 00:13:37.040 --> 00:13:41.730 tables ou votre entrepôt de données SQL, Vous pouvez générer votre bash 00:13:41.780 --> 00:13:43.200 cartes mères pour PC et l'analyse. 00:13:44.750 --> 00:13:45.750 Par conséquent, une de la clé 00:13:46.970 --> 00:13:49.340 points de conception de ce paquet. 00:13:50.180 --> 00:13:52.920 Est à l'aide de rubriques pour le ventilateur dans. 00:13:53.960 --> 00:13:57.730 Ventilateur dans essentielles signifie que vous avez moins les rubriques que vous ont des périphériques. 00:13:57.780 --> 00:13:59.900 Droit ? Que sont les qui cardinalité peut-être. 00:14:01.080 --> 00:14:03.820 Il est déconseillé d'être une. Il ne va pas être 00:14:03.870 --> 00:14:07.660 rubrique de tous les éléments. Il s'agit probablement ne va ne pas être N. vous permet de passer 00:14:07.710 --> 00:14:12.220 à quelque part entre les deux et en tant que Nous parlons de comment trouver 00:14:12.270 --> 00:14:13.860 avec ce numéro de droit. 00:14:14.410 --> 00:14:18.960 Vous allez charger le solde entre centres de données pour plusieurs raisons. 00:14:19.320 --> 00:14:22.490 Si vous fait penser que ces périphériques sont réellement géographiquement 00:14:23.190 --> 00:14:26.300 répartis, donc vous voulez faire assurer que le périphérique utilise le 00:14:26.350 --> 00:14:30.740 moins d'énergie, le plus bas connexion de latence pour pouvoir 00:14:30.790 --> 00:14:33.770 pour atteindre et ses données en file d'attente. 00:14:35.480 --> 00:14:39.640 Il s'agit donc d'équilibrage entre les données de la charge postes de charge. Ce bus est donc disponible 00:14:39.690 --> 00:14:45.690 dans toutes les régions Azure, tous les datacenters. Par conséquent, vous avez la possibilité de 00:14:45.740 --> 00:14:50.730 Pour répartir les rubriques autour. À présent que ne signifie pas que votre back-end 00:14:50.780 --> 00:14:53.890 les systèmes doivent être abdicated sur tous les favoris, trop. 00:14:54.880 --> 00:14:58.000 Dans les cas fait, si vous pensez qu'autour d'Hadoop clusters, il est en général 00:14:58.050 --> 00:15:01.860 pas quelque chose que vous pouvez répliquer dans toutes les régions dans chaque centre de données. 00:15:01.910 --> 00:15:05.890 Mais cela vous donne une faible latence point de terminaison. À partir de là, vous pouvez 00:15:05.940 --> 00:15:10.490 collectent des données à l'endroit où il est en cours généré. Puis tirez-la 00:15:10.540 --> 00:15:14.310 à partir de votre back-end. Traverser pour toutes les régions et 00:15:14.360 --> 00:15:18.450 abonnements dans différentes régions et la corrélation des données. 00:15:20.910 --> 00:15:23.690 Filtre True pour un seul abonnement, dans cette vertical 00:15:23.740 --> 00:15:27.550 cas client, ils réellement pourquoi consommation de toutes leurs données et 00:15:27.600 --> 00:15:31.700 code de suivi de l'état et le traitement par lots Analytics, mais pas dans BI. 00:15:31.750 --> 00:15:35.900 Par conséquent, ces trois ont été réellement filtres, mais un seul abonnement 00:15:35.950 --> 00:15:39.960 a un filtre de réduction. Il avait un filtre qui dit si il s'agit d'un jeu 00:15:40.010 --> 00:15:45.060 événements, puis nous ne me préoccupe qui et bien sûr vous pouvez faire 00:15:45.110 --> 00:15:47.360 analyse en temps réel et de traitement par lots. 00:15:49.410 --> 00:15:53.110 Par conséquent, dans ce scénario, j'ai pensé que Nous allons passer dans une démo rapide. 00:15:54.270 --> 00:15:59.080 Et vous montrent les CORS prise en charge de ses aspects. 00:16:00.290 --> 00:16:05.680 Car elle permet à un grand nombre de clients Atteindre le point de vue 00:16:05.730 --> 00:16:11.600 de pouvoir dans la file d'attente messages uniquement à l'aide de pure 00:16:13.270 --> 00:16:15.140 HTTP et sélections. 00:16:15.730 --> 00:16:21.550 J'ai un site Web configuré. Vous guys pouvez atteindre trop si vous avez 00:16:21.600 --> 00:16:25.950 un périphérique ou un élément. L'appelé utilisateur de fichier de note faire l'Azure 00:16:26.000 --> 00:16:28.260 sites Web .NET. 00:16:29.750 --> 00:16:40.510 Tout ce que j'ai ici est très, très simple JavaScript qui je vais 00:16:40.560 --> 00:16:41.160 vous montrer. 00:16:41.880 --> 00:16:43.280 Et ce qu'il fait 00:16:48.770 --> 00:16:53.470 est extrait les valeurs de clé, le basic valeurs de quel est son nom 00:16:53.520 --> 00:16:58.790 Quel est le nom de la file d'attente, le nom espace me donner votre règle SaaS, le 00:16:58.840 --> 00:17:02.140 autorisation de signature d'accès partagé, C'est ce qu'il utilise 00:17:02.190 --> 00:17:03.800 et la clé SaaS. 00:17:04.950 --> 00:17:07.970 Et selon qu'il peut envoyer un message. 00:17:14.280 --> 00:17:18.140 Message envoyé avec succès. C'est la Il s'agit. Pour que vous puissiez voir si vous 00:17:18.190 --> 00:17:21.380 ont beaucoup et clients de navigateur ou tout autre client ou 00:17:21.430 --> 00:17:25.940 DISPOSITIF qui peut faire simplement HTTP pur, Il n'y a aucun SOAP ici. Il y a aucune... 00:17:26.900 --> 00:17:31.300 n'importe quel codage. Vous pouvez placer le message propriétés dans JSON, puis 00:17:31.350 --> 00:17:35.930 Obtenez des messages d'une façon très, très simple dans la file d'attente. Nous allons 00:17:35.980 --> 00:17:38.170 vous avez le code de ce site Web. 00:17:47.070 --> 00:17:52.110 Par conséquent, vous pouvez voir si vous vous trouvez effectuant des propriétés enrichies 00:17:52.730 --> 00:17:55.220 ou même des propriétés de base très, très simplement, 00:17:58.440 --> 00:18:05.280 Vous pouvez facilement envoyer ce code. Et en fait, la bibliothèque JavaScript 00:18:05.330 --> 00:18:09.370 qui est utilisé ici, laisser moi aussi montrent que pour vous. 00:18:16.200 --> 00:18:22.410 Ceci est la page web que je a montré et vous pouvez voir comment 00:18:35.560 --> 00:18:40.400 simple vraiment l'envoyer et la réception de ce message. 00:18:40.450 --> 00:18:44.840 Le protocole HTTP, la suppression est en réalité pour le scénario de réception. 00:18:45.430 --> 00:18:47.500 Qui nous verrons un peu plus tard. 00:18:48.120 --> 00:18:56.600 Et la placer est post, pour le scénario de l'envoi, Nous sommes désolés, dans la mesure du scénario de l'envoyer. 00:18:58.510 --> 00:19:02.420 Laissez donc 00:19:03.620 --> 00:19:05.210 M'envoyer un peu plus de messages. 00:19:05.810 --> 00:19:09.220 Et juste pour vous montrer les messages s'affiche, ici j'ai serveur 00:19:09.270 --> 00:19:12.280 Explorateur est chargé avec... 00:19:21.330 --> 00:19:25.310 connecté à mon espace de noms. Et j'ai vous avez une simple file d'attente sur laquelle 00:19:25.360 --> 00:19:28.770 vous voyez maintenant deux messages dans la file d'attente. Si je faire un 00:19:28.820 --> 00:19:35.430 actualisation, 14 des messages sont affichés. Par conséquent Lorsque les messages arrivent et qu'ils 00:19:35.480 --> 00:19:37.840 apparaîtra sur cette file d'attente. 00:19:48.480 --> 00:19:53.620 Nous traiterons le scénario de réception un peu plus en termes de la 00:19:53.670 --> 00:19:56.920 Client HTTP. C'est pour un client HTTP. 00:19:57.510 --> 00:20:02.200 Mais je voulais vraiment parler en particulier à propos des protocoles. 00:20:02.820 --> 00:20:06.840 Quelles sont les considérations qui Vous devez faire lorsque vous décidez 00:20:06.890 --> 00:20:11.460 Si vous souhaitez utiliser le protocole HTTP ou à utiliser le AMQP. Comme vous le savez Service 00:20:11.510 --> 00:20:13.930 Bus prend en charge plusieurs protocoles. 00:20:15.060 --> 00:20:21.750 HTTP est simplement nos RKDPI, AMQP est un protocole standard qui je vais 00:20:21.800 --> 00:20:27.620 parler et SBMP est notre autre protocole propriétaire sur .NET. 00:20:29.320 --> 00:20:35.000 Maintenant, chacun d'eux peut avoir des considérations sur la performance et atteindre des considérations. 00:20:35.710 --> 00:20:39.950 Par conséquent, si vous disposez d'un périphérique sur lequel est très faible mise sous tension, que vous pouvez 00:20:40.000 --> 00:20:44.810 avez des questions concernant le protocole mise en œuvre peut vous placer 00:20:44.860 --> 00:20:49.590 de là. Si vous possédez des scénarios où vous souhaitez être fournisseur indépendant, 00:20:50.070 --> 00:20:54.160 Vous pouvez avoir des considérations sur la portée dire ici ne sont pas acheter dans 00:20:54.210 --> 00:20:57.830 n'importe quel protocole particulier ou une API avec un seul fournisseur. Je vais 00:20:57.880 --> 00:21:00.060 Utilisez un standard ouvert comme AMQP. 00:21:01.900 --> 00:21:04.390 Parfois les fonctionnalités varient par protocole. 00:21:05.130 --> 00:21:08.000 Et la partie que vous voulez mettre en évidence qui est perdue sur un lot 00:21:08.050 --> 00:21:11.300 personnes sont qu'il s'agit principalement recevoir des fonctionnalités de côté. 00:21:11.950 --> 00:21:13.290 Il existe certains côté envoi 00:21:14.560 --> 00:21:19.100 implications, trop, la plupart de la Il est sur la réception où 00:21:19.150 --> 00:21:23.270 protocoles sont différés vraiment un lot et nous verrons pourquoi qui est 00:21:23.320 --> 00:21:24.240 le cas. 00:21:25.950 --> 00:21:28.810 En général il existe certains différences de quota en termes de 00:21:28.860 --> 00:21:32.360 de combien de connexions, vous pouvez créer avec AMQP et SBMP. 00:21:32.410 --> 00:21:35.550 Par conséquent, ceux-ci sont également des considérations importantes Lorsque vous réfléchissez, Bonjour, 00:21:35.600 --> 00:21:38.980 quel protocole va utiliser pour mon à grande échelle, grand nombre 00:21:39.030 --> 00:21:50.090 des expéditeurs ? Protocoles donc binaires par rapport à HTTP, pourquoi est-elle importante 00:21:50.140 --> 00:21:53.280 pour la messagerie ? Quelles sont la clé Considérations pour la messagerie ? 00:21:53.810 --> 00:21:56.350 Je voulais juste appeler la clé scénarios où il est un 00:21:56.400 --> 00:21:59.380 différence, vous pouvez choisir et décider si elle est importante. 00:21:59.430 --> 00:22:02.780 ou pas à votre cas particulier. 00:22:04.210 --> 00:22:08.070 Cas HTTP, chaque fois que vous un appel, vous allez être 00:22:08.120 --> 00:22:11.480 capable d'accéder à une seule entité. Afin de un point de terminaison s'il s'agit 00:22:11.530 --> 00:22:13.850 un point de terminaison d'envoi ou un point de terminaison de réception. 00:22:14.850 --> 00:22:16.820 Vous pouvez effectuer une opération en attente. 00:22:17.560 --> 00:22:21.540 Juste un seul envoi d'appel ou un appel de réception unique. 00:22:22.370 --> 00:22:26.300 Et la plupart du temps, l'opération durée de vie ne peut pas être supérieure à 00:22:26.350 --> 00:22:30.940 60 secondes ou quel que soit votre charge équilibreur de tout ce qui permet 00:22:31.480 --> 00:22:33.060 fournisseur que vous exécutez sur. 00:22:34.490 --> 00:22:41.480 Par conséquent, qui apporte en sorte de des cas où vous souhaitez 00:22:41.530 --> 00:22:43.390 pour communiquer avec plusieurs points de terminaison. 00:22:44.040 --> 00:22:47.590 Un grand nombre de fois dans acheter directionnelle scénarios de communication que vous utilisez 00:22:47.640 --> 00:22:51.230 Atteindre envoyé à une file d'attente et réception d'un abonnement. 00:22:52.080 --> 00:22:55.730 Ou envoyez également à atteindre une notification concentrateur. Tous ces types de 00:22:55.780 --> 00:22:57.060 scénarios peut-être à cet emplacement. 00:22:57.640 --> 00:23:01.320 Avec un protocole binaire, vous en fait permet de créer une connexion unique, 00:23:01.370 --> 00:23:08.270 une seule MORSURE, un socket unique, et tous les autres liens dans la 00:23:08.320 --> 00:23:13.320 Contexte AMQP est un multiflexed de liens sur la connexion HTTP unique. 00:23:14.500 --> 00:23:18.740 Vous disposez ainsi d'un grand nombre d'avantages par ne pas avoir à effectuer la liaison 00:23:18.790 --> 00:23:22.680 et n'ayant ne pas d'établir ce socket et les sélections pour chaque 00:23:22.730 --> 00:23:26.880 paiement d'entité par rapport à faire... une fois les coûts et réutilisables 00:23:26.930 --> 00:23:29.460 que lorsque vous parlez à plusieurs entités. 00:23:30.290 --> 00:23:33.900 Gardez ce scénario à l'esprit. Parfois Lorsque vous écrivez des passerelles de champ 00:23:33.950 --> 00:23:37.240 ou passerelles personnalisées où vous êtes devant un grand nombre de périphériques, cela 00:23:37.290 --> 00:23:40.690 est un élément très important. 00:23:43.280 --> 00:23:48.250 L'autre partie est long en tirant. Il est donc cette chose constante 00:23:48.300 --> 00:23:51.400 à propos de tirant sur files d'attente, le droit, de Hé, ai-je un message ? 00:23:51.450 --> 00:23:55.160 Avez un message ? Avez un message ? Ici, car il est 00:23:55.210 --> 00:24:01.040 une connexion sur le protocole AMQP nous maintenir la connexion. 00:24:01.090 --> 00:24:04.370 Vous ne devez effectuer aucune opération autre qu'ont un en attente 00:24:04.420 --> 00:24:09.120 recevoir qui peut être définie pour un délai d'expiration de l'infini. Vous pourriez 00:24:09.170 --> 00:24:12.110 régler pour un jour, une semaine. En règle générale Vous ne règlera pas il 00:24:12.160 --> 00:24:16.090 correspondant à l'infini. Cette valeur est définie pour tout ce qui les caractéristiques de l'arrêt 00:24:16.140 --> 00:24:19.560 aspect, peut-être 20 minutes ou quelque chose comme qui. Mais vous 00:24:19.610 --> 00:24:24.920 peut avoir un long pull en attente de réception et vous n'avez pas à vous soucier 00:24:24.970 --> 00:24:27.640 recentrer les cycles de processeur et sélections de 00:24:29.370 --> 00:24:33.080 mise en route à ce sujet. Nous allons conserver la connexion active par le biais de 00:24:33.130 --> 00:24:37.040 commandes ping ou quel que soit l'équilibreur de charge est nécessaire et nous fournirons 00:24:37.090 --> 00:24:41.640 vous la réponse faible temps de latence chaque fois qu'un message apparaît. 00:24:42.360 --> 00:24:45.820 Pour que cela devienne une autre très importante considération en termes de 00:24:45.870 --> 00:24:50.380 de coût ainsi que l'impact sur votre périphérique. Protocoles donc binaires 00:24:50.430 --> 00:24:53.310 faire une différence en termes de vos scénarios. 00:24:56.240 --> 00:24:59.820 La contrepartie des protocoles apporte sont dans les kits de développement logiciel. 00:24:59.870 --> 00:25:03.520 Vous souhaitez devenir productif. Vous souhaitez Pour utiliser une base solide. Vous souhaitez 00:25:03.570 --> 00:25:08.220 Pour utiliser les bibliothèques solides. Par conséquent, vous vraiment pour être en mesure de choisir 00:25:08.270 --> 00:25:11.010 le protocole de droit le Kit de développement de droite. 00:25:12.880 --> 00:25:13.950 Ce Bus des services, 00:25:15.670 --> 00:25:19.750 Si vous utilisez .NET, puis par défaut Protocole SBMP est la valeur par défaut. 00:25:19.800 --> 00:25:24.130 C'est ce qui est utilisé. Vous pouvez basculer qu'il AMQP à tout moment et 00:25:24.180 --> 00:25:25.170 C'est également possible. 00:25:25.850 --> 00:25:28.980 Il existe certaines défenses en vedette actuellement, mais nous allons fermer 00:25:29.030 --> 00:25:33.730 cette lacune très bientôt. Mais si vous êtes l'utilisation de .NET, puis SBMP est 00:25:33.780 --> 00:25:36.010 sorte de votre scénario par défaut dès aujourd'hui. 00:25:37.560 --> 00:25:42.400 Si vous utilisez HTTP, si du un incident, nous avons des wrappers HTTP sur un lot 00:25:42.450 --> 00:25:46.160 systèmes d'exploitation disponibles et un grand nombre de bibliothèques disponibles. 00:25:47.010 --> 00:25:50.510 Et puis avec AMQP vous démarrez Pour voir un grand nombre de communauté 00:25:50.560 --> 00:25:51.700 bibliothèques de trouver. 00:25:52.940 --> 00:25:59.670 AMQP étant une norme ouverte a été tous conçus et développés par 00:26:00.690 --> 00:26:05.690 gardant à l'esprit, efficace et fiable, sont portable tri de données 00:26:05.740 --> 00:26:10.310 représentation et flexibilité n'oubliez pas. Flexibilité en termes de 00:26:10.360 --> 00:26:13.470 s'il est le client à client bibliothèques client ou à négocier 00:26:13.520 --> 00:26:15.120 ou interrompre à est tombé de bibliothèques. 00:26:16.680 --> 00:26:20.260 Par conséquent, vous commencez à voir avec la AMQP passer de normalisation en cours... 00:26:20.310 --> 00:26:26.370 Par ailleurs, AMQP a dernier OASIS standard Octobre. Elle désactivée que ISO/IEC. 00:26:27.560 --> 00:26:32.950 Il est donc désormais un international reconnu standard, trop. Afin de 00:26:33.210 --> 00:26:35.180 frais de la presse. 00:26:36.990 --> 00:26:41.560 Mais ce que cela signifie pour vous est que vous allez voir un certain nombre de bibliothèques 00:26:42.230 --> 00:26:47.750 développée par la bibliothèque Apache Qpid ensemble ou la bibliothèque de PROTONS 00:26:47.800 --> 00:26:51.010 clients dans différentes langues. 00:26:51.890 --> 00:26:55.240 C, Java, il existe une implémentation JMS. 00:26:56.110 --> 00:27:00.670 De PHP. Tous ces éléments seront disponibles vous avec la Communauté 00:27:00.720 --> 00:27:05.970 bibliothèque de prise en charge de la source pour l'utilisation d'ouvrir et développement et contribuer 00:27:06.020 --> 00:27:06.740 pour et 00:27:07.970 --> 00:27:12.310 avec le service plus ou avec tous les autres fournisseur qui prend en charge le 00:27:12.360 --> 00:27:14.070 Portail AMQP dans cet emplacement. 00:27:14.820 --> 00:27:18.400 Par conséquent, si vous essayez d'accéder aux Bus des services, Vous pouvez voir les différents protocoles. 00:27:18.450 --> 00:27:22.940 Vous disposez d'un grand nombre de choix de ce qui Kits de développement logiciel vous utilisez et quelles bibliothèques 00:27:22.990 --> 00:27:34.850 vous utilisez et que vous n'êtes pas obligé d'être limitée d'une façon particulière. 00:27:34.900 --> 00:27:36.150 Synchronisation, asynchrone, plutôt que par lots. 00:27:37.150 --> 00:27:40.650 Maintenant que nous savons quelles sont donc les nuances de protocole, je pense que 00:27:40.700 --> 00:27:45.840 Nous devons parler quand doit nous écrire un code de synchronisation, asynchrone 00:27:45.890 --> 00:27:49.170 code, code de lot et de ce que sont les les différences en termes réels 00:27:49.220 --> 00:27:54.100 des performances que vous pourriez voir dans ces différents scénarios. 00:27:55.890 --> 00:27:58.710 Le traitement par lots augmente nettement le débit. 00:27:59.460 --> 00:28:04.620 Il est toujours une très bonne pratique en ce qui concerne l'existence d' 00:28:04.670 --> 00:28:09.260 sur le côté de la réception ou même sur le côté envoi d'utiliser le traitement par lots. 00:28:09.310 --> 00:28:13.190 Le souci seulement négatif des gens Parfois, qui est la latence 00:28:13.240 --> 00:28:17.490 et nous verrons comment qui peuvent être affectés mais pas trop. 00:28:17.540 --> 00:28:18.880 Nous en reparlerons. 00:28:21.250 --> 00:28:24.830 Async est en général toujours le Il est recommandé. Vous souhaitez toujours 00:28:24.880 --> 00:28:28.620 pour l'utiliser chaque fois que possible. À l'exception de que vous ne souhaitez pas lié 00:28:28.670 --> 00:28:31.760 le nombre d'appels en vis-à-vis. Vous ne souhaitent avoir une étroite 00:28:31.810 --> 00:28:34.720 boucle qui émet un nombre infini des appels et nous verrons comment 00:28:34.770 --> 00:28:37.660 Bus de service d'aide à ce scénario. 00:28:40.160 --> 00:28:44.110 Puis enfin nous voir le binaire protocoles sensiblement plus élevés 00:28:44.160 --> 00:28:47.980 être en mesure d'atteindre le débit simplement parce que ces protocoles, 00:28:48.030 --> 00:28:54.290 le protocole AMQP a été développé. avec l'efficacité de l'esprit 00:28:55.260 --> 00:28:58.750 le contrôle de flux, des intégrée à la couche de protocole 00:28:58.800 --> 00:29:03.950 elle-même vous voyez un grand nombre d'avantages s'affiche. Je me réellement 00:29:04.000 --> 00:29:08.550 vous montrer certains numéros. Partie en cours d'exécution numéros de façon à pouvoir comparer 00:29:08.600 --> 00:29:10.090 Ces pour vous-même. 00:29:20.030 --> 00:29:24.820 J'ai donc ici du code qui est va pour essayer d'envoyer des messages. 00:29:26.190 --> 00:29:28.970 Et vous pouvez voir que j'ai divisé vers le haut en trois parties. 00:29:29.850 --> 00:29:32.930 Le premier d'entre eux consiste à effectuer un envoi de synchronisation. 00:29:33.690 --> 00:29:38.660 Voici les lignes principales. Pour chaque faire une qClient et d'envoyer les messages, 00:29:38.710 --> 00:29:44.060 le message. Il s'agit d'une synchronisation très appel. Poids de 1 à terminer. 00:29:44.110 --> 00:29:48.030 Il attend d'accusé de réception à venir à partir du serveur, atteindre 00:29:48.080 --> 00:29:51.200 à partir du client, une complète boucle, puis il déplace. 00:29:52.910 --> 00:29:56.650 L'autre fait d'une manière asynchrone. 00:29:57.900 --> 00:30:02.780 Où essentiellement création Tâches asynchrones pour tous ces 00:30:03.350 --> 00:30:04.470 envoyer des opérations. 00:30:05.700 --> 00:30:09.150 Attendez pour tous les tâches à effectuer. 00:30:11.410 --> 00:30:15.170 Enfin, il y a une mise en lots envoi et appelez-le commandée 00:30:15.220 --> 00:30:19.430 envoi de commandes car avec Async, généralement les personnes propose 00:30:19.480 --> 00:30:22.840 un scénario dans lequel ils disent, avec Async, interruption de l'ordre. Je ne pense pas 00:30:22.890 --> 00:30:25.800 savoir celui qui se produira en premier, celui qui va se produire ensuite. 00:30:26.300 --> 00:30:29.430 C'est pourquoi il est envoi par lots qui est de qualité supérieure 00:30:29.480 --> 00:30:32.300 dans les deux cas, car elle préserve tous les... soit l'ensemble 00:30:32.350 --> 00:30:35.920 provenant de lot ou de la totalité lot revient et vous allez 00:30:35.970 --> 00:30:38.910 consultez la quantité des performances après impact que cela peut avoir. 00:30:40.310 --> 00:30:45.300 J'ai donc tous ces éléments en pointant sur une simple file de messages exemple. 00:30:45.350 --> 00:30:47.900 Vous pouvez visualiser dès maintenant la compteur de file d'attente est égale à zéro. 00:30:48.910 --> 00:30:52.560 Et j'ai défini mon numéro de messages pour un petit nombre de 100. 00:30:53.660 --> 00:30:54.780 Nous pouvons donc effectuer cette opération. 00:30:57.310 --> 00:30:59.530 Et voyez combien nous obtenons. 00:31:00.250 --> 00:31:04.670 Il fait donc tout d'abord envoyer en utilisant synchronisation. Fabrication de donc de façon synchrone 00:31:04.720 --> 00:31:09.020 100 appels à partir de mon ordinateur portable tous les moyen pour le service et l'arrière. 00:31:09.550 --> 00:31:13.970 A pris environ dix secondes en termes de de qui. Et juste pour vous montrer, 00:31:14.020 --> 00:31:18.360 Nous pouvons toujours revenir, vérifier le nombre de messages et il doit 00:31:18.410 --> 00:31:21.860 être 100 maintenant. Toutes les cent les messages ont fait ici. 00:31:23.160 --> 00:31:26.940 Maintenant nous allons voir ce qui se passe lorsque Faire la même chose avec Async. 00:31:29.190 --> 00:31:30.590 Même chose avec Async. 00:31:31.940 --> 00:31:36.120 Et aucune différence en termes de des messages, car 00:31:37.540 --> 00:31:40.460 les messages ont toutes fait ici. Il est désormais 200 messages. 00:31:41.250 --> 00:31:46.450 Il a fallu.3 secondes. Pour toutes les personnes messages pour obtenir dans cet emplacement. 00:31:50.260 --> 00:31:52.620 Traitement par lots, il est encore plus rapide. 00:31:53.370 --> 00:31:54.990 Il est effectivement encore plus rapide. 00:31:56.080 --> 00:31:58.880 La raison est de nouveau, car sous le capot, le Bus des services 00:31:58.930 --> 00:32:04.440 à l'aide d'un protocole binaire donc lorsque vous nous les messages en mode asynchrone, 00:32:04.490 --> 00:32:09.600 Nous sommes à leur segment ensemble table et envoi sur avec le traitement par lots implicite. 00:32:10.260 --> 00:32:13.630 Vous devez définir cette valeur. Le intervalle de vidage par lots, ce que vous 00:32:13.680 --> 00:32:17.710 permet, sur une fabrique de messagerie vous permet de définir de cette fenêtre. 00:32:18.310 --> 00:32:21.010 Vous pouvez la définir dans une fenêtre plus large. Vous verrez une latence plus, 00:32:21.060 --> 00:32:23.690 mais vous verrez beaucoup mieux débit de bout en bout. Vous pouvez 00:32:23.740 --> 00:32:27.310 Définissez-la sur une fenêtre beaucoup plus petite et vous verrez mieux latence 00:32:27.360 --> 00:32:32.110 et peut-être un peu un débit inférieur. Mais vous pouvez voir le 00:32:32.160 --> 00:32:36.660 amplitude de différence ici il Permet d'utiliser la synchronisation 00:32:36.710 --> 00:32:38.410 ou asynchrone par rapport au traitement par lots. 00:32:45.080 --> 00:32:49.310 Par conséquent, nous allons voir rapidement, maintenant que Nous avons nos 300 messages ici, 00:32:49.360 --> 00:32:51.110 que pouvons-nous faire sur le côté de la réception ? 00:33:02.730 --> 00:33:06.700 En réception, Notez ici que je ne suis pas à l'aide de l'API de message sur. 00:33:08.710 --> 00:33:12.460 Il s'agit simplement de vous montrer une pommes comparaison entre les pommes des éléments 00:33:12.510 --> 00:33:15.560 la synchronisation Qu'api d'aspect et puis je vais vous montrer comment la 00:33:15.610 --> 00:33:18.370 message API effectue toutes Cela pour vous. 00:33:20.100 --> 00:33:23.620 Il s'agit d'une synchronisation de réception. 00:33:24.300 --> 00:33:28.740 Pour avoir clairement deux appels en cours effectuées sur le serveur si ce 00:33:28.790 --> 00:33:33.600 en termes de message traite. Vous allez jamais perdre 00:33:33.650 --> 00:33:38.280 un message sur le réseau ou en transit Étant donné que jusqu'à ce que vous n'appelez pas 00:33:38.330 --> 00:33:41.950 Terminer, nous vous enverrons vous sauvegardez le même message. 00:33:43.810 --> 00:33:48.260 L'autre est asynchrone et ici vous peut voir à quoi je fais 00:33:49.430 --> 00:33:56.230 est une tâche avec un continuer avec pour Appelez ensuite la complète sur y. 00:34:01.730 --> 00:34:05.290 Et une nouvelle fois va attendre que tous ceux gravure sur les tâches à effectuer 00:34:05.340 --> 00:34:07.770 avant d'appeler mon chronomètre terminé. 00:34:09.300 --> 00:34:10.660 Et enfin par lots. 00:34:11.330 --> 00:34:12.950 Traitement par lots est un peu plus intéressant. 00:34:13.890 --> 00:34:19.030 Dans ce cas, il est plus facile parce que je faire par lots de réception, notez une passe 00:34:19.080 --> 00:34:21.370 un numéro de message Il est 100. 00:34:22.040 --> 00:34:24.860 Une fois que vous appelez reçoivent maintenant des lots avec des centaines ne signifie pas que nous 00:34:24.910 --> 00:34:28.830 Vous obtiendrez des messages d'une centaine arrière. Il nous ferons tout ce qui 00:34:28.880 --> 00:34:32.660 est plus optimale pour le réseau en fonction concurrence d'être consommateur, 00:34:32.710 --> 00:34:35.970 selon le nombre de nœuds que vous avez tirant sur le message pour afficher 00:34:36.020 --> 00:34:38.800 générer un lot optimale et vous qui. 00:34:39.610 --> 00:34:43.320 C'est pourquoi vous voyez que j'ai un boucle externe qui effectue l'appel 00:34:43.370 --> 00:34:47.620 recevoir le lot jusqu'à ce que je ne parveniez centaines de mes messages. Je veux 00:34:47.670 --> 00:34:51.430 Pour effectuer ce calcul jusqu'à ce que le traitement par lots J'atteindre cent messages. 00:34:53.920 --> 00:34:59.030 Et dans ce cas, je vais ne contenir à son jeton verrouillé. 00:34:59.080 --> 00:35:01.160 C'est que je fais sur le message. Je n'ai pas à conserver de 00:35:01.210 --> 00:35:04.440 l'ensemble du message. Une fois que j'ai consommées le message, j'ai traité 00:35:04.490 --> 00:35:07.710 Being je n'ai à conserver sur le jeton de verrouillage, puis appelez 00:35:07.760 --> 00:35:12.940 le traitement par lots terminé Async avec tous les les jetons verrouillés dans cet emplacement. 00:35:14.060 --> 00:35:16.940 Et je fais cela chaque lot, encore une fois, je ne suis pas en attente 00:35:16.990 --> 00:35:19.490 la façon dont jusqu'à la fin de terminer tous les messages ? 00:35:19.500 --> 00:35:21.500 [Indiscernible] 00:35:21.660 --> 00:35:22.750 .. .subset là ? 00:35:23.510 --> 00:35:24.840 >> Désolé, quelle est la question ? 00:35:24.890 --> 00:35:28.400 >> Si vous pourriez traiter certaines d'entre elles messages, pu terminer 00:35:28.450 --> 00:35:30.520 que les tests, effectuer un sous-ensemble ? 00:35:30.860 --> 00:35:34.510 >> Absolument. Absolument. Lot de sorte que toutes Async. 00:35:35.250 --> 00:35:39.040 Vous pouvez appeler avec un seul jeton verrouillé deux verrouillés jetons, quelle que soit 00:35:39.090 --> 00:35:42.720 l'ensemble est. C'est juste qu'il va envoyer tous ces jetons verrouillés 00:35:42.770 --> 00:35:46.250 dans un lot et get vous sauvegarder les résultats d'un lot. Par conséquent, il a 00:35:46.300 --> 00:35:50.010 l'enregistrement de cette latence et que aller-retour pour faire tout cela 00:35:50.060 --> 00:35:52.540 et les rend très efficace. 00:35:54.300 --> 00:35:56.070 Voyons donc ce que qui ajoute jusqu'à. 00:35:58.400 --> 00:36:03.230 J'ai donc ici la même casse. Je suis tout d'abord que vous envisagez d'utiliser la synchronisation et 00:36:03.280 --> 00:36:07.440 Essayez de recevoir toutes les cent... les cent premiers messages 00:36:07.490 --> 00:36:11.190 Dans cet emplacement. Remarque maintenant que ce sera pire performances envoyer car 00:36:11.240 --> 00:36:14.080 Il fait deux fois le nombre d'opérations Par conséquent, je veux recevoir 00:36:14.130 --> 00:36:16.460 chaque message, complétez chaque message. Recevoir tous les messages, 00:36:16.510 --> 00:36:20.110 Complétez chaque message. Et puis passez. C'est le cas 18 secondes. 00:36:20.160 --> 00:36:24.220 Au lieu de l'envoie de dix que nous ayons vu Pour envoyer, elle est de 18 secondes 00:36:24.270 --> 00:36:28.760 pour ces messages et complète les. Donc absolument pas bon. 00:36:30.090 --> 00:36:35.330 Avec Async car vous faites quelques d'entre eux en parallèle, vous allez maintenant vers le bas 00:36:35.380 --> 00:36:38.880 à propos de 2,8 secondes. À présent, Ces chiffres ne sont que... 00:36:39.410 --> 00:36:43.230 Emportez-les avec un peu de recul, sont en cours d'exécution sur un réseau ici, 00:36:43.940 --> 00:36:47.470 mais vous pouvez voir que l'ordre de grandeur de la différence. Vous pouvez le voir 00:36:47.520 --> 00:36:49.620 Combien d'amélioration c'est le cas. 00:36:50.830 --> 00:36:52.580 Et maintenant nous allons voir ce que se produit avec le traitement par lots. 00:36:55.730 --> 00:37:00.720 Nous sommes précédent. Nous sommes en mesure de faire la même chose caractéristiques de presque comme 00:37:00.770 --> 00:37:04.590 0,1 seconde pour tous les cent opérations qui avaient... 00:37:05.410 --> 00:37:07.930 simplement parce que nous utilisons traitement par lots dans cet emplacement. 00:37:11.380 --> 00:37:16.640 Désormais, non seulement ne vous voyez tous ces avantages d'ici, mais Service 00:37:16.690 --> 00:37:21.680 Bus en fait, très, très facilement vous écrivez ce code particulier. 00:37:21.730 --> 00:37:26.700 Le code que je vous ai montré n'est pas très complexe, mais vous effectivement prises 00:37:26.750 --> 00:37:29.280 il d'aller plus loin et nous Faites encore plus facile. 00:37:30.200 --> 00:37:33.470 C'est le cas pour le... à ce propos, j'ai juste vous montrer ici sur le 00:37:33.520 --> 00:37:37.280 messages de qu'afficher ces 300 messages là, si il est actualisé, il 00:37:37.330 --> 00:37:41.920 doit revenir à zéro indiquant Je ne suis pas s'étendant. Toutes les 300 00:37:41.970 --> 00:37:43.380 les messages ont été traités. 00:37:47.270 --> 00:37:54.910 OK. Par conséquent, nous allons étudier le message sur API, mais dans l'intérêt de la 00:37:54.960 --> 00:37:57.880 du temps est consacré à la vitesse vers le haut un peu ici. 00:38:00.480 --> 00:38:04.820 Par conséquent, vous avez vu la différence entre synchronisation, asynchrone et traitement par lots, et 00:38:04.870 --> 00:38:10.330 J'espère que [Indiscernible] toujours utiliser le traitement par lots. La chose suivante à propos de débit. 00:38:10.380 --> 00:38:14.100 Files d'attente partitionnées et des rubriques. Nous avons ainsi publié 2.2 du Kit de développement logiciel. 00:38:15.680 --> 00:38:19.590 Partition essentiellement des files d'attente et rubriques une file d'attente et partition 00:38:19.640 --> 00:38:21.830 Il s'agit sur plusieurs nœuds de traitement. 00:38:23.240 --> 00:38:26.950 Non seulement vous avez ainsi beaucoup plus puissance de débit en termes de 00:38:27.000 --> 00:38:31.900 être en mesure de traiter davantage de messages, mais Il vous donne la capacité de stockage. 00:38:32.410 --> 00:38:35.820 Il vous donne la possibilité d'avoir files d'attente beaucoup plus grands. Il donne 00:38:35.870 --> 00:38:38.170 vous avez la possibilité d'être plus résistants. 00:38:39.270 --> 00:38:42.290 Si une partition n'est pas disponible une autre partition peut continuer. 00:38:42.340 --> 00:38:43.580 pour traiter les messages. 00:38:44.640 --> 00:38:49.270 Ainsi, partitionner files d'attente par et par mesure pour la plupart des scénarios 00:38:49.320 --> 00:38:52.990 vous un débit beaucoup plus élevé disponibilité et résilience 00:38:53.040 --> 00:38:58.570 voir les caractéristiques. En dehors de la zone. Il est donc facile de créer et 00:38:58.620 --> 00:39:02.700 utiliser des files d'attente de partition qui est Venez la recommandation 00:39:02.750 --> 00:39:06.470 toujours les utiliser. Utilisez simplement toujours Ces. En fait, dans la prochaine 00:39:06.520 --> 00:39:11.000 Version du Kit de développement logiciel, nous sommes sur la bonne voie pour rendre il la valeur par défaut qui, par défaut, 00:39:11.050 --> 00:39:13.380 Lorsque vous créez une file d'attente vous permet de obtenir une file d'attente partitionnée. 00:39:15.690 --> 00:39:20.650 À présent, vous n'avez pas à être informé ce qui se produit lorsque vous prenez 00:39:20.700 --> 00:39:22.590 une file d'attente et sur la partition. 00:39:24.060 --> 00:39:26.530 Si vous n'utilisez pas de sessions, nous allons parler beaucoup de sessions 00:39:26.580 --> 00:39:30.340 en détail, mais si vous n'utilisez pas sessions puis essentiellement, 00:39:31.060 --> 00:39:33.050 Vous devez être... 00:39:34.220 --> 00:39:38.380 Vous devez être conscient que vos messages peut s'afficher de manière désordonnée 00:39:38.430 --> 00:39:41.830 maintenant, car il est essentiel qu'ils peuvent allez dans différentes partitions 00:39:41.880 --> 00:39:46.770 et si une partition n'est pas disponible puis affiche le message 00:39:46.820 --> 00:39:47.720 dans le bon ordre. 00:39:48.460 --> 00:39:51.270 C'est une chose à savoir mais si vous utilisez des sessions, 00:39:51.320 --> 00:39:54.720 dont nous allons parler maintenant, puis tout votre sémantique de classement 00:39:54.770 --> 00:39:56.100 sont entièrement conservés. 00:39:57.120 --> 00:40:02.330 Et nous verrons comment. Juste pour vous montrer le code ici, lorsque vous êtes en 00:40:02.380 --> 00:40:05.590 Création d'une file d'attente, il y a un seul propriété EnablePartitioning. 00:40:05.640 --> 00:40:08.720 Aujourd'hui, il est défini sur false par défaut. Comme je l'ai dit dans le prochain 00:40:08.770 --> 00:40:10.040 Kit de développement logiciel il aura la valeur true. 00:40:10.780 --> 00:40:13.750 Ainsi, vous devez simplement définir qui. Par la façon dont je ne sais pas comment vous 00:40:13.800 --> 00:40:18.770 personnes généralement font mais ma philosophie en règle générale n'est jamais copie 00:40:18.820 --> 00:40:20.730 code qui s'affiche dans une présentation PowerPoint. 00:40:21.330 --> 00:40:24.470 Je ne sais pas si cela fonctionne pour vous guys. Jamais copier 00:40:24.520 --> 00:40:28.150 code qui s'affiche dans PowerPoint, car sera le plus simple 00:40:28.590 --> 00:40:32.710 et basic code type de laquelle toute personne peut y placer. Dans ce 00:40:32.760 --> 00:40:35.500 cas qu'il est évident. Vous définissez simplement une propriété, sont donc c'est parfait. 00:40:35.550 --> 00:40:38.540 Mais si j'ai montré jamais que votre code dans PowerPoint, ne pas copier. 00:40:40.650 --> 00:40:46.660 Ce débit de connexion. Nous avons parlé de à propos des expéditeurs. Nous l'avons vu 00:40:46.710 --> 00:40:50.290 comment les connexions binaires sont vraiment, très important. Il y a 00:40:50.340 --> 00:40:55.090 certains cas où vous pouvez envoyer des à l'aide d'un canal de communication très, très fat. 00:40:55.660 --> 00:40:58.340 Considérez-le comme votre principale afin d'être en tentant de messages de la file d'attente. 00:40:58.390 --> 00:41:03.370 Vous avez une tonne de fichier journal d'envoi à distance et des choses comme qui. 00:41:04.400 --> 00:41:08.450 Bien à un moment donné, création les connexions TCP physiques peut 00:41:08.500 --> 00:41:12.630 en fait être une bonne idée, vous pouvez Pour ce faire facilement. Chaque message 00:41:12.680 --> 00:41:16.220 dans l'instance d'une classe de la fabrique instance de fabrique de messagerie 00:41:16.270 --> 00:41:18.390 correspond à une connexion de PCP. 00:41:19.390 --> 00:41:22.550 Par conséquent, plus nombre de clients de file d'attente et les éléments que vous créez 00:41:22.600 --> 00:41:25.680 désactiver la même usine, comme je l'ai montré vous, vous êtes le multiplexage tous 00:41:25.730 --> 00:41:31.430 les connexions sur le même socket TCP. Donc créer plusieurs fabriques de messagerie. 00:41:31.480 --> 00:41:33.700 Et si vous créez plus de messagerie usines, vous allez simplement obtenir plus 00:41:33.750 --> 00:41:38.720 canaux de communication et plus de données peuvent être envoyés par le biais de sorte un critère essentiel 00:41:38.770 --> 00:41:42.540 Pour ce faire. Résilience de niveau connexion est intégré. Par conséquent, une fois que vous 00:41:42.590 --> 00:41:46.140 créer une fabrique de messagerie, vous n'avez jamais à l'ignorer. 00:41:46.190 --> 00:41:49.320 Si la connexion est interrompue, nous allons le régénérer. Si le lien est rompu 00:41:49.370 --> 00:41:52.740 une file d'attente, nous allons le régénérer. Quelle que soit C'est que nous permet de reconstruire 00:41:52.790 --> 00:41:54.860 en termes de vraiment vous jamais le faire... 00:41:55.370 --> 00:41:58.030 disposer de jeter cet objet et recréer l'objet. 00:41:58.310 --> 00:42:02.780 Juste créer plusieurs d'entre eux et réutiliser pour autant que vous avez besoin. 00:42:05.910 --> 00:42:07.540 Par conséquent, ce qui nous amène aux sessions. 00:42:08.520 --> 00:42:11.670 Étant donné que je vous demande de prendre tous ces expéditeurs grand nombre 00:42:11.720 --> 00:42:14.910 d'expéditeurs et de multiplexer tous les dans un très petit nombre 00:42:14.960 --> 00:42:17.850 des files d'attente, comment allez-vous Pour effectuer le traitement ? 00:42:17.900 --> 00:42:21.110 Nous avons vu le genre d'Orléans du framework et de fonctionnalités, qui sont tous les 00:42:21.160 --> 00:42:23.460 tentative de démultiplexer le flux, 00:42:24.720 --> 00:42:26.530 démultiplexer le flux de données. 00:42:28.490 --> 00:42:33.070 Sessions est un Isard intégré fonctionnalité de Service de Bus qui 00:42:33.120 --> 00:42:37.130 essentiellement crée des files d'attente secondaires. Pour chaque session, vous pouvez considérer 00:42:37.180 --> 00:42:40.290 de sous la forme d'une file d'attente secondaire lorsqu'une file d'attente pleine. 00:42:41.480 --> 00:42:44.860 Et de la nature d'origine seulement définir l'ID de session. 00:42:44.910 --> 00:42:46.840 Qui est la seule un propriété ils ont de la valeur. 00:42:48.090 --> 00:42:51.240 Elle est le destinataire où le paradigme change réellement. 00:42:52.050 --> 00:42:56.090 Le récepteur n'est plus devient et affirme Hé, me donner le message suivant. 00:42:56.140 --> 00:42:59.670 Indique que le récepteur me donner le suivant session. Me donner le suivant 00:42:59.720 --> 00:43:02.690 file d'attente secondaire dont certains messages et je vais aller les traiter dans 00:43:02.740 --> 00:43:06.760 Je vais aller les traiter avec des commandes un état, je peux stocker 00:43:06.810 --> 00:43:10.600 Pour que le récepteur. Par conséquent, si vous pensez à propos de millions d'appareils, 00:43:10.650 --> 00:43:13.290 maintenant vous pouvez penser que sur un seul file d'attente, vous pouvez demander à tous ces 00:43:13.340 --> 00:43:18.620 millions de files d'attente secondaires et de magasin état par la file d'attente secondaire. Par conséquent, très, 00:43:18.670 --> 00:43:20.410 très efficace en ce sens. 00:43:21.050 --> 00:43:24.400 Vous pouvez faire définir l'épinglage de travail la valeur travail. Qui signifie que vous pouvez prononcer 00:43:24.450 --> 00:43:29.230 récepteur un, que vous voulez localiser périphériques de 1 à 100. Par conséquent, il 00:43:29.280 --> 00:43:32.810 va aller et demandez les sessions 1 par le biais de 100 et seront épinglés 00:43:32.860 --> 00:43:33.440 à qui. 00:43:35.000 --> 00:43:39.680 Et bien sûr vous pouvez stocker état. Donc je vais vous montrer la 00:43:39.730 --> 00:43:43.490 code pour cela. Vous effectuez l'essentiel la valeur true après la session authenti 00:43:43.540 --> 00:43:45.270 vous créez la file d'attente. 00:43:45.790 --> 00:43:49.670 Sur le côté de l'envoi, il vous suffit définir une propriété, l'identificateur de session. 00:43:50.530 --> 00:43:55.720 Puis sur recevoir côté, tous les même type de paramètres s'appliquent 00:43:55.770 --> 00:43:59.840 comme je vous ai montré, le message d'acceptation session, vous pouvez accepter 00:43:59.890 --> 00:44:03.730 session avec un ID de message ou maintenant ce que nous avons vient de sortir 00:44:03.780 --> 00:44:08.760 est un moyen très simple de la possibilité de faire 00:44:11.810 --> 00:44:13.010 récepteurs de la session. 00:44:14.920 --> 00:44:18.080 Par conséquent, je vais ouvrir un expéditeur de session. 00:44:18.970 --> 00:44:21.810 Nous avons déjà réalisé que le traitement par lots est le meilleur moyen d'envoi 00:44:21.860 --> 00:44:25.740 Ainsi, tous les l'expéditeur fait pour chaque session ID il va 00:44:25.790 --> 00:44:30.240 envoyer autant de messages que le ID de session, plus un. Par conséquent, si elle a 00:44:30.290 --> 00:44:33.480 ID de session, je vais vous envoyer deux messages. S'il s'agit de session 00:44:33.530 --> 00:44:36.070 ID deux, je vais vous envoyer trois messages et ainsi de suite. 00:44:37.350 --> 00:44:38.920 Je commencerai donc simplement l'expéditeur. 00:44:39.880 --> 00:44:43.910 Et dans ce cas, si vous examinez cette file d'attente, sur un échantillon de file d'attente de messages, 00:44:44.580 --> 00:44:49.140 Création de cette file d'attente, le une seule propriété supplémentaire à définir 00:44:49.190 --> 00:44:55.090 Il n'était, l'exigent la propriété session. C'était la seule différence. 00:44:55.670 --> 00:44:59.940 Maintenant lorsque vous passez à ce particulier file d'attente et que vous consultez qu'il a 00:44:59.990 --> 00:45:02.440 propriétés, que vous allez 00:45:08.230 --> 00:45:09.410 reportez-vous à la section qui... 00:45:11.710 --> 00:45:16.480 nécessite la propriété de session valeur False. Qui n'est pas recommandé. 00:45:16.530 --> 00:45:20.780 OK. Me permettre de supprimer puis de cette file d'attente. 00:45:24.670 --> 00:45:34.390 Créer sur un exemple de session de message. 00:45:37.280 --> 00:45:38.780 Requièrent la session. 00:45:45.040 --> 00:45:47.020 Va pour lire mon de l'expéditeur. 00:45:51.490 --> 00:45:53.840 Ceci démarrera ainsi envoyer des messages. 00:46:09.430 --> 00:46:18.880 Je suppose qu'il ne trouve pas que nom de la file d'attente dès maintenant. 00:46:18.890 --> 00:46:20.800 [Indiscernible] 00:46:20.870 --> 00:46:27.580 >> Oh, a I ? Sur les sessions de messagerie... Oh, vous êtes prêt. 00:46:29.640 --> 00:46:36.750 Parfait. Je vais changer exemple de session de sur message. 00:46:39.450 --> 00:46:40.630 Merci beaucoup. 00:46:42.100 --> 00:46:43.360 Maintenant nous allons exécuter cet élément. 00:46:46.770 --> 00:46:49.710 Vous êtes prêt. A l'envoi de tous les messages. Maintenant nous allons 00:46:49.760 --> 00:46:54.350 vous ce que le code de réception l'aspect de ce. 00:46:55.510 --> 00:46:59.710 Il s'agit de l'API neuve qui Nous avons publié seulement, la sur 00:46:59.760 --> 00:47:02.010 API de traitement du message. 00:47:03.430 --> 00:47:07.500 Dans votre rôle de travail Azure, Je vais modifier cette trop. 00:47:10.890 --> 00:47:14.690 Dans votre rôle de collaborateur Azure, sur le méthode start vous feriez 00:47:14.740 --> 00:47:19.540 le même vérifier simplement si la file d'attente existe et vous créez le qClient. 00:47:20.250 --> 00:47:24.120 La règle d'exécution, vous remarquez que votre le code obtient encore plus simple. 00:47:25.610 --> 00:47:29.270 Tout ce que vous faites ceci est appel d'une caisse enregistreuse. 00:47:29.900 --> 00:47:32.770 Pour enregistrer un gestionnaire de session. 00:47:33.670 --> 00:47:36.500 Et c'est tout. Aucun deceive boucles à écrire. 00:47:37.120 --> 00:47:38.950 Aucune durée de vie pour gérer. 00:47:39.580 --> 00:47:43.920 Tout cela est pris en charge par la bibliothèque cliente pour vous. 00:47:43.970 --> 00:47:48.540 Vous devez encapsuler les votre logique de la manière dont vous allez 00:47:48.590 --> 00:47:53.790 pour traiter ce flux de données unique dans un classe appelée le Mon Gestionnaire de session. 00:47:54.700 --> 00:47:57.450 Nous allons étudier cette classe et voyez ce que je fais ici. 00:47:58.700 --> 00:48:02.660 La première chose est que dois-je faire lorsque En fait, j'obtiens le message ? 00:48:05.430 --> 00:48:09.430 Dans le message, je suis simplement l'impression de que j'ai reçu le message et 00:48:09.480 --> 00:48:10.870 Je suis l'augmentation de mon compte. 00:48:11.610 --> 00:48:15.320 Voilà, je fais dans cette classe. Nombre est un membre privé 00:48:15.370 --> 00:48:19.860 ici et nous allons simplement enregistrer cette valeur. 00:48:21.090 --> 00:48:22.960 Pour définir le nombre de 00:48:24.710 --> 00:48:28.550 est égal à zéro et nous Gardez un nombre C'est mon traitement de toutes les est. 00:48:29.270 --> 00:48:34.550 Session fermée, fermeture de session est appelé lorsqu'il n'y a aucune 00:48:34.600 --> 00:48:38.750 plus de messages disponibles pour ce session ou vous avez atteint 00:48:38.800 --> 00:48:42.360 le nombre maximal de devise. Nous avons parlé de sur combien simultanément 00:48:42.410 --> 00:48:43.630 vous souhaitez disposer. 00:48:44.260 --> 00:48:48.230 Par conséquent, si vous avez atteint votre max nombre d'accès concurrentiel de combien 00:48:48.280 --> 00:48:53.040 sessions à traiter, nous appelons Fermez cette session et ouvrez 00:48:53.090 --> 00:48:57.610 une nouvelle session en fonction de quels messages sont disponibles. Si vous fermez 00:48:57.660 --> 00:49:00.700 l'occasion pour vous dire que j'ai obtenu un ensemble de messages, avez 00:49:00.750 --> 00:49:03.900 le traitement de donnée session et maintenant je doit 00:49:03.950 --> 00:49:05.580 Enregistrez cet état. 00:49:07.140 --> 00:49:10.730 Et vous pouvez visualiser ici je fais définir l'état et get appelle 00:49:10.780 --> 00:49:15.250 état qui se trouve sur l'objection de la session. Il s'agit essentiellement de flux. 00:49:16.050 --> 00:49:20.770 Et le stockage de la valeur de count absent chaque fois que la session est fermée. 00:49:21.780 --> 00:49:26.130 Et puis la finale est l'erreur cas de lorsqu'une session est perdue. 00:49:27.420 --> 00:49:31.050 Maintenant n'oubliez pas, la raison pour laquelle vous êtes en mesure de pour établir une corrélation entre tous ces messages 00:49:31.100 --> 00:49:34.310 car nous verrouiller une session pour vous avez. Nous nous assurer que vous êtes 00:49:34.360 --> 00:49:38.790 le récepteur uniquement qui est mise en route messages de cette file d'attente secondaire, 00:49:38.840 --> 00:49:40.510 ce sous-session. 00:49:41.190 --> 00:49:43.780 Et vous pouvez perdre toujours un verrou. Un verrou seraient perdu, car 00:49:43.830 --> 00:49:47.660 d'une panne sur le serveur. Il a pu être perdue en raison de la connexion 00:49:47.710 --> 00:49:51.410 problèmes ou peut-être votre processeur tout est en attente et qu'il a perdu le verrouillage 00:49:51.460 --> 00:49:55.290 dans la mesure où il puis effectuez une opération Dans cet emplacement afin que vous disposiez toujours 00:49:55.340 --> 00:49:58.940 Cette erreur est appelée. Dans ce cas, tout ce que vous ferez est abandonner le 00:49:58.990 --> 00:50:03.500 jeu local de modifications et de déplacement sur. En termes de qui. 00:50:04.870 --> 00:50:07.150 Voyons donc ce que cela ressemble. 00:50:07.670 --> 00:50:08.790 Une exécution réelle. 00:50:10.210 --> 00:50:10.800 Existait une question ? 00:50:10.850 --> 00:50:11.930 >> De fonctionnement identique 00:50:13.740 --> 00:50:17.500 >> Donc la question a été : cela fonctionnera le même pour les abonnements ? Cent pour cent. 00:50:17.550 --> 00:50:21.170 Il est complètement symétrique. Si vous vous recevez à partir d'une file d'attente 00:50:21.220 --> 00:50:24.130 ou bien, vous recevez à partir d'un abonnement. 00:50:25.440 --> 00:50:28.920 Voici donc mon rôle de travail maintenant. Vous permettent de Me vérifier réellement rapidement ce que 00:50:28.970 --> 00:50:30.850 le compteur de file d'attente était comme après le 00:50:32.060 --> 00:50:36.390 rôle se faisait envoi. Ressemble à Il comporte des 3,700 messages droit 00:50:36.440 --> 00:50:40.610 à présent, 33, ressemble à traitement a exclu. 00:50:41.650 --> 00:50:56.690 Me laisser passer dans cet emplacement... Aller. Il est proche. 00:50:56.740 --> 00:51:03.350 Bonne. Donc maintenant, de mon ordinateur travail via et vous 00:51:03.400 --> 00:51:06.090 peut voir des milliers de traitement et des milliers de messages. 00:51:06.890 --> 00:51:10.740 Et le code que j'ai écrit était réflexion très, très simple 00:51:10.790 --> 00:51:15.170 à propos de simplement une session simple, un seul session et je n'avais 00:51:15.220 --> 00:51:18.800 pour écrire une boucle de réception unique. Je veux juste vous deviez inscrire le Gestionnaire de canal de communication. 00:51:19.200 --> 00:51:23.370 Le gestionnaire dont je vous ai montré est le cas simple où vous 00:51:23.420 --> 00:51:28.420 peuvent avoir des instances de cette création et Vous ne faites pas l'initialisation. 00:51:28.450 --> 00:51:32.020 Nous disposons d'une fabrique de sauvegarde qui est également disponible. Vous pouvez faire 00:51:32.070 --> 00:51:36.960 une fabrique de gestionnaires de Registre et que Vous pouvez contrôler la création de façon 00:51:37.010 --> 00:51:38.700 sémantique de qui également. 00:51:40.370 --> 00:51:43.560 Mais ici, vous pouvez voir persistent état et fermée la session. 00:51:44.420 --> 00:51:48.340 Je vais zoomer ici afin que les gens peuvent voir clairement ce qui est arrivé ici. 00:51:49.070 --> 00:51:54.740 Si vous voyez chaque session, session l'état était 22 pour session 21. 00:51:54.790 --> 00:51:57.810 L'état de session a été 46 pour la session 45. 00:51:58.620 --> 00:52:03.770 Étant donné que cette classe est uniquement les messages qui appartenait à cette session. 00:52:04.200 --> 00:52:08.320 Tout ce qui a demuxing et muxing simple et tout ce qui a été géré 00:52:08.370 --> 00:52:12.410 par Bus de Service pour vous. Donc lorsque vous pensez à multiplexage 00:52:12.460 --> 00:52:15.990 un grand nombre d'expéditeurs dans un petit nombre de files d'attente, connaître 00:52:16.040 --> 00:52:19.260 vous n'avez pas perdu la simplicité d'être en mesure de traiter 00:52:19.310 --> 00:52:23.800 sur le back-end à l'aide Ces flux de données individuels 00:52:30.570 --> 00:52:34.260 Dans cet emplacement. 00:52:37.740 --> 00:52:41.000 Nous avons parlé de l'état de session. Corrélation à l'aide de sessions. 00:52:41.350 --> 00:52:46.020 Juste pour résumer, effectivement avant de nous résumer, accédez à. 00:52:46.590 --> 00:52:49.230 Donc une autre considération clé est une fois ces très, très 00:52:49.280 --> 00:52:52.530 grand nombre d'expéditeurs, quel est le modèle d'authentification ? Quelle est la sécurité 00:52:52.580 --> 00:52:55.750 modèle que vous allez utiliser ? Par conséquent, je dirais accès partagé 00:52:55.800 --> 00:52:58.420 la signature est sans aucun doute la recommander le modèle d'authentification. 00:52:59.010 --> 00:53:02.150 Il existe beaucoup plus de détails. En fait le pont n'a plus de détails sur 00:53:02.200 --> 00:53:08.190 comment configurer des signatures d'accès partagé. Vous pouvez accéder au portail 00:53:08.540 --> 00:53:10.040 et de gérer vos files d'attente. 00:53:10.910 --> 00:53:15.270 J'ai ici la IOT en file d'attente que vous nos spécialistes ès utilisent depuis le site Web. 00:53:16.050 --> 00:53:18.850 Et je peux simplement aller ici et configurer. 00:53:19.420 --> 00:53:23.650 Notez que je devais Oh... 00:53:23.660 --> 00:53:23.720 [Indiscernible] 00:53:23.700 --> 00:53:25.290 >> Je suis je suis désolé. Je suis donc Désolé. 00:53:28.330 --> 00:53:33.790 Par conséquent, j'ai rajouté au portail Azure et j'ai sélectionné Ma file d'attente IOT. 00:53:34.890 --> 00:53:38.340 Et dans ce cas, lorsque j'accède à la configuration onglet, consultez mon partagé 00:53:38.390 --> 00:53:42.420 noms d'accès stratégie ici. Dans Cet exemple de site Web que je 00:53:42.470 --> 00:53:45.240 vous a montré, si j'appelle une réception, s'il serait effectivement 00:53:45.290 --> 00:53:49.650 échouer parce que maintenant, le seul l'autorisation sur ce est envoyer. 00:53:50.890 --> 00:53:54.310 Mais je peux facilement accéder et ajouter l'écoute autorisation de cette règle. 00:53:55.730 --> 00:53:56.440 Cliquez sur Enregistrer. 00:53:57.340 --> 00:53:58.640 Indiquant que la file d'attente de mise à jour. 00:53:59.190 --> 00:54:00.050 Et maintenant 00:54:01.700 --> 00:54:06.780 jeton qui a été généré pour ce règle aura la possibilité de 00:54:06.830 --> 00:54:11.480 pour à la fois envoyer et recevoir. Donc maintenant Je peux aller ici et cliquez sur recevoir, 00:54:12.880 --> 00:54:15.660 Ainsi, vous êtes prêt. Ressemble à des gens ont envoyé des messages. 00:54:15.710 --> 00:54:18.320 Donc maintenant vous allez à la session de conversation vont, vous guys pouvez rester en contact 00:54:18.370 --> 00:54:20.210 entre eux en ligne. 00:54:21.490 --> 00:54:24.220 Signature d'accès donc partagé, sont très, très légers, sont très 00:54:24.270 --> 00:54:28.290 modèle facile à utiliser. Si vous avez besoin Plongez dans un genre de descripteurs de sécurité du modèle, 00:54:28.340 --> 00:54:35.540 sont QU'ACS est entièrement compatible. ACS est toujours l'option de droite il. 00:54:35.590 --> 00:54:37.660 Vous venez de voir avec les files d'attente. 00:54:39.580 --> 00:54:43.390 Venez donc résumer, nous avons vu des protocoles. Pourquoi ils sont pertinents. 00:54:43.650 --> 00:54:47.970 Nous avons parcouru la corrélation de flux de données, pourquoi il n'est pas nécessaire que 00:54:48.020 --> 00:54:50.860 vous créez une file d'attente par périphérique. Vous ne souhaitez pas gérer 00:54:50.910 --> 00:54:53.980 files d'attente d'un million. Mais ce n'est pas pour être écrit du code qui 00:54:54.030 --> 00:54:57.760 doit être trop complexe super. Par conséquent Ces deux sont très, très 00:54:57.810 --> 00:55:00.840 facilement prises en charge avec le Service Bus de messagerie. 00:55:01.900 --> 00:55:05.320 Files d'attente, rubriques, abonnements. Symétrique dans chacun d'entre eux. 00:55:05.370 --> 00:55:08.990 Tout ce que je vous ai montré en termes de ce qui fonctionne avec les files d'attente pour 00:55:09.040 --> 00:55:12.280 sessions fonctionne exactement de la même façon avec des rubriques et des abonnements 00:55:12.330 --> 00:55:16.290 et les filtres. Lorsque vous créez un abonnement, vous dites simplement nécessite 00:55:16.340 --> 00:55:18.360 session sur celui-ci est égal à true ou non. 00:55:21.680 --> 00:55:22.910 Mettre à l'échelle sur les récepteurs. 00:55:27.210 --> 00:55:30.850 Visual Studio a ce défi où vous pouvez lancer une tonne de 00:55:30.900 --> 00:55:34.520 les instances de votre IDE, puis Vous pouvez accéder et modifier votre 00:55:34.570 --> 00:55:37.840 profil sur l'un d'eux et que vous que tous les synchroniser. 00:55:38.640 --> 00:55:41.980 Comment allez-vous faire communiquer pour toutes les instances ? 00:55:42.490 --> 00:55:45.600 Et ce sont les instances dynamiques trop, car le nombre de VS 00:55:45.650 --> 00:55:49.910 varie en fonction des instances que vous avez lancé selon le jour de la semaine. 00:55:49.960 --> 00:55:53.530 Nous disposons des statistiques pour indiquer que, par ailleurs. 00:55:53.580 --> 00:55:57.170 Personnes ouvrent des instances de façon plus le mercredi qu'ils ouvrent le vendredi. 00:55:57.220 --> 00:56:04.740 Par conséquent, la productivité est mise en réservoir d'ici le vendredi. Ainsi, malgré tout, le problème peut à nouveau 00:56:04.790 --> 00:56:07.440 être résolus avec des rubriques où vous avoir des millions et des millions de 00:56:07.490 --> 00:56:11.110 points de terminaison. Et si vous souhaitez que toutes les en écoutant leurs propres une 00:56:11.160 --> 00:56:14.070 abonnement unique pour les messages. 00:56:15.150 --> 00:56:19.140 Si ces messages sont généré en back-end en fonction 00:56:19.190 --> 00:56:22.840 sur certaines modifications dans le système ou par exemple, vous souhaitez envoyer 00:56:22.890 --> 00:56:26.270 une notification à un utilisateur, vous souhaitez pour les informer sur Windows 00:56:26.320 --> 00:56:30.510 case 7 où vous n'avez aucune notification service. Vous souhaitez avertir 00:56:30.560 --> 00:56:34.520 leur dire Bonjour il existe une nouvelle mise à jour disponible dans Visual Studio, 00:56:34.570 --> 00:56:39.970 Passez le télécharger. Ou plus important encore leur donner un tri faible temps de latence 00:56:40.020 --> 00:56:43.890 du tuyau où s'ils apportent des modifications sur une seule instance de VS, l'autre 00:56:43.940 --> 00:56:45.430 Instances de VS synchroniser. 00:56:46.140 --> 00:56:48.340 Vous pouvez sues des rubriques et Pour que les abonnements. 00:56:49.760 --> 00:56:52.470 Par conséquent, considérez-le conceptuellement en tant qu'utilisateur rubrique par VS. 00:56:53.200 --> 00:56:58.800 Vous avez une instance par VS de souscription toujours connecté à l'aide de MQP. 00:56:58.850 --> 00:57:03.260 Par conséquent, MQP nous offre un grand nombre de connexion efficacité de l'endroit où vous avez 00:57:03.310 --> 00:57:07.830 Nous millions et des millions de utilisation simultanée des sections avec très, 00:57:07.880 --> 00:57:12.350 frais administratifs très faibles, simplement en attente pour les notifications occasionnelles. 00:57:12.380 --> 00:57:14.840 C'est la différence sur les notifications. Ils sont très occasionnelles 00:57:14.890 --> 00:57:18.080 dans la nature. Faire la fréquence à laquelle les gens modifier la couleur de leur profil ? 00:57:19.770 --> 00:57:20.260 Une journée ? 00:57:20.310 --> 00:57:22.960 Semaine ? J'espère que pas tous les jours. 00:57:23.790 --> 00:57:25.160 Dépend de votre humeur que ça. 00:57:26.260 --> 00:57:29.100 Mais ne se produit pas très souvent. La fréquence à laquelle ils ont des mises à jour 00:57:29.150 --> 00:57:33.660 à distribuer ? Pas très souvent. Mais vous avez toujours ce type BNS 00:57:33.710 --> 00:57:38.290 de l'infrastructure disponible pour Lorsque vous disposez de connexions 00:57:38.340 --> 00:57:41.780 en attente de cette notification, car lors de la notification 00:57:41.830 --> 00:57:45.170 devient disponible, utiliser dans un instant. Vous souhaitez droite 00:57:45.220 --> 00:57:46.040 puis et là. 00:57:51.000 --> 00:57:54.990 Vous devez donc vraiment à propos et vous devez penser 00:57:55.040 --> 00:57:59.320 sur les flux de message. Dans la mesure où aujourd'hui rubriques permettent jusqu'à 2000 00:57:59.370 --> 00:58:03.170 abonnements et quand vous pensez de l'échelle du nombre 00:58:03.220 --> 00:58:07.420 des récepteurs, 2000 peut s'avérer suffisante ou 2000 peuvent ne pas suffire. 00:58:07.980 --> 00:58:10.910 Si vous pensez à propos de Visual Studio, une seule personne ayant plusieurs 00:58:10.960 --> 00:58:13.700 de 2000 instances de l'environnement IDE en cours d'exécution est 00:58:16.030 --> 00:58:20.210 pratiquement impossible. Je ne sais pas peut-être Il est possible, mais il ne se produit pas. 00:58:20.520 --> 00:58:24.520 Ainsi, pour eux, un utilisateur par VS de rubrique est correctement, mais pour vous qu'il peut 00:58:24.570 --> 00:58:27.660 être que tout le monde est à l'écoute au même flux. Vous souhaitez 00:58:27.710 --> 00:58:30.790 être en mesure d'envoyer à tout le monde envoyer... un seul message et l'envoyer 00:58:30.840 --> 00:58:34.790 une large diffusion à tous les utilisateurs. Eh bien, puis vous souhaitez chaîner des rubriques. 00:58:35.250 --> 00:58:38.680 Et vous qui utilisez faire auto transfert. 00:58:39.850 --> 00:58:43.350 Je ne vais pas passer en grappe Ces détails de motif dans 00:58:43.400 --> 00:58:45.280 conditions de la façon de définir des filtres. 00:58:45.800 --> 00:58:48.520 Tous ces éléments sont des exemples de MSDN.com. 00:58:49.130 --> 00:58:55.380 Cet exemple particulier est appelé. liste. Il existe un échantillon appelé 00:58:55.430 --> 00:58:58.720 publier s'abonner. Le code complet Il est disponibles. 00:58:58.770 --> 00:59:02.570 Vous encourage vivement guys pour aller prendre un coup de œil, mais avec ces rubriques 00:59:02.620 --> 00:59:06.190 Vous pouvez régler vraiment des ces riches les flux sont où chaque message 00:59:06.240 --> 00:59:09.930 ne doit pas routés à tous les gens de 2 millions, puis 00:59:09.980 --> 00:59:14.280 chaque heure d'être supprimé. Il peut obtenir routées vers une personne, à de nombreuses 00:59:14.330 --> 00:59:18.680 personnes, ou dans un type sans fin de cas où vous écrivez uniquement les adresses. 00:59:18.730 --> 00:59:19.660 Comme le courrier électronique. 00:59:20.190 --> 00:59:23.130 Dans ce cas, il ressemble à considérer le message que je peux dire que tout d'abord, 00:59:23.180 --> 00:59:24.230 virgule, seconde. 00:59:25.130 --> 00:59:27.850 Et je suis adressage deux appareils : le premier périphérique et la seconde 00:59:27.900 --> 00:59:30.770 périphérique ou deux abonnements ou plus, la première et la deuxième. 00:59:30.820 --> 00:59:35.390 Parce qu'ils ont des règles définies comme d'abord, comme second dans cet emplacement. 00:59:36.390 --> 00:59:40.470 Par conséquent, regardez ces sub pub (indiscernible) 00:59:42.610 --> 00:59:47.050 transfert automatique. Très, très facile à utiliser. Vous créez essentiellement 00:59:47.100 --> 00:59:52.150 la destination de la file d'attente préalable et puis, dans la file d'attente source, vous 00:59:52.200 --> 00:59:55.970 Ajoutez une propriété unique. La propriété unique est appelé source.ForwardTo, 00:59:57.220 --> 01:00:00.600 la file d'attente de destination et c'est la Il s'agit. Tous les messages entrants 01:00:00.650 --> 01:00:03.280 dans la file d'attente source, allez dans la file d'attente de destination. 01:00:03.330 --> 01:00:10.030 Les sources peuvent être des abonnements et files d'attente. Les audits peuvent être sujets 01:00:10.080 --> 01:00:10.960 et les files d'attente. 01:00:13.190 --> 01:00:16.800 Complètement symétrique, paramétrez les autant excuses de police que vous feriez 01:00:16.850 --> 01:00:18.810 comme et constatez que. 01:00:19.400 --> 01:00:22.540 Si vous disposez de cas transitoire où vous avez des abonnements qui 01:00:22.590 --> 01:00:23.390 Partez, 01:00:24.660 --> 01:00:28.430 Vous pouvez utiliser la suppression automatique sur inactif. Par conséquent Cette fonctionnalité est également très intéressante. 01:00:28.480 --> 01:00:32.570 Nous allons vous gérez un nombre important de connexions en régime transitoire. En fait 01:00:32.620 --> 01:00:35.640 un des scénarios clés, il s'agit de en cours d'utilisation est en SignalR et 01:00:35.690 --> 01:00:38.590 E/s de socket. Ils sont très, très transitoire dans la nature. 01:00:38.640 --> 01:00:40.200 Les connexions sont fournis, les connexions vont. 01:00:41.380 --> 01:00:43.700 Charges ajoutées et nœuds de suppression. 01:00:44.600 --> 01:00:48.680 Ainsi, ils utilisent des Bus de Service sous la forme d'une copie de sauvegarde lire où essentiellement ils sont 01:00:48.730 --> 01:00:52.540 écriture d'un abonnement par nœud chaque fois que un nouvel abonnement est fourni 01:00:52.590 --> 01:00:56.160 pas une nouvelle connexion s'affiche un nouveau nœud apparaît, quand ils 01:00:56.210 --> 01:00:57.260 ajouter des serveurs. 01:00:58.320 --> 01:01:03.210 Puis ils rubriques et abonnement le canal arrière à 01:01:03.260 --> 01:01:05.970 transfert les messages entre les nœuds et obtenez plus grande échelle. 01:01:07.010 --> 01:01:10.090 Et puis lorsqu'un nœud disparaît, l'abonnement arrive à expiration, ceux 01:01:10.140 --> 01:01:17.490 les messages ont maintenant disparus dans il. Les deux de ces code sont code ouvert. 01:01:17.540 --> 01:01:20.240 Les deux sont disponibles si vous le souhaitez mise à l'échelle, sortie signal ou Socket 01:01:20.290 --> 01:01:24.720 E/s car vous avez besoin d'une messagerie durable tuyau à la fin, Service 01:01:24.770 --> 01:01:27.980 Bus a mises en œuvre pour ces deux. 01:01:29.920 --> 01:01:33.050 Je ne voulait parler construit un peu sur la disponibilité je me 01:01:33.100 --> 01:01:36.780 porter rapidement sur qui. Je sais que Nous sommes presque au fil du temps 01:01:38.830 --> 01:01:42.440 le code doit être résistant à l'opération échecs, ainsi que de la connexion 01:01:42.490 --> 01:01:43.470 avec les problèmes. 01:01:43.990 --> 01:01:46.750 Files d'attente de lettres mortes, comme on a dit vous vraiment vous aider. Ils aident à 01:01:46.800 --> 01:01:50.790 vous au niveau de l'application de niveau où decivilization d'un message ou 01:01:50.840 --> 01:01:51.830 un élément peut échouer. 01:01:52.980 --> 01:01:57.440 Chaque message qui lève le Bus des services a une propriété transitoire en 01:01:57.490 --> 01:01:58.020 dessus 01:01:59.480 --> 01:02:02.780 clairement et simplement facilite Pour savoir si vous 01:02:02.830 --> 01:02:04.350 devoir de tentative ou non. 01:02:05.090 --> 01:02:08.560 Par défaut, nous avons effectivement sont automatiquement une nouvelle tentative. Par conséquent, j'ai parlé 01:02:08.610 --> 01:02:12.090 sur les délais d'attente essentiellement d'opération délais d'attente. Par défaut 01:02:12.140 --> 01:02:15.190 délais d'opération sont définis sur 60 secondes qui signifie que si vous 01:02:15.240 --> 01:02:19.720 appeler un envoi, une seule fois, il risque d'échouer Nous allons essayer à nouveau après 01:02:19.770 --> 01:02:22.980 trois secondes. Il peut le fichier deux fois. Nous allons Essayez à nouveau après dix secondes. 01:02:23.030 --> 01:02:27.840 Dans la mesure où les 60 secondes vous nous communiquez, nous allons Essayez d'effectuer cet appel aboutisse. 01:02:27.890 --> 01:02:29.740 Et dans le cas contraire, nous vous enverrons Il est à vous. 01:02:31.320 --> 01:02:33.650 Si vous disposez d'un autre endroit Pour rendre persistant, qui est correcte. 01:02:33.700 --> 01:02:36.920 Sinon Vérifiez comme transitoire et puis vous l'envoyer de nouveau, deviner. 01:02:38.160 --> 01:02:42.430 Et rubriques et les files d'attente de partition considérablement améliorer la disponibilité. 01:02:43.080 --> 01:02:48.230 Amélioration de l'ordre de grandeur. Par conséquent recommandons vivement, à l'aide de 01:02:48.280 --> 01:02:49.710 Cette fonctionnalité. 01:02:51.830 --> 01:02:55.280 Retenter au point de stratégies par défaut. Ne pas désactiver, veuillez. 01:02:57.200 --> 01:02:59.970 Espaces de noms associés. Le dernier chose que je vais parler aujourd'hui. 01:03:00.490 --> 01:03:03.540 Si vous avez un Bus de Service nommé espace, bien les messages sont transmis 01:03:03.590 --> 01:03:08.210 par l'intermédiaire d'et ensuite les données entières Centre de passe caput ou au moins 01:03:08.260 --> 01:03:13.570 l'espace de noms entier devient un caput. Espace de noms incorrect va créer. 01:03:13.620 --> 01:03:15.790 l'espace de noms de sauvegarder. Vous créez l'espace de noms de sauvegarder. 01:03:15.840 --> 01:03:19.190 Vous suffit de le fournir à nous et nous allons commencer à stocker les messages dans 01:03:19.240 --> 01:03:23.440 l'espace de noms de sauvegarder. Ainsi, toute message qui échoue aborder 01:03:24.140 --> 01:03:25.350 allez monter à l'arrière. 01:03:26.210 --> 01:03:29.450 À un certain moment démarrera messages traverse. Le système 01:03:29.500 --> 01:03:30.340 reviendra. 01:03:31.350 --> 01:03:35.150 À ce stade, nous avons un siphon prendra des messages à partir de ces 01:03:35.200 --> 01:03:39.110 files d'attente de transfert et de reenqueue les vers la file d'attente d'origine. 01:03:40.650 --> 01:03:43.590 Ainsi pour tout cela, votre code de l'expéditeur ne change pas, votre récepteur 01:03:43.640 --> 01:03:46.370 code ne change pas. Votre expéditeur et le récepteur, comme si elles étaient 01:03:46.420 --> 01:03:48.470 Parlez toujours à Service Espace de noms du bus. 01:03:49.240 --> 01:03:54.700 En pratique, nous allons créer les files d'attente de transfert, déplacement 01:03:54.750 --> 01:03:57.870 les messages de traction les Annuler pour vous. 01:03:58.720 --> 01:04:03.160 Et c'est la seule partie de code que vous avez à modifier. 01:04:03.740 --> 01:04:06.070 Ce n'est pas le travail seulement que vous avez pour le faire. Nous nous pencherons sur le 01:04:06.120 --> 01:04:08.520 considérations, mais ce n'est le seule une partie du code que vous devez 01:04:08.570 --> 01:04:13.330 modifier c'est-à-dire que lors de la création une fabrique, qui est votre 01:04:13.380 --> 01:04:17.690 Exécutez temps envoyer et recevoir le code classe, vous la coupler avec un nom 01:04:17.740 --> 01:04:21.230 espace, vous dire Bonjour qu'est une seconde en usine, un deuxième espace de noms 01:04:21.280 --> 01:04:24.130 avec lequel vous souhaitez que le Gestionnaire vous être associée. 01:04:24.660 --> 01:04:28.600 Et tout le reste est effectué par le côté client. Aucune modification de l'expéditeur. 01:04:28.650 --> 01:04:31.470 Aucune modification du récepteur. Code reste la même. 01:04:36.210 --> 01:04:41.520 Désormais, l'expéditeur disponible est pris en charge. Comme vous l'avez vu dans le diagramme, 01:04:41.570 --> 01:04:44.590 le récepteur ne recevra pas le message jusqu'à ce que le nom d'origine 01:04:44.640 --> 01:04:45.760 espace revient. 01:04:46.330 --> 01:04:49.340 Ainsi, il s'agit plus d'une disponibilité d'envoi. Dès maintenant, c'est pourquoi 01:04:49.390 --> 01:04:54.000 Nous l'appelons envoyer des options de disponibilité. Classement peut être perdu car 01:04:54.050 --> 01:04:57.910 messages qui se trouvent dans le transfert file d'attente ne s'afficheront pas. 01:04:58.630 --> 01:05:02.360 Et puis fin aux extrémités recevoir des temps de latence peut bien sûr être élevé. 01:05:02.410 --> 01:05:06.420 Il existe donc des considérations mais vraiment considérer cela comme 01:05:06.470 --> 01:05:10.730 un scénario clé de fabrication type de récupération après sinistre 01:05:12.070 --> 01:05:14.770 jamais les scénarios. 01:05:15.810 --> 01:05:18.710 Donc simplement pour fermer, nous avons vu Azure Bus de service peut réellement mettre à l'échelle 01:05:18.760 --> 01:05:21.870 dans toutes les dimensions. Beaucoup d'expéditeurs. Beaucoup de débit. 01:05:21.920 --> 01:05:23.080 Beaucoup de récepteurs. 01:05:23.730 --> 01:05:27.420 Vous pouvez améliorer la fiabilité les deux à l'aide des nouvelles fonctionnalités 01:05:27.470 --> 01:05:31.950 de la zone comme files d'attente de partition et associé les espaces de noms ou par 01:05:32.000 --> 01:05:37.320 rendre votre code d'utiliser des modèles comme Async et traitement par lots et sélections. 01:05:38.100 --> 01:05:41.750 Tonnes de liens. Tonnes de ressources. Vous avez accès à tout cela. 01:05:41.800 --> 01:05:44.130 Merci beaucoup. Toutes nos excuses Pour ce faire.