Bonjour à tous et bienvenue à l'Unhandled Exception podcast. Je suis Dan Clark et c'est
épisode 56. Aujourd'hui je suis venu à la chanson de Lailia Buggria pour parler de
l'Enseignement et la service bus et, selon sa bière, la fascination avec la solitude,
les rydoles distribuées, qui ressemble à ce qui est assez fun. Alors, bienvenue à la chanson Lailia,
c'est génial de vous avoir regardé. Merci pour avoir me, c'est bien d'être ici.
Ah oui, bienvenue, je pense que nous avons eu, on a eu ça dans le diaries depuis un
temps, c'est bien de parler de ça. Donc, pouvez-vous vous introduire à l'écoute et
vous dire un peu de ce que vous faites ? Je suis un architecteur de la solution des softwares
et de la solution. Je suis maintenant en train de travailler pour un softwares en particulier
à la base de la platform qui évoque les utilisateurs pour construire des systèmes distribués,
spécifiquement basés sur les technologies de message aussi. Et oui, je suis un développeur
pour, je ne suis pas sûr que je me sens confortable de partager pour combien de temps, mais non,
presque deux décennies, je pense, à ce point. Donc, je suis en train de travailler pour un
temps et je suis fait un très grand nombre de projets différents. Je suis travaillé
comme consultant. Un des plus grands projets que j'ai travaillé, à travers ma career,
était aussi à la banque où on a répliqué le mainframe, qui était encore en train de
travailler par une application moderne. C'était un projet vraiment, vraiment fun.
Et puis, il y a beaucoup, beaucoup d'autres choses. Et oui, j'ai commencé à utiliser
messe, à travers les années. Donc, je suis un customer avant que je travaillais en particulier,
mais oui, je pense que c'est aussi cool parce que vous pouvez aller dans la compagnie et dire,
« Bien, c'est les choses que j'aime, mais c'est les choses que je n'ai pas,
et puis comment on peut les improve, ce qui est toujours fun de pouvoir mettre votre
propre sort de dent sur un produit aussi. » Oui, c'est certain. Et c'est drôle,
no matter combien de temps vous avez été développeur, chaque jour est différent,
n'est-ce pas ? C'est une chose que j'aime beaucoup de cette chose.
Oui, oui. Et chaque jour, il y a quelque chose à apprendre,
si c'est techniquement ou non techniquement, vraiment.
Et il y a des problèmes pour l'investigation. Pourquoi ça marche ?
Oui, absolument.
Cool. Ok, donc avant de nous faire un service, mais je n'ai juste quelques
petites mentions avant de nous faire. Le premier est que mon cours de doc à
Dock est maintenant disponible. Et c'est sur Nick Japsons' Training Platform.
Les listeners peuvent utiliser le code « Dan Docker » pour s'en prendre 15%.
Donc, Dock est une technologie vraiment amusante et a beaucoup de cas de utilisation.
Et dans le cours, je vais traverser les bases, voir nos images, les containers.
Nous construisons nos propres images et nous allons aussi s'adresser à des plus
avances, comme la sécurité, la networking et comment les containers travaillent.
Et beaucoup plus. Donc, si vous êtes intéressés, je vais vous lier à la course dans les notes de la show.
Et le deuxième mention est que je n'ai maintenant commencé le Patreon.
Les supporters de la show peuvent maintenant avoir des épisodes un couple de jours plus tard et
ils vont être en train de se libérer. Et je vais aussi vous relier un épisode de la nouvelle
de la chaîne de l'Ontario.
Ce sera pour les supporters de la page Patreon.
Donc, si vous voulez supporter la show,
check out le link sur le site de podcast.
Et la dernière mention est que ce podcast a sa propre communauté de discord.
Si vous vous portez au site de la web « UnhandledExceptionPodcast.com »,
vous verrez un link de Discord.
Ok, donc maintenant, c'est tout pour nous.
Et le bus de service.
Je pense qu'on devrait commencer avec ce que le bus de service est.
C'est une bonne question.
Parce que je ne pense pas que c'est toujours super clair de la première fois que je
ai des questions, je veux dire tous les uns de la compagnie,
mais je aussi ai des questions beaucoup quand je suis à des conférences où les gens disent
« C'est-ce que c'est le même que le bus de service à l'Azure ? »
Par exemple.
Et c'est pas ça.
C'est une sorte de la layer de milieu qui s'étend à la top.
Donc, vous devez toujours choisir votre propre système de queue si vous voulez,
ou un système de queue que vous préférez utiliser.
Et ce que nous essayons de faire avec le framework et le plate-formes autour de ça,
c'est de juste faire cela semblant de l'utiliser.
Et de prendre en compte la complexité technique de la communication
pour avoir le temps de faire des messages dans un système,
pour que vous puissiez juste se concentrer sur vos besoins de business
et speeder votre cycle de développement.
Donc, est-ce que vous pourriez dire, pour le contexte de l'écart,
parce que nous avons un épisode 31 qui est sur le transit de la masse,
l'épisode 51 était avec Brighter, avec l'InCouper.
Et, en tant que l'anmoo, c'est une technologie très similaire.
Donc, pour le contexte,
vous disiez que c'est le même espace ?
Oui, je dirais que c'est très similaire.
On a des problèmes de la même manière, si vous voulez,
et on a des mêmes features.
Mais il y a toujours des différences plus grandes.
Si je dois être sur le top de mon cerveau,
et penser à quelques choses qui sont en train de se faire,
je dirais que, par exemple,
les tools de plate-formes que nous offrons,
qui font que ce soit beaucoup plus facile
pour se faire des scenarios de défaut.
Vous avez un build-up de messages dans votre RQ,
parce qu'il y a un bug,
ou il y a quelque part de votre infrastructure
qui était en train de faire un temps prolongant,
qui nous a aidés à faire des défauts,
et comment vous les retraiterez,
et peut-on vous les coller et les filtrer ?
Ou en pensant à un autre,
et en en dire, je dois avoir ce genre d'erreur,
mais comment j'ai eu l'air ici ?
Nous avons des tools pour des années,
qui vous permettent de visualiser le flow de messages,
et essayer de comprendre
quel sort de chaine de messages
qui a été envoyé à ce message,
et pourquoi ça a été failé.
Ce sont les choses que nous nous solvons,
avec d'autres choses,
comme l'observabilité,
mais c'est quelque chose que nous avons déjà investi,
en années, parce que nous avons sorti des points de paix.
Mais un autre gros point,
c'est que nous avons offert de support 24x7.
On a toujours des gens
qui sont disponibles pour aider les clients,
si ils sont en train de faire un problème,
qui peut se passer dans leur environnement de production,
si c'est une soirée,
ou une matinée,
il y a toujours quelqu'un qui se fait faire sure que personne ne s'en s'est pas mal.
Et il y a aussi un bunch d'autres features,
qui sont aussi utiles,
mais nous sommes en train de comparer un peu,
peut-être trop en détail.
Mais pour l'instant, c'est les choses que je voudrais appeler.
C'est vraiment cool.
Pour ce que tu as dit,
il y a beaucoup plus de choses que
l'Ensephir's Bus Library,
parce que tu as mentionné l'visualisation,
et tu as des dashboards et tout,
comme part de ça.
Oui, absolument.
Nous avons donc le contrôle de services,
qui est sort de l'endroit,
et si vous voulez,
où tous ces messages ont été faibles,
peut-être même des messages audits,
si vous avez les configurés.
Et nous avons un sort de front-end,
des front-end multiples,
sur le top de ça,
qui vous permet de voir
les messages qui ont été faibles,
ou de voir les métriques,
comment sont les messages ingestibles
dans un certain temps,
mais nous essayons aussi de
faire attention à des choses,
comme, comment ça prend,
pour un message de type spécifique,
pour se procurer,
pour avoir plus d'insights
dans ces types de choses.
Donc oui, il y a deux différents
sortes de front-end
qui sont en train de se battre
et de visualiser cette information pour vous.
C'est vraiment cool.
Je sais que, pendant ce temps,
nous parlons de ce genre de topic observable,
je sais que je l'ai dit,
mais je vais être careful de mentionner
l'opence de telemetrie,
car ça va se passer à un tout petit épisode.
Mais oui, on va le faire, on va le faire.
Je crois que c'est un nouveau
feature
et ServiceBus now supportent l'opence de telemetrie.
L'opence de telemetrie, oui.
Le sens de la observabilité, non.
Nous avons fait ça
depuis longtemps, avec les outils que nous avons,
mais avec nos outils de plate-formes,
c'est que vous pouvez visualiser le flow de message.
Et quand je commence
à comparer ça à l'opence de telemetrie,
l'opence de telemetrie est beaucoup plus grande.
Parce que
c'est pour ça que vous avez les API restants
ou les calles database
que vous faites,
ou peut-être quelque chose que vous vous portez
de l'argent ou pas,
ça vous donne beaucoup plus de détails,
beaucoup plus d'insights.
Ce que nos outils font,
c'est qu'ils fassent les messages.
Parce que c'est aussi ce que nous collectons
de l'information.
Ce qui est envoyé à l'envers,
c'est la deuxième, qui est toujours
privée à l'application.
Nous n'avons pas de ce type de data.
Mais oui, c'est limité
à juste les messages.
Alors que si nous parlons de l'opence de telemetrie
et de l'observabilité,
comme une grande concernation,
il s'agit de
quelque type de système de sub-systeme
qui est en partie
de votre système de large.
Si on regarde les pillars de la telemetrie,
les traces,
qui sont quasiment
les services de salle.
Où l'outil de la messager,
vous pouvez voir que
les choses qui s'appliquent,
comme un service qui fait un récit,
un service autre, etc.
Pour la messager,
vous avez toujours des traces,
mais par contre,
si vous fais un pattern de saga,
vous verrez que c'est une trace.
Donc,
par rapport à l'outil de la telemetrie,
l'outil de la telemetrie est ce que vous vous demandez,
oui, oui, oui.
Vous verrez exactement cela.
C'est un peu tricky,
en le sens que
tous ces calls sont synchronisés.
Ils peuvent aussi être connectés en temps.
Certaines des choses sont, par exemple,
solvées par trace links,
pour que la nouvelle trace soit connue,
mais elles sont toujours connectées.
Mais nous essayons de
regarder, comme vous l'avez dit,
quelque chose qui se passe très, très close
à l'un ou l'autre, pour exemple,
de toujours visualiser de la même manière,
parce que nous réalisons aussi
que c'est ce que les utilisateurs
vont essayer de faire des troubles.
Je pense que le suivi
de ces traces links est un peu...
Je dirais que j'espère que
pour cela, il y a un peu plus d'utilisation,
on va le mettre comme ça,
dans ces tools observables
dans le futur.
Mais bien sûr, c'est toujours
un peu plus grand,
et c'est toujours assez nouveau,
oui?
Je vais juste visualiser
cela, parce que je pense
que si un publiciste
a un message,
et le consommateur est en train
de faire 5 heures,
et le bug est fixé,
et il revient encore, et il s'en pique.
Donc, c'est 5 heures plus tard.
Est-ce que ce serait un 5-hour long trace,
et vous pouvez voir les timings
dans le graph de trace?
C'est le truc,
c'est que c'est dépendant de
comment c'est implémenté, et on a
aussi quelques issues,
je pense que j'ai ouvert,
en regardant ceci,
mais si c'est tellement connecté
dans le temps, il n'y a pas de trace
parce que vous ne savez pas
quel type de rétention
que les gens ont fait pour leurs traces.
Et si vous pensez aussi
sur les scénarios de sampling,
et que vous faites des samples de tails,
ça veut dire que vous allez
garder de collecter ces informations
pour que ce trace ne soit pas
completé,
ce qui pourrait être 5 heures,
comme vous l'avez dit, et ça va causer
beaucoup d'inquiétés, et ça serait
d'habitude une antipédale,
donc à un moment il y aura
une threshold de timings
que vous allez dire, si je ne vais pas
prendre tout le temps,
on va juste dédouer le tout trace,
ou juste les coller et les dédouer,
et on va juste le dédouer,
mais ensuite,
5 heures plus tard,
comme les consommateurs s'en retournent
et vous êtes consommé,
ça devient connecté.
Ce sont les parties des trucs drôles,
et c'est pourquoi nous essayons de relier
des liens, mais oui, comme je vous l'ai dit,
j'espère que cela va être un peu plus
user-friendly, car c'est plus facile
d'utiliser les liens,
car nous n'avons pas de care,
mais quand vous comparez
avec les liens, c'est
plus user-friendly de regarder
et d'investir, et d'understand
ce qui se passe. Mais je vous referai
à un blog poste où nous aussi
nous allons montrer comment cela fonctionne
dans le framework de service en service.
On peut définitivement inclure cela dans les notes de la show.
Donc, en tant que plus mature
en utilisant l'opinion de telemetry,
et l'opinion de telemetry peut évidemment
mettre des métriques, c'est standard,
donc vous pouvez utiliser le Grafano,
des dashboards, etc.
Vous avez vu les 4
users en service,
vous avez vu le go-to
des dashboards, comme tout,
ou encore votre plate-forme
des dashboards, est-ce que ça serait le meilleur place
d'aller ?
L'aimant, c'est
encore le meilleur place d'aller, parce que
nous avons déjà
décédé les métriques qui
font sens. Nous avons pensé
très longtemps et
plus tard, et basé sur un peu de feedback
des clients, et ça a
apporté à la sorte de métriques que nous avons
collectées. Maintenant, une des choses que vous pouvez aussi
faire, est de collecter ces métriques et de
les transmettre à quel point vous voulez.
Nous avons déjà décédé
les samples, si vous voulez, de
envoyer cette information à Grafano, et
nous sommes aussi en train de
incorporer cela en
en faisant
l'opinion de telemetry, si vous vous
vous en avez au côté de la métrique, mais
comme maintenant, nous avons souvent supporté la partie de tracé.
Vous pouvez aussi
connecter vos loges.
C'est très cool, oui.
J'ai dit que si on m'a dit que je vais parler de
l'opinion de telemetry, je pourrai vous
vous apporter.
Cette technologie, une des choses que je
n'aime pas, est un exemple
pour mes projets de présentation.
Je vais utiliser des choses comme
Rabiq, Locally,
mais en production, je vais
utiliser l'Ajacervis bus.
Et avoir cette abstraction
sur ce que la coque ne change pas,
c'est juste peut-être un peu de code bootstrap
qui change. C'est vraiment, vraiment
bon. Et puis, en regardant votre site,
il semble supporter beaucoup de choses.
En regardant, c'est comme Rabiq,
AjaService Bus, AjaStoreQ, Amazon,
SQL Server,
Amazon SQL Server, Amazon SQL Server,
c'est comme si vous avez supporté
beaucoup de choses différentes des
des messages de messages.
Oui, il y a plein de choses.
Et si vous trouvez quelque chose que vous
utilisez et que ce n'est pas dans la description,
vous pouvez nous le savoir,
parce que nous sommes toujours sortis
d'interessants pour voir ce qu'il y a
à l'intérieur. Mais nous trouvons
ce qui est vraiment important.
Notre goal est de faire ça plus facile
pour les messages de messages
indépendants de la message que vous
utilisez. Et nous avons aussi essayé
de regarder les features
qui vous font plus
successe de construire ces types
de systèmes. Et nous allons aussi essayer
de remplir les gâts
de l'interlayant de la systeme de queue
et de solider ça différemment.
C'est pourquoi nous avons aussi
dans notre documentation, pour exemple, toujours
une sorte de transport à un page de glace
où vous pouvez voir ce qui est supporté,
ce qui n'est pas, et comment est-ce
supporté nativement par le système de queue
ou pas, et des choses comme ça.
Donc, vous trouvez que vous avez
presque besoin, parce que c'est une abstraction,
de prendre
les plus communes de nos features,
par exemple, si AjaService Bus
fait quelque chose très spécifique
que les autres ne font pas,
si vous utilisez AjaService Bus, vous ne pouvez pas
faire ça ou avez-vous un moyen
d'en couper le plus
plus niche, pas le plus niche,
des features qui ne sont pas les plus
utilisées pour les brokers ?
Oui, c'est ce que j'ai cru.
Pour exemple,
je vais voir si je peux vous en parler
avec un exemple.
Pour exemple, on va dire que un type de
système de queue native, qui est supporté
par AjaService Bus, mais si vous utilisez
AjaSource queues, il n'y a pas de
topics là. Vous êtes toujours
capable de faire ça, d'ailleurs, parce que
nous avons sorti de le sol en dessous,
par utiliser notre mechanism de stockage
et des choses comme ça, pour que vous
puissiez toujours utiliser le même feature
et construire votre système de la même manière,
avec ce même
découpling que ça donne, sur le niveau
component, et nous sortions de
fixer ça pour vous, derrière les seins.
Et ça nous sometimes nous donne
un très très intéressant
problème dans la territoire,
mais c'est ce qui fait
plaisir, hein ?
Alors, avec AjaSource queues,
comme vous avez dit, c'est juste que
ce n'est pas des topics et des subscriptions, vous pouvez
faire ce genre de thing, ou peut-être
faire ce genre de thing en AjaService Bus.
Oui, exactement, vous pouvez.
C'est un système native, si vous
utilisez un table de stockage, vous pouvez
faire ça. Parce que
avec AjaSource queues, vous pouvez toujours
faire des tables de stockage, mais ça
n'a pas besoin d'un table de stockage.
Le truc est que ce que nous faisons,
c'est que nous serons
des choses en AjaSource.
Et c'est ce que ils disent,
c'est native, dans le sens que vous
vous utilisez
AjaSource, mais
nous utilisons
les tables de stockage et nous utilisons
les coupes de stockage, pour que vous puissiez
faire ou utiliser ces mécanismes de subscription.
C'est comme ça,
que vous avez fait un détail de
beaucoup de détails.
C'est assez complexe.
Mais il y a des choses que nous
essayons de voir, quelles sont
les des des features
qui font un différence
à nos utilisateurs et nous allons
trouver un moyen
pour essayer et faire
ce travail.
Oui, parce que je pense que
AjaSource queues, si vous vous faites
ça, c'est comme un concept de pollinger
plutôt que de la message qui vous a
pu.
C'est ce qui se passe derrière les scènes.
Je peux vous donner un autre exemple.
Par exemple, nous avons un
feature que nous appelons
« Delay delivery » qui est
de la message qui est
de la future.
Mais dans RabbitMQ, il n'y a pas
d'un concept comme ça.
Nous avons donc détenu
un concept très intéressant
où nous
faisons des queues, si je ne m'en fais pas
de la magnificence,
nous avons ajan spielt et

