Quando l'architettura dei microservizi incontra i servomotori: quei piccoli grattacapi

Immagina di aver trascorso mesi a progettare il sistema di microservizi perfetto. Ogni servizio viene implementato in modo indipendente, può essere ampliato in modo flessibile e teoricamente dovrebbe funzionare con la stessa precisione di un orologio svizzero. Quindi si inizia a integrare l'hardware vero e proprio, come i servomotori che controllano un braccio robotico o il sistema di sterzo che gestisce una catena di montaggio automatizzata. All'improvviso, le cose diventano un po'... sottili.

Hai sempre la sensazione che la risposta di un determinato servizio sia un po' lenta? Quando i dati circolano tra moduli diversi, alcuni parametri chiave vengono occasionalmente persi? O per essere più diretti: tutto è normale durante il test di un singolo servizio, ma una volta inserito nell'ambiente di produzione reale, il motore ogni tanto trema come in preda a una convulsione, si ferma per mezzo secondo e poi continua a funzionare come nessun altro?

Queste non sono allucinazioni. L'architettura dei microservizi presenta alcuni problemi unici quando si tratta di interazioni hardware.

Qual è il problema? Diverse "insidie" comuni

I ritardi nella comunicazione sono diventati un difetto. I microservizi si basano sulle chiamate di rete e ogni chiamata richiede una richiesta e una risposta. Per apparecchiature come i servomotori che richiedono istruzioni in tempo reale, anche un ritardo di decine di millisecondi può causare deviazioni nella traiettoria del movimento. Pensa a una catena di montaggio di precisione. Se un servo fa una pausa per 0,1 secondi mentre attende i dati, la precisione dell'intero lotto di prodotti potrebbe essere ridotta.

Poi ci sono le sfide inerenti alla coerenza dei dati. Stato del motore, feedback di posizione, letture di coppia... questi dati possono essere sparsi tra diversi servizi. Quando è necessario esprimere un giudizio globale (come ad esempio "ridurre automaticamente la velocità quando la temperatura è troppo alta"), le informazioni potrebbero non essere sincronizzate in tempo, determinando decisioni basate su dati obsoleti. L'hardware non aspetterà che tu raccolga i dati prima di agire.

C’è anche il problema del coordinamento delle risorse. Un servizio è responsabile della pianificazione del percorso, un altro gestisce gli azionamenti a motore e un terzo monitora lo stato di sicurezza. In teoria, ciascuno svolge i propri compiti, ma nel funzionamento reale, se un servizio viene temporaneamente sovraccaricato o riavviato, altri servizi possono continuare a impartire istruzioni. Il risultato è che il motore non riceve nuovi comandi e si blocca oppure ripete vecchie azioni.

Per non parlare del caos della distribuzione e della gestione delle versioni. Il controllo del movimento viene aggiornato oggi e il servizio della soglia di sicurezza verrà adeguato domani: se il test è insufficiente, una vecchia versione del servizio potrebbe improvvisamente non essere in grado di analizzare il nuovo formato di comando, causando il malfunzionamento dell'intera unità hardware. Questo problema è molto meno comune in un'architettura monolitica perché tutto il codice viene aggiornato insieme.

Come affrontarlo? L'idea può effettivamente essere molto "meccanica"

È interessante notare che il modo per risolvere questi problemi a volte richiede ispirazione dal pensiero hardware.

Ad esempio, puoi introdurre il concetto di "strato buffer". Come gli ammortizzatori in un sistema meccanico, progetta un buffer di dati leggero tra i servizi critici. Non tutti i dati devono essere sincronizzati in tempo reale. Le istruzioni che richiedono realmente un'elaborazione in tempo reale (come i segnali di arresto di emergenza) e gli aggiornamenti di stato con tolleranza agli errori vengono trasmessi attraverso canali separati. Ciò può ridurre significativamente la congestione della rete inefficace.

Puoi anche imparare dalla struttura "watchdog" del modulo hardware. Dotare ogni servizio che prevede il controllo hardware di un monitoraggio dello stato indipendente. Una volta rilevato un timeout della risposta o un'anomalia dei dati, invece di attendere ciecamente, il processo di downgrade verrà attivato automaticamente, ad esempio il passaggio al set di istruzioni di base della cache locale per garantire che l'hardware possa almeno fermarsi in modo sicuro invece di correre qua e là.

