perché usiamo Kafka nei microservizi

Hai mai provato a controllare un folto gruppo di servomotori in modo che si sincronizzino come un'orchestra sinfonica?

Una volta ho lavorato su un progetto di una linea di produzione automatizzata, dove dozzine di bracci robotici funzionavano contemporaneamente e i dati dei sensori continuavano ad affluire. All'inizio utilizzavo una normale coda di messaggi, ma ho scoperto che quando la quantità di dati in un determinato collegamento aumentava improvvisamente, l'intero sistema iniziava a "bloccarsi", proprio come un incrocio durante l'ora di punta, dove tutte le auto erano bloccate e il braccio robotico dietro poteva solo aspettare.

A questo punto ti chiederai: esiste un modo per rendere i dati come il flusso del traffico in autostrada, anche se una certa sezione è congestionata, altre corsie sono ancora libere?

Successivamente mi è venuta l’idea di utilizzare Kafka per elaborare i microservizi. In poche parole, è come un sistema di nastri trasportatori che non si intasa mai. Ciascuno dei tuoi microservizi, come un programma responsabile dell'analisi dei dati sulla posizione dello sterzo o un altro servizio che registra le frequenze delle vibrazioni meccaniche, può prendere in modo indipendente i pacchetti di dati di cui ha bisogno da questo nastro trasportatore e gestire i propri affari senza interferire tra loro.

Fai un esempio. Supponiamo di avere tre microservizi: A riceve i segnali dei sensori, B calcola le traiettorie di movimento e C registra i registri di esecuzione. Nell'architettura tradizionale, B attende che A finisca l'elaborazione prima di poter funzionare, e C deve aspettare B. Ma dopo aver utilizzato Kafka, A mette i dati originali sul "nastro trasportatore" e B e C possono accedervi contemporaneamente e lavorare in modo indipendente. Anche se C è temporaneamente più lento, non rallenterà A e B.

Perché questo è particolarmente importante per i progetti meccanici? Perché i sistemi meccanici sono spesso in tempo reale e altamente simultanei. I servomotori di ciascun giunto di un robot a sei assi forniscono dati di feedback a livello di millisecondi. Se si verifica un ritardo nella catena di elaborazione dei dati, l’intero movimento perderà il coordinamento. Il design "registro persistente" di Kafka garantisce che anche se un servizio viene riavviato, i dati durante il periodo di inattività non andranno persi, proprio come una registrazione continua del registro di funzionamento di ciascun dispositivo, che può essere riprodotto in qualsiasi momento.

Qualcuno mi ha chiesto: "Sembra bello, ma sarà complicato?" In effetti, la chiave non è quanto profonda sia la tecnologia in sé, ma se si adatta al tuo scenario. Se controlli solo due o tre servi per eseguire oscillazioni semplici, potrebbe non essere utile; ma se ti trovi di fronte a un intero gruppo di apparecchiature per l'automazione di un'officina con centinaia di origini dati, questa architettura può aiutarti a evitare la fatica di fare straordinari a tarda notte per risolvere i problemi.

Quando seleziono un modello, di solito guardo tre punti: il primo è se il throughput può corrispondere al picco di dati, ad esempio uno scenario di tempesta quando tutti i sensori segnalano contemporaneamente; la seconda è se il ritardo rientra nel range di tolleranza del vostro sistema meccanico; il terzo è il costo di funzionamento e manutenzione. Kafka ha trovato in queste dimensioni un buon punto di equilibrio.

Naturalmente, non esiste una soluzione miracolosa. Richiede di avere un piano chiaro per il flusso di dati, ad esempio come dividere gli argomenti e come progettare le partizioni. È come pianificare il percorso di un nastro trasportatore per una nuova fabbrica: quali dati devono andare nella corsia di sorpasso e quali possono essere consolidati per il trasporto, è necessario pensarci in anticipo.

Parliamo dell'effettiva esperienza di implementazione. Durante la distribuzione iniziale, il team deve adattarsi a questo cambiamento nel modo di pensare "pubblica-sottoscrivi" e non insiste più sulle chiamate dirette tra i servizi. Ma una volta avviato, la flessibilità del sistema risulta notevolmente migliorata. Quando un servizio viene aggiornato, gli altri servizi verranno eseguiti normalmente; quando viene aggiunto un nuovo modulo di analisi dei dati, è sufficiente lasciarlo iscrivere al flusso di dati pertinente senza modificare il collegamento originale.

Il mondo digitale dei sistemi meccanici è spesso invisibile, ma determina se i movimenti delle apparecchiature fisiche sono precisi e fluidi. Scegliere un'architettura dati adeguata è come dotare un preciso meccanismo meccanico di un sistema nervoso corrispondente: forse non è direttamente visibile, ma rende più certa la rotazione di ogni ingranaggio.

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.kpowerha 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.