fine detector
compiled
data
et de la plage de l'un à l'autre.
C'est assez complexe.
C'est difficile de expliquer cela en mots
sans visualiser le processus.
Mais oui, c'est une solution intéressante
parce que nous savons que ce feature
est tellement utilisé.
Par exemple, si vous utilisez un Saga,
c'est super utile
d'exister
dans un Saga.
Je vais juste attendre
pour dire que vous avez un processus
d'exploitation.
Vous dites que
une des règles de ma business est que
ce s'est pas suffisant
pour deux jours de business
et si ça ne se passe pas, je vais réfinir.
Vous pouvez dire
que je vais vous demander un temps en deux jours
et que ça va vous invoquer
le Saga et
un temps-out-handler
et que vous pouvez faire les tests
et finaliser
votre processus.
De l'aspect de la business
est tellement
plus semblable et
plus...
Je n'aime pas
la manière dont ça vous guide
et
vous protège
pour un processus de single
et c'est une des choses
que j'ai vraiment aimé
quand j'étais un utilisateur
et un customer
c'est que
ce n'est pas un casseur de la bête
et qu'il y ait
des alertes de pétier
parce que la bête a fallu
à 4h00
et c'est
un de ses 90 ans
d'arrivée à 2000 ans
je ne sais pas si c'est ça plus longtemps
Je suis sûr que
la MQ a un plugin native
pour faire de la delivery
Ils le font
mais ni si, c'est pas là à la fois
quand ça a été implémenté
parce que ça va rentrer un peu
c'est de v3
v4.3
ou on n'a pas envie d'introduire
la dépendance des utilisateurs
pour utiliser ça
c'est un autre chose
on a essayé de faire
un peu plus possible
pour faire ça
parce que ça augmente la complexité
je vais vous dire
on a mentionné des choses
des retraités
et beaucoup de choses que vous avez parlé
ça nous montre
la complexité
parce que vous faites ça
on ne doit pas faire ça
on peut juste faire la valeur business
et vous vous rappelez des retraités
donc vous pouvez mettre des différentes
stratégies
sur les retraités et les weights
etc
c'est un set default
par définition
vous allez avoir des retraités
et des mécanismes
on a ce qu'on appelle les retraités immédiates
c'est que ça ne va pas tout de suite
il n'y a pas de temps de weight
et on a ce qu'on appelle
les retraités délais
ce qui est un backup mécanisme
donc ce que nous allons faire
c'est de
dire que ça a fail
et
on va juste attendre
parce que nous avons peut-être
un peu hésité
de faire la sort de la salle de la ressource spécifique
donc on va attendre un peu
et on va essayer de nouveau
et à ce point, nous sommes basé derrière
les scènes en utilisant le fonctionnement
des messages délaisés
pour dire que nous allons délaiir ce message
avec 5 secondes, 10 secondes, 15 secondes
et on va continuer de faire ça
pour quelques fois et à un moment on va dire
on a essayé de ne pas trop
faire ça pour vous
mais maintenant on va vraiment
faire quelqu'un à l'envoyer
et on va essayer de le faire
pour que vous puissiez
utiliser les outils de plate-form
pour comprendre le cas
très très cool
on a mentionné
les termes Saga
mais je n'ai pas compris
si les listeners ne savent pas
comment on parle
je pense que
c'est un peu de conflite
j'aime très bien
les transactions
les transactions
qui vous trouverez
sur les guideurs d'architecture
et sur le service
Saga
ils sont très similes
et vous pouvez acheter des choses similes
mais elles ne sont pas
tout à l'heure
les transactions
sont une sorte de pattern de management
et
il y a des nécessaires
pour ne pas avoir des transactions
encore plus
peut-être que vous utilisez
des cosmos dans le partage de votre système
et des équipes dans le partage de votre système
et maintenant vous devez
poursuivre un partage de transaction
des données à l'infrastructure
et ils ont tous leur management de transaction
mais vous ne pouvez pas combiner ces choses
mais c'est
pour vous
une transaction logique
et c'est une des choses que vous pouvez utiliser
pour utiliser une pattern de transaction
et vous devez utiliser
l'infrastructure A
donc le service s'existe
je vais essayer le prochain
et si ça ne suffit pas
je dois aller au service s'exister
et vous pouvez
faire ça avec un service en service
pour envoyer un message
pour faire le travail sur le service s'existe
pour envoyer le message
pour les cosmos
et vous devez utiliser un service en service
pour impliquer cette pattern
mais le service s'existe
et c'est un peu plus grand
parce que vous pouvez
penser à ces services
comme une implementation de la pattern orchestration
qui est
une pattern
que nous pouvons utiliser
pour coordinateer une transaction
plus grande de la transaction
avec une chorégraphie
comme une pattern opposée
si vous voulez
je pense que la latrine est quand je pense que le service s'existe
mais puisque ça est neuf
ce n'est pas forcément pas closing
mais c'est joli que ceciабатte
le service va en raison de ce que moi

