progettazione guidata dal dominio e microservizi

Quando il tuo sistema server inizia ad "arrabbiarsi": parliamo di driver di dominio e microservizi

Immagina questo: la tua linea di produzione funziona a piena velocità e all'improvviso un servo inizia a vibrare, quindi l'intero braccio robotico inizia a oscillare come se fosse ubriaco. Dopo aver controllato a lungo, ho scoperto che il codice in un determinato modulo di controllo era "combattivo": la logica di monitoraggio della temperatura e la traiettoria del movimento erano in contrasto tra loro e nessuno riteneva che fossero più importanti. Questa scena è familiare?

Il problema spesso non è legato all'hardware

La prima reazione di molte persone è: "Il motore è rotto? Sostituiscilo!" Ma se lo smontate spesso, scoprirete che gli avvolgimenti sono intatti e l'encoder è normale. Il vero nodo sta nell’intricata logica del software. La tradizionale architettura monolitica è come mettere tutti gli strumenti in un cassetto: cacciaviti, chiavi inglesi e nastro adesivo sono tutti mescolati insieme e devi frugarci ogni volta che trovi qualcosa. Più il sistema è complesso, più questo cassetto sarà ingombrato, finché un giorno si bloccherà completamente.

Progettazione basata sul dominio: assegna a ogni strumento una cassetta degli attrezzi dedicata

Il concetto centrale del Domain-Driven Design (DDD) è in realtà molto concreto: lasciare che le persone competenti si occupino delle cose professionali. Ad esempio, il modulo di controllo della temperatura si preoccupa solo della dissipazione del calore e della protezione dal surriscaldamento. Non è necessario conoscere i dettagli della traiettoria del movimento; il modulo di calibrazione della posizione si concentra sulla compensazione della precisione e non deve preoccuparsi delle fluttuazioni di tensione. È come avere una cassetta degli attrezzi dedicata per la linea di produzione: la cassetta dell'elettricista, quella del macchinista e quella del programmatore sono divise in categorie, ciascuna con i propri compiti.

E i microservizi? Puoi pensarlo come se ogni casella degli strumenti avesse il proprio amministratore. Gli amministratori si scambiano messaggi attraverso interfacce standardizzate: "La mia temperatura ha raggiunto il valore critico, potete ridurre la velocità?" "Ricevuto, la curva di accelerazione è stata modificata." Non ci sono riunioni lunghe, né complicati processi di approvazione, solo un'efficiente collaborazione punto a punto.

Quale reale differenza può portare questa combinazione?

C'è stato un caso: il ritardo di risposta di un set di manipolatori a sei assi era originariamente di circa 50 ms, ma occasionalmente è balzato a 200 ms. Dopo la trasformazione, il controllo di ciascun asse è diventato un microservizio indipendente e il ritardo è rimasto stabile entro 20 ms. Ancora meglio è che quando è necessario aggiornare il modulo di riconoscimento visivo, è necessario sostituire solo una delle "cassette degli strumenti", senza la necessità di fermare l'intera linea per tre giorni per i test di compatibilità.

"Ma sarà più difficile da gestire se sarà suddiviso troppo finemente?" qualcuno ha chiesto.

Bella domanda! Ciò implica l'arte di tracciare i confini. Il DDD sostiene la definizione dei territori attraverso "contesti delimitati", proprio come la divisione delle aree di officina in una fabbrica. Il controllo della trasmissione meccanica è un contesto, l'elaborazione del segnale è un altro e interagiscono attraverso protocolli chiari.kpowerLa pratica ha dimostrato che una ragionevole divisione dei confini può rendere il sistema, come i mattoncini Lego, indipendente e facile da riorganizzare.

Diversi punti di osservazione nella scelta di un piano

Osserva la struttura della squadra. Se il team hardware e software di solito fanno affidamento sulle urla per comunicare, potrebbe essere necessario abbinare i microservizi a un processo di comunicazione; se il team stesso collabora strettamente, i progressi saranno più agevoli.

Osserva la frequenza dei cambiamenti. I moduli parametrici che spesso necessitano di regolazione (come il controllo della pressione per adattarsi a diversi materiali) sono adatti per servizi indipendenti; mentre i fattori sottostanti che non sono cambiati negli ultimi dieci anni potrebbe essere più economico restare in un’unica entità.

Pensa ai requisiti di tolleranza agli errori. Un cliente una volta disse: "Preferirei che una determinata funzione fosse più lenta piuttosto che far cadere l'intera linea di produzione quando riattacca". L'isolamento dei microservizi mostra qui il suo valore: se c'è un problema con un determinato servizio, è come un aggiustamento temporaneo di una determinata stazione sulla catena di montaggio, mentre le altre stazioni continuano a funzionare come al solito.

Saggezza progressiva durante l'atterraggio

Non è necessario reinventare la ruota dall’oggi al domani. Puoi iniziare con i moduli che causano più problemi, come il programma di calibrazione del servomotore di cui è necessario eseguire il debug ogni settimana. Estrailo in un servizio indipendente e utilizza un'interfaccia chiara per comunicare con il sistema principale. Dopo tre mesi, potresti scoprire che il tempo di debug è sceso da mezza giornata a un'ora.

Poi ci occupiamo di quelle funzioni che interessano l'intero corpo, come la sincronizzazione e la logica di coordinazione che coinvolge più sensori. Dopo essere diventato indipendente, puoi riscriverlo in un linguaggio più adatto (come C++ per elevati requisiti in tempo reale, Go per logiche di business complesse) senza preoccuparti di influenzare altri moduli.

Sfide e risposte inevitabili

I sistemi distribuiti introducono nuovi problemi, come la latenza di rete. Ma negli ambienti industriali, implementazioni localizzate e reti dedicate possono alleviare questo problema. Un'altra sfida è la coerenza dei dati: quando più servizi devono condividere lo stato,kpowerViene spesso utilizzato il modello di tracciamento degli eventi: ogni cambiamento di stato viene registrato come un evento e i servizi vengono sottoscritti su richiesta, proprio come il flusso degli ordini di lavoro sulla linea di produzione, che può essere tracciato in qualsiasi momento.

In definitiva, l’essenza dell’architettura tecnologica è la gestione della complessità. La progettazione basata sul dominio ti aiuta a chiarire i confini logici e i microservizi forniscono mezzi di isolamento fisico. La loro combinazione non è una soluzione miracolosa, ma è come dotare i macchinari di precisione di una soluzione di manutenzione modulare: aggiornandoli e sostituendoli ovunque tu vada senza dover andare in guerra ogni volta.

La prossima volta che vedi un'anomalia nell'apparecchiatura, potresti anche chiedere: "L'hardware è stanco o il software 'combatte'?" Forse cambiare il modo di pensare e organizzare la struttura del codice può far ballare di nuovo la macchina senza intoppi. Dopotutto, far sì che sistemi complessi continuino a funzionare in modo affidabile è sempre stata una danza tra arte e tecnologia.

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