{"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 riporta il corso \u00abArchitetto Software\u00bb<\/a><\/noindex>, per cui tradizionalmente condividiamo con voi materiale utile.<\/b><\/i><\/p>\n

\"Dichotomia
\n
\n Se ti sei trovato di fronte a tutta questa storia dei microservizi senza alcun contesto, \u00e8 comprensibile considerarla un po' strana. Suddividere un'applicazione in frammenti connessi tramite rete implica necessariamente l'aggiunta di modalit\u00e0 complesse di resilienza ai guasti nel sistema distribuito risultante. <\/p>\n

Nonostante questo approccio preveda la suddivisione in molteplici servizi indipendenti, l'obiettivo finale \u00e8 molto pi\u00f9 grande della semplice operativit\u00e0 di questi servizi su macchine diverse. Qui si parla di interazione con l'ambiente circostante, che per sua natura \u00e8 anch'esso distribuito. Non in un senso tecnico, ma piuttosto in termini di ecosistema, composto da molte persone, team, programmi, e ognuna di queste parti deve in qualche modo svolgere il proprio lavoro.<\/a><\/noindex><\/p>\n

Le aziende, ad esempio, rappresentano un insieme di sistemi distribuiti che insieme contribuiscono al raggiungimento di un determinato obiettivo. Abbiamo ignorato questo fatto per decenni, cercando di ottenere un'unificazione, trasferendo file tramite FTP o utilizzando strumenti di integrazione aziendale, concentrandoci sulle nostre singole ambizioni isolate. 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 lavorare con successo, \u00e8 necessario riconoscere e progettare due mondi fondamentalmente diversi: il mondo esterno, in cui viviamo in un ecosistema di molti altri servizi, e il nostro mondo personale, interno, 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 di costruzione dell'architettura monolitica tradizionale non reggono a nessuna critica. Pertanto, una corretta comprensione di tali sistemi \u00e8 qualcosa di pi\u00f9 che creare un bel diagramma su una lavagna bianca o una fantastica prova di concetto. Si tratta di garantire che un tale sistema funzioni con successo nel lungo periodo. Fortunatamente, i servizi esistono da abbastanza tempo, anche se si presentano in forme diverse. Lezioni di SOA<\/a><\/noindex> sono ancora rilevanti, anche se conditi da Docker, Kubernetes e leggermente trasandati da barbe hipster. <\/p>\n

Quindi, oggi daremo un'occhiata a come sono cambiate le regole, perch\u00e9 dobbiamo ripensare il nostro approccio ai servizi e ai dati che si scambiano e perch\u00e9 avremo bisogno di un set di strumenti completamente diverso.<\/p>\n

L'incapsulamento non sar\u00e0 sempre un tuo amico<\/h3>\n

\n I microservizi possono funzionare in modo indipendente l'uno dall'altro. Questa caratteristica \u00e8 ci\u00f2 che conferisce loro il maggior valore. Questa stessa caratteristica consente ai servizi di scalare e crescere. Non tanto in termini di scalabilit\u00e0 fino a quadrilioni di utenti o petabyte di dati (anche se possono aiutare in questo), quanto in termini di scalabilit\u00e0 dal punto di vista umano, poich\u00e9 team e organizzazioni crescono continuamente.<\/p>\n

\"Dichotomia
\n
\nTuttavia, l'indipendenza \u00e8 una lama a doppio taglio. Il che significa che un servizio pu\u00f2 funzionare facilmente e senza stress. Ma se all'interno di un servizio viene implementata una funzione che richiede l'utilizzo di un altro servizio, alla fine dobbiamo apportare modifiche a entrambi i servizi quasi simultaneamente. In un monolite, \u00e8 facile farlo, basta apportare la modifica e inviarla in produzione, ma nel caso della sincronizzazione di servizi indipendenti ci saranno pi\u00f9 problemi. Il coordinamento tra team e cicli di rilascio distrugge la flessibilit\u00e0.<\/p>\n

\"Dichotomia
\n
\nNel contesto dell'approccio standard, si cerca semplicemente di evitare cambiamenti problematici, suddividendo chiaramente le funzionalit\u00e0 tra i servizi. Un servizio di ingresso unico nel sistema pu\u00f2 essere un buon esempio qui. Ha un ruolo ben definito che lo differenzia dagli altri servizi. Tale chiara suddivisione significa che, in un mondo di requisiti in rapida evoluzione per i servizi circostanti, il servizio di ingresso unico nel sistema difficilmente cambier\u00e0. Esiste all'interno di un contesto rigidamente limitato.<\/p>\n

\"Dichotomia
\n
\n Il problema \u00e8 che nel mondo reale i servizi aziendali non possono mantenere una separazione netta dei ruoli. Ad esempio, gli stessi servizi aziendali spesso lavorano con dati provenienti da altri servizi simili. Se ti occupi di vendita al dettaglio online, l'elaborazione del flusso degli ordini, del catalogo dei prodotti o delle informazioni sugli utenti diventa una necessit\u00e0 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 funzionamento \u00e8 inestricabilmente intrecciato.<\/i><\/p>\n

Cos\u00ec siamo giunti a un punto importante di cui vale la pena parlare. Mentre i servizi funzionano bene per componenti dell'infrastruttura che operano in gran parte in modo isolato, la maggior parte dei servizi aziendali risulta essere molto pi\u00f9 interconnessa.<\/p>\n

Dichotomia dei dati<\/h3>\n

\n Forse esistono gi\u00e0 approcci orientati ai servizi, ma c'\u00e8 ancora poca informazione 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 le future modifiche. D'altra parte, abbiamo bisogno di poter condividere e gestire liberamente i dati comuni, come qualsiasi altro dato. Si tratta di avere la possibilit\u00e0 di iniziare a lavorare immediatamente, altrettanto liberamente che in qualsiasi altro sistema informativo.<\/p>\n

Tuttavia, i sistemi informativi hanno poco a che fare con l'incapsulamento. In realt\u00e0, \u00e8 quasi l'opposto. I database fanno tutto il possibile per consentire l'accesso ai dati in essi conservati. Sono dotati di un potente interfaccia dichiarativa che ti permette di modificare i dati come desideri. Questa funzionalit\u00e0 \u00e8 importante nella fase di ricerca preliminare, ma non per la gestione della crescente complessit\u00e0 di un servizio in continua evoluzione.<\/p>\n

\"Dichotomia
\n
\n E qui sorge il dilemma. Il paradosso. La dichotomia. Infatti, i sistemi informativi riguardano la fornitura di dati, mentre i servizi riguardano la loro occultazione.<\/p>\n

Queste due forze sono fondamentali. Esse costituiscono la base della maggior parte del nostro lavoro, combattendo costantemente per il predominio nei sistemi che creiamo.<\/p>\n

Con la crescita e l'evoluzione dei sistemi di servizi, vediamo diverse manifestazioni delle conseguenze della diade dei dati. O l'interfaccia del servizio cresce, offrendo un insieme di funzioni sempre pi\u00f9 ampio e inizia a sembrare un database artigianale molto strano, oppure ci imbattiamo in una delusione e implementiamo qualche modo per estrarre o trasferire massivamente interi dataset da un servizio all'altro.<\/p>\n

\"Dichotomia
\n
\n A sua volta, la creazione di qualcosa che appare come un database artigianale porter\u00e0 a una serie di problemi. Non scenderemo nei dettagli di quanto sia pericoloso shared database<\/i>, semplicemente diremo che rappresenta significative e costose difficolt\u00e0 ingegneristiche e operative per l'azienda che cerca di utilizzarlo.<\/a><\/noindex> Peggio, i volumi di dati amplificano i problemi ai confini dei servizi. Pi\u00f9 dati condivisi ci sono all'interno del servizio, pi\u00f9 complessa diventa l'interfaccia e pi\u00f9 difficile sar\u00e0 integrare i set di dati provenienti da diversi servizi.<\/p>\n

Un approccio alternativo con estrazione e trasferimento di interi set di dati ha anch'esso i suoi problemi. L'approccio comune a questo problema appare come una semplice estrazione e archiviazione di un set di dati nella sua interezza, e poi l'archiviazione locale in ogni servizio utilizzatore.<\/p>\n

Il problema \u00e8 che diversi servizi interpretano in modo diverso i dati che consumano. Questi dati sono sempre a portata di mano. Vengono modificati e trattati in locale. Abbastanza rapidamente smettono di avere qualsiasi cosa in comune con i dati alla fonte.<\/p>\n

\"Dichotomia
\n
\n Pi\u00f9 le copie sono mutabili, pi\u00f9 i dati si discosteranno nel tempo.<\/p>\n

\"Dichotomia
\n Peggio ancora, tali dati sono difficili da correggere in retrospettiva (<\/i><\/p>\n

MDMqui pu\u00f2 davvero venirci in aiuto). In effetti, alcuni dei problemi tecnologici irrisolvibili che le aziende affrontano derivano dai dati eterogenei che si moltiplicano da un'applicazione all'altra.<\/a><\/noindex> Per trovare una soluzione a questo problema riguardo ai dati condivisi, \u00e8 necessario pensare diversamente. Devono diventare oggetti di prima classe nelle architetture che costruiamo.<\/p>\n

Pat Helland Pat Helland<\/a><\/noindex> chiamano questi dati \"esterni\", e questa \u00e8 una caratteristica molto importante. Abbiamo bisogno di incapsulamento per non rivelare la struttura interna del servizio, ma dobbiamo facilitare l'accesso dei servizi ai dati condivisi, affinch\u00e9 possano svolgere 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 il Shared Database offrono una buona soluzione per lavorare con i dati esterni. Le interfacce di servizio non sono adatte per lo 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 vengono danneggiati. I Shared Database si concentrano troppo su un singolo punto, bloccando cos\u00ec lo sviluppo del progresso. Rimanere bloccati in un ciclo di inefficacia dei dati \u00e8 inevitabile:<\/p>\n

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

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

\n Idealmente, dobbiamo cambiare l'approccio su come i servizi lavorano con i dati condivisi. Attualmente, qualsiasi approccio si scontra con la dicotomia sopra menzionata, poich\u00e9 non esiste una polvere magica che possa essere sparsa generosamente per farla scomparire. Tuttavia, possiamo ripensare al problema e giungere a un compromesso.<\/p>\n

Questo compromesso implica un certo grado di centralizzazione. Possiamo sfruttare il meccanismo dei log distribuiti, poich\u00e9 esso fornisce flussi affidabili e scalabili. Ora \u00e8 necessario che i servizi possano connettersi e lavorare con questi flussi condivisi, tuttavia vogliamo evitare complessi \"God Service\" centralizzati che svolgono tale elaborazione. Quindi, la soluzione migliore \u00e8 incorporare l'elaborazione dei flussi in ogni servizio consumatore. In questo modo, i servizi potranno unire set di dati provenienti da diverse fonti e lavorare con essi come necessario.<\/p>\n

Uno dei modi per raggiungere un approccio simile \u00e8 utilizzare una piattaforma di streaming. Ci sono molte opzioni, ma oggi ci concentreremo su Kafka, poich\u00e9 l'uso della sua Stateful Stream Processing consente di affrontare in modo efficace il problema presentato.<\/p>\n

\"Dichotomia
\n
\n L'uso del meccanismo di logging distribuito ci permette di seguire il sentiero gi\u00e0 tracciato e di utilizzare lo scambio di messaggi per lavorare con architettura orientata agli eventi<\/a><\/noindex>. Si ritiene che questo approccio consenta una migliore scalabilit\u00e0 e separazione rispetto al meccanismo \"richiesta-risposta\", poich\u00e9 restituisce il controllo del flusso al destinatario e non al mittente. Tuttavia, per ogni cosa in questa vita si deve pagare, e qui avrai bisogno di un broker. Ma per i grandi sistemi questo compromesso ne vale la pena (cosa che non si pu\u00f2 dire delle tue applicazioni web medie).<\/p>\n

Se la registrazione distribuita \u00e8 gestita da un broker e non da un tradizionale sistema di messaggistica, puoi sfruttare funzionalit\u00e0 aggiuntive. Il trasporto pu\u00f2 essere scalato linearmente quasi altrettanto bene quanto un sistema di file distribuito. I dati possono essere conservati nei log per un periodo di tempo sufficientemente lungo, quindi otteniamo non solo uno scambio di messaggi, ma anche un archivio di informazioni. Un archivio scalabile senza paura di ottenere uno stato condiviso modificabile.<\/p>\n

Successivamente, \u00e8 possibile utilizzare un meccanismo di stateful stream processing (elaborazione del flusso con stato) per aggiungere strumenti dichiarativi di database ai servizi consumatori. Questo \u00e8 un concetto molto importante. Finch\u00e9 i dati vengono conservati in flussi condivisi, a cui possono accedere tutti i servizi, la fusione e l'elaborazione effettuate dal servizio sono private. Si trovano isolate all'interno di un contesto rigorosamente limitato.<\/p>\n

\"Dichotomia
\n Elimina la dicotomia dei dati separando il flusso di stati immutabili. Poi aggiungi questa funzione a ciascun servizio tramite Stateful Stream Processing.<\/i><\/p>\n

Quindi, se il tuo servizio deve gestire ordini, catalogo prodotti e magazzino, avr\u00e0 accesso completo: sei tu a decidere quali dati unire, dove elaborarli e come dovrebbero cambiare nel tempo. Nonostante i dati siano condivisi, la gestione di essi \u00e8 completamente decentralizzata. Avviene all'interno di ciascun servizio, in un mondo in cui tutto avviene secondo le tue regole.<\/p>\n

\"Dichotomia
\nCondividi i dati in modo da non compromettere la loro integrit\u00e0. Incapsula la funzione, non la fonte, in ciascun servizio di cui ha bisogno.<\/i><\/p>\n

Capita che i dati debbano essere spostati massicciamente. A volte il servizio richiede un insieme storico locale di dati nel motore di database scelto. La questione \u00e8 che si pu\u00f2 garantire che, se necessario, una copia pu\u00f2 essere ripristinata dalla fonte tramite il meccanismo di logging distribuito. I connettori in Kafka gestiscono ottimamente questo compito.<\/p>\n

Pertanto, l'approccio esaminato oggi presenta diversi vantaggi:<\/p>\n