differenza tra microservizi e API resto

Qual è la differenza tra microservizi e API REST? parliamo

Immagina di costruire un robot. Ciascun giunto richiede un servo indipendente per controllare la rotazione e questi servi devono coordinarsi tra loro per trasmettere i segnali. A questo punto qualcuno ti ha suggerito: che ne dici di mettere tutti i circuiti di controllo in una scatola e cablarli in modo uniforme? Oppure dovremmo dotare ciascun servo di un piccolo controller intelligente, lasciare che svolgano i rispettivi compiti e poi comunichino in modo semplice e universale?

Questa domanda ti suona familiare? In effetti, nel mondo del software, questa confusione si verifica ogni giorno. Esatto, stiamo parlando delle parole "microservizi" e "API REST" che spesso vengono confuse insieme. Molte persone non capiscono la differenza tra loro e pensano addirittura che siano la stessa cosa. Il risultato? Quando progetto il sistema, ho sempre la sensazione che qualcosa non va e mantenerlo in seguito sembra come svelare un pasticcio.

Quindi, parliamone casualmente oggi e togliamoci di mezzo. Non preoccuparti della terminologia, parleremo solo in volgare.

Per prima cosa scopriamolo: chi sono?

Usiamo un'analogia. Entri in un grande ristorante. Se questo negozio ha un'architettura "microservizi", lo chef può essere diviso in più gruppi indipendenti: il gruppo dei salumi si concentra solo sulle insalate, il gruppo del barbecue si concentra sul barbecue e il gruppo dei dolci si concentra sulla preparazione delle torte. Ogni team ha il proprio spazio cucina, strumenti e flussi di lavoro dedicati e comunica reciprocamente le proprie esigenze tramite un foglio di carta standard, come un modulo d'ordine. Questo "sistema di note cartacee" è come un'API REST.

Vedi la strada da percorrere? I microservizi sono un'idea architettonica: suddividono una grande applicazione in tanti piccoli servizi che funzionano in modo indipendente e si concentrano su funzioni specifiche, proprio come quei gruppi in un ristorante con una chiara divisione del lavoro. Ogni servizio si occupa della propria attività e può essere sviluppato, distribuito e persino riavviato in modo indipendente senza influire sulle altre parti. L'API REST è un protocollo di comunicazione, un "modo di parlare" basato su HTTP concordato tra i servizi, proprio come la nota d'ordine in formato standard.

In poche parole, i microservizi sono una struttura di team "divide et impera" e l'API REST è il "linguaggio di comunicazione" comune all'interno del team. Puoi utilizzare l'API REST per connettere i microservizi, ma l'API REST può essere utilizzata anche in altre architetture. Non è esclusivo dei microservizi.

Allora perché separarsi? Qual è il vantaggio?

Potresti chiederti, non sarebbe bello avere un'applicazione "grande monolitica" che impacchetta tutto il codice insieme? Perché prendersi la briga di dividerlo?

Pensa al tuo robot. Se tutta la logica di controllo è concentrata su un'unica scheda madre, una volta che si desidera aggiornare un determinato giunto, potrebbe essere necessario fermare l'intero robot, riscriverlo, testarlo e quindi distribuirlo. Per non parlare dei problemi, anche i rischi sono alti. Se però si utilizza un microcontrollore (microservizio) indipendente per ogni giunto (modulo funzionale), la situazione cambia. È possibile aggiornare la logica di presa del manipolatore in modo indipendente senza influenzare in alcun modo il modulo di movimento del telaio. L'intero sistema diventa più flessibile e robusto.

"Ma", mormora qualcuno, "se i servizi vengono smantellati, come possono dialogare tra loro in modo affidabile?" Questo risale a quello che chiamiamo "linguaggio di comunicazione". Il motivo per cui l'API REST è popolare è che è semplice e universale, come il mandarino nel mondo di Internet. Utilizza le azioni comuni del protocollo HTTP: GET (ottieni), POST (crea), PUT (aggiorna), DELETE (elimina) per trasmettere le intenzioni. Quando il servizio A necessita di dati, invia una richiesta HTTP formattata in modo chiaro al servizio B e il servizio B restituisce un pacchetto di dati in un formato standard (solitamente JSON). Chiaro e intuitivo per gli sviluppatori.

Come li usiamo?

esisterekpower, siamo stati esposti a molti scenari di integrazione. Ad esempio, esiste un progetto che richiede che il sistema di controllo centrale programmi in modo flessibile decine di tipi diversi di servomotori, fornendo allo stesso tempo un feedback sullo stato in tempo reale. Il piano iniziale era quello di scrivere tutta la logica di controllo in un programma gigante. Qual è stato il risultato? Ogni volta che veniva aggiunto un nuovo modello di motore, il codice tremava e i cicli di test erano dolorosamente lunghi.

Successivamente sono passato all'architettura dei microservizi. Suddividiamo le funzioni di controllo motore, monitoraggio dello stato, diagnosi dei guasti e accesso in piccoli servizi indipendenti. Ogni servizio si concentra sul fare bene una cosa. Come parlano tra loro? Ciò avviene attraverso un'API REST ben progettata e chiaramente documentata. Ad esempio, se il servizio di monitoraggio dello stato desidera conoscere la coppia in tempo reale del motore n. 3, invia una richiesta GET /api/motors/3/torque al servizio di controllo motore e ottiene immediatamente una stringa di dati chiara. Aggiornare la diagnostica? Finché il servizio diagnostico è abilitato, tutto il resto funzionerà normalmente.

Questo modello rende le iterazioni rapide e riduce l'accoppiamento tra i team. Il collega responsabile del controllo motorio può concentrarsi sul suo lavoro. Finché rispetta il "contratto di comunicazione" API concordato in anticipo, non ha paura di influenzare altri moduli.

A cosa prestare attenzione nella scelta?

Quindi, se stai pensando di strutturare il tuo progetto, non guardare solo le parole d’ordine. Chiediti:

• Il tuo sistema è complesso? Alcune parti verranno ampliate o modificate frequentemente in futuro? (Se è così, l’indipendenza di un’architettura di microservizi può essere un vantaggio.)
• Com'è la struttura del tuo team? È adatto a più piccoli team per sviluppare diversi moduli in parallelo?
• Come devono comunicare tra loro i servizi? Quanto sono elevati i requisiti di tempo reale e affidabilità? (L'API REST è una scelta comune, ma non l'unica; a volte una coda di messaggi o un altro protocollo è più adatto.)

Non esiste una risposta valida per tutti. Proprio come la scelta di un servo per un robot, dipende dai requisiti di carico, precisione e velocità di risposta. I microservizi e l'API REST sono una potente combinazione di strumenti, ma solo comprendendo i rispettivi ruoli puoi utilizzarli senza problemi.

Dopotutto, la tecnologia ha uno scopo. Un'architettura chiara e una comunicazione efficiente hanno lo scopo finale di rendere il sistema più robusto e più facile da mantenere. Proprio come una struttura meccanica precisa, ogni componente funziona in modo appropriato e si coordina per produrre una potenza precisa. esisterekpower, crediamo che smantellando le cose in modo chiaro e poi collegandole nel modo più comune, spesso possiamo andare avanti in modo più costante e ulteriore. Spero che questa condivisione casuale possa aiutarti a chiarire i tuoi prossimi passi.

Fondata nel 2005,kpowerè dedicata 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.