{"id":83248,"date":"2020-05-29T19:42:48","date_gmt":"2020-05-29T17:42:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam"},"modified":"2020-05-29T19:42:48","modified_gmt":"2020-05-29T17:42:48","slug":"dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam","title":{"rendered":"Dichotomia dei dati: ripensare il rapporto con i dati e i servizi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao a tutti! Abbiamo ottime notizie, a giugno OTUS lancia di nuovo il corso \u00abArchitetto Software\u00bb<\/a><\/noindex>, per cui come di consueto condividiamo con voi materiale utile.<\/b><\/i><\/p>\n

\"Dichotomia
\n
\n Se vi siete imbattuti in questa storia sui microservizi senza alcun contesto, \u00e8 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. <\/p>\n

Sebbene questo approccio comporti la suddivisione in numerosi servizi indipendenti, l'obiettivo finale \u00e8 molto pi\u00f9 grande della semplice operativit\u00e0 di questi servizi su macchine diverse. Qui si parla dell'interazione con un mondo circostante che \u00e8 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.<\/a><\/noindex><\/p>\n

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\u00f2 sui nostri obiettivi isolati. Ma con l'arrivo dei servizi, tutto \u00e8 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, \u00e8 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.<\/p>\n

\"Dichotomia
\n
\n Questo mondo distribuito \u00e8 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\u00f9 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. Lezioni di SOA<\/a><\/noindex> sono ancora rilevanti, anche aggiunte a Docker, Kubernetes e leggermente sfregiate da barbe hipster. <\/p>\n

Quindi, oggi esamineremo come sono cambiate le regole, perch\u00e9 \u00e8 necessario ripensare il nostro approccio ai servizi e ai dati che si scambiano e perch\u00e9 abbiamo bisogno di strumenti completamente diversi.<\/p>\n

L'incapsulamento non sar\u00e0 sempre dalla tua parte<\/h3>\n

\n 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\u00e0 fino a quadrilioni di utenti o petabyte di dati (sebbene possano aiutare anche in questo), quanto in termini di scalabilit\u00e0 dal punto di vista delle persone, poich\u00e9 team e organizzazioni crescono continuamente.<\/p>\n

\"Dichotomia
\n
\nTuttavia, l'indipendenza \u00e8 un'arma a doppio taglio. Cio\u00e8, un servizio pu\u00f2 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 \u00e8 facile, basta apportare la modifica e rilasciarla, ma nel caso della sincronizzazione di servizi indipendenti ci saranno pi\u00f9 problemi. Il coordinamento tra team e cicli di rilascio compromette la flessibilit\u00e0.<\/p>\n

\"Dichotomia
\n
\nNel contesto del nostro approccio standard, ci sforziamo di evitare cambiamenti intrusivi, separando nettamente le funzioni tra i servizi. Un buon esempio di questo \u00e8 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\u00e0. Esiste all'interno di un contesto rigorosamente limitato.<\/p>\n

\"Dichotomia
\n
\n Il problema \u00e8 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\u00e0 un'esigenza per molti dei tuoi servizi. Ogni servizio avr\u00e0 bisogno di accesso a questi dati per funzionare. <\/p>\n

\"Dichotomia
\nLa maggior parte dei servizi aziendali utilizza lo stesso flusso di dati, quindi il loro lavoro \u00e8 inevitabilmente intrecciato.<\/i><\/p>\n

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\u00f9 stretto.<\/p>\n

Dichotomia dei dati<\/h3>\n

\n Approcci orientati ai servizi potrebbero gi\u00e0 esistere, ma ci sono ancora poche informazioni su come scambiare grandi volumi di dati tra i servizi.<\/p>\n

Il problema principale \u00e8 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\u00e0 di iniziare a lavorare immediatamente, con la stessa libert\u00e0 di qualsiasi altro sistema informativo.<\/p>\n

Tuttavia, i sistemi informativi hanno poco a che fare con l'incapsulamento. In effetti, \u00e8 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\u00e0 \u00e8 importante in fase di ricerca preliminare, ma non per gestire la crescente complessit\u00e0 di un servizio in continua evoluzione.<\/p>\n

\"Dichotomia
\n
\n 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.<\/p>\n

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.<\/p>\n

Man mano che i sistemi di servizi crescono ed evolvono, osserviamo diverse manifestazioni delle conseguenze della dicotomia dei dati. L'interfaccia del servizio potr\u00e0 espandersi, offrendo un'ampia gamma di funzionalit\u00e0, 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.<\/p>\n

\"Dichotomia
\n
\n La creazione di qualcosa che assomiglia a un database artigianale comporter\u00e0 una serie di problemi. Non entreremo nei dettagli riguardo ai rischi associati a shared database<\/i>, ma possiamo dire che essa comporta significative e costose sfide ingegneristiche e operative per l'azienda che cerca di utilizzarla.<\/a><\/noindex> Peggio ancora, le dimensioni dei dati amplificano i problemi relativi ai confini dei servizi. Pi\u00f9 dati condivisi esistono all'interno del servizio, pi\u00f9 complessa diventa l'interfaccia e pi\u00f9 difficile risulta combinare set di dati provenienti da diversi servizi.<\/p>\n

Peggio ancora, la quantit\u00e0 di dati moltiplica i problemi legati ai confini dei servizi. Pi\u00f9 dati condivisi risiedono all'interno di un servizio, pi\u00f9 complesso diventa l'interfaccia e pi\u00f9 difficile sar\u00e0 unire i set di dati provenienti da vari servizi.<\/p>\n

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.<\/p>\n

\"Dichotomia
\n
\n Il problema \u00e8 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.<\/p>\n

\"Dichotomia
\n Pi\u00f9 le copie sono mutevoli, maggiore sar\u00e0 la differenza dei dati nel tempo.<\/i><\/p>\n

Peggio ancora, tali dati sono difficili da correggere in retrospettiva (MDM<\/a><\/noindex> qui pu\u00f2 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.<\/p>\n

Per trovare una soluzione a questo problema sui dati condivisi, \u00e8 necessario pensare in modo diverso. Devono diventare oggetti di prima classe nelle architetture che costruiamo. Pat Heland<\/a><\/noindex> chiama questi dati \"esterni\", ed \u00e8 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\u00e9 i servizi possano eseguire correttamente il loro lavoro.<\/p>\n

\"Dichotomia
\n
\n Il problema \u00e8 che nessuno degli approcci attuali \u00e8 pi\u00f9 rilevante, poich\u00e9 n\u00e9 le interfacce di servizio, n\u00e9 lo scambio di messaggi, n\u00e9 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\u00e0 dei dati:<\/p>\n

\"Dichotomia
\n Ciclo di inaffidabilit\u00e0 dei dati<\/i><\/p>\n

Flussi: un approccio decentralizzato ai dati e ai servizi<\/h3>\n

\n Ideale sarebbe rivedere l'approccio con cui i servizi gestiscono i dati condivisi. Attualmente, qualsiasi approccio si confronta con la dicotomia menzionata, poich\u00e9 non esiste una soluzione magica che possa farla scomparire. Tuttavia, possiamo ripensare al problema e raggiungere un compromesso.<\/p>\n

Questo compromesso implica un certo grado di centralizzazione. Possiamo sfruttare meccanismi di log distribuiti, poich\u00e9 forniscono flussi scalabili e affidabili. Ora \u00e8 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 \u00e8 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.<\/p>\n

Uno dei modi per adottare questo approccio \u00e8 utilizzare una piattaforma di streaming. Ci sono molte opzioni, ma oggi ci concentreremo su Kafka, poich\u00e9 l'uso del suo Stateful Stream Processing consente di affrontare efficacemente il problema presentato.<\/p>\n

\"Dichotomia
\n
\n L'uso del meccanismo di logging distribuito ci consente di seguire un percorso consolidato e utilizzare lo scambio di messaggi per lavorare con un'architettura orientata agli eventi<\/a><\/noindex>. Si ritiene che questo approccio offra una migliore scalabilit\u00e0 e separazione rispetto al meccanismo \"richiesta-risposta\", poich\u00e9 affida il controllo del flusso al destinatario invece che al mittente. Tuttavia, per tutto ci\u00f2 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\u00f2 dire delle vostre applicazioni web medie).<\/p>\n

Se la registrazione distribuita \u00e8 gestita da un broker invece che da un tradizionale sistema di messaggistica, \u00e8 possibile sfruttare caratteristiche aggiuntive. Il trasporto pu\u00f2 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.<\/p>\n

Si pu\u00f2 quindi utilizzare il meccanismo di stateful stream processing per aggiungere strumenti dichiarativi del database ai servizi consumatori. Questa \u00e8 un'idea molto importante. Finch\u00e9 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.<\/p>\n

\"Dichotomia
\n Elimina la dicotomia dei dati separando il flusso di stati immutabili. Quindi aggiungi questa funzione in ogni servizio utilizzando lo Stateful Stream Processing.<\/i><\/p>\n

In questo modo, se il tuo servizio deve lavorare con ordini, cataloghi di prodotti o magazzino, avr\u00e0 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 \u00e8 completamente decentralizzato. Viene gestito all'interno di ogni servizio, in un mondo in cui tutto segue le tue regole.<\/p>\n

\"Dichotomia
\nCondividi i dati in modo da non comprometterne l'integrit\u00e0. Incapsula la funzione, non la fonte, in ogni servizio che ne ha bisogno.<\/i><\/p>\n

A volte, \u00e8 necessario spostare grandi quantit\u00e0 di dati. Talvolta un servizio richiede un set di dati storici locale in un determinato motore di database. Il punto \u00e8 che si pu\u00f2 garantire che, se necessario, una copia pu\u00f2 essere ripristinata dalla fonte tramite l'accesso al meccanismo di registrazione distribuita. I connettori in Kafka gestiscono egregiamente questo compito.<\/p>\n

Quindi, l'approccio discusso oggi presenta diversi vantaggi:<\/p>\n