Perché tutti utilizzano i microservizi? È davvero così utile?

Immagina di costruire un robot complesso. Se tutte le parti sono saldate a un circuito stampato, una volta che un piccolo motore si rompe, potrebbe essere necessario smontare l'intera macchina e riavviarla da capo: un processo dispendioso in termini di tempo, manodopera e facile coinvolgimento di altre parti intatte. Ma cosa succederebbe se ogni giunto e ogni sensore fossero formati indipendentemente in un piccolo modulo? Sostituirli è facile come mettere insieme i blocchi. Questo è probabilmente il motivo per cui l’architettura dei microservizi ha silenziosamente cambiato molte idee di progettazione del sistema.

Qual è il problema?

In passato molti software erano come un grosso blocco di ferro. Le funzioni sono tutte affollate e un movimento colpisce tutto il corpo. Vuoi aggiornare una piccola funzionalità? L’intero sistema deve essere ridistribuito. Un aumento improvviso del traffico? Può essere ampliato solo nel suo insieme, anche se solo una piccola parte ha davvero bisogno di risorse. Per non parlare della selezione tecnica: una volta scelto il quadro, nei prossimi anni potrebbe essere “bloccato” ed è difficile modificarne anche una piccola parte.

È come se avessi un braccio robotico simile a un polipo con lo stesso set di motori e lo stesso controller per ogni giunto. Sembra carino, ma quando vuoi rendere i tuoi polsi più flessibili e i tuoi gomiti più forti, scopri che non hai modo di iniziare.

Che differenza apportano i microservizi?

La prima attrazione: l'indipendenza.

Ogni microservizio è come un volante indipendente nella macchina, responsabile solo delle proprie azioni: la gestione degli utenti si occupa solo della verifica dell'accesso e il servizio ordini si occupa solo del processo di transazione. Comunicano tra loro attraverso interfacce leggere e chiunque lo rompa lo aggiornerà senza trascinare giù gli altri. Ti piacerebbe riscrivere uno di questi in un nuovo linguaggio di programmazione oggi? casuale. Finché potrà ancora "salutare" i suoi vicini, gli altri servizi non avvertiranno alcun cambiamento.

La seconda caratteristica: il ridimensionamento elastico.

Quando il numero di visite aumenta, invece di sostituire l'intera macchina con una più grande, si "aggiungono muscoli" solo alle parti sotto alta pressione. Ad esempio, se il servizio ordini è troppo occupato durante la stagione promozionale, distribuisci qualche microservizi ordine in più; se il modulo Ritratto utente è inattivo, lascialo così com'è. L’utilizzo delle risorse è più raffinato e i costi sono più facili da controllare.

Il terzo fascino: la libertà tecnica.

Nessuno prevede che tutti i servizi debbano essere sviluppati con gli stessi strumenti. Alcuni sono adatti per l'iterazione rapida in Python e altri richiedono che Java gestisca un'elevata concorrenza. Il database può anche essere selezionato su richiesta: questo utilizza MySQL, l'altro MongoDB. I team possono scegliere lo stack tecnologico più conveniente per i servizi di cui sono responsabili, proprio come selezionano il modello motorio più appropriato per ciascun giunto di un braccio robotico, e non sono più limitati da “one size fits all”.

Quindi c'è qualche mal di testa in questo?

Naturalmente c'è. Con così tanti servizi, il coordinamento diventa una sfida. In passato veniva chiamata una richiesta tra funzioni interne, ma ora può estendersi a diversi servizi sulla rete. Ciò comporta problemi di latenza, problemi di affidabilità della rete e coerenza dei dati: il servizio A ha successo, ma il servizio B fallisce, come eseguire il rollback? Anche il monitoraggio e il debugging sono diventati più complicati. Bisogna avere una mappa chiara dei servizi per sapere quali percorsi hanno preso le richieste.

È come gestire una squadra di robot. È fantastico che ogni membro del team possa lavorare in modo indipendente, ma sono necessari una buona catena di comando, protocolli di comunicazione chiari e un meccanismo che consenta alla missione complessiva di continuare se un membro del team fallisce.

Di cosa si preoccupano veramente le persone quando scelgono?

Alcune persone potrebbero chiedersi: il sistema deve essere suddiviso in microservizi? non necessariamente. Se la tua attività è semplice e stabile, un’applicazione olistica sarà più semplice. I microservizi sono popolari negli scenari in cui l'azienda sta cambiando, le dimensioni del team si stanno espandendo e sono necessarie prove ed errori rapidi e un'implementazione indipendente.

Ciò che in realtà riflette è un tipo di pensiero: utilizzare componenti modulari e sostituibili per costruire un sistema flessibile. Proprio come quando facciamo la progettazione meccanica, non saldiamo tutte le trasmissioni allo stesso telaio. Riserverai interfacce e standardizzerai i protocolli in modo che ciascuna unità possa operare in modo indipendente e collaborativo.

In che modo questo è stranamente simile alla progettazione dell'hardware?

Le persone che hanno giocato con servi o servomotori potrebbero avere una certa esperienza. Un buon design modulare non comprime tutti i circuiti su un'unica scheda, ma consente all'alimentazione, al controllo e al rilevamento di formare moduli separati e collegarli tramite interfacce chiare. In questo modo, durante il debug dell'azionamento del motore, il sensore non verrà bruciato accidentalmente; quando si aggiorna il controllo, è necessario sostituire solo la scheda centrale senza ricablare.

Lo stesso vale per l'idea dei microservizi: il software "hardware". Ogni servizio è come un modulo di circuito con funzioni chiare e pin di ingresso e uscita (API) chiari. L'implementazione interna può essere continuamente aggiornata o addirittura sostituita. Finché le definizioni dei pin rimangono invariate, il sistema può evolversi senza intoppi.

Quindi, in quali scene brilla davvero?

Quando la tua azienda ha bisogno di lanciare rapidamente nuove funzionalità e i cicli di vita delle diverse funzionalità variano notevolmente; quando le dimensioni del team crescono e speri che più gruppi possano sviluppare, testare e andare online in modo indipendente; quando il sistema deve far fronte a traffico irregolare e alcune parti sono sotto forte pressione e altre sono inattive, emergono i vantaggi dei microservizi.

Suddivide la "grande macchina" in "collaborazione di piccoli team". Ogni servizio si concentra su una cosa e comunica in modo standardizzato, ma l'insieme può raggiungere obiettivi complessi. Ciò richiede un approccio progettuale iniziale e un buon supporto infrastrutturale, ma una volta installato e funzionante, l'adattabilità e l'evoluzione del sistema tendono ad essere molto più rapide.

Come un sofisticato dispositivo meccanico, un sistema veramente affidabile e flessibile è spesso composto da molti moduli dedicati. I microservizi sono popolari non perché siano perfetti, ma perché rispondono a un’esigenza costante: come mantenere i sistemi agili e resilienti in caso di cambiamenti. Non si tratta di una soluzione miracolosa, ma di un insieme di strumenti di pensiero che consentono l'iterazione, la sostituzione e l'aggiornamento del software come i moduli hardware. La prossima volta che progetterai un sistema, forse pensaci: se lo pensi come un insieme di unità indipendenti che cooperano tra loro, ci saranno nuove possibilità?

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.