Dove dovrebbe essere rafforzato l’allentamento? Parliamo dei grattacapi legati ai microservizi

I microservizi sembrano piuttosto belli: ogni piccolo modulo svolge i propri compiti e può essere espanso in modo flessibile e tutto sembra andare a posto. Ma si può davvero utilizzare? A volte ho la sensazione che più le cose sono sparse, più velocemente sorgeranno i problemi.

È come se avessi un sacco di servomotori e servi squisiti in mano. Guardandoli singolarmente, ognuno gira magnificamente. Ma una volta chiesto loro di lavorare insieme ed eseguire una serie completa di movimenti meccanici, ehi, alcuni rispondono mezzo battito più velocemente e alcuni segnali vengono persi. Il coordinamento è semplicemente pazzesco. Lo stesso principio vale per i microservizi: i servizi sono troppo indipendenti e i dati sono bloccati; sono troppo dipendenti e l’intero sistema ne risente. Dov'è il punto di equilibrio tra "adesione" e "accoppiamento"?

Perché i tuoi microservizi sono sempre "in conflitto"?

Potresti aver riscontrato questo scenario: un servizio ordini deve chiamare le informazioni dell'utente, controllare l'inventario e avvisare la logistica. Il processo non è lungo, ma una volta che un determinato collegamento si blocca, l'intero collegamento si interrompe. O più comunemente, per una piccola modifica di funzione, è necessario modificare tre o quattro servizi contemporaneamente, il che rende difficile il programma di implementazione.

Questo non è solo un problema tecnico, ma piuttosto una "malattia" del design. I confini tra i servizi sono sfumati, le responsabilità si sovrappongono e i dati circolano ovunque... Ovviamente vogliamo utilizzare i microservizi per migliorare la flessibilità, ma il risultato è una rete poco chiara.

Allora qualcuno si è chiesto: dobbiamo rendere il servizio quanto più "ampio" possibile e ridurre le chiamate? Ma ciò tornerebbe al vecchio percorso dell’architettura monolitica. Oppure tagliare il servizio in pezzi più piccoli? I costi di gestione tornano ad aumentare.

La risposta, infatti, non è “grande o piccolo”, ma “come connettersi”.

Una buona connessione è come un sistema di trasmissione fluido

Pensaci, hai mai assemblato un braccio robotico? La scatola dello sterzo è responsabile della svolta, il motore fornisce la potenza e il sensore segnala la posizione: qual è la coordinazione tra loro? Invece di attorcigliare tutti i cavi insieme, ciascuna unità può essere calibrata in modo indipendente e rispondere in modo sincrono attraverso protocolli di interfaccia chiari e un'appropriata trasmissione del segnale.

Anche lo stato ideale tra i microservizi dovrebbe essere così. Un'elevata coesione significa che la logica interna di un servizio è strettamente correlata, come un circuito indipendente; accoppiamento basso significa che la connessione tra i servizi è semplice e chiara, proprio come un'interfaccia plug-in, e la modifica di un componente non influisce sull'insieme.

Come? Invece di fare affidamento su regole ferree, torniamo alla fonte del problema: chi dovrebbe essere responsabile delle vostre azioni aziendali?

Ad esempio, l'operazione "utente che effettua un ordine": calcolo dell'importo, detrazione dell'inventario e generazione di ordini logistici: se questi passaggi sono tutti concentrati in un unico servizio, prima o poi si gonfierà. Ma se separiamo la "gestione dell'inventario" e l'"elaborazione degli ordini" e comunichiamo attraverso eventi o messaggi chiari, difficilmente sarà necessario toccare il servizio ordini quando il servizio di inventario viene ripetuto.

Si tratta di una progettazione "lascamente accoppiata": i servizi non chiamano direttamente i rispettivi database, non si basano sulla logica interna e "parlano" solo attraverso metodi concordati. Anche se una delle parti è temporaneamente inattiva, l'altra può continuare a lavorare, o almeno sapere quanto aspettare.

Dal “come fare” al “come scegliere”

Il metodo sembra semplice, ma quando lo implementi incontrerai sempre domande specifiche a scelta multipla. Per esempio:

• Per comunicare tra servizi dovremmo usare chiamate sincrone o messaggi asincroni?
• I dati dovrebbero essere condivisi o conservati separatamente?
• Qual è il confine appropriato da tracciare per una funzione?

In realtà non esiste una risposta standard, ma solo se sia appropriata o meno. Di solito, quelli che comportano cambiamenti di stato fondamentali, come il successo dei pagamenti, possono richiedere una conferma sincrona; per i log e le notifiche che possono essere ritardate, è più semplice utilizzare una coda asincrona. Lo stesso vale per i dati: le informazioni di base sugli utenti che vengono comunemente utilizzate e diventano meno comuni possono essere condivise in modo appropriato; ma per attività di grande rilevanza come il flusso degli ordini, è meglio mantenerli all'interno dei rispettivi servizi.

La chiave non è quanto sia nuova la tecnologia, ma come si adatta al ritmo del tuo business. Proprio come quando si sceglie un motore per un sistema meccanico, maggiore è la velocità non è meglio è, ma la coppia, la risposta e il consumo energetico devono soddisfare le esigenze generali.

Quando parliamo di microservizi, di cosa parliamo?

Dopotutto, l’architettura dei microservizi non è un fine, ma un mezzo. Ti aiuta a risolvere la complessità, consente ai team di svilupparsi in parallelo e consente al sistema di espandersi in più fasi. Ma il suo successo non può essere separato da una base invisibile: un design chiaro e coerente e un sano rapporto di accoppiamento.

È come una piattaforma di precisione guidata dal servosistema Kpower: ciascuna unità motore è stabile ed efficiente e allo stesso tempo interagisce leggermente attraverso il protocollo di controllo, ottenendo in definitiva un funzionamento complessivo fluido e affidabile. Non li vedrai "combattere" tra loro, né saranno in manutenzione su un'unità.

Una buona architettura di microservizi persegue esattamente questo stato: indipendente ma non antagonista; collegato ma non in bundle.

Quindi, prima di disinstallare il servizio la prossima volta, chiediti:

• Questa funzionalità cambia frequentemente? Vale la pena uscire da solo?
• Puoi controllare la maggior parte dei dati o della logica su cui si basa?
• Può comunicare con altri servizi utilizzando un protocollo semplice invece di essere strettamente legato?

Poni queste domande in modo chiaro e potresti trovare naturalmente il punto di equilibrio: lascia che ciò che dovrebbe essere riunito e ciò che dovrebbe essere allentato possa essere meravigliosamente rilassato.

Dopotutto, la progettazione architettonica non è mai solo uno schema a blocchi. È come iniettare un'"anima" armoniosa in un insieme di moduli meccanici: ogni unità deve essere solida di per sé e ogni unità deve avere spazio per respirare. Quando riesci a sentire il ritmo fluido e stabile della collaborazione tra i servizi, probabilmente sei sulla strada giusta.

Il resto è continuare ad osservare e mettere a punto. È come mantenere un sistema meccanico di cui ti fidi. Sai perché ciascuno dei suoi componenti è qui e come lavorano insieme. Questo senso di solidità è di per sé la parte più memorabile del design tecnico.

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.