Quando i servomotori incontrano i microservizi: aspetti dell'architettura dei dati

Ti è mai capitato di riscontrare questa situazione? Decine di servomotori sulla linea di produzione funzionano contemporaneamente e i dati si riversano come una marea. I dati sull'angolo del servo qui non sono ancora stati salvati e le informazioni sulla coppia in tempo reale del braccio robotico sono state nuovamente inserite. Il database non riesce a respirare e il sistema occasionalmente si blocca per alcuni millisecondi, ma solo questi pochi millisecondi a volte possono davvero causare mal di testa.

Non è questa la situazione che incontriamo spesso quando realizziamo progetti di automazione? I dispositivi stanno diventando sempre più intelligenti e la quantità di dati sta diventando sempre più grande. La tradizionale architettura a database unico comincia a sembrare inadeguata.

Domande a scelta multipla sui database nell'era dei microservizi

Quindi ecco la domanda: come dovrebbe essere progettato il database nell'ambito dell'architettura dei microservizi?

Una voce disse: "Com'è semplice per tutti i servizi condividere un database!" Ma nel funzionamento reale, scoprirai che dietro questa semplicità si nascondono molti problemi. Le modifiche alla struttura delle tabelle di un determinato servizio potrebbero influenzare accidentalmente altre funzioni; l'accoppiamento dei dati è troppo stretto ed è difficile espandere un modulo specifico.

Un altro modo di pensare sta diventando popolare: ogni microservizio gestisce il proprio database. Sembra ragionevole, vero? Lascia che il modulo responsabile del controllo della timoneria gestisca i propri dati di posizione e lascia che il modulo che monitora lo stato del motore memorizzi il proprio registro di funzionamento. Ciascuno svolge i propri compiti senza interferire gli uni con gli altri.

Ma sorge una nuova domanda: una volta dispersi i dati, cosa dovremmo fare con le query sui dati che richiedono servizi incrociati? Ad esempio, se si desidera analizzare l'efficienza complessiva di una determinata unità meccanica, è necessario esaminare la velocità di risposta del servomotore, la precisione di posizionamento della relativa scatola dello sterzo e i dati di carico della struttura meccanica. I dati sono sparsi in luoghi diversi e metterli insieme è un processo lungo e laborioso.

kpowerSoluzione: modelli ed equilibrio

Sono alcuni giorni che pensiamo a questo. esisterekpowerNell'esperienza reale del progetto, ho scoperto che la chiave è trovare uno "schema di database" adatto: non un modello rigido, ma un metodo flessibile di organizzazione dei dati.

Ad esempio, il modello "database separato per ogni servizio" è particolarmente utile nei sistemi di controllo motorio. I dati del modulo di controllo in tempo reale vengono memorizzati in modo indipendente per garantire velocità di risposta; il modulo di analisi storica utilizza un'altra serie di strategie di archiviazione per facilitare l'analisi delle tendenze a lungo termine. I confini dei dati sono chiari e i servizi scambiano le informazioni necessarie attraverso interfacce chiare invece di cercare direttamente nei database di altre persone.

Come garantire la coerenza dei dati? Spesso adottiamo un approccio event-driven. Quando un servo completa l'azione specificata, pubblicherà un evento "azione completata". Altri servizi che si preoccupano di questo stato, come il servizio di registrazione della traiettoria del movimento, ricevono ed elaborano questo evento e aggiornano i propri dati. Questo approccio evita le dipendenze dirette del database tra i servizi.

Dalla teoria agli scenari di vita reale sulla linea di produzione

L'anno scorso abbiamo contribuito a un progetto di rinnovamento della linea di produzione automatizzata, che utilizzava queste idee. Ci sono dodici servomotori che lavorano insieme sulla linea di produzione e ciascuno di essi deve registrare parametri operativi, codici di errore e cronologia della manutenzione. I servi dei tre gruppi di bracci robotici devono scambiarsi i dati di posizione in tempo reale.

