Eu não imaginava que microsserviços eram assim
Вставка
- Опубліковано 26 сер 2021
- ✅ Inscreva-se no Launch2022: rseat.in/eCHO_Euj3
💻 Quando comecei a estudar microsserviços eu caí em duas dúvidas que me tiraram o sono por dias: como estruturar o banco de dados para suportar múltiplas aplicações compartilhando dados em comum e como realizar a troca de informação entre os serviços sem causar acoplamento desnecessário. Nesse vídeo falo um pouco sobre minha experiência estudando esses dois pontos e minhas conclusões.
✅ Mais vídeos relacionados com esse:
MVP de microsserviço com TypeScript, Mongo e TDD | Behind the Code #10
• MVP de micro-serviço c...
Acompanhe a Rocketseat nas redes sociais:
Twitter: @rocketseat
Facebook: @rocketseat
Instagram: @rocketseat_oficial
Linkedin: @rocketseat
Nos ouça também no Spotify:
- Podcast Faladev
cara, esse formato ficou bom demais
Que show que curtiu, Natalia! Valeu demais pelo feedback! 💜 🚀
Na empresa onde trabalho não duplicamos os dados no DB do serviço. Usamos o Redash, que centraliza data sources de vários dos serviços e de varios formatos, ficando disponíveis pra consulta através de queries SQL. A query fica salva e pode-se definir um cache pra ela, com revalidação configurável. Então os serviços que precisam de dados de outros, podem consultar pela query_id os dados do Redash, que já vão estar em cache.
Seria um formato então de data center (banco de dados) com a uma api rest / redis (cache) que distribui as informações através da requisição ?? Fiz um sistema semelhante a este usando typeORM (nodejs) + redis (cache) para recuperar dados do data center a partir de views já pré definidas no banco
seria então uma tabela de usuario separada de qualquer sistema, na qual quando você quiser consumir, editar, inserir, é so chamar esta query(ou usar qualquer orm)?
Guilherme, não conhecia o Redash, mas o que acontece se ele cair? Existe algum impacto nos serviços que precisam consultar dados nele?
Como vocês lidam com indisponibilidade do serviço? Pelo que entendi o sistema fica completamente dependente dessa estratégia
@@tiagogoncalves6021 isso, mas o redash é somente pra leitura, os dados sao consultados nele através de uma api (passando o ID da query que já está salva)
@Rocketseat faz uma trilha de backend avançado que foque nessa parte 💜
A ideia é trazer cada vez mais esses assuntos pras trilhas existentes.
18:23 Como um desenho simples pode explodir nossa mente de uma forma tão grandiosa!!! Parabéns Diego pela clareza na explicação!
Esse tipo de vídeo com abstrações postas de forma gráfica fica muito bom, pois ajuda mentalizar os modelos. Parabéns!
Sempre trabalhei em monolitos. Quando parei pra estudar sobre arquitetura de microserviços, como o diego falou, o que mais foi dificil absorver foi a questão da consistência relacional de dados e concordo 100%, é uma questão de mindset e como vc enxerga o domínio da aplicacão. Parabéns pelo conteúdo.
Muito legal o conteúdo Diego! Essas dúvidas eu tenho muito também. Já que decidi migrar para microsserviço. Vai ser muito útil se você postar mais conteúdos como esse. Parabéns mais uma vez a vc e a Rocketseat!
Excelente conteúdo, gostaria bastante de conteúdos do padrão Rocket sobre uso do GRPC, Pub/Sub e afins no Node. Mas acho que um vídeo como esse entendendo o core da solução já é a base pra qualquer estudo de qualidade! :)
que video legal de se ver, adoraria ver videos nessa linha quase como um video "amador" sem tantas edições, video simples com um conteúdo sensacional.
Mais um dos infitos acertos da rocket esse formato ta f e n o m e n a l!! Parabéns!!!
Muito dificil achar um conteúdo tão claro e objetivo como vc mostrou no vídeo, parabéns ficou excelente !!!
Os videos nesse formato ficaram muito foda, parabéns.
Que massa que curtiu, Jhoy! Importante demais esse feedback pra nós! 💜 😍
Ontem o vídeo foi ótimo, é um posicionamento que te trás mais uma via de solução com base na POC de Diego, entretanto vejo que hoje, digo hoje pois assistir o vídeo duas vezes, tomei nota da experiência dele para fortalecer as minhas decisões pois sei como é difícil propor uma nova e/ou melhor solução, e de acordo com que se reobserva a prova de conceito a gnt passa a notar que o material agrega conhecimento de valor e por isso as apresentações de Diego tem se tornado melhor a cada dia. Parabéns Diego!
Tô justamente avaliando que abordagem usar para o próximo passo na empresa que trabalho e estava pesquisando sobre microsserviços. Não estava conseguindo imaginar iria ficar já que cada serviço deve ter seu DB, esclareceu muita coisa para mim e tenho certeza que para um monte de gente! Conteúdo super relevante! Obrigado pela contribuição para a comunidade!
Excelente didática e o novo formato de video! Estou ansioso para aprender mais sobre microserviços. Gostaria de ver a parte prática.
Muito bacana esse formato de vídeo, ficou top! Sobre comunicação assíncrona, eu descobri ela no meu trabalho novo há alguns meses atrás, a gente usa tanto rabbit mq quanto o Kafka, só que estamos em um processo de modernização e estamos tendendo mais para o Kafka. Mas claro, sou bem iniciante nesse assunto queria ver mais
Esse trio Nest + Graphql + Prisma eu vou estudar no ano que vem. E o formato tá bem legal, ainda mais descontraído.
Opaaa claro que quero ver mais sobre isso aee, se puder mostrar exemplos do uso como vocês fazem tô ansioso já
Achei incrível esse vídeo! Você consegui fazer eu entender de forma simples o porque de um micro serviço. Que venha o código! 😁👨🏾💻💻👊🏾💪🏾
Muito massa esses vídeos são incríveis, cara já deixando o Like Maroto e compartilhado.
Sempre bom aprender contigo.
Assisti o vídeo sobre tuas vídeo aulas e me deu uma luz pra resolver meu EAD.
Precisei aprender React para iniciar um projeto onde trabalho, fiz a tua primeira NLW na época, só com ela eu desenvolvi o projeto e imagina o que aconteceu, virei teu aluno KKKK.
Sucesso hoje e sempre e obrigado por tudo e todo o seu trabalho.
Curti demais esses conceitos.
Já ouvi muito, mas ainda tinha dificuldade em duplicidade de dados. Valeu!!!
tb fiquei bem surpreso qdo soube q duplicava.
mas a forma como vc colocou no livro clareou bastante e vou conseguir apoiar se alguem na empresa em q trabalho pensar ou nao em migrar p microservices.
a proposito, video ficou otimo tanto conteudo como o som, fundo etc =) vlw. parabens.
Incrivel o quanto o @Diego consegue tirar um pensamento que a pessoa tem na cabeça, sempre fui contra duplicação de dados mais vendo dessa forma fica tão simples de entender o porque duplicar e o cara mostra o quanto é correto : ) : )
Que incrível Diego! vídeo maravilhoso, to adorando esse formato vlog.
Que massa que ta curtindo, Alex! Valeu demais pelo feedback! 💜 🚀
Cara esse tipo de vídeo / formato acaba sendo MUITO mais VALIOSO do que um vídeo de tutorial. E olha que tutoriais são super úteis. Você comentou o problema e ainda MOSTROU a sua solução. Sensacional ver como os outros pensam.
Como instrutor de banco de dados, eu realmente fiquei surpreso sobre a duplicidade dos dados. Se possível, seria ótimo mostrar tanto o diagrama dos bds e como você tá fazendo essa integração entre as aplicações 🙏
Boa, no próximo vídeo vou trazer a parte mais técnica.
Fala Tyago, sobre a duplicação de dados, o segredo é mudar o paradigma e pensar como as empresas funcionavam antes da informática: papel carbono e três vias.
Quando uma venda é realizada, o pedido é copiado e cada via usada por uma parte da empresa. Uma via para a entrega, uma para o financeiro, uma para o controle de estoque, por exemplo. Cada “microserviço” da empresa vai usar a informação que necessita para tocar a sua atividade (itens e endereço pra entrega, preço e pagamento para o financeiro, etc.). E cada “microserviço” fica responsável por “se inscrever” a eventos que mudam esses dados (a entrega recebe notificação de mudança de endereço, mas o financeiro não precisa disso).
Ah! E as vias passando de mão em mão são naturalmente uma comunicação assíncrona! Pensa em uma pilha de recibos em cima da mesa esperando pra ser processado ;)
@@antoruby analogia perfeita!
De fato, quando o assunto é Microserviço, acredito que esse é o ponto de maior cautela... duplicação de dados, conexoes inter-serviços, etc...
Diego Muito bom seu vídeo, muito bem colocado... Vou compartilhar uma experiência que a mais ou menos um ano e meio eu tive... Faz uns 2 anos que sempre foquei em trabalhar com aplicações distribuídas, quando vejo que há um crescimento dessa aplicação em algum momento, e confesso que a ultima empresa que fiz parte, foi bem difícil trazer essa mudança de mindset, mesmo mostrando todos os lados positivos e o quanto para o cenário da empresa os positivos se sobressaem dos negativos. Até que fui desligado, dessa empresa rs... Não sei ao certo se foi por esse motivo, mas era muito evidente que o time estava estacionado, não aceitava sair da zona de conforto... Mas hoje eu vejo que foi a melhor coisa que aconteceu. :)
Grande abraço!
Show Diego !!! Como é bom "conversar" com mais gente pra clarear as ideias...
Eu estava criando alguns projetos baseados em MS, mas estava utilizando o Rabbit pra mensageria também porque com ele a gente consegue enviar mensagens síncronas, e era isso que eu estava fazendo para buscar algumas informações entre os MS.
Só que esse meu approach cria um acoplamento forte entre os MS, que eu não estava gostando muito.
Acho melhor a ideia de "duplicar" algumas informações entre os BDs, e mantê-las atualizadas de maneira assíncrona, assim mesmo que um MS caia, os outros (teoricamente) podem continuar funcionando sem problemas.
Grande abraço e se puder, gostaria de mais vídeos como esse... Já valeu o meu dia !!!
Muito bom esses vídeos sobre os desafios do dia a dia! Na empresa a gente tá com o desafio de quebrar um monolito também e estamos fazendo algo parecido, só que com SQS e SNS.
Sempre tem um trade-off, às vezes faz sentido duplicar uma informação para tornar o serviço mais independente, às vezes não.
Se possível fala sobre a parte de quebrar o banco atual e como estão transferindo os dados existentes, se precisam voltar dados para o banco principal para não quebrar processos, etc.
Formato muito show, conteúdo muito bom, altissímo nível. \o/ a Daniele tem que trazer um code/drops nesse contexto hein! haha
Booooooa, vamos cobrar ela! haha
Muito bom! Eu sempre achei muito complicado de entender a arquitetura de micro serviços, até por que eu sempre fui mais focado em front, mas esse vídeo ajudou bastante a entender de forma geral, traz o vídeo mostrando na prática!
Wooow! Que feedback massa, Igor! Deixa com a gente! 💜 🚀
Cara tô achando muito massa esse estilo de vídeo que vcs estão fazendo agora qualidade muito top.
Que massa que ta curtindo esse formato, Maxuell! Valeu demais pelo feedback! 💜 😍
Muito massa o video. Eu já tinha começado a estudar sobre microsserviços em uma bolsa da faculdade, e achei muito intessante, pois comecei a ter uma noção da quantidade de benefícios dessa abordagem, mas além disso da complexidade e dos problemas que podem vim, e por isso é bom estudar e avaliar para verificar se é essa transição é realmente algo viável. Além disso, também estudei esse conteúdo em uma disciplina da faculdade, e achei muito legal o professor ter trazido esse assunto e algumas tecnologias correlacionadas, como RabbitMQ e Kubertnets
18:33 Obrigado por enfatizar que elas são "duplicadas" Essa é a parte que a maioria das pessoas entende errado sobre Microservicos. Isso não é óbvio e eu diria que é o erro mais comum de quem adota Microservicos: Chamada rest pra todo lado estourando a latência. Tem um vídeo com o case da Dell chamado "Avoiding Microservicos Mega Disasters" que explica bem isso.
Parabéns pelo conteúdo publicado Diego, me pegava na mesma dúvida que vc, mas com este vídeo, felizmente, abriu ainda mais minha visão sobre o assunto...
Que feedback massa, Guilherme! Valeu demais! 😍 🚀
Muito bom, fiz um curso de banco de dados e consegui absorver como funciona o microserviço na prática
Maneiro de mais.
Massa Diego, parabéns pelo conteúdo, muito bacana essa abordagem. Já manda logo um #CodDrops disso tudo. Semana que vem já??? Kkkk
Muito bom! Quero ver isso tudo na prática e de preferência abordando como ficariam serviços separados com integridade referencial (ex se vc tivesse um microservico de turmas e outro de alunos).
Pô, traz pra nós o próximo vídeo mostrando os serviços. Muito bom!!
Vídeo Espetacular como sempre!
Concordo completamente.
O Elemar Junior da Eximia também segue essa mesma linha.
Valeu por compartilhar esses conhecimentos.
Bacana o vídeo. O único problema de usar apenas Pub/Sub é que se algum serviço não estiver on-line ele vai perder a atualização. Creio que utilizar uma message queue seria uma melhor opção pra ter uma garantia maior.
Muito bom trazer código e desenhos.. Estou curtindo muito os episódios! Parabéns!
Que massa que ta curtindo o novo formato, Gustavo! Valeu demais pelo feedback! 💜 🚀
Esses vlogs tão muito brabo, parabéns equipe, beijo Deschamps
Que massa que curte esse formato, Luan! Valeu demais! Essa equipe é braba! 💜 🚀
Concordo 100% com a "opinião" do framework. Isso vai unificar a equipe e aumentar a produtividade!
Muito massa! Cada ferramenta em seu quadrado e momento :)
Recomendo o estudo do CAP theorem!
Mano só foi que gostei demais desse formato de vídeo....
Ficou foda demais !!!!
Diego, parabéns pelo vídeo! Onde trabalho, diariamente enfrentamos este desafio e isso nos fez procurar soluções/padrões para resolver a questão. Recentemente, entramos nos estudos sobre as soluções de CDC (Change Data Capture). Já ouviu falar? Com ela, conseguimos gerar menos códigos "sincronizadores" e delegamos, à esta solução especialista em eventos de dados, a responsabilidade de sincronizar outras bases de dados ou, ainda, entregar os eventos aos serviços de mensageria. Casos de aplicação: bases analíticas e de outros microserviços (caso apresentado no seu vídeo).
Fala diego, faz um video mostrando o codigo da arquitetura de microserviços e a comunicação entre os serviço.
Video muito massa!!
Mereceu meu like. Parabéns!
Show de bola! Esse formato é bem bacana mesmo bem da hora...
Catapimbas, o vídeo certo no momento certo. Estou passando exatamente pelo que o Diego de um ano atrás passou
Interessante a forma de pensar para micro service e eu aprendi muito de arquitetura com vc hoje, trabalho com react native mas gosto também de backend.
Que massa esse formato de vídeo! O conteúdo também ficou show
Que massa que curtiu, Matheus! Valeu pelo feedback! 💜 🚀
Como vc perguntou no final, acho seria bem bacana mostrar o fluxo dos dados, os eventos e a recebição deles.
Ver o código ajuda, mas depois de muito tempo passei a preferir aprender como são as "Regras e passos do negocio". código mesmo a gente corre atras de fazer afinal uma mesma coisa pode ser codada de zilhoes de formas. desde que o input e output sejam os mesmos esperados
Esse formato é massa demais!!
Excelente conteúdo! Queremos ver o setup do Kafka ou outra ferramenta de comunicação assíncrona.
Mais um video maravilhoso, um exemplo pratico de uma emplementação referida no video seria top!!!!!!
Mas como sempre, conteudo de qualidade e de coração!!!!!!!
Muito bom! Legal programar a trigger na atualização da tabela de pessoas! Parabéns!
Fala Diego, acho que seria massa trazer mais sobre a parte prática!
Adotamos o NestJS aqui na minha empresa e já estamos colhendo os frutos, produtividade, organização de código e facilidade de manutenção! Antes usávamos JS puro.
O grande desafio do desacoplamento é a consistência (Vide o teorema CAP). Para serviços que não guardam estado(Sem banco de dados), show. Agora pensando como Bounded Contexts do DDD por exemplo, é que a porca torce o rabo. Na maioria dos casos é praticamente inviável desacoplar sem usar Event-Driven com um serviço de mensageria.
To nisso dai. Tenho o famoso exemplo de ecommerce onde quando realiza a compra o pessoal do estoque tem que remover um item do banco depois o pessoal do financeiro tem receber o dinheiro e por fim o pessoal do delivery entregar o produto. Caso ocorra um entre as transações o banco vai ficar inconsistente. To usando rabbitmq no spring e o pattern sagas.
Diego, parabéns pelo vídeo. O formato ficou top!
Gostei muito da stack adotada para os projetos de backend isolados, também comecei a usar o Nest recentemente e estou gostando muito.
O conceito que você apresentou faz muito sentido com a forma que vejo arquitetura distribuída. É realmente uma mudança de paradigma e traz seus desafios também.
Achei super bacana a ideia de você mostrar aplicações reais. Queria algumas ideias para monitoramento, governança e atualização de microsserviços desacoplamos e interdependentes.
A sugestão do Deschamps é muito boa. Trazer pessoas com experiência prática para abordar assuntos de interesse da comunidade e, quem sabe, mostrar um pouco de código seria bem legal.
Grande abraço!
Boa, no próximo já quero trazer código nessa parte :)
Viva,
Pergunta :
Como foi planeado o warmup dos serviços (email services), quer dizer no reboot, como alimenta a colecção inicial?
Excelente conteúdo, ansioso pelo vídeo com o código dessa solução!
Que massa que curtiu, Edu! 😍 💜
Fala Diego! Dizer que esse conteúdo é super interessante seria "chover no molhado" :). Obrigado por abordar, colocando luz sobre o tema!
O título desse vídeo é a essência do que muitos Devs sentem quando têm o primeiro contato com os microsserviços. Acho que de uma maneira bem natural, os paradigmas de normalização de bases de dados são primeiro "dogma" dos BDs relacionais que enfrentam resistência cognitiva em serem quebrados. Acho que a dúvida que você teve, todos nós temos também!!!
Distribuir dados (gerando redundância), os quais, em tese, deveriam ser únicos, é como "tirar um chão" (que sempre esteve ali) sob os pés de quem há bastante tempo se calça nas Formas Normais de normalização de BD relacionais.
As razões pelas quais isso DEVE acontecer (não tenho dúvidas, ou pelo menos não muitas kkk) nem sempre estão muito claras para todos. Resolvi então escrever, sob a ótica de quem está gostando muito do conteúdo, para fazer uma humilde sugestão para outros vídeos sobre o tema: Seria legal expor o Cenário, no que se refere a requisitos não funcionais. Explico melhor abaixo, mas creio que na cabeça do Dev ainda não ficam claras todas as questões que os microsserviços se propõem a solucionar.
Creio que a quebra de paradigma do BD Relacional e das aplicações monolíticas se justificam quando colocamos elementos adicionais para a solução de requisitos não funcionais. Traduzindo em miúdos, o cenário para o qual os microsserviços são uma solução necessária me parecem associados a:
1o. Desacoplamento, considerando uma visão pura de manutenibilidade, disponibilidade e escalabilidade;
2o. Volume x tempo de resposta, considerando um requisito não funcional importantíssimo para aplicações de grande porte;
Será que estou certo? Ou será que estou viajando no espaço sem propulsores? :)
Acho que fundamentar a decisão sobre quando quebrar os paradigmas e quando não, em detrimento de alguma razão clara e mensurável, é um tema muito muito importante.
Seria muito bacana expormos isso para a comunidade dar um próximo passo de maturidade em relação às suas decisões de arquitetura.
Teremos mais condições de decidir que tipo de foguete a gente usa para ir para Lua e que tipo precisamos para ir a Marte.
Um grande abraço e muito, muito obrigado por expor temas tão relevantes e importantes para nós desenvolvedores. O trabalho da Rocketseat não tem paralelo em termos de qualidade, relevância para o mercado e amadurecimento ágil dos Devs. #tamojunto
Muito esclarecedor esse vídeo, obrigado 👏👏👏😁
Cara é isso ir com cautela é o caminho !! não ir no by the book.. a granularidade correta , na real quantidade de equipe influencia na divisão neh.. não é so a visao de negócio mesmo.. show legal começar a levar essa cultura pro publico geral ajuda a comunidade a evoluir na maturidade.
Poderia fazer um POC de microserviços pra gente acompanhar o desenvolvimento
No meu trabalho estou criando um serviço de criação de pedidos que gera uma planilha de orçamentos para ajudar o time de atendimento. Ao invés de criar a planilha no momento da criação do ticket de atendimento, publiquei numa fila e um serverless fica ouvindo as alterações nela. Dessa forma a função cria a planilha e vincula numa conta Onedrive para o time desfrutar da mesma.
Ótimo vídeo Diogo 🚀
Muito bom esse formato!
Que massa que curtiu, Lucas! Valeu por trazer seu feedback! 😍 💜
Ótimo o novo formato!
Que bom que curtiu, Willian! Valeu pelo feedback! 💜 😍
Muito show!! @Rocketseat várias dúvidas me surgiram em torno dessa assunto :
- Qual a vantagem de usar outro banco de dados e qual seria o melhor tipo de banco para armazenamento desses informações simplificadas?? (Redis/MongoDB/PostgreSQL)
- Por que não usar outra conexão para o mesmo banco, já que a ideia é tornar independente da aplicação principal? Nada impede que duas aplicações possam interrogar o mesmo banco.
- Seria possível usar logstash para a sincronização desses dados? Usando templates específicas para alimentar os diferentes bancos de dados (simplificados), partindo do princípio que temos outros serviços com seu próprio banco, além desde de envio de e-mails.
Desde já agradeço pelo o vídeo, e obrigado pela a resposta a este comentário.
1. A vantagem de usar dois bancos é que os serviços ficam desacoplados e não preciso ficar buscando dados entre múltiplos serviços durante a execução. Você pode usar qualquer banco, a ideia é usarmos o conceito de banco de dados poliglota, ou seja, podemos ter bancos diferentes (Mongo, PG, MySQL) pra cada micro-serviço.
2. Duas aplicações com o mesmo banco causa acoplamento porque se o banco estiver lento por causa da aplicação A, a aplicação B sofre com isso.
3. Não sei, tenho pouco conhecimento em logstash.
Muito obrigada por compartilhar!
Esse cara e esse time são top!!!
Eu nao chamaria de "duplicidade", mas de "cache". No seu exemplo, [A] é o dono da informacao e [B] so faz um cache dos dados. Este dado nunca deveria ser alterado diretamente no lado de B (read-only), mas sempre atraves de eventos vindos de [A], como bem foi apresentado no seu exemplo.
Em relacao ao kafka, algumas dicas que podem ajudar:
- Definir uma message key (codigo do cliente, por exemplo) pra garantir a ordem das mensagens de uma mesma entidade;
- Pra valer a pena o Kafka, vc provavelmente vai implementar auto-commit, e logo precisará de em um mecanismo de retry e ate um DLQ (dead letter queue) pra quando seu consumer falhar;
Conteúdo muito bom, parabéns a ao grande Diego.
A minha questão é a seguinte: Ao desenvolver uma aplicação, vou directamente para microsserviços ou começo por um monolítico? Porque parece que uma arquitetura em microsserviços poderá levar um pouquinho de mais tempo.
Fala Diegao, gostaria de elogiar esse formato de vídeo, ficou excelente.
Faaaaala, Vini! Valeu demais pelo feedback! Que massa que curtiu esse formato! 😍 💜
Fala Diego! Você acha que seria interessante a criação de uma rotina de sincronização das bases de tempos em tempos? A ideia seria validar os dados no caso de quedas no microserviço de envio de e-mails onde ele acabou não "escutando" alguns eventos emitidos pelo serviço principal.
Bom demais, excelente explicação
Fala Diegão!
manda esse vídeo de toda essa estrutura na prática!! haha
e fiquei surpreso com a parte de duplicação de dados entre os serviços, feito por integração 🤯
e aqui na FIRMA, estamos planejando usar Nest + Graphql + Prisma nos próximos projetos :PPPPP
muito massa o conteúdo!! 🚀
Maaaaaassa demais!
Eu só não costumo usar o termo "dados duplicados", pois pode soar pejorativamente e algumas pessoas acabam entendendo errado (experiência própria), então eu uso o termo "dados distribuídos". E se vc não trabalhar dessa forma, vai matar uma das principais vantagens da arquitetura de micro-serviço: não ter um único ponto de falha. Mas, além do desafio de manter os dados distribuídos, é lidar com transações distribuídas nessa arquitetura, aí a coisa vai ficando mais complexa, mas existem patterns para resolver isso, como SAGA, por exemplo. Sem contar que, pode acontecer do seu Message Broker falhar, e a mensagem não ser entregue ao micro-serviço X, e você acabar tendo problemas de dados inconsistentes ou até mesmo a falta deles em algum micro-serviço. Enfim, trabalhar com esse tipo de arquitetura requer um certo cuidado, estudo, testes, etc. Sugiro a leitura do livro "Microsserviços prontos para produção" da Susan J. Fowler (Ex Gerente de SRE da Uber).
Ficou legal o modelo. Utilizo serviços parecidos, porem o BD é único. Cada serviço consome o que lhe interessa da base. Obviamente o tuning da base fica justo pra aguentar a carga. Backup, replicação também são pontos sensíveis.
A participação do Cleiton foi a melhor parte do vídeo 😂. Arrasaram! 🥳
Toque especial hahah 💜
Vídeo excelente, tava estudando afundo mas não ficava claro, agora está como a água.
Show!
Aguardando o próximo video! XD
Que massa que curtiu, Rodrigo! 😍 💜
esse tipo de vídeo e mttttttt bom
esse vídeo foi libertador
faz tempo que eu queria entender isso
Muito interessante sim, acho que pode fazer mais vídeos no código.
Na empresa onde eu trabalho, como usamos o azure pra tudo, acaba sendo utilizado o servicebus da microsoft em ambientes buildados pelo CI/CD, e em ambiente local é utilizamos o RabbitMQ, por realmente ser mais fácil. Outro fato interessante sobre, é que utilizamos muitas vezes mais de um MS pra uma feature, sendo muitas vezes um pra entrada do dado (podendo ser http2 ou amqp) e outro que utilizar esse dado pra alguma coisa, seja pra transforma, armazenar e tudo mais. Esse mundo de integrations é muito louco, cada dia me empolgo pra aprender mais sobre!
Sugiro na parte dos logs adicionar um campo chamado "PlatformID", dessa forma, sempre que houver um erro, você consegue saber em qual micro-serviço a falha nasceu, melhorando a observabilidade.
Fala João, cara, consegue dissertar mais sobre isso? Não entendi muito bem aonde adicionaria esse platform_id, na mensagem do Kafka?
@@dieegosf irá ser um atributo no body. O intuito é saber quem emitiu a mensagem, e nos logs (bugsnag, Kibana etc) também adicionar sempre esse identificador a fim de saber qual microserviço teve a excessão. No exemplo que você deu não se encaixaria, mas em microserviços, interdependentes, em que você abre mão da availability para ter o dado mais fresco, você vai ter uma requisição a ser trafegada entre 3, 4, ou mais serviços. Foi nesse intuito e cenário a sugestão.
Dá uma olhada em HATEOAS - Hypermedia as the Engine of Application State, um modelo desenvolvido por Leonard Richardson.
Nossa me apaixonei pelos vídeos de vcs , conheci pela Los grandes
Diego uma dica ... troca uma ideia com a galera da netshoes de backend porque eles ja trabalham com microserviços a muito tempo e talvez possam te dar uma luz do que são aplicadas em cada aplicação .. contexto de problemas e coisas que possam ajudar. Inclusive eu sei que trabalham com o kafka, tem redis, tem rabbit e varios outras ferramentas ... talvez se você conseguir falar com eles vai te abrir uma luz .. sem contar que é mais conteúdo avançado pros videos...
Como você lida com a questão de paralelismo e concorrência sem colocar a trava no banco de dados? Por exemplo, suponha que você queira atualizar um campo, mas só se ele estiver com um valor específico. Se chegarem dois requests ao mesmo tempo, um pode acabar sobrescrevendo o outro se você não tiver uma transaction no nível do banco que junta a consulta do valor com a atualização. Só que colocar no nível do banco começa a ficar ruim quando essa condição passa a precisar de mais de um banco.
Outro ponto é que um microservico nunca deve consultar o banco de dados do outro. Nem se quer deveria saber se o outro serviço usa ou não banco de dados. A comunicação deve ser direta com a fila de mensageria. Assim você garante desacoplamento e independência entre os serviços.
Usamos banco de dados sob demanda no ambiente da nuvem Microsoft Azure e isso trouxe muita liberdade e muito menos preocupação com banco de dados. Num motor principal as regras de negócios e no front Nuxt. Alias no ambiente Azure tem muitos recursos sob demanda, inclusive esses envios de e-mail. De fato tem muita roda pronta para uso. Ah sim, no motor não abrimos mão do C#.
Que legal seu depoimento. É sempre muito bom acompanhar a Rocketseat. Vai aqui uma dica de uma pessoa que gosta muito de backend: Quanto menor for o seu escopo, mais fácil serão as suas alterações ou expansões. Reduzir escopo significa especializar seus serviços. É aí que entram os conceitos de microsserviço e de redução de acoplamento, dentre outros. Abraço!! Sucesso!
Exato! Eu não sei se estou pensando certo, mas pra não trazer tanta fricção agora, pretendo fazer em etapas, separar um gigante em 10 menores e depois esses 10 menores serem especializados e divididos em 50 por exemplo, o que acha?
@@dieegosf Eu apoio 100%.
@@dieegosf A parte mais trabalhosa é alinhar a especialização com o banco de dados e suas restrições de integridade. O resto é delicinha, como diria nosso amigo Deschamps.
Dahora demais Diego! Foi só eu ou faz todo sentido a duplicação com o objetivo de desacoplamento ? Não sei se eu sou muito estranho ou penso que é muito mais fácil pensar em um microserviço do que em um monolito kkkk (ps: diego falando em 2x apareceu um cara estranho na porta de casa)
Estamos em um processo semelhante a esse. O monolito que foi criado chegou a um ponto de executar tantas ações que fica praticamente impossível acompanhar alguns erros ou mensurar algumas questões. A ideia de microservices parece ideal para nosso caso. O problema é que pouca coisa será reaproveitada e o problema principal está está ligado aos relacionamentos entre entidades do sistema, o que parece que será resolvido apenas com rotas restFull para todos eles ... Pelo menos parece até agora 😆. Conteúdo muito bom!
Boa Manoel, mas lembre que uma arquitetura de micro-serviços traz ainda mais dificuldades na observabilidade da aplicação.
O que me ajudou no início foi tentar visualizar, mentalmente, como vc criaria um serviço para ser um produto único e separado. Um serviço que vc poderia até mesmo oferecer o uso dele pra outra pessoa/empresa sem precisar acoplar.
Seguindo o exemplo do vídeo vc teria um produto que oferece serviço de e-mail e que sua única responsabilidade é lidar com os e-mails. Então nele teria o seu banco próprio para gravar/consultar os dados necessários pro envio (remetente, destinatários, corpo do e-mail, etc) e os dados de envio quando finalizado (data, hora, solicitante e etc). E quando precisar de consultar algo relacionado aos envios de e-mail ele seria o "source of truth".
Perfeita essa forma de pensar.
Fala Diego, beleza? O que acontece se o sistema B estiver fora quando o sistema A mandar o sinal de alguma atualização? Você assume o risco ou implementou algum gerenciamento sobre esse edge case?
Será que o Diego vai se lançar vloger ? assim disse alguém dias atrás... kkk ÓTIMO CONTEÚDO!
Será... 👀 😋