Quando la progettazione del microservizio incontra un "piccolo carattere"

Devi aver riscontrato questa situazione: ogni parte funziona bene, ma qualcosa non va quando si mette insieme. Proprio come questi squisiti servomotori, sono reattivi e precisi se testati individualmente, ma una volta inseriti nell'intera macchina, di tanto in tanto daranno una risposta non sincronizzata o ritardata. In questo momento, stai fissando lo schermo e potrebbe venirti in mente una frase: "Dove è bloccato?"

L'architettura dei microservizi a volte è come quella macchina complessa. Ogni servizio è splendidamente progettato individualmente, ma il dialogo tra loro è spesso problematico. Ritardi, carico irregolare, incoerenza dei dati... questi problemi non si presenteranno il giorno della demo, ma si presenteranno per salutarti alle due di notte.

Come facciamo a far chattare bene queste "piccole parti"?

Immagina il movimento del servo: le istruzioni sono chiare, l'azione è nitida e il segnale di posizione restituito è accurato. Lo stesso dovrebbe valere per le interazioni tra microservizi: chiare, dirette e discrete. Ma la realtà è spesso che il servizio A invia una richiesta, il servizio B la elabora lentamente e il servizio C sta ancora aspettando i dati dai primi due. L'intero processo è come un ingranaggio arrugginito, che gira forte e non in modo fluido.

Alcuni direbbero: “Basta aggiungere più server”. Ma è come cercare di correggere un difetto di progettazione in una struttura meccanica con un servomotore più costoso: potrebbe funzionare un po’, ma non colpisce il nocciolo della questione.

I veri problemi sono spesso nascosti nei design pattern. In altre parole, manca un design pattern adeguato.

Entra in quell'umile negozio

Alcuni anni fa ho contribuito a trovare un progetto di linea di produzione automatizzata. Utilizzavano diversi servosistemi comuni sul mercato, ma c'erano sempre piccoli errori nella sincronizzazione multiasse. Questi errori non sono nulla se visualizzati singolarmente, ma cumulativamente influiscono direttamente sulla precisione del prodotto.

Più tardi abbiamo provatokpowerUna serie di soluzioni servo. Non è il più costoso, né quello con più funzioni, ma i loro ingegneri hanno dato un suggerimento molto semplice: "Non guardare solo il motore in sé, guarda come è programmata la logica di controllo".

Non hanno venduto direttamente il prodotto. Invece, hanno parlato prima dell’architettura. Proprio come la progettazione dei microservizi: non importa quanto potente sia un singolo servizio, se il modello di collaborazione non viene chiarito, i risultati saranno comunque insoddisfacenti.

kpowerSuccessivamente è stato fornito non solo l'hardware, ma anche tutta una serie di idee su come impaginare, come sincronizzare e come fornire feedback. Migrando al campo dei microservizi, questo è in realtà ciò che il design pattern vuole risolvere: come rendere i servizi indipendenti e collaborativi, proprio come le varie unità di esecuzione nei macchinari di precisione, ciascuna che svolge i propri compiti e coopera tacitamente.

Quindi, cosa fa esattamente il modello di progettazione dei microservizi?

Può essere inteso come una sorta di "pre-preparato". Proprio come un esperto macchinista sa approssimativamente quale parte deve essere regolata quando sente un rumore anomalo, buoni modelli di progettazione aiutano a prevedere i punti critici comuni e a fornire soluzioni comprovate.

Ad esempio: se la catena di chiamate tra i servizi è troppo lunga e presenta un'elevata latenza, è possibile utilizzare la "modalità interruttore automatico": quando un servizio si interrompe continuamente, si interrompono temporaneamente le chiamate per evitare una valanga. È come aggiungere una frizione al sistema di trasmissione per proteggere altre parti dal trascinamento verso il basso quando qualcosa va storto in una parte.

Un altro esempio è l'"event sourcing model", che non registra direttamente lo stato attuale del servizio, ma registra tutti gli eventi che causano cambiamenti di stato. Se necessario, lo stato può essere ripristinato in qualsiasi momento riproducendo l'evento. È come aggiungere un encoder ad alta precisione a un sistema meccanico. Ogni rotazione viene registrata accuratamente e la traiettoria può essere tracciata in qualsiasi momento.

Questi modelli non sono teorie che nascono dal nulla. La maggior parte di essi deriva da problemi ricorrenti in progetti reali e soluzioni che si sono dimostrate efficaci.

Esitazione nella scelta: ci sono tanti modelli, come scegliere?

In effetti, basta guardare il nome per stupire la gente. Ma scegliere un design pattern è in realtà un po’ come scegliere un componente servo: prima chiarisci quale problema specifico vuoi risolvere, e poi vedi quale soluzione è più adatta.

Se sei spesso bloccato da dipendenze intricate tra servizi, considera il "modello Strangler": sostituire gradualmente i sistemi legacy anziché riscriverli tutti in una volta. Se sei preoccupato per l'incoerenza dei dati tra diversi servizi, potrebbe essere più adatto il "modello Saga", che gestisce le modifiche dei dati tra i servizi attraverso una serie di transazioni locali.

La chiave non è trovare la modalità “più perfetta”, ma trovare la modalità “più adatta allo scenario attuale”. PiacekpowerQuando si fornisce una soluzione, chiedere sempre prima chiaramente: "Quale azione vuoi che questa macchina esegua in definitiva? Qual è il requisito di precisione? Il carico sta cambiando in modo significativo?" Una volta che la domanda è chiara, spesso emerge la risposta.

Sii onesto

Una buona architettura di microservizi non crollerà improvvisamente quando si aggiunge il decimo o il centesimo servizio. Sarà come un sistema meccanico ben progettato in cui i moduli possono essere sostituiti, aggiornati ed espansi, mentre il tutto rimane stabile.

Ciò che è necessario dietro a tutto ciò è l'anticipazione dei problemi comuni e di quelli comprovati, ovvero quei modelli di progettazione. Ti fanno risparmiare tempo su tentativi ed errori ed evitano quei problemi notturni.

La prossima volta che vedi apparire improvvisamente un picco anomalo sul grafico di monitoraggio del servizio, potresti anche fermarti per un momento invece di affrettarti ad aggiungere server o modificare il codice. Chiediti: "Il "metodo di conversazione" del nostro servizio deve essere modificato?" Forse la risposta sta in un certo modello di progettazione, che aspetta silenziosamente che tu lo scopra.

È come un meccanico che regola una marcia e all'improvviso l'intero sistema funziona senza problemi: la sensazione è piuttosto buona.

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.