Se tutti i dati vengono stipati in un unico database, i dati di controllo e di analisi in tempo reale occuperanno risorse. Abbiamo adottato una strategia divide et impera: configurare un database di serie temporali ad alte prestazioni per servizi di controllo in tempo reale per memorizzare valori in tempo reale di velocità e coppia del motore; configurare un database relazionale per i servizi di gestione delle apparecchiature per archiviare i parametri delle apparecchiature e i registri di manutenzione; e il servizio di analisi ottiene dati da diverse fonti a seconda delle esigenze ed esegue un'elaborazione completa.

Il risultato? Il ritardo della risposta del controllo in tempo reale è ridotto del 40% e la velocità delle query di analisi dei dati è aumentata. Poiché ogni database può essere indirizzato alle proprie attività principali, non è necessario destreggiarsi tra tutti i tipi di operazioni sui dati.

I dettagli in pratica

Quando si sceglie uno schema di database, di solito ci poniamo diverse domande:

Qual è il modello di accesso ai dati per questo servizio? Si tratta di operazioni frequenti di lettura e scrittura in tempo reale di piccole quantità di dati o di query di analisi occasionali su larga scala?

Qual è la crescita prevista dei dati? Alcuni dati dei sensori generano più registrazioni al secondo, che possono accumularsi fino a raggiungere una quantità sorprendente in un mese.

Quanto sono forti le dipendenze dei dati tra i servizi? È davvero necessaria la sincronizzazione in tempo reale o è accettabile un breve ritardo?

Dopo aver risposto a queste domande, la scelta della modalità diventa molto più chiara. I dati di controllo con elevati requisiti di tempo reale possono essere adatti per database in memoria o database di serie temporali specifiche; per i dati di configurazione che richiedono relazioni di query complesse, i tradizionali database relazionali potrebbero essere più adatti; per grandi quantità di dati di registro storici, i motori di archiviazione colonnari a volte funzionano meglio.

Il modello non è schiavitù ma danza

Un buon schema di database non dovrebbe essere come una camicia di forza, ma come un abito da lavoro adatto che ti permetta di muoverti liberamente fornendo il supporto necessario. esisterekpowerNella nostra esperienza di progetto, abbiamo scoperto che le implementazioni di maggior successo sono spesso quelle squadre che sanno essere flessibili.

Scelgono uno schema di database primario per un servizio principale, abbinato a soluzioni di storage secondarie per funzioni specifiche. Proprio come un preciso sistema meccanico, ogni componente ha il materiale e la struttura più adatti, in modo che possa raggiungere la massima efficacia quando combinato.

A volte, guardando questi dati che fluiscono senza intoppi tra diversi servizi, penserete a quei sistemi di trasmissione ben progettati: la potenza viene trasmessa tra gli ingranaggi, ogni collegamento è giusto e infine convertito in movimento preciso.

scritto dentro

La progettazione di database nell'ambito dei microservizi consiste in definitiva nel trovare un equilibrio: l'equilibrio tra indipendenza del servizio e integrità dei dati, l'equilibrio tra prestazioni in tempo reale e flessibilità delle query e l'equilibrio tra efficienza di sviluppo a breve termine e costi di manutenzione a lungo termine.

Non esiste una risposta valida per tutti, ma solo scelte appropriate per scenari specifici. Ogni progetto è una nuova esplorazione, dal controllo motorio alla coordinazione meccanica, l'architettura dei dati è sempre la pietra angolare che silenziosamente sostiene tutto.

Quando scende la notte e le apparecchiature sulla linea di produzione entrano nel periodo di manutenzione, quei database che funzionano silenziosamente stanno ancora sistemando i dati della giornata e preparandosi per un funzionamento efficiente domani - proprio come una serie di dispositivi meccanici precisi, ogni parte è nella posizione corretta e adempie alla sua missione.

Fondata nel 2005, Kpower si dedica 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.