Microservicios, dibujados con honestidad
Todos los diagramas de microservicios se parecen y casi ninguno responde a la única pregunta que importa: ¿se puede desplegar uno solo por separado? Dos disposiciones de los mismos cuatro servicios: una en la que sí, otra en la que no.
8 min de lecturaUML 2.5.122 de 23
01The question a microservice diagram must answer
Not "what services are there" - a list does that, and the list is usually in the repository names. The question is: can any one of these be deployed on its own? Everything people hope to get from microservices - independent releases, independent scaling, a team that can ship without a coordination meeting - follows from the answer being yes, and no other property of the drawing matters if it is no.
A component diagram answers it, provided you draw the right things. Every deployable service is a component; every published contract is an interface; every event is a «signal». Then cover a service with your hand: if what remains fully specifies its replacement, that service can be released on its own schedule.
02Two kinds of arrow, deliberately
On the figure above, the gateway depends on IOrders - a synchronous contract, because the gateway cannot answer the user without an order. Shipping and billing point at OrderPlaced, a signal the order service sends and does not wait on.
Drawing the two differently is the entire value of the picture. The synchronous edges are where availability composes: if the order service is down, the gateway returns an error. The event edges are where it does not: shipping being down delays a parcel and takes nothing else with it. A diagram that draws both as plain arrows has erased the distinction that decides how the system fails.
03The arrangement to recognise
This is a distributed monolith, and it is the most common shape in production. Nothing on it is illegal, nothing is badly named, and it will pass review because it looks like every other microservice diagram. What it says, if you read the arrows rather than the boxes, is that the four services must be deployed together, tested together and be up together - so the team has taken on every cost of distribution and kept every constraint of a monolith.
The tell is countable: the number of synchronous hops on one request. One is fine. Two is usually fine. Three or more and the availability of the whole is the product of the parts, so four services at 99.9% each answer about 99.6% together - which is three hours a month of nobody being able to order anything.
The fixes are visible on the same drawing. Let orders publish an event and let pricing and inventory react to it. Or merge two of the boxes, which is a legitimate answer that rarely gets proposed. Or cache what pricing needs, so the hop stops being on the request path. All three are edits to this diagram, which is why drawing it before building is worth the twenty minutes.
In one line each
- 01One component per deployable service, one interface per published contract, one signal per event.
- 02Draw synchronous and asynchronous coupling differently - it is how the system fails.
- 03Synchronous when the caller needs the answer; an event when it does not.
- 04Count synchronous hops per request: three or more is a distributed monolith.
- 05Availability multiplies along a synchronous chain, and four nines become three.
- 06Cover any service: what remains must specify its replacement, or it cannot ship alone.
The notation is covered in the component diagram guide, and five more arrangements - including the two-way cycle this article does not repeat - are in component diagram examples.
04Preguntas frecuentes
¿Cómo se dibujan los microservicios en UML?
Como componentes, uno por servicio desplegable, con una interfaz por cada contrato publicado y una señal por cada evento. Lo que lo convierte en un diagrama de microservicios es que cada caja podría publicarse en su propio día, afirmación que las interfaces de alrededor sostienen o contradicen.
¿Cómo se detecta un monolito distribuido en un diagrama?
Sigue las flechas síncronas y cuenta los saltos de una petición. Si una sola acción de usuario cruza tres o más servicios que deben estar todos arriba, has distribuido un monolito en lugar de descomponerlo, y el diagrama te lo dijo antes que producción.
¿Los servicios deben hablar de forma síncrona o por eventos?
De forma síncrona cuando quien llama no puede seguir sin la respuesta, y por evento cuando sí puede. Dibujar ambos de forma distinta - interfaz para llamadas, señal para eventos - convierte ese criterio en algo que un revisor ve y puede discutir, en vez de una convención enterrada en el código.
¿Dónde va la base de datos en un diagrama de microservicios?
Una por servicio, y fuera de este diagrama. La vista de componentes trata de los contratos entre servicios: dibujar cinco bases añade cinco cajas que dicen lo mismo. Dónde corren es cosa del despliegue, y qué guardan, del modelo propio de cada servicio.
Lecturas relacionadas