Inoltre, non consentire che i servizi siano troppo frammentati. Per le unità di controllo hardware strettamente coordinate, a volte è una scelta più sicura unire diversi servizi strettamente correlati in un "super servizio". Proprio come se si mettessero le tre funzioni di azionamento del motore, lettura dell'encoder e calcolo della posizione nello stesso servizio, lo scambio di dati tra di loro passerà attraverso il processo interno, eliminando il sovraccarico della rete e la perdita di serializzazione. Ciò va contro il dogma “piccolo e specializzato” dei microservizi, ma la praticità è un compromesso.

Anche la standardizzazione dei formati dei dati è particolarmente critica. Definisci un insieme rigoroso ma semplificato di protocolli di istruzioni hardware e tutti i servizi correlati aderiscono allo stesso insieme di linguaggi. Non lasciare che il servizio A invii valori angolari in JSON, ma il servizio B si aspetta un flusso binario. Dopo l'unificazione, l'efficienza di analisi è elevata e la probabilità di errori è naturalmente bassa.

kpowerPratica: trasformare i problemi in funzionalità

esisterekpower, abbiamo vissuto questi momenti di mal di testa. Quando all'inizio utilizzavo il framework di microservizi standard per collegare progetti di sterzo ad alta precisione, ho sofferto anche di ritardi nella comunicazione. Successivamente, abbiamo elaborato un'idea un po' "mista e abbinata".

Abbiamo mantenuto la flessibilità dei microservizi nell'architettura, ma abbiamo apportato rinforzi mirati sul percorso critico dell'interazione hardware. Ad esempio, un canale di comunicazione prioritario è progettato per servizi di controllo in tempo reale, in modo che le istruzioni chiave possano essere elaborate in anticipo. Per fare un altro esempio, abbiamo sviluppato un leggero meccanismo di caching dello stato locale in modo che il servizio possa fare affidamento sugli ultimi dati memorizzati nella cache per prendere decisioni ragionevoli anche quando il servizio è temporaneamente disconnesso, invece di segnalare ciecamente gli errori.

Prestiamo particolare attenzione anche alla costruzione dell'ambiente di test di simulazione. Prima di essere implementati sull'hardware reale, tutti i servizi sono stati sottoposti innumerevoli volte a vari scenari estremi nell'ambiente di simulazione: interruzione della rete, perdita di pacchetti, riavvio improvviso di un determinato servizio... Solo così possiamo sentirci sicuri quando arriviamo al laboratorio reale.

Queste regolazioni possono sembrare poco interessanti o anche un po’ “scadenti”, ma funzionano. Rende l’architettura dei microservizi non più solo una bellezza teorica in un ambiente industriale, ma uno scheletro in grado di supportare realmente una produzione stabile.

Quindi, dovremmo usare i microservizi?

Se nel tuo progetto il controllo hardware è il fulcro e i requisiti in tempo reale sono estremamente elevati (come la risposta in millisecondi), potrebbe essere necessario valutare attentamente l'architettura pura del microservizio. Ma se il tuo sistema è molto complesso e richiede iterazioni a lungo termine e le interazioni hardware consentono un certo grado di flessibilità (ad esempio, la maggior parte delle istruzioni può tollerare ritardi di centinaia di millisecondi), allora i vantaggi della modularità e dell’implementazione indipendente apportati dai microservizi sono piuttosto interessanti.

La chiave potrebbe essere "non essere troppo dogmatico". L’architettura è al servizio delle persone e non viceversa. A volte, aggiungendo qualche idea di progettazione monolitica ai microservizi o facendo qualcosa di "non standard" sul percorso critico, si possono effettivamente ottenere risultati più solidi.

Proprio come progettare una macchina, perseguire esclusivamente il layout teorico ottimale potrebbe non essere così affidabile come lasciare un po’ di ridondanza e aggiungere alcuni buffer. Dopotutto, dopo aver corso, la stabilità è molto più importante della bellezza.

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.