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)?
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.
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!
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.
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!
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.
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!
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 !!!
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.
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 🙏
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 ;)
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!
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.
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.
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.
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.
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!
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 : ) : )
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).
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
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!
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
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.
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 🚀
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! :)
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
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".
Vídeo Espetacular como sempre! Concordo completamente. O Elemar Junior da Eximia também segue essa mesma linha. Valeu por compartilhar esses conhecimentos.
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!! 🚀
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;
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
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...
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.
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).
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.
@@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.
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!
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!
A duplicidade de dados e comunicação assíncrona também foram meus principais pontos de dificuldade para entender, mas depois disso as coisas ficam um pouco mais fáceis. O próximo nível que eu estou enfrentando agora é na prática. Tentei ir para um lado mais simples ainda, os domínios nem sequer estão em projetos diferentes, apenas foram separados de uma forma modular, onde sua comunicação já é feita utilizando eventos, porém de forma síncrona. O banco de dados é único para toda a aplicação e não possui duplicidade, mesmo que na camada de domínio exista contextos diferentes com dados duplicados. Essa foi a maneira que encontrei para já desenvolver esse projeto em especifico com microserviços em mente, pois sei que ele precisa escalar e não queria desenvolver novamente partes dele.
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.
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.
26:26 Eu já conhecia essa área da arquitetura distribuída. Aprendi na faculdade, mas foi quase que puramente teórico. As práticas lá feitas foram irrisórias. Ainda não cheguei a colocar as mãos na massa, mas fazer um use case disso é um plano que tenho para um futuro próximo. Acho que todas essas ideias de sistemas distribuídos são muito interessantes e vantajosas em determinadas situações.
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).
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.
Eae Diegão, estou nos estudos e desenvolvimento de um projeto de microserviço, o escopo seria desenvolver uma Amazon ou Mercado Livre usando microserviços. De começo estou usando o NestJs e TypeORM, na comunicação entre os microserviço estou usando o Apache Kafka, e para as credenciais os usuários estou usando o KeyCloak, até o momento o que está desenvolvido é a api-gateway, user-engine, auth-engine e estou começando a desenvolver o product-engine, talvez esse projeto leve meses ou anos, mas estou aprendendo muito com essa nova metodologia de desacoplamento de responsabilidade de cada serviço. Talvez esse assunto seja interessante para todos, até para ninguem começar de formar errada em microserviços. Vou fazer um README lindão, e depois vou postar aqui os repositório desses microserviços.
Uma dúvida, nessa situação (22:04) não seria interessante ter um serviço de manipulação de usuário separado? Quero dizer, ao invés da aplicação A saber da aplicação B para enviar para ela a alteração de usuários, não seria melhor ter uma aplicação intermediária que receberia a alteração de A (ou de B) e dispararia tanto em A quanto em B o evento de alteração de usuário para que cada um lidasse como isso conforme suas necessidades?
Olá, Diego, gostaria de tirar uma dúvida: como fica a questão da autenticação e os hashs da senha do usuário na aplicação principal e o compartilhamento disso para as demais aplicações?
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...
nest é top. estou fazendo um serviço em NestJS de disparo de notificação SMS (também por voz), EMAIL e push notification para um banco (banco mesmo $) de MG. da pra fazer tudo nele para a api e lambdas
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!!!!!!!
Padrão Event Driven com Observer é bom de mais pra desacoplar. Tipo, se a gente tem um app que tem nuitas sub-funcionalidades basta disparar um evento com os dados associados. Fica legal pq dá pra a gente programar as partes separadamente sem nem se preocupar se aquele miniapp tá funcionando dentro de outro :D
Aliás, algo que me ajudou bastante a começar entender foi a playlist do Felipe Deschamps do jogo multiplayer. Depois disso foi bem legal extrair essa arquitetura pra uma mini lib que tenho usado em alguns projetos. Aliás, dá pra implementar em outras linguagens também; vale a pena estudar esses conceitos ^^
Como funciona a sincronia dos eventos? Digo que sendo assincrono acredito que não tenha garantia de ordem dos eventos, então o que acontece se o evento de enviar um e-mail de criação de conta chegue antes do evento que duplica o usuário na base do microservico que envia e-mail?
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#.
É quando começamos a falar de softwares mais complexos que fica evidenciado a importância de uma boa arquitetura. Muito bom você citar o site do Martin Fowler. Talvez seja legal também citar o livro dele DDD, e também começar a introduzir o conceito de eventos de domínio, que, facilitam a compreensão de como serviços podem se comunicar de maneiras mais compreensíveis. Uma observação para os novatos (me incluo nessa), que eu acho que não ficou bem explicado. Serviços distribuídos não podem ser síncronos, pois, isto diminui a disponibilidade. Afinal, quando um serviço cai, os outros que dependem deste, ficam indisponíveis também. No entanto, quando os serviços que dependem entre si, são assíncronos e caem, os que permanecem conseguem continuar operando. Outra observação: Nada é escrito em pedra, portanto, soluções que funcionam muito bem num determinado cenário podem não funcionar em outro.
cara, esse formato ficou bom demais
Que show que curtiu, Natalia! Valeu demais pelo feedback! 💜 🚀
18:23 Como um desenho simples pode explodir nossa mente de uma forma tão grandiosa!!! Parabéns Diego pela clareza na explicação!
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
@@tiago.gcastro 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)
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.
@Rocketseat faz uma trilha de backend avançado que foque nessa parte 💜
A ideia é trazer cada vez mais esses assuntos pras trilhas existentes.
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!
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.
Os videos nesse formato ficaram muito foda, parabéns.
Que massa que curtiu, Jhoy! Importante demais esse feedback pra nós! 💜 😍
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.
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!
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.
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! 💜 🚀
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 !!!
Esse tipo de vídeo com abstrações postas de forma gráfica fica muito bom, pois ajuda mentalizar os modelos. Parabéns!
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.
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...
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!
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.
Mano só foi que gostei demais desse formato de vídeo....
Ficou foda demais !!!!
Muito dificil achar um conteúdo tão claro e objetivo como vc mostrou no vídeo, parabéns ficou excelente !!!
Fala diego, faz um video mostrando o codigo da arquitetura de microserviços e a comunicação entre os serviço.
Video muito massa!!
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.
Muito bom, fiz um curso de banco de dados e consegui absorver como funciona o microserviço na prática
Maneiro de mais.
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.
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.
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 :)
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 : ) : )
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).
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.
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!
Poderia fazer um POC de microserviços pra gente acompanhar o desenvolvimento
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
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 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.
Que incrível Diego! vídeo maravilhoso, to adorando esse formato vlog.
Que massa que ta curtindo, Alex! Valeu demais pelo feedback! 💜 🚀
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 🚀
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! :)
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
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.
Mais um dos infitos acertos da rocket esse formato ta f e n o m e n a l!! Parabéns!!!
Vídeo excelente, tava estudando afundo mas não ficava claro, agora está como a água.
Vídeo Espetacular como sempre!
Concordo completamente.
O Elemar Junior da Eximia também segue essa mesma linha.
Valeu por compartilhar esses conhecimentos.
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! 💜 😍
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 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;
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
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! 😍 🚀
Catapimbas, o vídeo certo no momento certo. Estou passando exatamente pelo que o Diego de um ano atrás passou
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! 💜 🚀
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.
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).
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!
Excelente didática e o novo formato de video! Estou ansioso para aprender mais sobre microserviços. Gostaria de ver a parte prática.
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.
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!
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.
A duplicidade de dados e comunicação assíncrona também foram meus principais pontos de dificuldade para entender, mas depois disso as coisas ficam um pouco mais fáceis.
O próximo nível que eu estou enfrentando agora é na prática. Tentei ir para um lado mais simples ainda, os domínios nem sequer estão em projetos diferentes, apenas foram separados de uma forma modular, onde sua comunicação já é feita utilizando eventos, porém de forma síncrona. O banco de dados é único para toda a aplicação e não possui duplicidade, mesmo que na camada de domínio exista contextos diferentes com dados duplicados.
Essa foi a maneira que encontrei para já desenvolver esse projeto em especifico com microserviços em mente, pois sei que ele precisa escalar e não queria desenvolver novamente partes dele.
Fala Diegao, gostaria de elogiar esse formato de vídeo, ficou excelente.
Faaaaala, Vini! Valeu demais pelo feedback! Que massa que curtiu esse formato! 😍 💜
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! 😁👨🏾💻💻👊🏾💪🏾
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.
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.
Esse formato é massa demais!!
26:26 Eu já conhecia essa área da arquitetura distribuída. Aprendi na faculdade, mas foi quase que puramente teórico. As práticas lá feitas foram irrisórias. Ainda não cheguei a colocar as mãos na massa, mas fazer um use case disso é um plano que tenho para um futuro próximo. Acho que todas essas ideias de sistemas distribuídos são muito interessantes e vantajosas em determinadas situações.
No próximo vídeo pretendo trazer uma visão prática disso tudo.
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).
Mereceu meu like. Parabéns!
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.
Viva,
Pergunta :
Como foi planeado o warmup dos serviços (email services), quer dizer no reboot, como alimenta a colecção inicial?
Curti demais esses conceitos.
Já ouvi muito, mas ainda tinha dificuldade em duplicidade de dados. Valeu!!!
Opaaa claro que quero ver mais sobre isso aee, se puder mostrar exemplos do uso como vocês fazem tô ansioso já
Finalmente uma opinião lúcida sobre microsserviços.
Curtiu o conteúdo, Rodrigo? 💜
Eae Diegão, estou nos estudos e desenvolvimento de um projeto de microserviço, o escopo seria desenvolver uma Amazon ou Mercado Livre usando microserviços. De começo estou usando o NestJs e TypeORM, na comunicação entre os microserviço estou usando o Apache Kafka, e para as credenciais os usuários estou usando o KeyCloak, até o momento o que está desenvolvido é a api-gateway, user-engine, auth-engine e estou começando a desenvolver o product-engine, talvez esse projeto leve meses ou anos, mas estou aprendendo muito com essa nova metodologia de desacoplamento de responsabilidade de cada serviço. Talvez esse assunto seja interessante para todos, até para ninguem começar de formar errada em microserviços. Vou fazer um README lindão, e depois vou postar aqui os repositório desses microserviços.
Booooooa, ia ser incrível compartilhar isso.
Gostei do monitor, poderia informar qual a referencia dele?
salve rocket, vai ter video de Github-cli?
Pô, traz pra nós o próximo vídeo mostrando os serviços. Muito bom!!
Nossa me apaixonei pelos vídeos de vcs , conheci pela Los grandes
Uma dúvida, nessa situação (22:04) não seria interessante ter um serviço de manipulação de usuário separado? Quero dizer, ao invés da aplicação A saber da aplicação B para enviar para ela a alteração de usuários, não seria melhor ter uma aplicação intermediária que receberia a alteração de A (ou de B) e dispararia tanto em A quanto em B o evento de alteração de usuário para que cada um lidasse como isso conforme suas necessidades?
Qual a configuracao do teu pc
Olá, Diego, gostaria de tirar uma dúvida: como fica a questão da autenticação e os hashs da senha do usuário na aplicação principal e o compartilhamento disso para as demais aplicações?
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...
Muito bom! Legal programar a trigger na atualização da tabela de pessoas! Parabéns!
Esses vlogs tão muito brabo, parabéns equipe, beijo Deschamps
Que massa que curte esse formato, Luan! Valeu demais! Essa equipe é braba! 💜 🚀
Muito esclarecedor esse vídeo, obrigado 👏👏👏😁
Sempre critiquei duplicação de dados, mas dessa forma que foi apresentado faz total sentido kkkkkk.
Muito bom, vlw!!!
nest é top. estou fazendo um serviço em NestJS de disparo de notificação SMS (também por voz), EMAIL e push notification para um banco (banco mesmo $) de MG. da pra fazer tudo nele para a api e lambdas
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!!!!!!!
Excelente conteúdo! Queremos ver o setup do Kafka ou outra ferramenta de comunicação assíncrona.
Que massa esse formato de vídeo! O conteúdo também ficou show
Que massa que curtiu, Matheus! Valeu pelo feedback! 💜 🚀
Padrão Event Driven com Observer é bom de mais pra desacoplar. Tipo, se a gente tem um app que tem nuitas sub-funcionalidades basta disparar um evento com os dados associados. Fica legal pq dá pra a gente programar as partes separadamente sem nem se preocupar se aquele miniapp tá funcionando dentro de outro :D
Aliás, algo que me ajudou bastante a começar entender foi a playlist do Felipe Deschamps do jogo multiplayer. Depois disso foi bem legal extrair essa arquitetura pra uma mini lib que tenho usado em alguns projetos. Aliás, dá pra implementar em outras linguagens também; vale a pena estudar esses conceitos ^^
@@LucasAlfare Massa, pretendemos usar bastante eventos e até usar Event Sourcing com CQRS em alguns serviços.
Como funciona a sincronia dos eventos? Digo que sendo assincrono acredito que não tenha garantia de ordem dos eventos, então o que acontece se o evento de enviar um e-mail de criação de conta chegue antes do evento que duplica o usuário na base do microservico que envia e-mail?
Gostei do vídeo .. mostrou bem embora resumida o que são microserviços e a mensageria
esse vídeo foi libertador
faz tempo que eu queria entender isso
Qual o nome programa que usa pra acessar o Github? Seali?
Fala Diego, acho que seria massa trazer mais sobre a parte prática!
Massa Diego, parabéns pelo conteúdo, muito bacana essa abordagem. Já manda logo um #CodDrops disso tudo. Semana que vem já??? Kkkk
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#.
A participação do Cleiton foi a melhor parte do vídeo 😂. Arrasaram! 🥳
Toque especial hahah 💜
É quando começamos a falar de softwares mais complexos que fica evidenciado a importância de uma boa arquitetura. Muito bom você citar o site do Martin Fowler. Talvez seja legal também citar o livro dele DDD, e também começar a introduzir o conceito de eventos de domínio, que, facilitam a compreensão de como serviços podem se comunicar de maneiras mais compreensíveis.
Uma observação para os novatos (me incluo nessa), que eu acho que não ficou bem explicado. Serviços distribuídos não podem ser síncronos, pois, isto diminui a disponibilidade. Afinal, quando um serviço cai, os outros que dependem deste, ficam indisponíveis também. No entanto, quando os serviços que dependem entre si, são assíncronos e caem, os que permanecem conseguem continuar operando.
Outra observação: Nada é escrito em pedra, portanto, soluções que funcionam muito bem num determinado cenário podem não funcionar em outro.
Diego mostra como ficou a infra também!
Bom demais, excelente explicação