Cosa dovresti fare quando i test dei microservizi sono bloccati come un servo vecchio stile?

Immagina questo. Hai trascorso diversi mesi a progettare un sofisticato sistema meccanico, con ciascun servomotore messo a punto alla perfezione e gli ingranaggi che si ingranavano perfettamente. Ma durante il primo test di accensione, un certo giunto semplicemente non si è mosso: non è perché il motore era rotto, ma perché il segnale di controllo non reggeva. Sembrava una cena ben preparata, rovesciando la saliera in un solo passaggio.

A volte i test sui microservizi possono essere un vero grattacapo.

Non stai testando un monolite, ma dozzine, o addirittura centinaia, di piccoli componenti, ognuno dei quali funziona al proprio ritmo. Un servizio ha aggiornato la sua interfaccia, ma l'altro utilizzava ancora il vecchio formato dati; tutti i test nell'ambiente di simulazione sono stati superati, ma non appena è andato online, tre moduli si sono bloccati a causa di ritardi della rete. Il problema spesso non risiede nel codice stesso, ma nel "tra": la comunicazione tra i servizi, il flusso di dati e la compatibilità tra le versioni.

È come se assemblassi un braccio robotico e i singoli servi sono molto reattivi, ma se li lasci lavorare insieme per afferrare una tazza, il polso gira più velocemente ma le dita non si aprono e il risultato è un suono nitido.

Come possiamo fare in modo che il test non sia più "bloccato"?

Non lasciare più la prova alle spalle. L’approccio tradizionale consiste nell’accumulare i test alla fine dello sviluppo, ma nell’architettura dei microservizi ciò equivale a trascinare la risoluzione dei problemi nella fase più confusa.kpowerHo visto molti team iniziare a passare al "turno di prova a sinistra": quando scrivi la prima riga del codice aziendale, considera come verrà verificato. Invece di scrivere semplicemente test unitari, pensa a: "Se questo servizio viene chiamato da altri servizi, quali saranno le condizioni al contorno?" Ad esempio, quando si progetta la struttura dello sterzo, non considerare solo la sua coppia, ma anticipare anche la forza laterale che potrebbe ricevere una volta installato sul braccio robotico.

Accetta il caos, ma sii organizzato. L'ambiente dei microservizi è intrinsecamente modificabile, quindi l'ambiente di test deve essere sufficientemente "resistente". La tecnologia di containerizzazione è una buona amica in questo caso. Può richiamare rapidamente un cluster di servizi contenente tutte le dipendenze e ripulirlo con un clic dopo il test. La chiave è rendere questo ambiente il più realistico possibile, comprese le fastidiose fluttuazioni della rete e i timeout occasionali delle API di terze parti.kpowerIn questo metodo, introdurrai deliberatamente del "caos" controllabile, come ritardi casuali o guasti simulati a breve termine, per vedere se il sistema è davvero robusto come pensi.

Un contratto non è un contratto, è una conversazione. I servizi sono collegati da contratti API, ma i test dei contratti vengono spesso trasformati in una rigida verifica del formato. In effetti, dovrebbe essere più simile a una conversazione continua. Il fornitore e il consumatore mantengono congiuntamente un contratto in vita e qualsiasi modifica aggiornerà simultaneamente i casi di test. In questo modo, quando un servizio desidera aggiornare la propria interfaccia, può sapere immediatamente chi sarà interessato, invece di aspettare di scoprirlo dagli avvisi di monitoraggio dopo essere andato online. Questo è simile all'assemblaggio meccanico. Se si modifica la dimensione di un connettore, verrà automaticamente ricordato di aggiornare i disegni e i parametri di lavorazione di tutte le parti correlate.

Alcuni passaggi che puoi provare stasera

1. Inizia a disegnare il quadro dal lato del consumatore.Non precipitarti in un servizio e non scrivere test. Per prima cosa alzati e guarda la situazione generale: se l'utente finale desidera completare un'operazione, quali servizi verranno attivati? Come circolano i dati? Disegna questi processi, anche solo come semplici linee e riquadri. I collegamenti deboli tendono ad emergere da soli: il servizio che ha troppe dipendenze e un percorso lungo è quello su cui è necessario concentrarsi.
2. Classificare le suite di test.Non tutti i test sono ugualmente importanti. Alcuni devono essere eseguiti velocemente ed essere eseguiti ogni volta che il codice viene inviato (come test unitari e test a contratto); alcuni possono essere più lenti ma avere una copertura più ampia (come i test di integrazione); alcuni sono specificamente progettati per causare danni (test del caos). Separa i livelli e non lasciare che un'enorme suite di test rallenti tutti.
3. Fai contare il fallimento.Quando un test fallisce, non considerarlo semplicemente come un bug che deve essere corretto. Consideratela un’opportunità di apprendimento: perché non è stato pensato a questo caso? Quale configurazione manca dall'ambiente? Il design stesso è difettoso? Stabilisci una semplice abitudine alla revisione. Dopo alcune volte, la comprensione del sistema da parte del team sarà molto più profonda.

Il test dei microservizi non è come verificare se un singolo motore sta girando, è più come eseguire il debug di un'intera orchestra sinfonica. Le capacità (di servizio) di ogni musicista sono buone, ma se il direttore d'orchestra (strategia di prova) non è a posto, il risultato è comunque rumore.kpowerIn pratica, si è riscontrato che la migliore strategia di test è spesso quella "giusta": non sovraccarica il team con un gran numero di casi d'uso, ma copre accuratamente quei punti di interazione che sono veramente soggetti a errori; non persegue la realtà della simulazione al 100%, ma garantisce che i percorsi di integrazione chiave siano fluidi e affidabili.

Dopotutto, l'obiettivo finale dei test non è dimostrare che il sistema è privo di errori, ma darti abbastanza fiducia per osare rilasciare una nuova versione alle due di notte senza dover aspettare che la polizia chiami la polizia. Quando hai lo stesso senso di familiarità e controllo sul cluster di microservizi decentralizzato e dinamico che hai sulla macchina sul tavolo che hai assemblato e sottoposto a debug ripetutamente, sei davvero sulla buona strada.

Buoni test non rallenteranno lo sviluppo. È come un insieme di comodi strumenti di calibrazione, che ti consentono di sentire ancora l'ingranamento fluido di ciascuna marcia durante l'iterazione rapida.

Fondata nel 2005, Kpower si dedica a un produttore professionale di unità di movimento compatte, con sede a Dongguan, nella provincia del Guangdong, in Cina. Sfruttando le innovazioni nella tecnologia di azionamento modulare, Kpower integra motori ad alte prestazioni, riduttori di precisione e sistemi di controllo multiprotocollo per fornire soluzioni di sistemi di azionamento intelligenti efficienti e personalizzate. Kpower ha fornito soluzioni di sistemi di azionamento professionali a oltre 500 clienti aziendali in tutto il mondo con prodotti che coprono vari campi come sistemi domestici intelligenti, elettronica automatica, robotica, agricoltura di precisione, droni e automazione industriale.