Ola a todos! Temos unha gran noticia, OTUS volve poñer en marcha o curso en xuño , en relación co que tradicionalmente compartimos material útil contigo.
Se atopaches todo isto dos microservizos sen ningún contexto, perdoarías que penses que é un pouco estraño. Dividir unha aplicación en fragmentos conectados por unha rede significa necesariamente engadir modos complexos de tolerancia a fallos ao sistema distribuído resultante.
Aínda que este enfoque implica dividilo en moitos servizos independentes, o obxectivo final é moito máis que ter eses servizos executados en máquinas diferentes. Falamos aquí da interacción co mundo exterior, que tamén se distribúe na súa esencia. Non no sentido técnico, senón no sentido dun ecosistema formado por moitas persoas, equipos, programas e cada unha destas partes, dalgún xeito, ten que facer o seu traballo.
As empresas, por exemplo, son unha colección de sistemas distribuídos que contribúen colectivamente á consecución dalgún obxectivo. Ignoramos este feito durante décadas, tentando lograr a unificación mediante ficheiros FTP ou utilizando ferramentas de integración empresarial mentres nos centramos nos nosos propios obxectivos illados. Pero coa chegada dos servizos, todo cambiou. Os servizos axudáronnos a mirar máis aló do horizonte e ver un mundo de programas interdependentes que funcionan xuntos. Porén, para traballar con éxito é necesario recoñecer e deseñar dous mundos fundamentalmente diferentes: o mundo externo, onde vivimos nun ecosistema de moitos outros servizos, e o noso mundo persoal, interno, onde gobernamos sós.
Este mundo distribuído é diferente ao que nos criamos e ao que estamos afeitos. Os principios de construción da arquitectura monolítica tradicional non resisten as críticas. Polo tanto, acertar estes sistemas é algo máis que crear un diagrama de encerado ou unha proba de concepto interesante. A cuestión é garantir que tal sistema funcione con éxito durante un longo período de tempo. Afortunadamente, os servizos levan bastante tempo, aínda que parecen diferentes. seguen sendo relevantes, mesmo aderezados con Docker, Kubernetes e barbas hipster lixeiramente descuidadas.
Entón, hoxe veremos como cambiaron as regras, por que temos que repensar a forma en que abordamos os servizos e os datos que se transmiten entre si e por que necesitaremos ferramentas completamente diferentes para facelo.
O encapsulamento non sempre será o teu amigo
Os microservizos poden funcionar de forma independente uns dos outros. É esta propiedade a que lles dá un maior valor. Esta mesma propiedade permite que os servizos se escalan e medren. Non tanto no sentido de escalar a cuatrillóns de usuarios ou petabytes de datos (aínda que tamén poden axudar), senón no sentido de escalar en termos de persoas a medida que os equipos e as organizacións medran continuamente.
Porén, a independencia é unha arma de dobre fío. É dicir, o servizo en si pode funcionar de forma sinxela e natural. Pero se se implementa unha función dentro dun servizo que require o uso doutro servizo, entón acabamos tendo que facer cambios en ambos servizos case simultáneamente. Nun monólito isto é doado de facer, só tes que facer un cambio e envialo ao lanzamento, pero no caso de sincronizar servizos independentes haberá máis problemas. A coordinación entre os equipos e os ciclos de lanzamento destrúe a axilidade.
Como parte do enfoque estándar, simplemente intentan evitar os molestos cambios de extremo a extremo, dividindo claramente a funcionalidade entre servizos. O servizo de inicio de sesión único pode ser un bo exemplo aquí. Ten un papel claramente definido que o diferencia doutros servizos. Esta clara separación significa que nun mundo de demandas que cambian rapidamente sobre os servizos que o rodean, é pouco probable que o servizo de inicio de sesión único cambie. Existe nun contexto estritamente limitado.
O problema é que no mundo real, os servizos empresariais non poden manter a mesma pura separación de roles todo o tempo. Por exemplo, os mesmos servizos empresariais funcionan en maior medida con datos procedentes doutros servizos similares. Se estás involucrado na venda polo miúdo en liña, o fluxo de pedidos de procesamento, o catálogo de produtos ou a información do usuario converterase nun requisito para moitos dos teus servizos. Cada un dos servizos necesitará acceso a estes datos para funcionar.
A maioría dos servizos empresariais comparten o mesmo fluxo de datos, polo que o seu traballo está invariablemente entrelazado.
Así chegamos a un punto importante do que vale a pena falar. Aínda que os servizos funcionan ben para compoñentes de infraestrutura que funcionan en gran medida de forma illada, a maioría dos servizos empresariais acaban entrelazando moito máis estreitamente.
Dicotomía de datos
É posible que xa existan enfoques orientados aos servizos, pero aínda carecen de coñecementos sobre como compartir grandes cantidades de datos entre servizos.
O principal problema é que os datos e os servizos son inseparables. Por unha banda, o encapsulamento anímanos a ocultar os datos para que os servizos poidan separarse entre si e facilitar o seu crecemento e posteriores cambios. Por outra banda, temos que ser capaces de dividir e conquistar libremente os datos compartidos, como calquera outro dato. A cuestión é poder comezar a traballar de inmediato, tan libremente como en calquera outro sistema de información.
Porén, os sistemas de información teñen pouco que ver coa encapsulación. De feito, é todo o contrario. As bases de datos fan todo o que poden para proporcionar acceso aos datos que almacenan. Veñen cunha poderosa interface declarativa que che permite modificar os datos segundo o precises. Tal funcionalidade é importante na fase de investigación preliminar, pero non para xestionar a crecente complexidade dun servizo en constante evolución.
E aquí xorde un dilema. Contradición. Dicotomía. Despois de todo, os sistemas de información tratan de proporcionar datos e os servizos son de ocultar.
Estas dúas forzas son fundamentais. Eles sustentan gran parte do noso traballo, loitando constantemente pola excelencia nos sistemas que construímos.
A medida que os sistemas de servizos crecen e evolucionan, vemos as consecuencias da dicotomía de datos de moitas maneiras. Ou a interface do servizo crecerá, proporcionando unha gama cada vez maior de funcionalidades e comezará a parecer unha base de datos propia moi elegante, ou frustraremos e implementaremos algún xeito de recuperar ou mover en masa conxuntos enteiros de datos dun servizo a outro.
Á súa vez, crear algo que pareza unha elegante base de datos propia dará lugar a unha serie de problemas. Non entraremos en detalles sobre por que é perigoso base de datos compartida, digamos que representa un custo significativo de enxeñería e operación para a empresa que está intentando utilizalo.
O peor é que os volumes de datos aumentan os problemas dos límites do servizo. Cantos máis datos se compartan dentro dun servizo, máis complexa será a interface e máis difícil será combinar conxuntos de datos procedentes de diferentes servizos.
O enfoque alternativo de extraer e mover conxuntos de datos enteiros tamén ten os seus problemas. Un enfoque común para esta pregunta parece simplemente recuperar e almacenar todo o conxunto de datos e despois almacenalo localmente en cada servizo consumidor.
O problema é que os distintos servizos interpretan de forma diferente os datos que consomen. Estes datos están sempre a man. Son modificados e procesados localmente. Moi rápido deixan de ter algo en común cos datos da fonte.
Canto máis mutables sexan as copias, máis variarán os datos ao longo do tempo.
Para empeorar as cousas, tales datos son difíciles de corrixir retrospectivamente ( Aquí é onde realmente pode vir ao rescate). De feito, algúns dos problemas tecnolóxicos insolubles aos que se enfrontan as empresas xorden dos datos dispares que se multiplican dunha aplicación en outra.
Para atopar unha solución a este problema, necesitamos pensar de forma diferente sobre os datos compartidos. Deben converterse en obxectos de primeira clase nas arquitecturas que construímos. chama a tales datos "externos", e esta é unha característica moi importante. Necesitamos encapsulamento para non expor o funcionamento interno dun servizo, pero debemos facilitar que os servizos accedan aos datos compartidos para que poidan facer o seu traballo correctamente.
O problema é que ningún dos enfoques é relevante hoxe en día, xa que nin as interfaces de servizo, nin a mensaxería, nin a Base de Datos Compartida ofrecen unha boa solución para traballar con datos externos. As interfaces de servizo son pouco adecuadas para o intercambio de datos a calquera escala. A mensaxería move os datos pero non almacena o seu historial, polo que os datos corrompen co paso do tempo. As bases de datos compartidas céntranse demasiado nun punto, o que impide o progreso. Inevitablemente quedamos atrapados nun ciclo de falla de datos:
Ciclo de falla de datos
Streams: un enfoque descentralizado de datos e servizos
O ideal é que cambiemos a forma en que funcionan os servizos cos datos compartidos. Neste punto, calquera dos enfoques enfróntase á mencionada dicotomía, xa que non hai po máxico que se poida rociar sobre el para facelo desaparecer. Non obstante, podemos repensar o problema e chegar a un compromiso.
Este compromiso implica un certo grao de centralización. Podemos utilizar o mecanismo de rexistro distribuído porque ofrece fluxos fiables e escalables. Agora queremos que os servizos poidan unirse e operar nestes fíos compartidos, pero queremos evitar os complexos servizos centralizados de Deus que realizan este procesamento. Polo tanto, a mellor opción é incorporar o procesamento de fluxos en cada servizo ao consumidor. Deste xeito, os servizos poderán combinar conxuntos de datos de diferentes fontes e traballar con eles da forma que precisen.
Unha forma de conseguir este enfoque é mediante o uso dunha plataforma de streaming. Hai moitas opcións, pero hoxe veremos a Kafka, xa que o uso do seu procesamento de fluxos con estado permítenos resolver eficazmente o problema presentado.
Usar un mecanismo de rexistro distribuído permítenos seguir o camiño ben transitado e empregar a mensaxería para traballar . Considérase que este enfoque proporciona un mellor escalado e partición que o mecanismo de solicitude-resposta porque dá o control do fluxo ao receptor e non ao emisor. Non obstante, para todo nesta vida tes que pagar, e aquí necesitas un corredor. Pero para sistemas grandes, a compensación paga a pena (o que pode non ser o caso da túa aplicación web media).
Se un corredor é responsable do rexistro distribuído en lugar dun sistema de mensaxería tradicional, podes aproveitar as funcións adicionais. O transporte pode escalar linealmente case tan ben como un sistema de ficheiros distribuído. Os datos pódense almacenar nos rexistros durante bastante tempo, polo que non só podemos intercambiar mensaxes, senón tamén almacenar información. Almacenamento escalable sen medo a un estado compartido mutable.
Despois podes usar o procesamento de fluxos con estado para engadir ferramentas de bases de datos declarativas aos servizos consumidores. Esta é unha idea moi importante. Aínda que os datos se almacenan en fluxos compartidos aos que todos os servizos poden acceder, a agregación e o procesamento que fai o servizo é privado. Atópanse illados nun contexto estritamente limitado.
Elimine a dicotomía de datos separando o fluxo de estado inmutable. A continuación, engade esta funcionalidade a todos os servizos mediante o procesamento de fluxos con estado.
Así, se o teu servizo precisa traballar con pedidos, un catálogo de produtos, un almacén, terá acceso total: só ti decidirás que datos combinar, onde procesalos e como deben cambiar co paso do tempo. A pesar de que os datos se comparten, o traballo con eles está completamente descentralizado. Prodúcese dentro de cada servizo, nun mundo onde todo vai segundo as túas regras.
Comparte datos sen comprometer a súa integridade. Encapsule a función, non a fonte, en todos os servizos que o necesiten.
Ocorre que hai que mover os datos en masa. Ás veces, un servizo require un conxunto de datos históricos locais no motor de base de datos seleccionado. O truco é que pode garantir que, se é necesario, se pode restaurar unha copia desde a fonte accedendo ao mecanismo de rexistro distribuído. Os conectores de Kafka fan un gran traballo con isto.
Polo tanto, o enfoque discutido hoxe ten varias vantaxes:
- Os datos úsanse en forma de fluxos comúns, que se poden almacenar nos rexistros durante moito tempo, e o mecanismo para traballar con datos comúns está configurado en cada contexto individual, o que permite que os servizos funcionen de xeito sinxelo e rápido. Deste xeito, pódese equilibrar a dicotomía dos datos.
- Os datos procedentes de diferentes servizos pódense combinar facilmente en conxuntos. Isto simplifica a interacción cos datos compartidos e elimina a necesidade de manter conxuntos de datos locais na base de datos.
- O procesamento de fluxos con estado só almacena datos na caché e a fonte da verdade seguen sendo os rexistros xerais, polo que o problema da corrupción dos datos ao longo do tempo non é tan agudo.
- Na súa base, os servizos están baseados en datos, o que significa que, a pesar dos volumes de datos cada vez máis grandes, os servizos aínda poden responder rapidamente aos eventos empresariais.
- Os problemas de escalabilidade recaen no corredor, non nos servizos. Isto reduce significativamente a complexidade dos servizos de escritura, xa que non hai que pensar na escalabilidade.
- Para engadir novos servizos non é necesario cambiar os antigos, polo que conectar novos servizos faise máis fácil.
Como podes ver, isto é algo máis que REST. Recibimos un conxunto de ferramentas que che permiten traballar con datos compartidos de forma descentralizada.
Non todos os aspectos foron tratados no artigo de hoxe. Aínda temos que descubrir como equilibrar o paradigma solicitude-resposta e o paradigma impulsado por eventos. Pero tratarémolo a próxima vez. Hai temas que debes coñecer mellor, por exemplo, por que o procesamento de fluxos con estado é tan bo. Diso falaremos no terceiro artigo. E hai outras construcións poderosas que podemos aproveitar se recorremos a elas, por exemplo, . É un cambio de xogo para os sistemas comerciais distribuídos porque ofrece garantías transaccionais para nunha forma escalable. Isto será discutido no cuarto artigo. Finalmente, teremos que repasar os detalles de implementación destes principios.
Pero de momento, só lembra isto: a dicotomía de datos é unha forza á que nos enfrontamos á hora de construír servizos empresariais. E debemos lembrar isto. O truco é darlle voltas a todo e comezar a tratar os datos compartidos como obxectos de primeira clase. O procesamento de fluxos con estado ofrece un compromiso único para iso. Evita os "compoñentes de Deus" centralizados que frean o progreso. Ademais, garante a axilidade, escalabilidade e resistencia das canalizacións de transmisión de datos e engádeas a todos os servizos. Polo tanto, podemos centrarnos no fluxo xeral de conciencia ao que calquera servizo pode conectarse e traballar cos seus datos. Isto fai que os servizos sexan máis escalables, intercambiables e autónomos. Así que non só se verán ben en encerados e probas de hipóteses, senón que tamén funcionarán e evolucionarán durante décadas.
Fonte: www.habr.com