Comunicazione kafka tra microservizi

Quella notte suonò di nuovo l'allarme della catena di montaggio.

Ti trovi nell'officina e ascolti i ticchettii scoordinati del braccio robotico. I dati di più servounità sono come aquiloni con le corde rotte: le istruzioni sono state inviate, ma un determinato giunto è lento di mezzo battito. La temperatura non è anomala e il carico è normale, ma l'intera traiettoria di movimento è leggermente deviata, con il risultato che un lotto di parti deve essere rielaborato.

Dopo aver controllato più e più volte, ho scoperto che il problema non era nel motore stesso, ma nella comunicazione tra diversi moduli di controllo: i dati andavano persi per alcuni millisecondi e le azioni non potevano essere collegate.

Deviazioni di controllo come questa causate da una "comunicazione inaffidabile tra microservizi" sono in realtà abbastanza comuni nei sistemi meccanici e di automazione. Soprattutto quando più servounità, sensori e PLC devono lavorare insieme, se il flusso di dati viene ritardato, perso o fuori sequenza, l'intero sistema potrebbe presentare jitter visibile o invisibile.

In questo momento potrebbe essere necessaria un'architettura di comunicazione più robusta per inviare stabilmente i dati in tempo reale uno dopo l'altro come le parti su un nastro trasportatore, in modo che nessuno venga "lasciato indietro" a metà strada.

E Kafka può aiutare.

Non è magia, solo un'idea progettuale: lasciare che i dati vengano raccolti, distribuiti e conservati in un flusso continuo e che ciascun microservizio possa accedervi su richiesta senza bloccarsi a vicenda. Puoi pensarlo come un nastro trasportatore ordinato e ad alta velocità: tutti i dati sulla posizione del servomotore, il feedback di coppia e le informazioni sulla temperatura vengono inseriti in "pacchetti dati" uno per uno. Qualsiasi modulo che necessiti di questi dati può prelevare in qualsiasi momento il pacco di cui ha bisogno dal nastro trasportatore senza influenzare la lettura degli altri moduli.

In questo modo, anche se un servizio è temporaneamente occupato o riavviato, il flusso di dati non verrà interrotto, ma attenderà tranquillamente sul nastro trasportatore finché non verrà prelevato.

Quali sono i vantaggi? È ovvio.

Ad esempio, puoi espandere il sistema in modo più flessibile: aggiungi un'unità di monitoraggio senza ricablare o interrompere le comunicazioni esistenti, lascia semplicemente che inizi a leggere le informazioni dallo stesso flusso di dati. Oppure, quando un determinato modulo di controllo necessita di dati storici, può risalire direttamente ai pacchetti di dati precedenti senza dover arrestare l'intero sistema.

Naturalmente, l'implementazione richiede alcune considerazioni di progettazione. Ad esempio, è necessario pianificare la divisione degli argomenti dei dati: ciascun motore dovrebbe essere un argomento separato o dovrebbe essere diviso per tipo di dati? La politica di conservazione dei dati deve essere impostata in base ai requisiti in tempo reale dello scenario reale. Esiste anche la configurazione di gruppi di consumatori per garantire che i servizi di controllo chiave possano ottenere prima i dati più recenti, mentre i servizi di analisi possano digerire lentamente i dati esistenti.

Sembra un po’ astratto, ma se lo inserisci in uno scenario reale, sarà facile da capire.

Supponiamo di avere una catena di montaggio e che sei servoassi debbano lavorare insieme per completare un movimento preciso. Se viene utilizzata la tradizionale comunicazione punto a punto, una volta che la rete tra il PLC di controllo principale e un determinato driver si instaura, l'intera catena di azioni potrebbe essere sbilanciata. Se Kafka viene utilizzato come data center e ciascun asse pubblica i propri dati di stato in tempo reale, il PLC di controllo principale deve solo iscriversi a questi flussi di dati per calcolare l'istruzione successiva in tempo reale. Anche se i dati di un asse sono in ritardo di qualche millisecondo, gli altri assi non rimarranno bloccati: continueranno a perfezionarsi in base agli ultimi dati esistenti, quindi li integreranno rapidamente quando arrivano i dati in ritardo e la coerenza dell'azione complessiva sarà mantenuta.

Alcuni si chiedono anche: questo aumenterà la complessità del sistema?

Sì, all'inizio è necessario dedicare più tempo alla progettazione del flusso di dati e dell'architettura di distribuzione. Ma a lungo termine, cambia l’affidabilità della comunicazione da “fare affidamento sullo stato transitorio della rete” a “fare affidamento su un flusso di dati persistente”, il che a sua volta riduce il rischio di guasti sporadici. È come se si utilizzasse un nastro trasportatore anziché gli operai trasportassero i pezzi mano a mano: inizialmente il binario deve essere posato, ma una volta in funzione non è facile interrompere la produzione perché a qualcuno scivola la mano.

Come iniziare ad usarlo?

Non esiste una risposta standard, ma di solito puoi pilotarlo da un sottosistema. Ad esempio, lascia prima che il monitoraggio della temperatura e il rapporto sullo stato del servo passino attraverso il flusso Kafka e mantieni le istruzioni di controllo principali ancora attraverso il canale originale in tempo reale. Dopo aver acquisito familiarità con le caratteristiche dei flussi di dati e degli strumenti di monitoraggio, è possibile eseguire gradualmente la migrazione di più moduli dati con requisiti di tempo reale moderati. La chiave è riservare abbastanza log e monitoraggio in modo da poter vedere chiaramente se ci sono "blocchi" o "fughe di pacchetti" nel flusso di dati.

A proposito di questo, potresti pensare: sembra più un lavoro di architettura IT, cosa ha a che fare con il controllo meccanico?

In effetti, il rapporto è sempre più stretto. Il servosistema di oggi non è più un semplice ciclo di "esecuzione-istruzione". È necessario integrare più feedback in tempo reale, dati ambientali e indicatori di manutenzione predittiva. Se questi dati vengono ancora sincronizzati uno per uno attraverso i metodi di comunicazione tradizionali, l’efficienza e l’affidabilità incontreranno dei colli di bottiglia. Le piattaforme di dati in streaming come Kafka forniscono un’idea: trattare i dati come un flusso continuo di acqua invece che come gocce d’acqua sparse. È possibile accedere a ciascuna parte del sistema su richiesta, il che può non solo disaccoppiare ma anche mantenere la sincronizzazione generale.

Naturalmente, tutto ciò è inseparabile da una base hardware stabile e affidabile. Il prerequisito per tutto questo è ancora la prestazione dei servomotori e degli azionamenti: proprio come un nastro trasportatore che funziona senza intoppi, anche i suoi componenti devono essere precisi e resistenti.

Pertanto, se anche tu sei preoccupato dai ritardi e dalle perdite di dati nella collaborazione multi-dispositivo, potresti voler andare oltre la prospettiva di guardare semplicemente l'hardware o le reti e pensare se dovresti progettare un "sistema di trasmissione" più robusto per il flusso di dati stesso.

Dopotutto, ciò che fa muovere il robot in modo fluido non è solo la velocità con cui ruota il motore, ma anche la stabilità con cui vengono trasmessi i dati.

kpowerConcentrandoci su servoazionamento e automazione, creiamo per te una base di controllo del movimento più affidabile, dall'hardware al flusso di dati.

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.