Hola a tots! Tenim una gran notícia, OTUS torna a posar en marxa el curs al juny , en relació amb el qual tradicionalment compartim material útil amb vostè.
Si us heu trobat amb tot això dels microserveis sense cap context, us perdonarien que penseu que és una mica estrany. Dividir una aplicació en fragments connectats per una xarxa significa necessàriament afegir modes de tolerància a errors complexos al sistema distribuït resultant.
Tot i que aquest enfocament implica desglossar-lo en molts serveis independents, l'objectiu final és molt més que tenir aquests serveis executats en màquines diferents. Estem parlant aquí de la interacció amb el món exterior, que també es distribueix en la seva essència. No en el sentit tècnic, sinó en el sentit d'un ecosistema format per moltes persones, equips, programes i cadascuna d'aquestes parts d'alguna manera ha de fer la seva feina.
Les empreses, per exemple, són una col·lecció de sistemes distribuïts que col·lectivament contribueixen a l'assoliment d'algun objectiu. Hem ignorat aquest fet durant dècades, intentant aconseguir la unificació mitjançant fitxers FTP o utilitzant eines d'integració empresarial mentre ens centrem en els nostres propis objectius aïllats. Però amb l'arribada dels serveis, tot va canviar. Els serveis ens han ajudat a mirar més enllà de l'horitzó i a veure un món de programes interdependents que funcionen junts. Tanmateix, per treballar amb èxit, cal reconèixer i dissenyar dos mons fonamentalment diferents: el món extern, on vivim en un ecosistema de molts altres serveis, i el nostre món personal, intern, on governem sols.
Aquest món distribuït és diferent del que hem crescut i al qual estem acostumats. Els principis de construcció de l'arquitectura monolítica tradicional no resisteixen les crítiques. Per tant, encertar aquests sistemes és més que crear un diagrama de pissarra o una prova de concepte fantàstica. La qüestió és garantir que aquest sistema funcioni amb èxit durant un llarg període de temps. Afortunadament, els serveis ja fa temps que existeixen, tot i que semblen diferents. segueixen sent rellevants, fins i tot assaonades amb Docker, Kubernetes i barbes hipster una mica cutre.
Així doncs, avui veurem com han canviat les regles, per què hem de repensar la manera com ens apropem als serveis i les dades que es transmeten entre ells i per què necessitarem eines completament diferents per fer-ho.
L'encapsulació no sempre serà el teu amic
Els microserveis poden funcionar de manera independent els uns dels altres. És aquesta propietat la que els dóna el major valor. Aquesta mateixa propietat permet als serveis escalar i créixer. No tant en el sentit d'escalar a quadrilions d'usuaris o petabytes de dades (tot i que també hi poden ajudar), sinó en el sentit d'escalar en termes de persones a mesura que els equips i les organitzacions creixen contínuament.
Tanmateix, la independència és una arma de doble tall. És a dir, el servei en si pot funcionar de manera fàcil i natural. Però si una funció s'implementa dins d'un servei que requereix utilitzar un altre servei, acabem havent de fer canvis a tots dos serveis gairebé simultàniament. En un monòlit això és fàcil de fer, només cal fer un canvi i enviar-lo al llançament, però en el cas de sincronitzar serveis independents hi haurà més problemes. La coordinació entre equips i cicles de llançament destrueix l'agilitat.
Com a part de l'enfocament estàndard, simplement intenten evitar els molestos canvis d'extrem a extrem, dividint clarament la funcionalitat entre serveis. El servei d'inici de sessió únic pot ser un bon exemple aquí. Té un paper clarament definit que el diferencia d'altres serveis. Aquesta clara separació significa que en un món de demandes que canvien ràpidament dels serveis que l'envolten, és poc probable que canviï el servei d'inici de sessió únic. Existeix en un context estrictament limitat.
El problema és que en el món real, els serveis empresarials no poden mantenir la mateixa pura separació de rols tot el temps. Per exemple, els mateixos serveis empresarials funcionen en major mesura amb dades procedents d'altres serveis similars. Si participeu en la venda al detall en línia, el processament del flux de comandes, el catàleg de productes o la informació dels usuaris es convertirà en un requisit per a molts dels vostres serveis. Cadascun dels serveis necessitarà accedir a aquestes dades per funcionar.
La majoria de serveis empresarials comparteixen el mateix flux de dades, de manera que el seu treball està invariablement entrellaçat.
Així arribem a un punt important del qual val la pena parlar. Tot i que els serveis funcionen bé per als components d'infraestructura que operen en gran part de manera aïllada, la majoria de serveis empresarials acaben entrellaçant-se molt més estretament.
Dicotomia de dades
Potser ja existeixen enfocaments orientats als serveis, però encara no tenen coneixements sobre com compartir grans quantitats de dades entre serveis.
El principal problema és que les dades i els serveis són inseparables. D'una banda, l'encapsulació ens anima a amagar les dades perquè els serveis es puguin separar els uns dels altres i facilitar-ne el creixement i els canvis posteriors. D'altra banda, hem de poder dividir i conquerir lliurement les dades compartides, com qualsevol altra dada. La qüestió és poder començar a treballar immediatament, amb la mateixa llibertat que en qualsevol altre sistema d'informació.
Tanmateix, els sistemes d'informació tenen poc a veure amb l'encapsulació. De fet, és tot el contrari. Les bases de dades fan tot el possible per proporcionar accés a les dades que emmagatzemen. Venen amb una potent interfície declarativa que us permet modificar les dades segons les vostres necessitats. Aquesta funcionalitat és important en l'etapa d'investigació preliminar, però no per gestionar la complexitat creixent d'un servei en constant evolució.
I aquí sorgeix un dilema. Contradicció. Dicotomia. Al cap i a la fi, els sistemes d'informació es refereixen a proporcionar dades i els serveis són a amagar-se.
Aquestes dues forces són fonamentals. Ells sustenten gran part del nostre treball, lluitant constantment per l'excel·lència en els sistemes que construïm.
A mesura que els sistemes de serveis creixen i evolucionen, veiem les conseqüències de la dicotomia de dades de moltes maneres. O la interfície del servei creixerà, proporcionant una gamma cada vegada més gran de funcionalitats i començarà a semblar una base de dades pròpia molt elegant, o ens frustrarem i implementarem alguna manera de recuperar o moure en massa conjunts sencers de dades d'un servei a un altre.
Al seu torn, la creació d'alguna cosa que sembli una base de dades pròpia de luxe comportarà tota una sèrie de problemes. No entrarem en detalls sobre per què és perillós base de dades compartida, diguem que representa una enginyeria i una operativa costoses importants per a l'empresa que està intentant utilitzar-lo.
El pitjor és que els volums de dades augmenten els problemes dels límits del servei. Com més dades es comparteixin dins d'un servei, més complexa serà la interfície i més difícil serà combinar conjunts de dades procedents de diferents serveis.
L'enfocament alternatiu d'extreure i moure conjunts de dades sencers també té els seus problemes. Un enfocament comú d'aquesta pregunta sembla simplement recuperar i emmagatzemar tot el conjunt de dades, i després emmagatzemar-lo localment a cada servei consumidor.
El problema és que diferents serveis interpreten les dades que consumeixen de manera diferent. Aquestes dades sempre estan a mà. Es modifiquen i es processen localment. Molt ràpidament deixen de tenir res en comú amb les dades de la font.
Com més mutables siguin les còpies, més variaran les dades al llarg del temps.
Per empitjorar les coses, aquestes dades són difícils de corregir en retrospectiva ( Aquí és on realment pot venir al rescat). De fet, alguns dels problemes tecnològics insolubles als quals s'enfronten les empreses sorgeixen de les dades dispars que es multipliquen d'aplicació a aplicació.
Per trobar una solució a aquest problema, hem de pensar de manera diferent sobre les dades compartides. Han de convertir-se en objectes de primera classe en les arquitectures que construïm. anomena aquestes dades "externes", i aquesta és una característica molt important. Necessitem l'encapsulació per no exposar el funcionament intern d'un servei, però hem de facilitar que els serveis accedeixin a les dades compartides perquè puguin fer la seva feina correctament.
El problema és que cap enfocament és rellevant avui dia, ja que ni les interfícies de servei, ni la missatgeria, ni la Base de dades compartida ofereixen una bona solució per treballar amb dades externes. Les interfícies de servei són poc adequades per a l'intercanvi de dades a qualsevol escala. La missatgeria mou les dades però no emmagatzema el seu historial, de manera que les dades es corrompeixen amb el temps. Les bases de dades compartides se centren massa en un punt, cosa que frena el progrés. Inevitablement ens quedem atrapats en un cicle de fallades de dades:
Cicle de fallada de dades
Streams: un enfocament descentralitzat de dades i serveis
L'ideal seria canviar la manera com funcionen els serveis amb dades compartides. En aquest punt, qualsevol enfocament s'enfronta a la dicotomia esmentada, ja que no hi ha pols màgic que s'hi pugui ruixar per fer-lo desaparèixer. Tanmateix, podem repensar el problema i arribar a un compromís.
Aquest compromís implica un cert grau de centralització. Podem utilitzar el mecanisme de registre distribuït perquè proporciona fluxos fiables i escalables. Ara volem que els serveis puguin unir-se i operar en aquests fils compartits, però volem evitar els serveis centrals complexos de God que facin aquest processament. Per tant, la millor opció és incorporar el processament de flux a cada servei de consum. D'aquesta manera, els serveis podran combinar conjunts de dades de diferents fonts i treballar amb ells de la manera que necessitin.
Una manera d'aconseguir aquest enfocament és mitjançant l'ús d'una plataforma de streaming. Hi ha moltes opcions, però avui mirarem Kafka, ja que l'ús del seu Stateful Stream Processing ens permet resoldre eficaçment el problema presentat.
L'ús d'un mecanisme de registre distribuït ens permet seguir el camí ben fressat i utilitzar la missatgeria per treballar-hi . Es considera que aquest enfocament proporciona un millor escalat i partició que el mecanisme de sol·licitud-resposta perquè dóna control del flux al receptor en lloc de l'emissor. No obstant això, per tot en aquesta vida has de pagar, i aquí necessites un corredor. Però per a sistemes grans, la compensació val la pena (cosa que pot no ser el cas de la vostra aplicació web mitjana).
Si un corredor és responsable del registre distribuït en lloc d'un sistema de missatgeria tradicional, podeu aprofitar les funcions addicionals. El transport pot escalar linealment gairebé tan bé com un sistema de fitxers distribuït. Les dades es poden emmagatzemar als registres durant força temps, de manera que no només obtenim l'intercanvi de missatges, sinó també l'emmagatzematge d'informació. Emmagatzematge escalable sense por a l'estat compartit mutable.
A continuació, podeu utilitzar el processament de flux amb estat per afegir eines de base de dades declaratives als serveis consumidors. Aquesta és una idea molt important. Tot i que les dades s'emmagatzemen en fluxos compartits als quals poden accedir tots els serveis, l'agregació i el processament que fa el servei són privats. Es troben aïllats en un context estrictament limitat.
Elimineu la dicotomia de dades separant el flux d'estat immutable. A continuació, afegiu aquesta funcionalitat a tots els serveis mitjançant Stateful Stream Processing.
Així, si el teu servei necessita treballar amb comandes, un catàleg de productes, un magatzem, tindrà accés total: només tu decidiràs quines dades combinar, on tractar-les i com han de canviar amb el temps. Tot i que les dades es comparteixen, el treball amb elles està completament descentralitzat. Es produeix dins de cada servei, en un món on tot va segons les teves normes.
Comparteix dades sense comprometre la seva integritat. Encapsular la funció, no la font, en tots els serveis que ho necessitin.
Passa que les dades s'han de moure massivament. De vegades, un servei requereix un conjunt de dades històriques locals al motor de base de dades seleccionat. El truc és que podeu garantir que, si cal, es pot restaurar una còpia des de la font accedint al mecanisme de registre distribuït. Els connectors de Kafka fan una gran feina.
Per tant, l'enfocament que s'ha comentat avui té diversos avantatges:
- Les dades s'utilitzen en forma de fluxos comuns, que es poden emmagatzemar en registres durant molt de temps, i el mecanisme per treballar amb dades comunes està configurat en cada context individual, cosa que permet que els serveis funcionin de manera fàcil i ràpida. D'aquesta manera, es pot equilibrar la dicotomia de les dades.
- Les dades procedents de diferents serveis es poden combinar fàcilment en conjunts. Això simplifica la interacció amb les dades compartides i elimina la necessitat de mantenir conjunts de dades locals a la base de dades.
- El processament de flux amb estat només emmagatzema les dades a la memòria cau i la font de la veritat segueixen sent els registres generals, de manera que el problema de la corrupció de dades al llarg del temps no és tan agut.
- En el seu nucli, els serveis es basen en dades, és a dir, malgrat els volums de dades cada cop més creixents, els serveis encara poden respondre ràpidament als esdeveniments empresarials.
- Els problemes d'escalabilitat cauen en el corredor, no en els serveis. Això redueix significativament la complexitat dels serveis d'escriptura, ja que no cal pensar en l'escalabilitat.
- Afegir nous serveis no requereix canviar els antics, de manera que connectar nous serveis es fa més fàcil.
Com podeu veure, això és més que REST. Hem rebut un conjunt d'eines que us permeten treballar amb dades compartides de manera descentralitzada.
No tots els aspectes s'han tractat a l'article d'avui. Encara hem d'esbrinar com equilibrar el paradigma petició-resposta i el paradigma impulsat per esdeveniments. Però ens ocuparem d'això la propera vegada. Hi ha temes que necessiteu conèixer millor, per exemple, per què el processament de flux amb estat és tan bo. En parlarem al tercer article. I hi ha altres construccions potents que podem aprofitar si hi recorrem, per exemple, . És un canvi de joc per als sistemes comercials distribuïts perquè ofereix garanties transaccionals en forma escalable. Això es parlarà al quart article. Finalment, haurem de revisar els detalls d'aplicació d'aquests principis.
Però de moment, només recordeu això: la dicotomia de dades és una força a la qual ens enfrontem a l'hora de crear serveis empresarials. I això ho hem de recordar. El truc és capgirar-ho tot i començar a tractar les dades compartides com a objectes de primera classe. El processament de flux amb estat ofereix un compromís únic per a això. Evita els "components de Déu" centralitzats que frenen el progrés. A més, garanteix l'agilitat, l'escalabilitat i la resistència de les canalitzacions de transmissió de dades i les afegeix a tots els serveis. Per tant, podem centrar-nos en el corrent general de consciència al qual qualsevol servei es pot connectar i treballar amb les seves dades. Això fa que els serveis siguin més escalables, intercanviables i autònoms. Així que no només quedaran bé a les pissarres blanques i a les proves d'hipòtesis, sinó que també funcionaran i evolucionaran durant dècades.
Font: www.habr.com