c'est une transition
soit plus que lorsqu'ils sont posición
les usually







��
c'est que, généralement, vous avez des données et des databases, mais vous êtes aussi en utilisant un message broker.
Donc, vous êtes déjà, par définition, en utilisant deux différents types d'infrastructure avec, si vous voulez,
différents mécanismes de transaction.
Donc, c'est déjà très drôle.
C'est moins que vous en utilisiez un MSMQ, où ça vous a sorti de la main pour vous.
Pourquoi vous faisiez ça ?
Bien, je pense qu'il y a encore plein de très réussissimes applications en train de faire ça.
Mais clairement, ce n'est pas votre choix aujourd'hui.
Nous commençons à construire quelque chose.
Donc, ça nous a exposés à, ok, comment nous avons handlesé ça ?
Et je me sens juste comme si je me suis juste en train de mettre des patterns sur le terrain,
mais ça introduit une sorte d'outre-boxe pattern.
Ce que nous essayons de faire, c'est de créer la consistance entre vos opérations database et vos opérations broker.
C'est là où nous parlons des messages de la Ghost et des records de zombies.
Je trouve que ça me donne une opportunité de me faire faire des pictures de la Silly.
Mais, pense en un scédériaire où vous êtes en train de persister,
d'avoir des informations sur votre database, et puis vous voulez évoquer un événement
pour le signal de l'autre système, comme, je pouvais le détendre ou créer un ordre,
ou autre chose, pour le signal de l'autre système, un événement concrétiste qui a été créé.
Si vous pouvez commencer à avoir des informations sur votre database,
et puis la connexion de vos opérations broker s'élève,
alors que, à ce point, vous avez ce que nous appelons un record de zombies,
parce que c'est dans votre database, et cela a été évoqué par la transaction,
mais le reste de l'élément est complètement inévitable de la facture que ça a été passé,
parce que vous n'avez pas pu évoquer l'événement.
Donc, c'est un problème de consistance, et puis un alternative est de dire,
je vais évoquer l'événement, et puis je vais commencer à avoir des informations sur mon database.
Mais cela introduit le problème, le problème est que je vais évoquer l'événement,
le reste de l'élément se dévient, et puis je ne peux pas accéder à mon database.
Et puis vous avez un message de la Ghost, comme, ce message est dévoilé dans le système
que ce ordre était placé, mais ce n'est pas où il est trouvé dans le système.
Donc, c'est ce que l'outbox s'adresse, parce que ce que nous essayons de faire, c'est de dire,
vous savez, on va, à l'institialité, évoquer tout ce message d'opérations,
de rembourser les informations sur le database, de dégager les informations, et puis,
dans un autre mécanisme, ce qui est, en fait, beaucoup plus clair, on va évoquer ou évoquer
tout ce que l'opérations était, ce n'est pas vraiment important, c'est-à-dire,
qu'il soit un send ou une operation publique.
Donc, est-ce que ce que vous avez fait pour les messages de Ghost ou les messages de Zombie,
est-ce que ce que l'Enseignable est pour vous, ou est-ce que vous devez
impliquer quelque chose pour vérifier ces messages?
Non, c'est une des choses que nous faisons,
si vous avez juste évoqué l'outbox sur vos points de termin, parce que c'est un caveat,
vous devez faire cela à travers votre système entier, ou ce n'est pas le cas,
alors ce n'est pas un problème que vous devez penser, parce que ce que nous allons
prendre en compte est de se dédiéter toutes ces opérations, on pourrait être dédiéter
les duplicates, mais nous devons être sûrs que nous les dédiéterons sur le côté le plus
et c'est pourquoi c'est aussi important de l'outbox évoquer sur tous les points de termin,
parce que nous ne solvons pas cela sur un point de termin, nous essayons de ne pas
mais il y a des scenarios où les messages duplicates peuvent se dédiéter,
mais sur le point de termin de reçue, nous devons être sûrs que nous les dédiéterons.
Ça fait le sens?
Oui, donc si vous ne utilisez pas ceci dans le pattern de saga, et dis que je utilise
le service SQL comme mon premier database et que je vais juste utiliser un barbecue, ou quelque chose,
et un service bus, alors dans ce scénario, un service bus ne sait pas
tout ce que je vais utiliser pour le service SQL, si je vais utiliser le saga,
ça veut dire que je dois dire que c'est l'intégration entre service et service plus
que le service SQL à ce point?
Bien, vous pouvez toujours les avoir travaillés ensemble, parce que si vous utilisez un saga,
vous pouvez en dédiéter des informations dans votre data saga, qui est encore réglée par un service bus,
mais si vous ne pouvez pas dédiéter l'outbox, ça veut dire que vous pourriez
avoir ou recevoir des messages du duplicate, ce qui veut dire que vous devez avoir des handlers importants.
Je pense que ce que je veux dire, c'est que, par exemple, si j'ai un consommateur et que je dois faire
quelque chose comme créer un ordre, je peux utiliser un framework de l'entité pour parler à mon database,
et ça n'a pas de ce que je dois faire avec un service bus, mais si je vais utiliser l'outbox,
je dois changer et ne pas utiliser le framework de l'entité, ou j'ai un connecteur de l'entité,
je ne sais pas si je vais expliquer très bien ce que je vais essayer de dire, mais...
Oui, alors, ce premier statement n'est pas tout de même pas vrai, car quand vous sortez de
un point de service bus, vous allez dire que je vais travailler avec ce message broker,
mais généralement, vous allez aussi mettre un système de résistance, et ça va résoudre
ces problèmes, même si vous ne l'avez pas utilisé dans l'outbox. Donc, ça veut dire que si vous
vous êtes en train de créer un saga, et que vous avez votre point de service de l'entité pour utiliser
un framework, ou quelque chose, et que vous avez des tables complètement différentes, et tout ça,
c'est séparé de votre data de business, mais ça veut dire que nous pouvons encore utiliser la même transaction
pour se protéger de cette information, et ça se fait encore séparer du problème de la consistance
entre le message broker et les operations database. Je vois, donc il y a un message broker pour les messages,
il y a un message de business database, et une consistance de data store,
qui pourrait être le database de business ? C'est le database de business, et ça est souvent dans
ce que nous voyons nos clients se réunir, parfois, ils vont avoir peut-être un scheme différent,
ou quelque chose, mais généralement, c'est dans la même database, parce que nous pouvons leur donner
ces garanties de transaction, et ça explique, donc, ça fait qu'il y a de la série de
headaches que vous avez d'autre, ou que vous êtes exposés à ça.
Donc, dans ce database, est-ce que ça serait différent ? Vous avez dit que c'est un scheme différent,
ou est-ce que ça serait différents tables ou quelque chose, juste dans la même database,
ou est-ce que vous pourriez regarder les entities de framework, les détails ?
Non, donc nous ne touchons pas vos entités. Même si vous regardez par exemple le Saga Data,
c'est une entité complètement différente pour nous, on sort de se séparer de ça.
Parce que les choses importantes pour se rappeler sont que, quand un Saga est complet,
nous avons retiré le data de Saga, parce que le flow de business est sort de
démontré, donc nous ne nous restons pas de ce data. Donc, c'est généralement dans la même database,
ça pourrait être dans un scheme différent, ça ne pourrait pas être, c'est certainement
dans les tables différentes.
C'est vraiment bien, c'est vraiment bien. Je dois dire que, même si j'ai utilisé les messages,
je n'ai pas utilisé les Saga que beaucoup, donc j'ai toujours eu la séparation où je n'ai pas eu
mon database de business, je n'ai rien fait, les messages sont juste séparés, mais ça
semble que ça vous donne beaucoup d'extrême protection et résilience, je pense.
Je trouve que c'est un pattern vraiment powerful. Je pense que, certainement, comme un utilisateur,
c'est comme que vous êtes introduits à ce concept de Saga, et vous vous en voyez partout,
mais ça se passe avec tous les uns avec un type de feature ou un type de concept, mais je pense
que vous devez être aware de l'introduction et l'overhead, parce que ça signifie que
si vous êtes sort de processer un message qui est connecté à un Saga, vous devez toujours
obtenir ce data de Saga sur le database, pour que vous avez ça disponible pour travailler avec,
et tout ça. Et si vous faites des changements pour ça, ça va être persisté. Donc, vous devez être
aware que vous êtes sort de construire une machine de state, et de l'utiliser quand ça fait
sens. Quand vous avez une transaction complexe de business qui requiert de ce genre de choses.
Une des guidelines que je trouve vraiment powerful de penser sur ces choses,
c'est que si vous regardez à un processus complexe, surtout quand ça vous requiert de
faire des transactions, si les choses se sont mises ou pas même mises dans le sens technique,
mais dans le sens business, vous êtes credité, et maintenant, on doit peut-être canceler l'ordre.
Puis je trouve que l'approche orchestrée de Saga peut être superbe.
Oui, ça fait le sens très fort. Vous pouvez le faire, je pense, mais sans mentionner,
pour clake. Je pilgrse beaucoup plus le fleeing, alors je voudrais même s'allumer qu'il pel vole referral à
ces Serve dishon depressed. Je vais vous toneser les trucs, je vais vousOH spineuré,
Donc ça vous donne vraiment une idée de « je dois avoir une réquestion ici, mais je vais juste reposer à qui que je donne ça »
et on va juste prendre du travail en matière de messages que nous introduisons.
Mais oui, c'est l'une des patterns que nous soutenons.
Le subscribe publié est super super populaire, mais en fait, j'ai ça dans une de mes sessions,
j'ai tendu à utiliser ça comme un exemple pour prouver la vérité,
mais c'est vraiment important de comprendre quand la réponse de réquest est encore utile,
même dans un scénario de messages, et quand la chose est publiée,
c'est le meilleur.
Parce que l'une des choses que j'ai sorti de beaucoup, c'est ce que nous appelons « passives agressives »
parce que l'idée de la pattern de subscribes publiés est que le public est complètement inquiétant de les abonnés.
Mais si vous vous faites une évent, et vous avez cette expectation que quelque chose va arriver,
ou que vous allez avoir une réponse,
ou que vous avez des éléments qui sont abonnés à ça, et que vous êtes dépendants de ça,
alors que vous utilisez la réponse de réquest, parce que c'est ce que nous appelons « passives agressives »
Je compare toujours ça avec moi, en marchant dans la cuisine, après une évent,
mon mari est toujours assez gentil de la cuisson,
et puis je me dis « oh mon Dieu, c'est quoi? Qu'est-ce qui s'est passé?
Vous avez utilisé tous les pots et les panneaux dans la cuisine? »
Et à ce point, je peux éventer et dire « la cuisine est malade! »
Mais j'ai cette expectation que, 1, il m'a écouté,
et 2, qu'il va en faire actuellement et m'a aidé à me faire couler le mien.
C'est une communication passive agressive,
et je pense que nous pouvons tous s'y agir,
que ça ne soit pas vraiment bien pour vos relations,
mais j'ai essayé de comparer ça avec ça,
mais c'est aussi pas vraiment bien pour vos systèmes.
Donc, pour être clair sur votre intent, c'est expliqué.
J'adore tous ces différents termes,
comme passées aux événements agressifs, zombies, les réchauffements.
Je me souviens, en épisode 54, je parlais avec Matt Hunt
sur la peau de la mienne, il parlait de la CQS.
C'est très similaire de la situation où vous avez découvert
dans la cuisine avec votre mari,
il a découvert une situation avec une analogie
avec sa fille et d'en avoir à la cuisson.
Vous n'avez pas la commande de la salle,
et tout ça? C'est assez drôle.
Je me souviens.
Je me souviens.
Je me souviens.
Je me souviens.
Je me souviens.
Je me souviens.
Je me souviens.
Je me souviens.

