Renuncias
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.
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
Otros servicios no devuelven mensajes fáciles de usar. No es posible para mí solicitar cambios por parte de 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: /)
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
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.
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.
¿Alguna otra idea sobre una solución escalable y sostenible?
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 .
Error. <Un mensaje de error fácil de usar y muy predeterminado>. Sigue el enlace para más información
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).