¿Dónde debe ir el disyuntor?
Estoy desarrollando una nueva API REST y he visto que algunos proyectos colocan el disyuntor en el archivo Controller
. Solía colocarlo en el DAO
.
La primera diferencia que puedo decir es que colocarlo en DAO
es que todos los servicios que consumen este tercero estarán abiertos en el escenario de error. Y colocarlo en Controller
, EVENTUALMENTE abriría todas las rutas que consumen este tercero; así que no será inmediatamente. Pero la segunda opción (en el Controller
) parece más fácil de mantener.
¿Alguna recomendación sobre dónde debería ir?
Respuestas
Hay dos partes en esta respuesta. La primera parte ya fue abordada por Robert Harvey en su comentario:
- De acuerdo con el catálogo de patrones de microservicios de Chris Richardson, el disyuntor debe estar en un proxy para el servicio remoto. API Gateway es un buen lugar para ello.
- Otra alternativa es el descubrimiento del lado del servidor, especialmente si la estrategia de recuperación implica encontrar otras instancias en ejecución del mismo servicio.
Pero hay una segunda parte. El objetivo del disyuntor es fallar rápidamente si se detecta que el servicio no está disponible, en lugar de acumular pasos que luego fallarán y crearán mucha frustración. Por lo tanto, el disyuntor adquiere todo su sentido solo si el servicio que lo consume está listo para reaccionar ante la interrupción:
- Tal vez el servicio remoto sea esencial, y el servicio consumidor podría decidir ponerse en espera (es decir, disyuntor interno).
- Puede ser que el servicio remoto no sea esencial, y el servicio consumidor podría decidir continuar sirviendo, pero en un modo degradado.
- (los interruptores basados en el descubrimiento de servicios probablemente no fallarán, pero encontrarán otro servicio que funcione y los consumidores no se darán cuenta).
Desde el punto de vista general, este tipo de elecciones en el comportamiento es responsabilidad del controlador: el controlador coordina entre los elementos del servicio y puede adaptar el procesamiento en función de la información de "falla".
Sin embargo, si en su caso, solo se trata de obtener datos de otro lugar y si su estrategia de procesamiento de errores es siempre la misma (no hay diferencia entre esencial y no esencial; por ejemplo, intente usar un valor almacenado en caché si está disponible y falla de lo contrario) usted podría perfectamente decidir ponerlo en el dao en mi humilde opinión.