Je me souviens.
Je me souviens.
Je me souviens.
Je me souviens.
Je me souviens.
Je me souviens, c'est faux c trabalhar,




chains de gourmet goings converties.
The
season MPL a




C'est un component qui va imprimer le modèle de la prière.
Et le autre est le point de vue.
Si il y a des endpoints où vous avez pu procéder des milliers de messages,
ça va aussi arriver dans une différence de prière,
en tant que je suis en train de prendre 10 à 100 messages par jour.
C'est aussi un impact.
Et nous avons aussi toutes ces autres questions,
quels types de support vous voulez,
et comment vite vous avez besoin d'une réponse.
Vous pouvez être en train de faire des versions d'older
que nous ne pouvons pas soutenir de la box anymore.
Mais parfois, c'est pas facile de garder les changements,
même si nous essayons de faire ça comme fréquentement possible.
C'est toujours parfois difficile de passer,
même si c'est juste de l'updater
et qu'il y a peut-être un changement de break-in,
ou même rien, parce que les gens qui nous ont introduits ne vous affectent pas.
Mais quand même, vous devez faire le tout,
ce qui est un détail massive si nous regardons les systèmes très grands.
C'est pourquoi nous avons aussi une offre.
C'est souvent, spécialement pour les entreprises,
qui donnent la confiance que nous avons payé pour nous.
Et ils savent que c'est une offre derrière nous
qui n'est pas quelqu'un qui fait ça en fait.
Je ne veux pas qu'on soit des gens qui font des projets en ce moment,
mais je pense que c'est un point de vue business
et qu'ils ont la confiance
de faire une technologie pour beaucoup de années.
Absolument. Je me sens très d'une perspective
pour beaucoup de membres de la communauté
qui travaillent sur les projets d'opensours.
Mais c'est aussi mon expérience.
Si vous êtes dans un état business,
et si vous travaillez avec des données cruciales,
ils parfois ont des propres policies
qui disent qu'on ne travaille pas sur le soutien de la software.
Si vous ne pouvez pas donner une offre pour une policy de soutien,
non, vous ne pourrez pas faire ce que nous pouvons faire
parce que nous ne pouvons pas prendre ce risque.
Mais je suis bien sûr que si vous faites un projet d'opensours,
vous pouvez utiliser en service bus for free.
Il y a un free tier pour l'opensours.
Absolument. Nous n'en sommes pas.
Je pense que c'est une édition de communauté.
C'est limité à un peu de points de terminus.
Mais vous pouvez utiliser ça dans un environnement de production.
Ça fait que c'est vraiment bien de commencer.
On peut même construire un partage de votre système
et de se mettre à la production,
voir comment ça fait et comment ça fait
de maintenir ce type de système
avant de aller en disant,
« OK, on va faire le whole shebang de cette façon. »
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.



