Quando il tuo progetto di servomotore incontra i microservizi: perché hai bisogno di una coda di messaggi e la nostra pratica

Immagina questo: stai eseguendo il debug di un braccio robotico, con ciascun giunto controllato da un servomotore indipendente. Questi motori devono funzionare insieme in tempo reale, ma le istruzioni provengono da diversi microservizi: uno calcola la traiettoria, uno gestisce il feedback dei sensori e un altro gestisce la logica di sicurezza. All'improvviso, un determinato servizio rallenta per alcuni millisecondi a causa del carico elevato e l'intera operazione inizia a bloccarsi o addirittura a non essere sincronizzata. In quel momento, pensavi che sarebbe stato fantastico se questi servizi potessero rendere le conversazioni più "fluide"?

Questo in realtà non è solo un problema riscontrato dal controllo meccanico. Qualsiasi sistema suddiviso in microservizi deve affrontare sfide simili: come comunicare tra i servizi in modo affidabile ed efficiente? Come garantire che i dati non vadano persi, che l'ordine non venga confuso e che possa resistere al traffico improvviso?

Ci siamo scontrati con questo muro qualche anno fa mentre stavamo aggiornando una linea di smistamento automatizzata. I metodi tradizionali, come le chiamate HTTP dirette, diventano fragili con l’aumento dei servizi. Quando un servizio si interrompe, anche gli altri servizi sul collegamento vengono interessati; non appena arrivano i picchi di richieste, il sistema inizia a mettersi in coda e le prestazioni in tempo reale sono fuori questione. Abbiamo bisogno di un meccanismo che assomigli più a un "nastro trasportatore": metti i dati su di esso e lascia che i luoghi in cui sono necessari vi accedano al proprio ritmo senza bloccarsi a vicenda.

Quindi abbiamo iniziato a cercare e alla fine abbiamo introdotto Kafka.

Cos'è Kafka? Considerala come una catena di montaggio intelligente e ad alta velocità

Se utilizzi una scena familiare come analogia: Kafka è come il nastro trasportatore infinito in una fabbrica. Ogni microservizio può essere considerato come una workstation. La stazione A deposita i semilavorati (messaggi) sul nastro trasportatore, mentre le stazioni B e C li prelevano per la lavorazione in qualsiasi momento secondo necessità. Il nastro trasportatore stesso continua a funzionare. Anche se una determinata stazione viene temporaneamente riparata, i prodotti semilavorati non scompariranno, ma aspetteranno tranquillamente sulla linea finché una stazione non subentrerà.

Questo risolve diversi grattacapi:

• disaccoppiamento: I servizi non "chiamano" più direttamente, ma vengono consegnati tramite un nastro trasportatore. Il mittente lascia cadere il messaggio e se ne va senza sapere chi lo gestirà o quando.
• respingente: Quando il flusso a monte genera improvvisamente una grande quantità di dati (come un improvviso segnale ad alta frequenza da un sensore), il nastro trasportatore può trasportarli temporaneamente e il flusso a valle può digerirli in base alle proprie capacità per evitare di essere sopraffatto.
• affidabilità: I messaggi rimangono sul nastro trasportatore e, anche se alcuni servizi vengono riavviati, i dati non andranno persi.
• sequenzialità: Su un nastro trasportatore, l'ordine degli elementi è fisso. Questo è fondamentale per i dati sensibili alla sequenza come le istruzioni di controllo del motore.

Come lo usiamo? Un esperimento non lineare

All'inizio, alcune persone nel team erano preoccupate: "È troppo complicato? Dobbiamo mantenere un nuovo set di middleware". Ma in pratica, abbiamo scoperto che era più come costruire dei mattoncini che costruire un grattacielo.

Non abbiamo iniziato con una revisione completa. Abbiamo invece scelto un collegamento con il punto dolente più evidente per testare il terreno: il monitoraggio dello stato del braccio robotico. Si scopre che i dati sullo stato vengono inviati da un servizio all'altro e spesso vengono persi a causa di problemi di rete, causando di tanto in tanto la "frammentazione" del pannello di monitoraggio. Abbiamo semplicemente creato un argomento Kafka (che può essere inteso come un nastro trasportatore dedicato), lasciato che il servizio di pubblicazione dello stato scriva i dati qui e il servizio di monitoraggio si iscrive ad esso. Quasi immediatamente il problema della frammentazione è scomparso. Perché anche se il servizio di monitoraggio è temporaneamente offline, dopo il riavvio può comunque leggere tutti gli aggiornamenti di stato non elaborati dal punto di interruzione.

Questo piccolo successo ci ha dato fiducia. Successivamente, abbiamo gradualmente migrato il flusso delle istruzioni dell'ordine e il flusso degli eventi di allarme. A poco a poco, il flusso di dati dell'intero sistema diventa chiaramente visibile, come se guardassimo una mappa logistica in tempo reale. È chiaro a colpo d'occhio quali linee sono congestionate e quali sono inattive.

Alcuni frammenti e sentimenti reali

Naturalmente c'è stata qualche esplorazione nel processo. Ad esempio, una volta ci siamo chiesti "In quanti nastri trasportatori (Argomenti) dovrebbero essere divisi?" Successivamente, abbiamo scoperto che, proprio come in un workshop, tutte le parti non verranno mescolate su un'unica riga ed è più ragionevole gestirle separatamente per dominio di dati e urgenza. Le istruzioni di controllo del motore richiedono una bassa latenza e una linea separata ad alta velocità; i dati di registro e di controllo hanno un volume elevato ma richiedono bassi requisiti di tempo reale, quindi utilizzare un'altra linea ad alta capacità. Ognuno va per la sua strada senza interferire l'uno con l'altro.

Alcuni chiedono anche: "E se si rompesse il nastro trasportatore stesso?" Il design distribuito di Kafka lo rende intrinsecamente ridondante. Verrà eseguito il backup dei dati su più nodi. Se un singolo nodo fallisce, altri nodi possono subentrare immediatamente e il servizio sarà quasi impercettibile. È come mettere un motore di riserva nella trasmissione.

Guardando indietro ora, l’introduzione di Kafka non ha reso il sistema più “complesso”, ma ha invece reso ordinato il caos originariamente invisibile. Il teso rapporto di accoppiamento diretto tra i microservizi è stato allentato. Ogni servizio può concentrarsi maggiormente sulla propria logica e la flessibilità dell'intera architettura è stata notevolmente migliorata. Quando è necessario espandere la linea di produzione e aggiungere una nuova stazione di ispezione, dobbiamo solo abbonare il nuovo servizio al Topic corrispondente, il che è semplice come aggiungere una nuova stazione accanto al nastro trasportatore, senza disturbare in alcun modo le altre parti.

Parliamo di scelte

Esistono molti strumenti per la coda dei messaggi sul mercato, perché scegliere Kafka? Per noi, apprezziamo le sue prestazioni equilibrate in termini di produttività elevata, persistenza e garanzie di sequenza. Potrebbe non essere quello con le funzionalità più brillanti, ma è abbastanza solido per scenari industriali che richiedono un'elaborazione stabile dei flussi di dati. Naturalmente, nessuno strumento è una soluzione miracolosa e la sua curva di apprendimento e i costi operativi e di manutenzione richiedono investimenti. Ma se anche i vostri microservizi iniziano a "agire in modo scoordinato" a causa di problemi di comunicazione, potrebbe valere la pena considerare l'installazione di una serie di tali "nastri trasportatori intelligenti" sul sistema.

Dopotutto, una buona tecnologia dovrebbe essere come una trasmissione meccanica affidabile: silenziosa, precisa e in grado di facilitare la collaborazione complessa.

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.