Durable Execution: A revolutionary abstraction for building resilient applications
[!note] Charla de Maxim Fateev — CTO/Cofounder @ Temporal.io LinkedIn
Introducción
Representación del sistema solar, trajectoria de los planetas:
)
Abstracciones
Nosotros trabajamos con abstracciones, pero hay niveles de abstracción. El problema aparece cuando se modelas las abstracciones equivocadas o de manera equivocada.
)
Complejidad de los sistemas
)
Propiedad de un sistema monolito
)
Concepto de Transaccionalidad
)
Consistencia Eventual
Un sistema monolítico es transaccional y las transacciones no permiten "fallas parciales".
Pero cuando el monolito es muy grande, la estrategia es separarlo en microservicios. Y cuando los pasos de un determinado proceso está separado y toma más tiempo completarlo, las transacciones no sirven. Entonces apare: Event-Driven.
)
Fuente: https://pivovarit.github.io/talks/embracing-microservices/
Event-Driven Architecture al rescate
flowchart LR
PROD["📤 Productor\n(genera evento)"] -->|"publica"| CANAL["📡 Canal / Broker\n(Kafka / RabbitMQ)"]
CANAL -->|"propaga"| C1["📥 Consumidor A\n(procesa evento)"]
CANAL -->|"propaga"| C2["📥 Consumidor B\n(procesa evento)"]
CANAL -->|"propaga"| C3["📥 Consumidor C\n(procesa evento)"]
style CANAL fill:#1e1e2e,stroke:#ffd700,color:#f8f8f2
style PROD fill:#1e1e2e,stroke:#61dafb,color:#f8f8f2
- Productores: produced => un EVENTO es generado
- Canal: publica y propaga un mensaje (asociado un evento)
- Consumidores: detectan el mensaje del canal y consumen el mensaje, para luego actuar sobre el “evento”
- Arquitectura de mensajes "asincrónica" y distribuida.
Ref. https://en.wikipedia.org/wiki/Event-driven_architecture
Abstracciones y sus complejidades
)
Abstracciones y sus complejidades
- Microservices => complejidad distribuida
- Monolitos => complejidad en un solo lugar
- Arquitectura basada en eventos=> se pierde la lógica
- Scatered Logs. => se distribuye la lógica de negocio
- Error Handling => mal manejada, distribuida, que pasa con la lógica distribuida.
- Visibilidad y Debugging => solo notifica que pasan cosas n algún lugar
Eventos => son variables globales en sistemas distribuidos. ATENCION.
)
Durable Execution
=> ejecución que no crashea por causas de fallas a nivel sistema.
La principal idea es: recuperar el estado de una transacción distribuida, pese a la falla de una parte o todo el sistema.
sequenceDiagram
participant C as Cliente
participant W as Workflow\n(Temporal.io)
participant A as Activity A\n(debit)
participant B as Activity B\n(credit)
participant S as State Store\n(persistente)
C->>W: start transfer(100$)
W->>S: persist state=STARTED
W->>A: execute debit()
A-->>W: success
W->>S: persist state=DEBITED
Note over W: sistema falla aquí 💥
Note over W: se reinicia y recupera estado
W->>S: recover state=DEBITED
W->>B: execute credit()
B-->>W: success
W->>S: persist state=COMPLETED
W-->>C: transfer done ✓
Caracteristicas:
- Estado totalmente persistente.
- Duración ilimitada
- Duración ilimiatda de llamadas a API
- Logica de Retry
- Comunicación asincronica
- Times Durables.
)
Demo: Implementación
- Usando event-sourcring.
- Ejemplo de un banco y transacciones.
Armar ambiente dev
Paso #01. Instalar el CLI de temporal.io para comenzar a desarrollar:
| Link: [Set up a local development environment for Temporal and Java | Learn Temporal](https://learn.temporal.io/getting_started/java/dev_environment/) |
Luego de bajar el CLI, se puede ejecutar:
$ temporal server start-dev
CLI 1.0.0 (Server 1.24.2, UI 2.28.0)
Server: localhost:7233
UI: http://localhost:8233
Metrics: http://localhost:63504/metrics
Servidor local en localhost
Link: Workflows default
)
Proyecto de ejemplo: money-transfer
git clone https://github.com/temporalio/money-transfer-project-java
Básicamente la aplicación es lo siguiente:
)
1) Iniciar: TransferApp 2) Ver en la UI el workflow en progreso 3) Iniciar un worker: MoneyTransferWorker (hace el Withdraw y el Deposit ) 4)
Video Tutorial
Temporal.io Durable Execution platform
- Web: temporal.io
- GitHub demo: temporalio/money-transfer-project-java