We have a microservice with a web API, but what about other ways of talking to other systems? How will we know if, say, a shipment is delayed or the quantity is amended? How will we tell the warehouse system that an order has been allocated and needs to be sent to a customer?
Our application will receive events from external sources via an external message bus (we’ll use Redis pub/sub queues as an example) and publish its outputs, in the form of events, back there as well.
Distributed Ball of Mud, and Thinking in Nouns
Cuando se habla de microservicios, un patrón que se puede aplicar es el de dividir el sistema en sustantivos
En nuestro sistema podrían ser batches, stock, orders, products, customers. Cada “cosa” en nuestro sistema es un servicio que expone una HTTP API. Un microservicio = Tabla de base de datos → Anemic model → CRUD interface → HTTP APIs Este tipo de arquitectura es el approach más común para diseño orientado a microservicios
Esto funciona para sistemas simples pero rápidamente se puede convertir en un distributed ball of mud.
Error Handling in Distributed Systems
Tip
Asumí que las cosas se van a romper
Tenemos 2 opciones acá:
- Mandamos la orden y la dejamos unallocated
- Rechazamos la orden porque la allocation no pudo ser garantizada
Cuando N cosas tienen que cambiar juntas, decimos que están coupled. Este failure cascade es un temporal coupling: cada parte del sistema tiene que funcionar al mismo tiempo para que todo funcione.
Connascence - http://www.connascence.io/
- Otro término usado para describir distintos tipos de coupling
- No es algo malo en sí, pero algunos tipos son más fuertes que otros.
- Ejemplos:
- Execution: multiple components need to know the correct order of work for an operation to be successful.
- Timing: multiple things have to happen, one after another, for the operation to work.
- Name: multiple components need to agree only on the name of an event and the names of fields it carries.
Alternativa
Pensar en término de verbos, no sustantivos. Nuestro domain model se trata de modelar un proceso de negocio != un modelo de datos estático.
Sistema para orders/batches → Sistema para pedir/asignar
Los microservicios deberían ser consistency boundaries, al igual que los aggregates como vimos en Consistency
Cada servicio acepta comandos del exterior y crea eventos para guardar el resultado → Otros servicios escuchan esos eventos → disparan nuevos workflows
TIP
Para evitar Distributed Ball of Mud, en vez de usar Sync HTTP API, queremos usar Async messaging para integrar nuestros sistemas.
Ventajas:
- Las cosas pueden fallar independientemente. Podemos tomar órdenes aunque el sistema de allocation esté degradado
- Reducimos el coupling entre sistemas
Cómo? Con un message broker: toma mensajes de publishers y los entrega a los subscribers (Pub/Sub)
Redis provee el evento BatchQuantityChanged → este dispara todo el proceso → Allocated event es publicado nuevamente a Redis al final.
| Pros | Cons |
|---|---|
| Avoids the distributed big ball of mud. | The overall flows of information are harder to see. |
| Services are decoupled: it’s easier to change individual services and add new ones. | Eventual consistency is a new concept to deal with. |
| Message reliability and choices around at-least-once versus at-most-once delivery need thinking through. |