Qu'est-ce que SEDA (Staged Event Driven Architecture)?

Une Étape est analogue à un "Événement". Pour simplifier l'idée, pensez à SEDA comme à une série d'événements qui envoient des messages entre eux.

une raison d'utiliser ce type d'architecture, je pense, est que vous fragmentez la logique et pouvez la connecter et découpler chaque événement, principalement pour les services de haute performance avec des exigences de latence faible s'adapte bien.

si vous utilisez Java TPE, vous pouvez surveiller la santé, le débit, les erreurs, la latence de chaque étape, et trouver rapidement où goulot d'étranglement des performances. Et comme un bel effet secondaire, avec de plus petits morceaux de code, vous pouvez facilement les tester et augmenter votre couverture de code (c'était mon cas).

Pour l'enregistrement, c'est l'architecture interne de Cassandra (NoSQL), et la Mule ESB (autant que je sache).

je recommande la lecture du papier original (désolé, dupliquer lien):

• https://github.com/mdwelsh/mdwelsh.github.io/blob/master/papers/seda-sosp01.pdf

voici un framework que j'ai créé pour modéliser SEDA pour Java EE: http://code.google.com/p/seide/

architecture Thread vs architecture Event-Drive mise en scène dans la vie réelle:

Imaginez que vous ayez un restaurant. Maintenant, comment cela va fonctionner?

avec "le Fil de l'Architecture":

1. Un client arrive
2. Serveur(un) va lui
3. le serveur (a) l'emmène à une table disponible
4. serveur (a) prend l'ordre
5. serveur (a) cuisine l'ordre
6. serveur (a) prend à l'ordre la table
7. serveur (a) attend que le client finisse son repas pour payer
8. le serveur (a) sort le client

Dans ce cas, le garçon est avec le client pendant tout le processus. Si le serveur a 10 threads, peut gérer 10 connexions simultanées.

avec SEDA:

1. Un client arrive
2. Serveur(un) va lui
3. serveur (a) l'emmène à une table disponible (et revient pour un autre client à venir)
4. serveur (b) prend la commande (beaucoup d'E/S, prend du temps)
5. Cuisiner la commande
6. serveur (c) prend à l'ordre à la table
7. serveur (d) attend que le client finisse son repas pour payer
8. le serveur (e) sort le client

dans ce cas, il y a différents types d'acteurs qui font les activités. Cela permet de réutiliser des acteurs dans les activités qui prennent moins de temps et le résultat est plus efficace. En effet, c'est ainsi qu'un restaurant fonctionne (probablement plus de cas de serveur sont la même personne, mais le cuisinier certainement pas).

ceci est un exemple extrême, et bien sûr avec des serveurs threadés certaines tâches asynchrones peuvent être effectuées. Ce n'est qu'un exemple théorique.

Les docs sont disponibles à github

SEDA comme mentionné dans le document: "l'unité fondamentale du traitement au sein de SEDA est le stade. Étape est une application autonome composé d'un gestionnaire d'événement, une file d'attente d'événements entrants, et un pool de threads... Chaque étape est gérée par un contrôleur qui affecte l'ordonnancement et l'allocation de thread. Stade de threads fonctionne en tirant un lot d'événements hors de l'événement entrant file d'attente et l'appel le gestionnaire d'événements fourni par l'application. Le gestionnaire d'événements traite chaque lot d'événements, et envoie zéro ou plus d'événements en les interrogeant sur les files d'attente d'événements des autres étapes."

pour moi, vous pourriez concevoir votre scène comme une modularisation logique de votre flux d'application. Elle pourrait être fondée sur la fonctionnalité, sur la séparation des préoccupations, sur la performance, sur le fonctionnement et la maintenance.

je vous demande de lire le PDF ci-joint comme il mentionne la nécessité d'une file d'événements pour découpler les choses, la compénentisation logique pour atteindre l'efficacité maximale du composant, comment réutiliser efficacement les ressources existantes au-dessus desquelles l'application tourne comme le réseau, le stockage, les cycles CPU, etc.,

pour tracer un parallèle, il y a des études faites sur les ouvriers de la chaîne de montage qui ont travaillé en série assembler quelque chose du début à la fin a obtenu moins de productivité, mais quand ils ont été isolés et faits pour faire un seul travail et passer la partiellement assemblés unité à l'autre groupe, chacun d'eux est devenu efficace dans la gestion de son travail. Fondamentalement, votre flux d'assembler quelque chose s'est divisée en plusieurs étapes et chacune d'entre elles ou un groupe d'entre eux étaient chargés de travailler sur une scène.

Tout ce qui a été fait ici a été d'activer et de mettre en place un cadre autour de chaque personne ou groupe et un mode de communication d'une personne/groupe à l'autre. Maintenant, nous pouvons comparer chaque personne / groupe et le cadre mis en place autour de lui à un étape.

pour ajouter la dimension d'événement dans SEDA, pensez à la façon dont le groupe de personnes Communique entre eux et le nombre d'événements qui sont impliqués. Disons, par exemple, que les gars de la première étape n'ont plus d'écrous et de boulons pour terminer leur étape et qu'ils informent immédiatement le Gestionnaire de la section des commandes au sujet des écrous et des boulons. Il est possible que l'ordre de la section gestionnaire a reçu une demande d'une autre étape 6 mecs que des écrous et des boulons. Maintenant, il voit les demandes à un point central (il est comme le contrôleur dans SEDA) et la feuille excel qu'il a où toutes les entrées qu'il a gardé les demandes de commandes à placer (est comme la file d'attente dans SEDA), il les combine et les commandes ensemble à un aller au lieu d'envoyer deux demandes de commande (thread et gestion du calendrier dans SEDA).

maintenant si vous avez un mécanisme comme celui-là dans votre architecture logicielle qui a plusieurs composants, envoyant divers événements les uns aux autres et ont des contrôleurs consommant et en agissant en conséquence, alors vous avez probablement une très bonne mise en scène événementielle mis en place.