Olá a todos! Temos ótimas notícias, a OTUS está lançando o curso novamente em junho , em relação ao qual tradicionalmente compartilhamos com você material útil.
Se você se deparou com toda essa coisa de microsserviços sem qualquer contexto, será perdoado por pensar que é um pouco estranho. Dividir uma aplicação em fragmentos conectados por uma rede significa necessariamente adicionar modos complexos de tolerância a falhas ao sistema distribuído resultante.
Embora esta abordagem envolva a divisão em muitos serviços independentes, o objetivo final é muito mais do que apenas ter esses serviços executados em máquinas diferentes. Estamos falando aqui de interação com o mundo exterior, que também se distribui em sua essência. Não no sentido técnico, mas sim no sentido de um ecossistema que consiste em muitas pessoas, equipes, programas, e cada uma dessas partes precisa de alguma forma fazer o seu trabalho.
As empresas, por exemplo, são um conjunto de sistemas distribuídos que contribuem coletivamente para o alcance de algum objetivo. Ignoramos esse fato há décadas, tentando alcançar a unificação por meio de FTP de arquivos ou usando ferramentas de integração empresarial enquanto nos concentramos em nossos próprios objetivos isolados. Mas com o advento dos serviços tudo mudou. Os serviços ajudaram-nos a olhar para além do horizonte e a ver um mundo de programas interdependentes que funcionam em conjunto. No entanto, para trabalhar com sucesso, é necessário reconhecer e conceber dois mundos fundamentalmente diferentes: o mundo externo, onde vivemos num ecossistema de muitos outros serviços, e o nosso mundo pessoal e interno, onde governamos sozinhos.
Este mundo distribuído é diferente daquele em que crescemos e ao qual estamos acostumados. Os princípios de construção da arquitetura monolítica tradicional não resistem às críticas. Portanto, acertar esses sistemas envolve mais do que criar um diagrama de quadro branco interessante ou uma prova de conceito interessante. O objetivo é garantir que tal sistema funcione com sucesso durante um longo período de tempo. Felizmente, os serviços já existem há algum tempo, embora pareçam diferentes. ainda são relevantes, mesmo temperados com Docker, Kubernetes e barbas hipster levemente surradas.
Portanto, hoje veremos como as regras mudaram, por que precisamos repensar a forma como abordamos os serviços e os dados que eles transmitem uns aos outros e por que precisaremos de ferramentas completamente diferentes para fazer isso.
O encapsulamento nem sempre será seu amigo
Os microsserviços podem operar independentemente uns dos outros. É esta propriedade que lhes confere maior valor. Essa mesma propriedade permite que os serviços sejam escalonados e cresçam. Não tanto no sentido de escalar para quatrilhões de usuários ou petabytes de dados (embora isso também possa ajudar), mas no sentido de escalar em termos de pessoas à medida que equipes e organizações crescem continuamente.
No entanto, a independência é uma faca de dois gumes. Ou seja, o próprio serviço pode funcionar de forma fácil e natural. Mas se uma função for implementada dentro de um serviço que requer a utilização de outro serviço, então acabamos tendo que fazer alterações em ambos os serviços quase simultaneamente. Em um monólito isso é fácil de fazer, basta fazer uma alteração e enviar para liberação, mas no caso de sincronização de serviços independentes haverá mais problemas. A coordenação entre equipes e ciclos de lançamento destrói a agilidade.
Como parte da abordagem padrão, eles simplesmente tentam evitar alterações irritantes de ponta a ponta, dividindo claramente a funcionalidade entre os serviços. O serviço de logon único pode ser um bom exemplo aqui. Tem um papel claramente definido que o diferencia de outros serviços. Esta separação clara significa que, num mundo em que as exigências dos serviços à sua volta mudam rapidamente, é pouco provável que o serviço de início de sessão único mude. Existe dentro de um contexto estritamente limitado.
O problema é que, no mundo real, os serviços empresariais não conseguem manter sempre a mesma separação pura de funções. Por exemplo, os mesmos serviços empresariais funcionam em maior medida com dados provenientes de outros serviços semelhantes. Se você estiver envolvido com varejo on-line, o processamento do fluxo de pedidos, do catálogo de produtos ou das informações do usuário se tornará um requisito para muitos de seus serviços. Cada um dos serviços precisará de acesso a esses dados para funcionar.
A maioria dos serviços empresariais partilha o mesmo fluxo de dados, pelo que o seu trabalho está invariavelmente interligado.
Chegamos assim a um ponto importante sobre o qual vale a pena falar. Embora os serviços funcionem bem para componentes de infraestrutura que operam em grande parte isoladamente, a maioria dos serviços empresariais acaba por estar interligada de forma muito mais estreita.
Dicotomia de dados
Talvez já existam abordagens orientadas a serviços, mas ainda faltam informações sobre como compartilhar grandes quantidades de dados entre serviços.
O principal problema é que dados e serviços são inseparáveis. Por um lado, o encapsulamento encoraja-nos a ocultar dados para que os serviços possam ser separados uns dos outros e facilitar o seu crescimento e futuras alterações. Por outro lado, precisamos de ser capazes de dividir e conquistar livremente os dados partilhados, tal como quaisquer outros dados. A questão é poder começar a trabalhar imediatamente, tão livremente como em qualquer outro sistema de informação.
No entanto, os sistemas de informação têm pouco a ver com encapsulamento. Na verdade, é exatamente o oposto. Os bancos de dados fazem tudo o que podem para fornecer acesso aos dados que armazenam. Eles vêm com uma interface declarativa poderosa que permite modificar os dados conforme necessário. Essa funcionalidade é importante na fase de investigação preliminar, mas não para gerir a complexidade crescente de um serviço em constante evolução.
E aqui surge um dilema. Contradição. Dicotomia. Afinal, os sistemas de informação servem para fornecer dados e os serviços servem para ocultar.
Estas duas forças são fundamentais. Eles sustentam grande parte do nosso trabalho, lutando constantemente pela excelência nos sistemas que construímos.
À medida que os sistemas de serviços crescem e evoluem, vemos as consequências da dicotomia de dados de várias maneiras. Ou a interface de serviço crescerá para fornecer uma gama cada vez maior de funcionalidades e começará a parecer um banco de dados interno muito sofisticado, ou ficaremos frustrados e implementaremos alguma maneira de recuperar ou mover em massa conjuntos inteiros de dados de um serviço para outro.
Por sua vez, criar algo que se pareça com um banco de dados sofisticado e desenvolvido internamente levará a uma série de problemas. Não entraremos em detalhes sobre por que é perigoso banco de dados compartilhado, digamos apenas que representa custos significativos de engenharia e operacionais para a empresa que está tentando usá-lo.
O pior é que os volumes de dados ampliam os problemas de limites de serviço. Quanto mais dados partilhados existirem num serviço, mais complexa se tornará a interface e mais difícil será combinar conjuntos de dados provenientes de diferentes serviços.
A abordagem alternativa de extrair e mover conjuntos inteiros de dados também tem seus problemas. Uma abordagem comum para essa questão é simplesmente recuperar e armazenar todo o conjunto de dados e, em seguida, armazená-lo localmente em cada serviço de consumo.
O problema é que diferentes serviços interpretam os dados que consomem de maneira diferente. Esses dados estão sempre à mão. Eles são modificados e processados localmente. Rapidamente eles deixam de ter algo em comum com os dados da fonte.
Quanto mais mutáveis forem as cópias, mais os dados variarão ao longo do tempo.
Para piorar a situação, esses dados são difíceis de corrigir retrospectivamente ( É aqui que ele pode realmente ajudar). Na verdade, alguns dos problemas tecnológicos intratáveis que as empresas enfrentam surgem dos dados díspares que se multiplicam de aplicação para aplicação.
Para encontrar uma solução para este problema, precisamos de pensar de forma diferente sobre os dados partilhados. Eles devem se tornar objetos de primeira classe nas arquiteturas que construímos. chama esses dados de “externos”, e este é um recurso muito importante. Precisamos de encapsulamento para não expor o funcionamento interno de um serviço, mas precisamos facilitar o acesso dos serviços aos dados compartilhados para que possam realizar seu trabalho corretamente.
O problema é que nenhuma das abordagens é relevante hoje, uma vez que nem as interfaces de serviço, nem as mensagens, nem o Banco de Dados Compartilhado oferecem uma boa solução para trabalhar com dados externos. As interfaces de serviço são pouco adequadas para troca de dados em qualquer escala. As mensagens movem dados, mas não armazenam seu histórico, portanto, os dados são corrompidos com o tempo. Os bancos de dados compartilhados concentram-se demais em um ponto, o que retarda o progresso. Inevitavelmente ficamos presos em um ciclo de falha de dados:
Ciclo de falha de dados
Streams: uma abordagem descentralizada para dados e serviços
Idealmente, precisamos mudar a forma como os serviços funcionam com dados compartilhados. Neste ponto, qualquer uma das abordagens enfrenta a dicotomia acima mencionada, pois não há pó mágico que possa ser espalhado sobre ela para fazê-la desaparecer. No entanto, podemos repensar o problema e chegar a um compromisso.
Este compromisso envolve um certo grau de centralização. Podemos usar o mecanismo de log distribuído porque ele fornece fluxos confiáveis e escaláveis. Agora queremos que os serviços possam se juntar e operar nesses threads compartilhados, mas queremos evitar serviços divinos complexos e centralizados que fazem esse processamento. Portanto, a melhor opção é incorporar o processamento de fluxo em cada serviço do consumidor. Desta forma, os serviços poderão combinar conjuntos de dados de diferentes fontes e trabalhar com eles da forma que necessitarem.
Uma maneira de conseguir essa abordagem é através do uso de uma plataforma de streaming. As opções são muitas, mas hoje veremos o Kafka, pois a utilização do seu Stateful Stream Processing permite-nos resolver eficazmente o problema apresentado.
Usar um mecanismo de registro distribuído nos permite seguir o caminho já trilhado e usar mensagens para trabalhar com . Considera-se que esta abordagem fornece melhor escalonamento e particionamento do que o mecanismo de solicitação-resposta porque dá o controle do fluxo ao receptor e não ao remetente. Porém, para tudo nesta vida você tem que pagar, e aqui você precisa de um corretor. Mas para sistemas grandes, a compensação vale a pena (o que pode não ser o caso de uma aplicação web comum).
Se um corretor for responsável pelo registro distribuído em vez de um sistema de mensagens tradicional, você poderá aproveitar recursos adicionais. O transporte pode ser dimensionado linearmente quase tão bem quanto um sistema de arquivos distribuído. Os dados podem ser armazenados em logs por um longo tempo, portanto, obtemos não apenas a troca de mensagens, mas também o armazenamento de informações. Armazenamento escalável sem medo de estado compartilhado mutável.
Você pode então usar o processamento de fluxo com estado para adicionar ferramentas de banco de dados declarativas aos serviços de consumo. Esta é uma ideia muito importante. Embora os dados sejam armazenados em fluxos compartilhados que todos os serviços podem acessar, a agregação e o processamento realizados pelo serviço são privados. Eles se encontram isolados dentro de um contexto estritamente limitado.
Elimine a dicotomia de dados separando o fluxo de estado imutável. Em seguida, adicione essa funcionalidade a todos os serviços usando Stateful Stream Processing.
Assim, se o seu serviço precisar trabalhar com pedidos, catálogo de produtos, armazém, ele terá acesso total: só você decidirá quais dados combinar, onde processá-los e como devem mudar ao longo do tempo. Apesar dos dados serem compartilhados, o trabalho com eles é totalmente descentralizado. É produzido dentro de cada serviço, num mundo onde tudo corre de acordo com as suas regras.
Compartilhe dados sem comprometer sua integridade. Encapsule a função, não a fonte, em cada serviço que dela necessita.
Acontece que os dados precisam ser movidos em massa. Às vezes, um serviço requer um conjunto de dados históricos locais no mecanismo de banco de dados selecionado. O truque é que você pode garantir que, se necessário, uma cópia poderá ser restaurada da fonte acessando o mecanismo de registro distribuído. Os conectores em Kafka fazem um ótimo trabalho nisso.
Portanto, a abordagem discutida hoje tem diversas vantagens:
- Os dados são utilizados na forma de fluxos comuns, que podem ser armazenados em logs por um longo tempo, e o mecanismo para trabalhar com dados comuns é conectado em cada contexto individual, o que permite que os serviços funcionem de maneira fácil e rápida. Desta forma, a dicotomia dos dados pode ser equilibrada.
- Os dados provenientes de diferentes serviços podem ser facilmente combinados em conjuntos. Isto simplifica a interação com dados compartilhados e elimina a necessidade de manter conjuntos de dados locais no banco de dados.
- O Stateful Stream Processing apenas armazena dados em cache, e a fonte da verdade continua sendo os logs gerais, portanto, o problema de corrupção de dados ao longo do tempo não é tão grave.
- Na sua essência, os serviços são orientados por dados, o que significa que, apesar dos volumes cada vez maiores de dados, os serviços ainda podem responder rapidamente a eventos de negócios.
- Os problemas de escalabilidade recaem sobre o corretor, não sobre os serviços. Isso reduz significativamente a complexidade dos serviços de escrita, uma vez que não há necessidade de pensar em escalabilidade.
- Adicionar novos serviços não requer a alteração dos antigos, portanto, conectar novos serviços fica mais fácil.
Como você pode ver, isso é mais do que apenas REST. Recebemos um conjunto de ferramentas que permite trabalhar com dados compartilhados de forma descentralizada.
Nem todos os aspectos foram abordados no artigo de hoje. Ainda precisamos descobrir como equilibrar o paradigma de solicitação-resposta e o paradigma orientado a eventos. Mas trataremos disso na próxima vez. Existem tópicos que você precisa conhecer melhor, por exemplo, por que o Stateful Stream Processing é tão bom. Falaremos sobre isso no terceiro artigo. E há outras construções poderosas das quais podemos tirar vantagem se recorrermos a elas, por exemplo, . É um divisor de águas para sistemas de negócios distribuídos porque fornece garantias transacionais para de forma escalável. Isso será discutido no quarto artigo. Finalmente, precisaremos examinar os detalhes de implementação desses princípios.
Mas, por enquanto, lembre-se disto: a dicotomia de dados é uma força que enfrentamos na construção de serviços empresariais. E devemos lembrar disso. O truque é virar tudo de cabeça para baixo e começar a tratar os dados compartilhados como objetos de primeira classe. O Stateful Stream Processing oferece um compromisso exclusivo para isso. Evita “Componentes de Deus” centralizados que impedem o progresso. Além disso, garante a agilidade, escalabilidade e resiliência dos pipelines de streaming de dados e os adiciona a todos os serviços. Portanto, podemos nos concentrar no fluxo geral de consciência ao qual qualquer serviço pode se conectar e trabalhar com seus dados. Isso torna os serviços mais escaláveis, intercambiáveis e autônomos. Portanto, eles não só ficarão bem em quadros brancos e testes de hipóteses, mas também funcionarão e evoluirão por décadas.
Fonte: habr.com