Nuestra empresa ejecuta aplicaciones en una arquitectura de Micro Service que incluye miles de servicios. Estoy trabajando en una aplicación de fondo "X" que habla con más de 50 servicios. Los servicios frontend llaman a mi servicio "X" para ejecutar solicitudes en otros servicios.
Problema :
El front end quiere mostrar mensajes fáciles de usar cuando algo falla en otros servicios.
- Otros servicios no devuelven mensajes fáciles de usar. No es posible para mí solicitar cambios por otros equipos ya que hay varios.
- No hay códigos de error acordados como tales. Otros servicios devuelven un mensaje de error de cadena. Actualmente, se devuelve a la interfaz de usuario. A veces, los mensajes de error son referencias de un puntero (código incorrecto: /)
Posible solución :
Verifique la cadena del mensaje de error y tenga una asignación en mi servicio a un mensaje fácil de usar. Pero las cosas pueden romperse si el servicio llamado cambió su mensaje de error. Recurrir a un mensaje de error predeterminado cuando no se encuentra una asignación de error personalizada.
¿Alguna otra idea sobre una solución escalable y sostenible? ¡Gracias!
fuente
Respuestas:
Renuncias
En primer lugar, miles de servicios aleatorios no hacen que una arquitectura sea Microservicios como la arquitectura. Todavía es necesario un cierto sentido de "todo" y un poco de acuerdo entre los servicios. Pautas o reglas generales.
Contextualizar el backend dentro del 'todo'
Supongo que su backend no es puerta de enlace ni proxy . Supongo que tiene su propio negocio y un contexto acotado bien definido. Entonces, con respecto a otros servicios, el backend es una fachada .
Como fachada, ocultar los detalles de implementación (como por ejemplo, integraciones con servicios remotos) es una de sus responsabilidades. Para el front-end (y, por lo tanto, el usuario final), el único interlocutor confiable es
Xy ningún detalle de implementación debe llegar a las capas externas. Pase lo que pase debajo del capó, no es asunto del usuario.Eso no significa que no podamos decirle al usuario que algo salió mal. Podemos, pero lo hacemos abstrayendo estos detalles. No daremos la sensación de que algo remoto está fallando. Justo lo contrario, algo
Xfalló y eso es todo.Como estamos hablando de miles de integraciones posibles (+50 atm), la cantidad de errores posibles y diferentes es significativa. Si asignamos cada uno a un mensaje personalizado, el usuario final se verá abrumado por tanta información (y no textualizada). Si asignamos todos los errores a un pequeño conjunto de errores personalizados, estamos sesgando la información, lo que nos dificulta rastrear el problema y resolverlo.
En mi opinión, los mensajes de error deberían proporcionar al usuario la sensación de que hay algo que podemos hacer para corregir el problema.
Sin embargo, si los usuarios finales aún quieren saber qué sucede debajo del capó, hay otras formas más útiles para toda la organización.
Responsabilidad
Como desarrollador, su responsabilidad es exponer estos argumentos a las partes interesadas. Es una cuestión de responsabilidad. En mi opinión, hay una fuga de liderazgo técnico y ese es un problema real cuando se trata de sistemas distribuidos.
No hay visión técnica. Si lo hubiera, los servicios se implementarían según las reglas generales dirigidas para hacer que el sistema sea escalable y facilitar las integraciones entre los servicios. En este momento parece que los servicios aparecen de manera salvaje, sin la sensación de contribución al "todo".
Si me pidieran que hiciera lo que se le ha pedido que haga (y a veces lo he hecho), diría que convertir la anarquía actual en mensajes fáciles de usar está fuera del alcance de
X.Al menos, "levante la mano", exponga sus preocupaciones, exponga sus alternativas y deje que quien tenga la responsabilidad de decidir.
Haga que sus soluciones sean valiosas para la empresa
Tienes razón. Esa es una solución débil. Es frágil e ineficiente a mediano y largo plazo.
También creo que causa el acoplamiento, ya que los cambios en estas cadenas podrían obligarlo a refractar las asignaciones. No es una gran mejora.
Informes . Manejar los errores, darles un código / ticket / id e informar. Luego, permita que el front-end visualice el informe. Por ejemplo, compartir un enlace al servicio de informes .
De esta manera, puede integrar tantos servicios como necesite. Y te liberas de la sobrecarga de manejar y traducir cadenas aleatorias en nuevas cadenas aleatorias, pero fáciles de usar.
El servicio de informes es reutilizable para el resto de los servicios, de modo que, si tiene identificadores correlacionados, debería ser posible permitir que los usuarios tengan una vista panorámica de los errores y las causas. En arquitecturas distribuidas, la trazabilidad es bastante importante.
Más tarde, el servicio de informes se puede mejorar con el mayor número de asignaciones como sea necesario para dar instrucciones legibles y útiles sobre qué hacer en caso de error X sucede . Si las cadenas cambian aquí no importa en absoluto. Lo que tenemos (tienda) es un estado final del informe.
El servicio de informes abrirá la puerta a una posible normalización de los errores dentro de la organización, ya que el servicio expondrá una API pública (por lo tanto, un contrato).
fuente
No hay milagro en tu caso. La posible solución parece la solución que ya propusiste.
Está bien que una API cambie el mensaje de error si la API devuelve algún tipo de código de error también, que el consumidor de API puede usar para rastrear el error y asignar otro mensaje (como intenta hacerlo, pero con el mensaje).
Solo asegúrese de registrar el mensaje que la API devolvió antes de ejecutar el error de reserva. Tal vez pueda agregar el mensaje API en algún tipo de
developerMessageerror personalizado, lo que ayudará a identificar el problema sin usar el registro (solo asegúrese de que su API no arroje ningún mensaje con información sensible).Si tiene algún canal de comunicación con el equipo que está haciendo estos servicios, explique su problema y solicite ayuda de ellos, porque ese podría ser el mismo problema para el otro equipo que está tratando de usar su API.
fuente