On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.

On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.




On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.






On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.







On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.







On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.

On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.


On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.




On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.








On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.







On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.

On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.


On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.







On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.


On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.

On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.





On va faire le whole shebang de cette façon.

On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.

On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.



On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.


On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.

On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.



On va faire le whole shebang de cette façon.




On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.







On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.






On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.




On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.
On va faire le whole shebang de cette façon.

On va faire le whole shebang de la version que tu as appelé stehen Hani.
Mais une des choses que j'ai réalisé dans l'année est que je me suis apprécié à apprendre.
C'est une des choses que je trouve le plus fun et le plus réel, c'est la capacité de...
Je ne sais rien de cela.
Et quelques mois après, tu es comme...
Ok, je suis très bien à ça.
Je trouve cela super réel.
Je ne sais pas si c'est de la lait, mais c'est de la jouissance.
Tu joues, tu joues, tu joues.
Et tu joues comme un side effect.
Il y a beaucoup de toits et des outils pour jouer.
C'est très cool.
Cool.
On devrait vraiment rappeler.
Mais avant de faire ça, où est le place de blessure pour les listeners pour vous acheter ?
Vous avez des questions ?
Je suis sur Twitter, je veux dire X.
Je ne peux pas le dire X, c'est juste...
Pourquoi ?
Et on a aussi toujours dit tweet,
donc je ne sais pas comment ça va changer.
Mais de toute façon, c'est aussi un masodon,
mais le plus facile de me faire acheter est LinkedIn.
C'est le sort de platform social,
mais je suis aussi sur GitHub.
Il y a beaucoup de places où je vais vous partager.
Vous pouvez le mettre en info.
LinkedIn est la façon de aller.
Ou le podcast Discord ?
Ou le podcast Discord, absolument.
Je vais essayer de faire comme beaucoup de listeners
et de vraiment faire comme une communauté.
C'est une bonne communauté au-delà des épisodes
et tout ça.
On peut juste parler de différentes technologies.
Cool.
Avec ça, merci beaucoup d'avoir participé à la vidéo.
C'était vraiment un plaisir de geeker sur les trucs distributifs.
Merci d'avoir invité.
C'était un plaisir de vous dire.
Merci beaucoup.
Merci beaucoup à tous d'avoir regardé.
C'est un bon moment que ce podcast est sponsorisé par Everstack,
qui est mon propre company,
qui donne des services de développement et de consultation.
Pour plus d'informations, visite www.everstack.com.
Si vous aimez le podcast,
s'il vous plait, vous pouvez me séparer sur les mots de la social.
Je utilise le hashtag UnhandledException.
Je peux être trouvé sur Twitter.
X.
Et mon nom est...
Les listening cancés de votre expression.
Sorry, c'était drôle.
Je ne parle pas.
Je vais le lire,
parce que j'ai perdu ma trackworm.
Je sais que je vais le draper sur Twitter.
Je suis open.
Et mon blog,
www.dancoloc.com,
a des links à tous mes trucs sociaux.
Je vais me dire ça.
Et tous les links qu'on a mentionné,
seront incluses dans les notes de la show,
qui peuvent être trouvées sur UnhandledException.
Je ne peux pas parler maintenant.
Je vous remercie,
merci à tous d'avoir regardé.
Sorry.
Je ne peux pas m'en parler,
alors que c'était drôle.
Parce que je ne sais pas,
tu as dit que Twitter est X.
Je vais le dire.
Maintenant,
je vais me dire X,
je vais me remercier.
Et je vais commencer à rire.
...