{"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\/pt\/blog\/administrirovanie\/dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam","title":{"rendered":"Dicotomia de Dados: Repensando a Rela\u00e7\u00e3o com Dados e Servi\u00e7os","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ol\u00e1 a todos! Temos \u00f3timas not\u00edcias, em junho, a OTUS novamente ir\u00e1 lan\u00e7ar um curso \u00abArquiteto de Software\u00bb<\/a><\/noindex>, e por isso, tradicionalmente, compartilhamos com voc\u00eas materiais \u00fateis.<\/b><\/i><\/p>\n

\"Dicotomia
\n
\n Se voc\u00ea se deparou com toda essa hist\u00f3ria de microsservi\u00e7os sem qualquer contexto, \u00e9 compreens\u00edvel que a considere um pouco estranha. Dividir um aplicativo em fragmentos conectados por uma rede inevitavelmente implica a adi\u00e7\u00e3o de modos complexos de resili\u00eancia \u00e0 falha no sistema distribu\u00eddo resultante. <\/p>\n

Embora essa abordagem envolva a divis\u00e3o em muitos servi\u00e7os independentes, o objetivo final \u00e9 muito maior do que apenas a opera\u00e7\u00e3o desses servi\u00e7os em m\u00e1quinas diferentes. Estamos falando sobre a intera\u00e7\u00e3o com o mundo ao nosso redor, que em ess\u00eancia tamb\u00e9m \u00e9 distribu\u00eddo. N\u00e3o no sentido t\u00e9cnico, mas mais em termos de um ecossistema composto por v\u00e1rias pessoas, equipes, programas, e cada uma dessas partes deve, de alguma forma, realizar seu trabalho.<\/a><\/noindex><\/p>\n

As empresas, por exemplo, representam um conjunto de sistemas distribu\u00eddos que, em conjunto, ajudam a alcan\u00e7ar um determinado objetivo. Ignoramos esse fato por d\u00e9cadas, buscando a unifica\u00e7\u00e3o, transferindo arquivos via FTP ou utilizando ferramentas de integra\u00e7\u00e3o corporativa, enquanto nos concentr\u00e1vamos em nossos pr\u00f3prios objetivos isolados. Mas, com a chegada dos servi\u00e7os, tudo mudou. Os servi\u00e7os nos ajudaram a olhar al\u00e9m do horizonte e ver um mundo de programas interdependentes que trabalham em conjunto. No entanto, para ter sucesso, \u00e9 necess\u00e1rio compreender e projetar dois mundos fundamentalmente diferentes: o mundo externo, onde vivemos em um ecossistema de muitos outros servi\u00e7os, e nosso pr\u00f3prio mundo interno, onde governamos sozinhos.<\/p>\n

\"Dicotomia
\n
\n Esse mundo distribu\u00eddo \u00e9 diferente daquele em que crescemos e ao qual estamos acostumados. Os princ\u00edpios de constru\u00e7\u00e3o da arquitetura monol\u00edtica tradicional n\u00e3o resistem a qualquer cr\u00edtica. Portanto, uma compreens\u00e3o correta de tais sistemas \u00e9 algo mais do que criar um \u00f3timo diagrama em um quadro branco ou uma prova de conceito impressionante. Trata-se de garantir que tal sistema funcione com sucesso por um longo tempo. Felizmente, os servi\u00e7os existem h\u00e1 bastante tempo, embora apresentem apar\u00eancias diferentes. Li\u00e7\u00f5es de SOA<\/a><\/noindex> ainda s\u00e3o relevantes, mesmo temperadas com Docker, Kubernetes e levemente desgastadas por barbas de hipster. <\/p>\n

Ent\u00e3o, hoje vamos analisar como as regras mudaram, por que precisamos repensar nossa abordagem em rela\u00e7\u00e3o aos servi\u00e7os e os dados que eles trocam entre si, e por que precisaremos de um conjunto de ferramentas completamente diferente para isso.<\/p>\n

A encapsula\u00e7\u00e3o nem sempre ser\u00e1 sua amiga<\/h3>\n

\n Os microsservi\u00e7os podem operar independentemente uns dos outros. \u00c9 essa caracter\u00edstica que lhes confere o maior valor. Essa mesma propriedade permite que os servi\u00e7os escalem e cres\u00e7am. N\u00e3o tanto em termos de escalar para quadrilh\u00f5es de usu\u00e1rios ou petabytes de dados (embora possam ajudar aqui tamb\u00e9m), mas em termos de escalar em rela\u00e7\u00e3o \u00e0s pessoas, \u00e0 medida que equipes e organiza\u00e7\u00f5es crescem continuamente.<\/p>\n

\"Dicotomia
\n
\nNo entanto, a independ\u00eancia \u00e9 uma faca de dois gumes. Ou seja, um servi\u00e7o pode rodar de forma f\u00e1cil e despreocupada por si s\u00f3. Mas se dentro do servi\u00e7o for implementada uma fun\u00e7\u00e3o que requer a utiliza\u00e7\u00e3o de outro servi\u00e7o, acabamos tendo que fazer altera\u00e7\u00f5es em ambos os servi\u00e7os quase simultaneamente. Em um monolito, isso \u00e9 f\u00e1cil; voc\u00ea simplesmente faz a altera\u00e7\u00e3o e envia para o release, enquanto na sincroniza\u00e7\u00e3o de servi\u00e7os independentes h\u00e1 mais problemas. A coordena\u00e7\u00e3o entre equipes e ciclos de releases destr\u00f3i a flexibilidade.<\/p>\n

\"Dicotomia
\n
\nDentro da abordagem padr\u00e3o, mudan\u00e7as indesejadas s\u00e3o geralmente evitadas, separando claramente as funcionalidades entre os servi\u00e7os. Um servi\u00e7o de entrada \u00fanica no sistema pode ser um bom exemplo disso. Ele desempenha um papel bem definido que o distingue de outros servi\u00e7os. Essa clara separa\u00e7\u00e3o significa que, em um mundo de requisitos em r\u00e1pida mudan\u00e7a em rela\u00e7\u00e3o aos servi\u00e7os ao seu redor, o servi\u00e7o de entrada \u00fanica no sistema dificilmente mudar\u00e1. Ele existe dentro de um contexto rigorosamente limitado.<\/p>\n

\"Dicotomia
\n
\n O problema \u00e9 que, no mundo real, os servi\u00e7os de neg\u00f3cios n\u00e3o conseguem manter uma separa\u00e7\u00e3o de fun\u00e7\u00f5es consistentemente clara. Por exemplo, os pr\u00f3prios servi\u00e7os de neg\u00f3cios, em grande parte, trabalham com dados recebidos de outros servi\u00e7os semelhantes. Se voc\u00ea est\u00e1 no varejo online, o processamento de pedidos, o cat\u00e1logo de produtos ou as informa\u00e7\u00f5es dos usu\u00e1rios se tornam requisitos para muitos de seus servi\u00e7os. Cada um dos servi\u00e7os necessitar\u00e1 de acesso a esses dados para operar. <\/p>\n

\"Dicotomia
\nA maioria dos servi\u00e7os de neg\u00f3cios utiliza o mesmo fluxo de dados, por isso seu funcionamento se entrela\u00e7a inevitavelmente.<\/i><\/p>\n

Assim, chegamos a um ponto importante que merece ser discutido. Enquanto os servi\u00e7os funcionam bem para componentes da infraestrutura que operam em grande parte de forma isolada, a maioria dos servi\u00e7os de neg\u00f3cios est\u00e1 mais entrela\u00e7ada do que se imagina.<\/p>\n

Dicotomia de dados<\/h3>\n

\n Embora j\u00e1 existam abordagens orientadas a servi\u00e7os, ainda h\u00e1 pouca informa\u00e7\u00e3o sobre como trocar grandes volumes de dados entre os servi\u00e7os.<\/p>\n

O principal problema reside no fato de que dados e servi\u00e7os s\u00e3o insepar\u00e1veis. Por um lado, a encapsula\u00e7\u00e3o nos incentiva a esconder dados, para que os servi\u00e7os possam ser separados uns dos outros, facilitando seu crescimento e futuras modifica\u00e7\u00f5es. Por outro lado, precisamos ser capazes de compartilhar e controlar dados comuns livremente, assim como temos em qualquer outro sistema de informa\u00e7\u00e3o. Trata-se de poder come\u00e7ar a trabalhar imediatamente, assim como em qualquer outro sistema de informa\u00e7\u00e3o.<\/p>\n

No entanto, sistemas de informa\u00e7\u00e3o t\u00eam pouco em comum com a encapsula\u00e7\u00e3o. Na verdade, \u00e9 quase o oposto. Os bancos de dados fazem de tudo para fornecer acesso aos dados que armazenam. Eles v\u00eam com uma interface declarativa poderosa que permite modificar os dados como voc\u00ea precisar. Essa funcionalidade \u00e9 importante na fase de pesquisa inicial, mas n\u00e3o para gerenciar a crescente complexidade de um servi\u00e7o em constante evolu\u00e7\u00e3o.<\/p>\n

\"Dicotomia
\n
\n E aqui surge a dilema. A contradi\u00e7\u00e3o. A dicotomia. Afinal, sistemas de informa\u00e7\u00e3o s\u00e3o sobre fornecer dados, enquanto servi\u00e7os s\u00e3o sobre oculta\u00e7\u00e3o.<\/p>\n

Estas duas for\u00e7as s\u00e3o fundamentais. Elas est\u00e3o na base da maior parte de nosso trabalho, lutando constantemente pela supremacia nos sistemas que criamos.<\/p>\n

\u00c0 medida que os sistemas de servi\u00e7o crescem e evoluem, vemos diferentes manifesta\u00e7\u00f5es das consequ\u00eancias da dicotomia de dados. Ou a interface do servi\u00e7o cresce, oferecendo um conjunto cada vez mais amplo de fun\u00e7\u00f5es e come\u00e7a a parecer uma base de dados caseira muito peculiar, ou nos deparamos com frustra\u00e7\u00f5es e encontramos alguma maneira de extrair ou mover conjuntos inteiros de dados de um servi\u00e7o para outro.<\/p>\n

\"Dicotomia
\n
\n Por sua vez, criar algo que pare\u00e7a uma base de dados caseira peculiar levar\u00e1 a uma s\u00e9rie de problemas. N\u00e3o vamos entrar em detalhes sobre os riscos da shared database<\/i>, apenas diremos que ela representa consider\u00e1veis dificuldades de engenharia e operacionais para a empresa que tenta utiliz\u00e1-la.<\/a><\/noindex> Pior ainda, os volumes de dados exacerbam os problemas nas fronteiras dos servi\u00e7os. Quanto mais dados compartilhados existem dentro de um servi\u00e7o, mais complicada a interface se tornar\u00e1 e mais dif\u00edcil ser\u00e1 combinar conjuntos de dados provenientes de diferentes servi\u00e7os.<\/p>\n

Uma abordagem alternativa de extra\u00e7\u00e3o e movimenta\u00e7\u00e3o de conjuntos inteiros de dados tamb\u00e9m apresenta seus pr\u00f3prios problemas. A abordagem comum para essa quest\u00e3o se parece com a simples extra\u00e7\u00e3o e armazenamento de um conjunto de dados inteiro, seguido de seu armazenamento local em cada servi\u00e7o consumidor.<\/p>\n

O problema \u00e9 que diferentes servi\u00e7os interpretam os dados que consomem de maneiras distintas. Esses dados est\u00e3o sempre ao alcance. Eles mudam e s\u00e3o processados localmente. Rapidamente, eles perdem qualquer semelhan\u00e7a com os dados da fonte.<\/p>\n

\"Dicotomia
\n
\n Quanto mais mut\u00e1veis as c\u00f3pias, mais os dados divergir\u00e3o ao longo do tempo.<\/p>\n

\"Dicotomia
\n O que \u00e9 ainda pior, esses dados s\u00e3o dif\u00edceis de corrigir retrospectivamente (<\/i><\/p>\n

MDMpode realmente ajudar aqui). De fato, alguns dos problemas tecnol\u00f3gicos irresol\u00faveis enfrentados pelos neg\u00f3cios surgem de dados heterog\u00eaneos, multiplicando-se de aplicativo para aplicativo.<\/a><\/noindex> Para encontrar uma solu\u00e7\u00e3o para o problema dos dados compartilhados, \u00e9 necess\u00e1rio pensar de forma diferente. Eles devem se tornar objetos de primeira classe nas arquiteturas que constru\u00edmos.<\/p>\n

Pat Helland Pett Helland<\/a><\/noindex> classifica esses dados como 'externos', e essa \u00e9 uma caracter\u00edstica muito importante. Precisamos de encapsulamento para n\u00e3o revelar a estrutura interna do servi\u00e7o, mas devemos facilitar o acesso a dados compartilhados para que os servi\u00e7os possam realizar seu trabalho adequadamente.<\/p>\n

\"Dicotomia
\n
\n O problema \u00e9 que nenhuma das abordagens atuais \u00e9 relevante, pois nem as interfaces de servi\u00e7o, nem a troca de mensagens, nem o Banco de Dados Compartilhado oferecem uma boa solu\u00e7\u00e3o para trabalhar com dados externos. As interfaces de servi\u00e7o s\u00e3o mal adaptadas para a troca de dados em qualquer escala. A troca de mensagens move dados, mas n\u00e3o mant\u00e9m seu hist\u00f3rico, portanto, com o tempo, os dados se corrompem. Os Bancos de Dados Compartilhados se concentram demais em um \u00fanico ponto, o que impede o progresso. Inevitavelmente, ficamos presos em um ciclo de fal\u00eancia de dados:<\/p>\n

\"Dicotomia
\n Ciclo de fal\u00eancia de dados<\/i><\/p>\n

Fluxos: abordagem descentralizada para dados e servi\u00e7os<\/h3>\n

\n Idealmente, precisamos mudar a abordagem de como os servi\u00e7os trabalham com dados comuns. No momento, qualquer abordagem enfrenta a dicotomia mencionada acima, pois n\u00e3o existe nenhuma 'po\u00e7\u00e3o m\u00e1gica' que possa ser generosamente aplicada para fazer isso desaparecer. No entanto, podemos repensar o problema e chegar a um compromisso.<\/p>\n

Esse compromisso implica um certo grau de centraliza\u00e7\u00e3o. Podemos aproveitar o mecanismo de logs distribu\u00eddos, pois ele fornece fluxos escal\u00e1veis e confi\u00e1veis. Agora, precisamos garantir que os servi\u00e7os possam se conectar e operar esses fluxos compartilhados, mas queremos evitar servi\u00e7os centralizados complexos que realizem tal processamento. Portanto, a melhor op\u00e7\u00e3o \u00e9 integrar o processamento de fluxos em cada servi\u00e7o consumidor. Assim, os servi\u00e7os poder\u00e3o combinar conjuntos de dados de diferentes fontes e trabalhar com eles conforme necess\u00e1rio.<\/p>\n

Uma das maneiras de alcan\u00e7ar tal abordagem \u00e9 o uso de uma plataforma de streaming. Existem muitas op\u00e7\u00f5es, mas hoje vamos considerar o Kafka, pois seu uso de Processamento de Fluxo Stateful permite resolver eficientemente o problema apresentado.<\/p>\n

\"Dicotomia
\n
\n O uso do mecanismo de logging distribu\u00eddo nos permite seguir um caminho comprovado e usar a troca de mensagens para trabalhar com arquitetura orientada a eventos<\/a><\/noindex>. Acredita-se que essa abordagem oferece melhor escalabilidade e separa\u00e7\u00e3o do que o mecanismo de \"request-response\", uma vez que d\u00e1 controle do fluxo ao destinat\u00e1rio, n\u00e3o ao remetente. No entanto, tudo na vida tem seu pre\u00e7o, e aqui voc\u00ea precisar\u00e1 de um broker. Mas, para sistemas grandes, esse compromisso vale a pena (o que n\u00e3o se pode dizer sobre suas aplica\u00e7\u00f5es web m\u00e9dias).<\/p>\n

Se o broker \u00e9 respons\u00e1vel pela loga\u00e7\u00e3o distribu\u00edda, e n\u00e3o um sistema tradicional de troca de mensagens, \u00e9 poss\u00edvel aproveitar funcionalidades adicionais. O transporte pode ser escalado linearmente t\u00e3o bem quanto um sistema de arquivos distribu\u00eddo. Os dados podem ser armazenados nos logs por um tempo consider\u00e1vel, portanto, obtemos n\u00e3o apenas troca de mensagens, mas tamb\u00e9m armazenamento de informa\u00e7\u00f5es. Armazenamento escal\u00e1vel sem temor de afetar um estado compartilhado mut\u00e1vel.<\/p>\n

Em seguida, pode-se utilizar um mecanismo de processamento de fluxo stateful (processamento de fluxo com estado) para adicionar ferramentas de banco de dados declarativas aos servi\u00e7os consumidores. Este \u00e9 um pensamento muito importante. Enquanto os dados estiverem armazenados em fluxos comuns, que todos os servi\u00e7os podem acessar, a agrega\u00e7\u00e3o e o processamento realizados pelo servi\u00e7o s\u00e3o privados. Eles ficam isolados dentro de um contexto estritamente limitado.<\/p>\n

\"Dicotomia
\n Elimine a dicotomia dos dados, separando o fluxo de estados imut\u00e1veis. Em seguida, adicione essa fun\u00e7\u00e3o a cada servi\u00e7o por meio do Stateful Stream Processing.<\/i><\/p>\n

Assim, se seu servi\u00e7o precisa trabalhar com pedidos, cat\u00e1logo de produtos, estoque, ele ter\u00e1 acesso total: voc\u00ea ser\u00e1 o \u00fanico a decidir quais dados agregar, onde process\u00e1-los e como eles devem mudar ao longo do tempo. Embora os dados sejam comuns, o trabalho com eles \u00e9 totalmente descentralizado. Ele \u00e9 realizado dentro de cada servi\u00e7o, em um mundo onde tudo opera sob suas regras.<\/p>\n

\"Dicotomia
\nCompartilhe dados de forma que sua integridade n\u00e3o seja comprometida. Incorpore a fun\u00e7\u00e3o, n\u00e3o a fonte, em cada servi\u00e7o que precisar dela.<\/i><\/p>\n

\u00c0s vezes, \u00e9 necess\u00e1rio mover dados em massa. \u00c0s vezes, o servi\u00e7o requer um conjunto hist\u00f3rico local de dados no banco de dados selecionado. O foco \u00e9 que \u00e9 poss\u00edvel garantir que, quando necess\u00e1rio, uma c\u00f3pia possa ser restaurada da fonte por meio da chamada ao mecanismo de registro distribu\u00eddo. Os conectores no Kafka fazem isso muito bem.<\/p>\n

Assim, a abordagem discutida hoje tem v\u00e1rias vantagens:<\/p>\n