Quando il tuo sistema server inizia a "parlare": svelare i miti delle API e dei microservizi

Ricordi la scena in cui hai eseguito il debug del braccio robotico l'ultima volta? Quel pomeriggio fissavi i parametri di salto sul pannello di controllo e all'improvviso ti rendevi conto che la trasmissione di ogni comando era in realtà come un dialogo preciso. Ora, quando parliamo di moderni sistemi di controllo, questo approccio “conversazionale” si divide silenziosamente in due scuole: API e microservizi. Sembrano simili, ma svolgono ruoli molto diversi nel funzionamento reale.

La domanda è: è davvero necessario distinguere tra i due?

Immagina questo. Progetti una serie di bracci robotici a sei assi. I servi di ciascun giunto devono ricevere istruzioni, feedback sullo stato e coordinare le azioni. Se tutte le funzioni sono raggruppate in un enorme pacchetto di istruzioni, una volta che è necessario regolare un determinato collegamento, come l'aggiornamento della precisione della rotazione del polso, è necessario sospendere l'intero sistema, ricompilare, testare e implementare. Questa scena è familiare?

È come utilizzare un set fisso di stampi per produrre tutte le parti, con una flessibilità limitata. Il dilemma che incontrano molti team è: quale architettura di “dialogo” dovrebbe essere scelta per rendere il sistema più intelligente e tollerante?

Sfatare i miti: le API non sono microservizi e i microservizi sono inseparabili dalle API

Facciamo una semplice analogia. L'API è più simile a uno schema elettrico standard, che definisce come collegare la spina e come trasmettere il segnale. I microservizi smantellano l'intero quadro elettrico in moduli indipendenti: uno per l'illuminazione, uno per i motori e un altro per i sensori. Ogni modulo può funzionare in modo autonomo e comunicare con altri moduli tramite interfacce standard (API).

Nel mondo del servocontrollo questa distinzione diventa concreta. Per esempio,kpowerDopo che il sistema di sterzo intelligente ha adottato un'architettura di microservizi, il monitoraggio della temperatura, il feedback della posizione e la regolazione della coppia sono diventati servizi indipendenti. Quando il carico aumenta improvvisamente, il modulo di temperatura può emettere un allarme individualmente senza interrompere l'intero processo di controllo. Questo design rende la manutenzione intuitiva quanto la sostituzione delle parti modulari.

Perché questa architettura merita attenzione?

La scorsa settimana stavo chiacchierando con un leader di progetto e ha menzionato un fenomeno interessante: da quando il sistema di controllo è stato spostato da una singola API a una combinazione di microservizi, il numero di tempi di inattività imprevisti del sistema è stato ridotto di quasi il 70%. "È come passare da un circuito in serie a un circuito parallelo", ha descritto. “Se si rompe una lampadina, le altre restano accese.”

Ci sono diversi vantaggi pratici dietro questo:

• L'aggiornamento locale non influisce sulla situazione globale: Vuoi ottimizzare l'algoritmo PID? Basta aggiornare il servizio dell'algoritmo di controllo senza toccare il modulo di pianificazione della traiettoria di movimento.
• I guasti sono isolati nelle "stanze piccole": Quando si verifica un problema con il servizio di comunicazione, il servizio di registrazione dei dati può comunque continuare a salvare i dati normali precedenti.
• Gli stack tecnologici possono essere mescolati e abbinati: C++ viene utilizzato per la parte di controllo in tempo reale e Python viene utilizzato per il dashboard dei dati: è possibile selezionare lo strumento più adatto per ciascun servizio.

Come scegliere?

Questa non è una domanda o/o. Nella maggior parte dei casi sono complementari. Proprio come quando si progetta un sistema di trasmissione, non è necessaria solo un’interfaccia di accoppiamento standard (API), ma è anche necessario considerare di trasformare la guida, la frenata e il rilevamento in unità indipendenti (microservizi).

Diversi scenari pratici possono aiutarti a giudicare:

• Se il modello del tuo dispositivo è fisso e il ciclo di iterazione delle funzioni è lungo, un'API ben progettata potrebbe essere sufficiente.
• Ma se stai sviluppando una piattaforma che deve aggiungere frequentemente funzioni o connettersi a una varietà di dispositivi di terze parti, l'architettura dei microservizi può offrirti maggiore flessibilità.

Un cliente una volta ha condiviso il proprio processo di trasformazione: inizialmente veniva utilizzata un'unica API per gestire l'intera catena di montaggio e ogni volta che una stazione di lavoro veniva aggiunta o rimossa era necessario un test completo. Successivamente è stata adottata la progettazione dei microservizi e ciascuna postazione di lavoro è diventata un servizio indipendente. Aggiungere una nuova stazione di ispezione visiva è stato come inserire una nuova scheda nello slot di espansione: può essere integrata nel sistema esistente dopo aver configurato l'interfaccia di comunicazione (API).

Le sottigliezze durante l'atterraggio

Naturalmente, qualsiasi architettura ha un prezzo. Le caratteristiche distribuite apportate dai microservizi richiedono una pianificazione della rete più dettagliata e considerazioni sulla coerenza dei dati. È come passare dalla lubrificazione centralizzata alla fornitura di olio indipendente per ciascun giunto: ci sono più punti di manutenzione, ma l'impatto dei guasti locali è minore.

Nella distribuzione effettiva, i team spesso iniziano il pilotaggio dalle funzioni principali. Ad esempio, dividi innanzitutto il controllo motorio e il feedback sullo stato in due servizi per sperimentare il processo di implementazione e scalabilità indipendenti. Questo tipo di trasformazione graduale è spesso più agevole di una ricostruzione una tantum.

Torniamo alla domanda iniziale

Pertanto, la differenza tra API e microservizi è essenzialmente una diversa concezione del "metodo di dialogo" del sistema. Uno tende a sviluppare protocolli di comunicazione unificati e completi, mentre l'altro si concentra sulla creazione di unità funzionali flessibili e sostituibili.

Nel mondo dei servocomandi e del controllo macchine, questa scelta influisce sul modo in cui il sistema opera ogni giorno. Determina se quando un sensore diventa improvvisamente "silenzioso", se l'intera linea di produzione si ferma e attende, o se altri moduli continuano a completare azioni eseguibili; determina anche quando si desidera migliorare la precisione di una determinata apparecchiatura, se l'intera linea viene spenta per aggiornamenti a tarda notte o se un piccolo modulo viene sostituito durante la pausa pranzo.

Una buona architettura dovrebbe essere come un sistema di trasmissione ben progettato: ogni componente ha un ruolo chiaro, le connessioni sono fluide e affidabili e, anche se i singoli ingranaggi devono essere sostituiti, l'intero sistema può comunque mantenere il ritmo di funzionamento. E questa potrebbe essere l’affidabilità che realmente perseguiamo dietro le nostre scelte tecnologiche.

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,kpowerintegra 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.