Avvertenze
Our company runs applications on a Micro Service architecture that
includes thousands of services. I am working on a backend application
"X" that talks to 50+ services. Frontend services call my service "X"
to execute requests on other services.
Prima di tutto, migliaia di servizi casuali non rendono l'architettura un Microservizio come l'architettura. È ancora necessario un certo senso di un "intero" e un po 'di accordo tra i servizi. Linee guida o regole pratiche.
Contestualizza il back-end all'interno di "intero"
Suppongo che il tuo back-end non sia né gateway né proxy . Immagino che abbia il proprio business e un contesto limitato ben definito. Quindi, per quanto riguarda altri servizi, il back-end è una facciata .
Come facciata, nascondere i dettagli di implementazione (come ad esempio le integrazioni con i servizi remoti) rientra tra le sue responsabilità. Per il front-end (e quindi per l'utente finale), l'unico interlocutore affidabile è X e nessun dettaglio di implementazione dovrebbe raggiungere i livelli esterni. Qualunque cosa sia successa sotto il cofano, non è affare degli utenti.
Questo non significa che non possiamo dire all'utente che qualcosa è andato storto. Possiamo, ma lo facciamo astrarre questi dettagli. Non daremo l'impressione che qualcosa di remoto stia fallendo. Al contrario, qualcosa in X ha avuto esito negativo e il gioco è fatto.
Dato che stiamo parlando di migliaia di possibili integrazioni (+50 atm), il numero di errori possibili e diversi è significativo. Se mappiamo ognuno di essi in un messaggio personalizzato, l'utente finale sarà sopraffatto da così tante (e non contestualizzate) informazioni. Se mappiamo tutti gli errori su una piccola serie di errori personalizzati, stiamo distorcendo le informazioni, rendendo difficile per noi tenere traccia del problema e risolverlo.
A mio parere, i messaggi di errore dovrebbero fornire all'utente la sensazione che ci sia qualcosa che possiamo fare per modificare il problema.
Tuttavia, se gli utenti finali vogliono ancora sapere cosa sta succedendo sotto il cofano, ci sono altri modi più utili per l'intera organizzazione.
Responsabilità
Other services do not return user-friendly messages. It is not possible for me to request changes by other teams as there are
several.There are no agreed error codes as such.
Other services return a string error message. Currently, it is passed back to the UI. Sometimes the error messages are a pointer
references (bad code :/)
Come sviluppatore, la tua responsabilità è di esporre questi argomenti alle parti interessate. È una questione di responsabilità. A mio parere, c'è una perdita di leadership tecnica e questo è un vero problema quando si tratta di sistemi distribuiti.
Non ci sono previsioni tecniche. Se ci fosse, i servizi sarebbero implementati su regole empiriche per rendere il sistema scalabile e facilitare le integrazioni tra i servizi. In questo momento sembra che i servizi appaiano selvaggiamente, senza il senso di contributo al "tutto".
Se mi venisse chiesto di fare ciò che ti è stato chiesto di fare (e sono stato a volte), direi se trasformare l'anarchia corrente in messaggi user-friendly va oltre lo scopo di X .
Almeno, "alza la mano", esponi le tue preoccupazioni, esponi le tue alternative e lascia che chi ha la responsabilità di decidere.
Rendi preziose le tue soluzioni per l'azienda
Check for error message string and have a mapping in my service to a
user-friendly message. But things can break if the callee service
changed their error message. Fallback to a default error message when
a custom error mapping is not found.
Hai ragione. Questa è una soluzione debole. È fragile e inefficiente nel medio-lungo periodo.
Penso anche che causi l'accoppiamento poiché i cambiamenti in queste stringhe potrebbero costringerti a rifrattare i mapping. Non un grosso miglioramento.
Any more ideas on a scalable and sustainable solution?
Rapporti . Gestire gli errori, fornire un codice / ticket / id a loro e riferire. Quindi, consentire al front-end di visualizzare il report. Ad esempio, condividendo un link al servizio di segnalazione .
Error. < A user-friendly and very default error message >. Follow the link for further information
In questo modo puoi integrare tutti i servizi di cui hai bisogno. E ti libererai dal sovraccarico di gestire e tradurre stringhe casuali in stringhe casuali, ma user-friendly.
Il servizio di report è riutilizzabile per il resto dei servizi in modo che, se si dispone di ID correlati, dovrebbe essere possibile consentire all'utente di visualizzare una panoramica degli errori e delle cause. Nelle architetture distribuite, tracciabilità è abbastanza importante.
In seguito, il servizio di reporting può essere migliorato con tutti i mapping necessari per fornire istruzioni leggibili e utili su cosa fare se si verifica l'errore X . Se le stringhe cambiano qui non importa affatto. Quello che abbiamo (archivio) è uno stato finale del rapporto.
Il servizio di segnalazione aprirà le porte a una possibile normalizzazione degli errori all'interno dell'organizzazione poiché il servizio esporrà un'API pubblica (quindi un contratto).