¿Qué es SEDA(Staged Event Driven Architecture)?
event-driven (3)
SEDA: una arquitectura para servicios de Internet escalables y bien acondicionados
"SEDA es un acrónimo de arquitectura de eventos por etapas y descompone una aplicación compleja de eventos en un conjunto de etapas conectadas por colas ".
Entiendo que es una arquitectura y que hay muchas implementaciones de SEDA (consulte el artículo de Wikipedia ). ¿Qué es una "etapa"? ¿Puede alguien proporcionar un resumen completo de alto nivel de una arquitectura basada en eventos organizados y en qué se diferencia de las arquitecturas tradicionales (no organizadas) basadas en eventos?
Los documentos están disponibles en github
SEDA como se menciona en el documento: "La unidad fundamental de procesamiento dentro de SEDA es la etapa. Una etapa es un componente de aplicación independiente que consiste en un controlador de eventos, una cola de eventos entrantes y un grupo de hilos ... Cada etapa se administra por un controlador que afecta a la programación y la asignación de subprocesos. Los subprocesos de etapa operan extrayendo un lote de eventos de la cola de eventos entrantes e invocando el controlador de eventos suministrado por la aplicación. El controlador de eventos procesa cada lote de eventos y distribuye cero o más eventos encolando en las colas de eventos de otras etapas ".
Para mí, podría diseñar su etapa como una modularización lógica de su flujo de aplicaciones. Podría basarse en la funcionalidad, en la separación de inquietudes, en el rendimiento, en las operaciones y el mantenimiento.
Le pediría que lea el PDF adjunto, ya que menciona la necesidad de una cola de eventos para desacoplar las cosas, la compenentización lógica para lograr la máxima eficiencia del componente, cómo reutilizar eficientemente los recursos existentes sobre los cuales la aplicación se está ejecutando como red, almacenamiento, Ciclos de CPU etc.
Para dibujar un paralelo, hay estudios realizados en trabajadores de líneas de ensamblaje que trabajaron en serie ensamblando algo de principio a fin y lograron menos productividad, pero cuando se aislaron y se hicieron para hacer un solo trabajo y pasar la unidad parcialmente ensamblada al siguiente grupo, Cada uno de ellos se volvió eficiente en la gestión de su trabajo. Básicamente, su flujo de ensamblar algo se dividió en múltiples etapas y cada uno de ellos o un grupo de ellos fueron responsables de trabajar en un escenario.
Todo lo que se hizo aquí fue habilitar y establecer un marco alrededor de cada persona o grupo y un modo de comunicación de una persona / grupo a otro. Ahora podemos comparar a cada persona / grupo y el marco establecido alrededor de él para una etapa.
Para agregar la dimensión del evento en SEDA, piense en cómo el grupo de personas se comunica entre sí y el número de eventos que están involucrados. Digamos, por ejemplo, que los chicos de la etapa 1 se han quedado sin tuercas y tornillos para completar su etapa e inmediatamente informan al gerente de la sección de pedidos sobre las tuercas y los pernos. Es posible que el gerente de la sección de pedidos haya recibido una solicitud similar de otros muchachos de la etapa 6 de que las tuercas y los tornillos se han agotado. Ahora, ve las solicitudes en un punto central (es como el controlador en SEDA) y la hoja de Excel que tiene donde se encuentran todas las entradas que ha guardado en las solicitudes de pedidos (es como la cola en SEDA), los combina y los ordena de una vez en lugar de enviar dos solicitudes de pedido (gestión de programación y subprocesos en SEDA).
Ahora, si tiene un mecanismo como ese en su arquitectura de software que tiene múltiples componentes, se envían varios eventos entre sí y hay controladores que los consumen y actúan en consecuencia, entonces probablemente tenga una muy buena configuración de eventos organizados.
Thread Architecture vs Staged Event-Drive Architecture en la vida real:
Imagina que tienes un restaurante. Ahora, ¿cómo funcionará?
con "Thread Architecture":
- Llega un cliente
- El camarero (a) va hacia el / ella
- El camarero (a) lo lleva a una mesa disponible
- El camarero (a) toma la orden
- Camarero (a) cocina el orden
- Camarero (a) lleva a la mesa a la orden.
- El camarero (a) espera hasta que el cliente termine su comida para pagar
- El camarero (a) saca al cliente
En este caso, el camarero está con el cliente durante todo el proceso. Si el servidor tiene 10 hilos, puede manejar 10 conexiones al mismo tiempo.
con SEDA:
- Llega un cliente
- El camarero (a) va hacia el / ella
- El camarero (a) lo lleva a una mesa disponible (y regresa para que venga otro cliente)
- El camarero (b) toma el pedido (un montón de E / S, toma tiempo)
- Cocinero cocina el orden
- El camarero (c) lleva a la mesa
- El camarero (d) espera hasta que el cliente termine su comida para pagar
- Camarero (e) saca al cliente
En este caso, hay diferentes tipos de actores que realizan las actividades. Esto ayuda a reutilizar a los actores en las actividades que llevan menos tiempo y el resultado es más efectivo. De hecho, así es como funciona un restaurante (probablemente más instancias de Waiter sean la misma persona, pero el cocinero definitivamente no).
Este es un ejemplo extremo y, por supuesto, con los servidores de subprocesos se pueden realizar algunas tareas asíncronas. Esto es sólo un ejemplo teórico.
Un escenario es análogo a un "evento". Para simplificar la idea, piense en SEDA como una serie de eventos que envían mensajes entre ellos.
Creo que una razón para usar este tipo de arquitectura es que fragmentas la lógica y puedes conectarla y desacoplar cada evento, principalmente para servicios de alto rendimiento con bajos requisitos de latencia.
Si utiliza Java TPE, puede controlar el estado, el rendimiento, los errores, la latencia de cada etapa y encontrar rápidamente dónde está el cuello de botella en el rendimiento. Y como efecto secundario agradable, con piezas de código más pequeñas, puede probarlas fácilmente e incrementar la cobertura de su código (ese fue mi caso).
Para el registro, esta es la arquitectura interna de Cassandra (NoSQL) y Mule ESB (AFAIK).
Recomiendo leer el artículo original (lo siento, enlace duplicado):
Aquí hay un marco que he creado para modelar SEDA para Java EE: http://code.google.com/p/seide/