Quando il progetto di microservizi C++ riscontra problemi di gestione: una nota di risposta informale

Ho dimenticato che giorno fosse, ma stavo eseguendo il debug di un servoarray. I tre servomotori avrebbero dovuto girare in modo sincrono secondo le istruzioni, ma invece sembravano ballare i propri passi di danza casuali. Ritardo nella comunicazione? Tensione instabile? Oppure c'è qualcosa che non va nella logica? Ho osservato il flusso di dati sullo schermo e all'improvviso ho capito che il problema potrebbe non essere l'hardware, ma i "nervi" che li collegano.

Noi siamo sempre così: passiamo molto tempo a calibrare accuratamente la scatola dello sterzo e a progettare la struttura meccanica affinché sia ​​robusta, ma è facile ignorare il “cervello” che fa muovere tutto. Nei progetti complessi, soprattutto quelli che prevedono il controllo in tempo reale, le tradizionali applicazioni monolitiche sono come mettere tutte le parti in una scatola, influenzando l’intero corpo. Una piccola modifica in un determinato modulo potrebbe causare la necessità di eseguire nuovamente il debug dell'intero sistema.

Cosa facciamo di solito quando ci troviamo di fronte a questa situazione?

La prima reazione della maggior parte delle persone è armeggiare. Aggiungi un pezzo di codice di tolleranza agli errori qui, regola la priorità del thread lì. Ma presto scoprirai che questo non fa altro che respingere il problema. Man mano che i sensori aumentano e la logica di controllo diventa più complessa, i programmi diventeranno gonfiati e fragili. All'inizio non osi aggiornare facilmente, perché ogni compilazione e distribuzione è un'avventura.

Esiste un modo più interessante? Immagina se la logica che controlla il servomotore, l'unità che elabora i dati dei sensori e l'unità che gestisce le traiettorie di movimento potessero funzionare tutte come moduli Lego indipendenti, concentrandosi su ciascuno e comunicando attraverso un'interfaccia chiara. Questo è il fascino dell’architettura dei microservizi nel campo del controllo integrato e meccanico.

Ma francamente, costruire un'architettura del genere in un ambiente C++ è come aprire un sentiero in una foresta all'inizio. È necessario considerare cosa utilizzare per la comunicazione tra processi (gRPC? ZeroMQ? Simple TCP?), come gestire la serializzazione dei dati, come isolare gli errori senza diffonderli, per non parlare della questione basilare ma complessa della gestione delle risorse. Costruirlo da zero richiederebbe almeno settimane e comporterebbe innumerevoli cicli di debug fino a tarda notte.

Perché hai bisogno di un buon punto di partenza?

Detto questo, mi sono ricordato di un'implementazione di riferimento open source che avevo già incontrato. Non ha espedienti, mostra semplicemente in modo chiaro come può apparire un'applicazione di microservizi in C++. Ogni servizio ha responsabilità chiare. Ad esempio, il servizio che gestisce specificamente la generazione del segnale PWM è completamente separato dal servizio che analizza le istruzioni di posizione. I dati vengono trasferiti tra loro tramite messaggi leggeri. Anche se un determinato servizio non risponde temporaneamente, l'intero sistema non si bloccherà.

I vantaggi di questa struttura sono pratici. Ad esempio, se è necessario aggiungere un nuovo collegamento di feedback del sensore al braccio robotico, non è necessario ricostruire l'intero programma. Devi solo sviluppare un servizio indipendente per elaborare i nuovi dati e quindi connetterti al sistema esistente tramite l'interfaccia stabilita. Quando si aggiorna o si esegue il debug di una funzione specifica, è anche possibile riavviare il modulo di servizio corrispondente in modo indipendente senza influenzare altre attività di controllo in esecuzione. Ciò significa una maggiore disponibilità per le apparecchiature che devono funzionare 24 ore al giorno.

Un amico una volta chiese: "Sarebbe troppo pesante per i dispositivi embedded con risorse limitate?" Questa è una buona domanda La chiave sta nel metodo di attuazione. Processi leggeri, comunicazione efficiente della memoria condivisa ed evitamento di inutili spese di serializzazione: tutto questo può essere risolto in un'architettura ben progettata. Il progetto di riferimento mostra come bilanciare disaccoppiamento ed efficienza in modo che i vantaggi della modularità non siano compensati da perdite di prestazioni.

Su cosa dovremmo concentrarci?

Quando guardi un esempio di microservizio C++, non limitarti a guardare quanti protocolli di comunicazione implementa. Ciò che è più importante è se i limiti di errore sono chiaramente definiti. Il crash di un servizio influenzerà altri servizi? Il flusso di dati prevede meccanismi di timeout e fallback ragionevoli in circostanze anomale? Questo è fondamentale per i sistemi che controllano i macchinari fisici.

Poi c'è l'osservabilità. Ciascun servizio può produrre in modo indipendente log e parametri di stato significativi? Quando si verifica una deviazione nel movimento dello sterzo, è possibile individuare rapidamente il collegamento di elaborazione dati che presenta il problema? Una buona progettazione rende la diagnosi intuitiva come guardare un cruscotto.

È la cordialità di costruzione e dispiegamento. Ti consente di compilare e testare facilmente i singoli servizi in modo indipendente? È possibile avviare l'intero sistema nell'ambiente di sviluppo o nel simulatore con un clic? Ridurre gli ostacoli all'implementazione ti consente di concentrarti maggiormente sulla logica aziendale stessa, ovvero far funzionare i motori e le strutture meccaniche esattamente come previsto.

Un pensiero casuale

Il valore di questo repository di esempio open source è che fornisce un punto di partenza per pensare. Puoi non essere d'accordo con alcune delle sue implementazioni, ma puoi evitare la confusione di iniziare da zero. Proprio come su un disegno con una griglia di coordinate disegnata, puoi rappresentare le tue esigenze specifiche direttamente su di esso senza dover rimisurare le proporzioni ogni volta.

Torniamo al problema del servo non sincronizzato all'inizio. Successivamente ho scoperto che un'attività non critica nel ciclo di controllo principale occasionalmente bloccava l'invio di istruzioni in tempo reale. Se all'epoca il sistema fosse stato modulare, il compito non critico avrebbe potuto essere "stordito" occasionalmente nel suo piccolo mondo senza trascinare l'intera catena di controllo del movimento. Per risolverlo, riavvia semplicemente quel singolo servizio invece di disattivare l'intero dispositivo.

Potrebbe essere questo il dono che l’architettura software porta ai progetti hardware: la possibilità di affrontare la complessità con serenità. Quando ogni componente conosce le proprie responsabilità e dispone di metodi di comunicazione chiari, l’intero sistema può dimostrare una vitalità che è allo stesso tempo flessibile e robusta. Ciò che resta è che tu pensi di più a far funzionare perfettamente il meccanismo: questa è la parte più divertente, non è vero?

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.