Manutenzione e documentazione degli endpoint API di molte applicazioni in un'architettura di microservizio

7

Penso che uno dei più grandi punti dolenti nel lavorare con i microservizi sia assicurarsi che le API siano ben documentate e che le API non cambino il loro comportamento senza influenzare le applicazioni a valle. Questo problema si amplifica quando si hanno molti servizi che sono interdipendenti l'uno con l'altro. Forse a quel punto hai sbagliato i microservizi, ma sto divagando.

Supponiamo di aver ereditato 20 microservizi appartenenti a team diversi e non esiste una documentazione chiara su quale applicazione utilizzi l'endpoint dell'API di altre applicazioni. C'è un modo prescritto per documentare questo? All'inizio ho pensato di analizzare gli endpoint di ogni applicazione e di aggiungerli a una tabella di database, quindi creare una relazione FK tra ogni applicazione e il percorso di un'applicazione su una tabella molti-a-molti (quasi tutte sono app per binari). Ma non sono sicuro che questo sia un buon modo per gestirlo, o sto reinventando la ruota qui.

In retrospettiva, questo potrebbe essere un modo non così negativo di documentare l'interazione delle applicazioni se si inizia con i microservizi da zero. Ciò imporrebbe semplicemente che venga mantenuta un'unica fonte di verità tramite l'uso di un database e che eventuali modifiche agli endpoint vengano eseguite nell'applicazione insieme al cambiamento nel database. Pensieri?

    
posta hyde 23.01.2018 - 19:27
fonte

2 risposte

4

Gran parte dei vantaggi di una "architettura dei microservizi" è che non non documenta tutte queste relazioni. Ogni servizio è il proprio prodotto. E ogni proprietario del servizio è responsabile per il funzionamento del loro servizio come prodotto indipendente. Questo può includere cose come:

  • Pubblicazione di documenti "marketing", documenti degli utenti e registri delle modifiche (tra cui deprecazioni )
  • Fornire un modo per clienti / consumatori di richiedere funzionalità / segnalare bug
  • Manutenzione di un SLA
  • Fare aggiornamenti come compatibile con le versioni precedenti il più possibile e recupero delle modifiche
  • Conoscendo e guardando i feed di notizie per i servizi che consumano direttamente
  • Le dipendenze di sfoltimento quando possibile
  • Deprecare l'intero servizio quando diventa irrilevante o troppo costoso per mantenere

E così via.

Soprattutto, sottolineo, come uno dei principali vantaggi di un microservizio, l'opportunità per i proprietari di servizi di concentrarsi e specializzarsi su "una cosa" del loro servizio.

Riguardo al luogo in cui ogni proprietario di prodotti o servizi dovrebbe documentare le proprie dipendenze - ciò dovrebbe accadere "naturalmente" man mano che vengono aggiunti alla configurazione del compilatore (o allo script di compilazione). Se hai bisogno di sapere cosa ServiceA dipende da, ServiceA/Configuration.xml (o qualunque cosa ) ti dirà. Normalmente mi aspetto che ogni proprietario del servizio inizialmente diagram le proprie dipendenze immediate - ma non le dipendenze delle dipendenze e così via. E, dato che le informazioni sono già in codice, non mi aspetto necessariamente che tali diagrammi vengano mantenuti in futuro.

Se vuoi davvero un'immagine globale, esplora i configs / gli script di compilazione. Quello che fai con quell'output, come lo memorizzi e così via, dipende interamente da quali decisioni i dati ti aiuteranno a fare.

    
risposta data 23.01.2018 - 21:05
fonte
1

Penso che una buona idea sia creare un diagramma di integrazioni e includerlo nel tuo repository. Scegli uno strumento gratuito (come draw.io) che può esportare il diagramma in un file XML o JSON e salvare questo file nel tuo repository. Se usi Github o Gitlab, genera l'immagine da questo diagramma e includi nel Wiki o nel file README.md, in modo che l'immagine sia visibile ogni volta che lo sviluppatore visualizza il repository dal browser.

La stessa strategia può essere utilizzata per il database.

Informazioni sulla documentazione delle risorse API, Swagger è una buona opzione.

This problem becomes amplified when you have many services that are interdependent on each other. Perhaps at that point you doing microservices wrong, but I digress.

Questo è sicuramente un problema.

    
risposta data 23.01.2018 - 20:25
fonte

Leggi altre domande sui tag