Ciao a tutti! Abbiamo ottime notizie, a giugno OTUS lancia di nuovo il corso , per cui come di consueto condividiamo con voi materiale utile.
Se vi siete imbattuti in questa storia sui microservizi senza alcun contesto, è comprensibile considerarla un po' strana. Suddividere un'applicazione in frammenti, collegati tra loro da una rete, implica necessariamente l'aggiunta di complessi meccanismi di tolleranza ai guasti nel sistema distribuito risultante.
Sebbene questo approccio comporti la suddivisione in numerosi servizi indipendenti, l'obiettivo finale è molto più grande della semplice operatività di questi servizi su macchine diverse. Qui si parla dell'interazione con un mondo circostante che è anch'esso distribuito. Non in senso tecnico, ma piuttosto nel senso di un'ecosistema composta da molte persone, team, programmi, e ognuna di queste parti deve in qualche modo portare a termine il proprio lavoro.
Le aziende, ad esempio, rappresentano un insieme di sistemi distribuiti che insieme contribuiscono al raggiungimento di un certo obiettivo. Abbiamo ignorato questo fatto per decenni, cercando di ottenere l'integrazione, trasferendo file tramite FTP o utilizzando strumenti di integrazione aziendale, concentrandoci però sui nostri obiettivi isolati. Ma con l'arrivo dei servizi, tutto è cambiato. I servizi ci hanno aiutato a guardare oltre l'orizzonte e a vedere un mondo di programmi interdipendenti che lavorano insieme. Tuttavia, per operare con successo, è necessario riconoscere e progettare due mondi fondamentalmente diversi: il mondo esterno, dove viviamo in un ecosistema di molti altri servizi, e il nostro mondo personale, dove regniamo da soli.
Questo mondo distribuito è diverso da quello in cui siamo cresciuti e a cui siamo abituati. I principi della tradizionale architettura monolitica non reggono alcuna critica. Quindi, comprendere correttamente questi sistemi significa fare qualcosa di più che creare uno schema interessante su una lavagna bianca o una bella prova di concetto. Si tratta di far funzionare con successo un sistema per un lungo periodo. Fortunatamente, i servizi esistono da un bel po' di tempo, anche se appaiono in modi diversi. sono ancora rilevanti, anche aggiunte a Docker, Kubernetes e leggermente sfregiate da barbe hipster.
Quindi, oggi esamineremo come sono cambiate le regole, perché è necessario ripensare il nostro approccio ai servizi e ai dati che si scambiano e perché abbiamo bisogno di strumenti completamente diversi.
L'incapsulamento non sarà sempre dalla tua parte
I microservizi possono operare in modo indipendente l'uno dall'altro. Questa caratteristica conferisce loro il massimo valore. Questo stesso aspetto consente ai servizi di scalare e crescere. Non tanto in termini di scalabilità fino a quadrilioni di utenti o petabyte di dati (sebbene possano aiutare anche in questo), quanto in termini di scalabilità dal punto di vista delle persone, poiché team e organizzazioni crescono continuamente.
Tuttavia, l'indipendenza è un'arma a doppio taglio. Cioè, un servizio può funzionare facilmente da solo. Ma se all'interno del servizio viene implementata una funzione che richiede l'utilizzo di un altro servizio, alla fine ci troviamo a dover apportare modifiche a entrambi i servizi quasi simultaneamente. In un monolite è facile, basta apportare la modifica e rilasciarla, ma nel caso della sincronizzazione di servizi indipendenti ci saranno più problemi. Il coordinamento tra team e cicli di rilascio compromette la flessibilità.
Nel contesto del nostro approccio standard, ci sforziamo di evitare cambiamenti intrusivi, separando nettamente le funzioni tra i servizi. Un buon esempio di questo è un servizio di accesso unificato. Ha un ruolo ben definito che lo distingue dagli altri servizi. Questa chiara separazione significa che, in un mondo in rapida evoluzione delle esigenze dei servizi circostanti, il servizio di accesso unificato difficilmente cambierà. Esiste all'interno di un contesto rigorosamente limitato.
Il problema è che nel mondo reale i servizi aziendali non possono mantenere costantemente una separazione netta dei ruoli. Ad esempio, gli stessi servizi aziendali tendono a lavorare maggiormente con dati provenienti da altri servizi simili. Se operi nel commercio al dettaglio online, l'elaborazione degli ordini, del catalogo dei prodotti o delle informazioni sugli utenti diventerà un'esigenza per molti dei tuoi servizi. Ogni servizio avrà bisogno di accesso a questi dati per funzionare.
La maggior parte dei servizi aziendali utilizza lo stesso flusso di dati, quindi il loro lavoro è inevitabilmente intrecciato.
Siamo dunque giunti a un momento importante di cui vale la pena parlare. Mentre i servizi funzionano bene per i componenti dell'infrastruttura che operano in gran parte in modo isolato, la maggior parte dei servizi aziendali si intrecciano in modo molto più stretto.
Dichotomia dei dati
Approcci orientati ai servizi potrebbero già esistere, ma ci sono ancora poche informazioni su come scambiare grandi volumi di dati tra i servizi.
Il problema principale è che dati e servizi sono inseparabili. Da un lato, l'incapsulamento ci invita a nascondere i dati in modo che i servizi possano essere separati l'uno dall'altro e facilitare la loro crescita e modifiche successive. Dall'altro lato, abbiamo bisogno di essere in grado di condividere liberamente e gestire i dati comuni, proprio come qualsiasi altro. Si tratta di avere la possibilità di iniziare a lavorare immediatamente, con la stessa libertà di qualsiasi altro sistema informativo.
Tuttavia, i sistemi informativi hanno poco a che fare con l'incapsulamento. In effetti, è addirittura l'opposto. I database fanno tutto il possibile per garantire l'accesso ai dati in essi conservati. Sono dotati di un potente interfaccia dichiarativa che consente di modificare i dati come necessario. Questa funzionalità è importante in fase di ricerca preliminare, ma non per gestire la crescente complessità di un servizio in continua evoluzione.
E qui sorge il dilemma. La contraddizione. La dicotomia. Infatti, i sistemi informativi riguardano la fornitura di dati, mentre i servizi riguardano la loro occultazione.
Queste due forze sono fondamentali. Sono alla base della maggior parte del nostro lavoro, in una continua lotta per il predominio nei sistemi che creiamo.
Man mano che i sistemi di servizi crescono ed evolvono, osserviamo diverse manifestazioni delle conseguenze della dicotomia dei dati. L'interfaccia del servizio potrà espandersi, offrendo un'ampia gamma di funzionalità, e iniziare a somigliare a un database artigianale molto strano, oppure potremmo rimanere delusi e implementare qualche metodo per estrarre o spostare interi set di dati da un servizio all'altro.
La creazione di qualcosa che assomiglia a un database artigianale comporterà una serie di problemi. Non entreremo nei dettagli riguardo ai rischi associati a shared database, ma possiamo dire che essa comporta significative e costose sfide ingegneristiche e operative Peggio ancora, le dimensioni dei dati amplificano i problemi relativi ai confini dei servizi. Più dati condivisi esistono all'interno del servizio, più complessa diventa l'interfaccia e più difficile risulta combinare set di dati provenienti da diversi servizi.
Peggio ancora, la quantità di dati moltiplica i problemi legati ai confini dei servizi. Più dati condivisi risiedono all'interno di un servizio, più complesso diventa l'interfaccia e più difficile sarà unire i set di dati provenienti da vari servizi.
Un approccio alternativo per l'estrazione e lo spostamento di interi set di dati presenta anch'esso delle problematiche. Un modo comune per affrontare questa questione consiste nell'estrarre e memorizzare un set di dati intero, per poi conservarlo localmente in ciascun servizio consumatore.
Il problema è che i diversi servizi interpretano i dati che consumano in modi diversi. Questi dati sono sempre a portata di mano. Vengono modificati e elaborati localmente. Ben presto perdono ogni legame con i dati originali.
Più le copie sono mutevoli, maggiore sarà la differenza dei dati nel tempo.
Peggio ancora, tali dati sono difficili da correggere in retrospettiva ( qui può davvero tornare utile). In effetti, alcuni dei problemi tecnologici irrisolvibili con cui le aziende si confrontano derivano da dati eterogenei, che si moltiplicano da un'applicazione all'altra.
Per trovare una soluzione a questo problema sui dati condivisi, è necessario pensare in modo diverso. Devono diventare oggetti di prima classe nelle architetture che costruiamo. chiama questi dati "esterni", ed è una caratteristica molto importante. Abbiamo bisogno dell'incapsulamento per non rivelare l'architettura interna del servizio, ma dobbiamo facilitare l'accesso ai dati condivisi affinché i servizi possano eseguire correttamente il loro lavoro.
Il problema è che nessuno degli approcci attuali è più rilevante, poiché né le interfacce di servizio, né lo scambio di messaggi, né i database condivisi offrono una buona soluzione per lavorare con dati esterni. Le interfacce di servizio non si prestano bene allo scambio di dati su alcuna scala. Lo scambio di messaggi sposta i dati, ma non ne conserva la storia, quindi col passare del tempo i dati si danneggiano. I database condivisi si concentrano troppo su un singolo punto, ostacolando il progresso. Ci ritroviamo inevitabilmente intrappolati in un ciclo di inaffidabilità dei dati:
Ciclo di inaffidabilità dei dati
Flussi: un approccio decentralizzato ai dati e ai servizi
Ideale sarebbe rivedere l'approccio con cui i servizi gestiscono i dati condivisi. Attualmente, qualsiasi approccio si confronta con la dicotomia menzionata, poiché non esiste una soluzione magica che possa farla scomparire. Tuttavia, possiamo ripensare al problema e raggiungere un compromesso.
Questo compromesso implica un certo grado di centralizzazione. Possiamo sfruttare meccanismi di log distribuiti, poiché forniscono flussi scalabili e affidabili. Ora è necessario che i servizi possano connettersi e lavorare su questi flussi condivisi; tuttavia, vogliamo evitare complicati God Service centralizzati che gestiscono tale elaborazione. Pertanto, la soluzione migliore è incorporare l'elaborazione dei flussi in ogni servizio consumatore. In questo modo, i servizi possono combinare set di dati da diverse fonti e lavorarci come necessario.
Uno dei modi per adottare questo approccio è utilizzare una piattaforma di streaming. Ci sono molte opzioni, ma oggi ci concentreremo su Kafka, poiché l'uso del suo Stateful Stream Processing consente di affrontare efficacemente il problema presentato.
L'uso del meccanismo di logging distribuito ci consente di seguire un percorso consolidato e utilizzare lo scambio di messaggi per lavorare con . Si ritiene che questo approccio offra una migliore scalabilità e separazione rispetto al meccanismo "richiesta-risposta", poiché affida il controllo del flusso al destinatario invece che al mittente. Tuttavia, per tutto ciò si paga un prezzo, e avrete bisogno di un broker. Ma per sistemi di grandi dimensioni, questo compromesso vale la pena (cosa che non si può dire delle vostre applicazioni web medie).
Se la registrazione distribuita è gestita da un broker invece che da un tradizionale sistema di messaggistica, è possibile sfruttare caratteristiche aggiuntive. Il trasporto può essere scalato linearmente quasi altrettanto bene quanto un sistema di archiviazione distribuito. I dati possono essere memorizzati nei log per un lungo periodo, quindi otteniamo non solo uno scambio di messaggi, ma anche uno storage di informazioni. Uno storage scalabile senza il timore di ottenere uno stato condiviso modificabile.
Si può quindi utilizzare il meccanismo di stateful stream processing per aggiungere strumenti dichiarativi del database ai servizi consumatori. Questa è un'idea molto importante. Finché i dati vengono memorizzati in stream condivisi accessibili a tutti i servizi, l'unione e l'elaborazione effettuate dal servizio sono private. Queste operazioni risultano isolate all'interno di un contesto rigorosamente limitato.
Elimina la dicotomia dei dati separando il flusso di stati immutabili. Quindi aggiungi questa funzione in ogni servizio utilizzando lo Stateful Stream Processing.
In questo modo, se il tuo servizio deve lavorare con ordini, cataloghi di prodotti o magazzino, avrà accesso completo: sarai tu a decidere quali dati unire, dove elaborarli e come devono cambiare nel tempo. Anche se i dati sono condivisi, il loro utilizzo è completamente decentralizzato. Viene gestito all'interno di ogni servizio, in un mondo in cui tutto segue le tue regole.
Condividi i dati in modo da non comprometterne l'integrità. Incapsula la funzione, non la fonte, in ogni servizio che ne ha bisogno.
A volte, è necessario spostare grandi quantità di dati. Talvolta un servizio richiede un set di dati storici locale in un determinato motore di database. Il punto è che si può garantire che, se necessario, una copia può essere ripristinata dalla fonte tramite l'accesso al meccanismo di registrazione distribuita. I connettori in Kafka gestiscono egregiamente questo compito.
Quindi, l'approccio discusso oggi presenta diversi vantaggi:
- I dati vengono utilizzati come flussi condivisi, che possono essere a lungo memorizzati nei log, e il meccanismo di gestione dei dati condivisi è incorporato in ciascun contesto, consentendo ai servizi di operare in modo semplice e rapido. In questo modo è possibile bilanciare la dicotomia dei dati.
- I dati provenienti da vari servizi possono essere facilmente uniti in set. Così si semplifica l'interazione con i dati condivisi ed elimina la necessità di mantenere set di dati locali nel database.
- Il Stateful Stream Processing cache solo i dati, mentre la fonte di verità rimane nei log condivisi, quindi il problema della corruzione dei dati nel tempo è meno pressante.
- Essenzialmente, i servizi sono gestiti dai dati, il che significa che, nonostante la continua crescita dei volumi di dati, i servizi possono ancora rispondere rapidamente agli eventi aziendali.
- I problemi di scalabilità ricadono sul broker, non sui servizi. Questo riduce significativamente la complessità nella scrittura dei servizi, poiché non c'è necessità di preoccuparsi della scalabilità.
- L'aggiunta di nuovi servizi non richiede modifiche ai vecchi, rendendo più semplice l'integrazione di nuove soluzioni.
Come potete vedere, questo va oltre il semplice REST. Abbiamo a disposizione un insieme di strumenti che permette di lavorare con dati condivisi in modo decentralizzato.
Nell'articolo di oggi non sono stati trattati tutti gli aspetti. Dobbiamo ancora capire come bilanciare tra il paradigma "richiesta-risposta" e il paradigma orientato agli eventi. Ma ne parleremo la prossima volta. Ci sono argomenti su cui dobbiamo approfondire meglio, come la grande utilità della Stateful Stream Processing. Di questo parleremo nel terzo articolo. Inoltre, ci sono altre potenti costruzioni che possiamo sfruttare, se decidiamo di utilizzarle, come . Con questa costruzione cambiamo le regole del gioco per i sistemi aziendali distribuiti, poiché offre garanzie transazionali per in maniera scalabile. Di questo ci occuperemo nel quarto articolo. Infine, dovremo esaminare i dettagli dell'implementazione di questi principi.
Ma per ora ricordate semplicemente questo: la dicotomia dei dati è la forza che affrontiamo nella creazione di servizi aziendali. E dobbiamo tenerne conto. L'obiettivo è capovolgere tutto e iniziare a considerare i dati comuni come oggetti di prima classe. La Stateful Stream Processing offre un compromesso unico a questo proposito. Essa evita componenti centralizzati "God Component" che ostacolano lo sviluppo e il progresso. Inoltre, garantisce rapidità, scalabilità e resilienza nei pipeline di streaming dei dati, integrandoli in ogni servizio. Così possiamo concentrarci sul flusso comune di coscienza, al quale può connettersi qualsiasi servizio e lavorare con i suoi dati. Di conseguenza, i servizi diventano più scalabili, intercambiabili e autonomi. Pertanto, non solo appariranno bene nelle board e nei test di ipotesi, ma funzioneranno e si svilupperanno per decenni.
Fonte: habr.com
