Come gestire le dipendenze per i microservizi?

È difficile dare una risposta esatta senza ulteriore conoscenza dell'architettura del sistema. Tuttavia, suggerirei di creare e rilasciare l'artefatto che più o meno contiene prima l'interfaccia del servizio B.

L'interfaccia non dovrebbe avere alcuna logica che richiede test. Inoltre non dovrebbe avere alcuna dipendenza da altre risorse del tuo sistema ancora da rilasciare. Quindi, dovrebbe essere facile cambiare l'interfaccia e rilasciarne una nuova versione.

Dopo che l'interfaccia è stata rilasciata, la prossima versione del client può essere sviluppata e costruita sulla versione già rilasciata dell'interfaccia di servizio. Non è necessario che l'implementazione del servizio sia stata ancora rilasciata. In realtà, anche il servizio stesso potrebbe essere sviluppato solo dopo aver rilasciato l'interfaccia. Poiché non vi sono dipendenze dirette tra i servizi stessi, i servizi di promozione A e B possono essere svolti in qualsiasi ordine o allo stesso tempo, dopo i test esplorativi o così.

Questo è il principio di inversione delle dipendenze applicato al livello di impacchettamento e configurazione. Il servizio A non dipende direttamente dall'implementazione del servizio B. Entrambi dipendono dall'interfaccia del servizio B.

È possibile mantenere una strategia di branca monolitica, approccio di rilascio e consegna, con tutti i microservizi affiancati ma che agiscono nel loro complesso. Ciò eliminerebbe praticamente la gestione delle dipendenze, i requisiti di compatibilità con le versioni precedenti e il numero potenzialmente inesauribile di test di integrazione basati sulle combinazioni di versioni.

A parte il fatto che avere storie di rilascio / pubblicazione indipendenti per ogni microservizio era uno dei motivi per cui stai dividendo il monolite, ovviamente. Personalmente considero l'abilità di farlo più di uno svantaggio, vedi anche link