\n \n \n Benef\u00edcios dos Microservices\n<\/h3>\n\n
A utiliza\u00e7\u00e3o de microservices aparece para solucionar problemas como:<\/p>\n\n
- \n
- \nEscalabilidade e Alta Disponibilidade:<\/strong> Com microservices aliados a estrat\u00e9gias de DevOps, \u00e9 poss\u00edvel identificar gargalos de forma facilitada, devido \u00e0 separa\u00e7\u00e3o de dom\u00ednios das aplica\u00e7\u00f5es, e aplicar escalabilidade horizontal apenas nos pontos de gargalo.<\/li>\n
- \nPromo\u00e7\u00e3o de T\u00e9cnicas de CI\/CD:<\/strong> Como um mesmo sistema possui suas funcionalidades distribu\u00eddas em servi\u00e7os independentes, a integra\u00e7\u00e3o e implanta\u00e7\u00e3o de c\u00f3digo tamb\u00e9m ser\u00e3o independentes, permitindo deploys a qualquer momento de qualquer parte do sistema.<\/li>\n
- \nPromo\u00e7\u00e3o do Desenvolvimento de Testes:<\/strong> Utilizando servi\u00e7os com contextos menores e bem definidos, os desenvolvedores ter\u00e3o um maior poder de teste, visto que n\u00e3o ter\u00e3o que realizar mocks de l\u00f3gicas alheias \u00e0 funcionalidade que est\u00e3o desenvolvendo.<\/li>\n<\/ul>\n\n
\n \n \n Desafios dos Microservices\n<\/h3>\n\n
Apesar de solucionar alguns problemas, tamb\u00e9m surgem desafios como:<\/p>\n\n
- \n
- \nComplexidade do Sistema:<\/strong> Um sistema monol\u00edtico, querendo ou n\u00e3o, \u00e9 mais simples que um sistema de microservices distribu\u00eddos, pois todas as funcionalidades e regras de neg\u00f3cio s\u00e3o concentradas em um s\u00f3 lugar, facilitando l\u00f3gicas de rollbacks, por exemplo.<\/li>\n
- \nPontos de Falhas:<\/strong> Quanto mais microservices o sistema tiver, mais pontos de falhas ele pode ter.<\/li>\n
- \nObservabilidade:<\/strong> Como vamos trabalhar com mais pontos de falhas, a observabilidade se torna algo crucial para todos os microservices, coletando e analisando logs, m\u00e9tricas e traces (gerando um novo desafio, trace distribu\u00eddo).<\/li>\n
- \nConsist\u00eancia dos Dados:<\/strong> Com o sistema distribu\u00eddo, tornam-se necess\u00e1rias pr\u00e1ticas para manter a consist\u00eancia dos dados em todos os pontos da aplica\u00e7\u00e3o, visto que com aplica\u00e7\u00f5es distribu\u00eddas, as transa\u00e7\u00f5es que acontecem no sistema tamb\u00e9m ser\u00e3o distribu\u00eddas, necessitando do maior n\u00edvel de consist\u00eancia de dados poss\u00edvel.<\/li>\n<\/ul>\n\n
\n \n \n Transa\u00e7\u00f5es Distribu\u00eddas em Microservices\n<\/h3>\n\n
Transa\u00e7\u00f5es distribu\u00eddas nada mais s\u00e3o que transa\u00e7\u00f5es normais, como em banco de dados, mas distribu\u00eddas ao longo dos microservices envolvidos no sistema distribu\u00eddo. Ou seja, devem respeitar os princ\u00edpios de atomicidade, consist\u00eancia, isolamento e durabilidade.<\/p>\n\n
\n \n \n Exemplo de Transa\u00e7\u00e3o Distribu\u00edda\n<\/h3>\n\n
Como um bom exemplo, podemos utilizar uma l\u00f3gica de realizar um pedido em um sistema hipot\u00e9tico. Esse pedido segue a seguinte l\u00f3gica:<\/p>\n\n
- \n
- Receber o pedido<\/li>\n
- Validar o pedido recebido<\/li>\n
- Validar o estoque<\/li>\n
- Criar a cobran\u00e7a para o cliente<\/li>\n<\/ol>\n\n
\n \n \n Microservices e Rollback Distribu\u00eddo\n<\/h3>\n\n
Dentro de um monolito, essa opera\u00e7\u00e3o pode ser simples, podendo ser realizada dentro de um caso de uso, por exemplo. Mas, quando falamos de microservices, podemos quebrar essa l\u00f3gica em 4 microservices independentes, e \u00e9 a\u00ed que os desafios come\u00e7am.<\/p>\n\n
\n \n \n Exemplo de Implementa\u00e7\u00e3o com Microservices\n<\/h3>\n\n
Vamos supor a utiliza\u00e7\u00e3o de quatro microservices:<\/p>\n\n
- \n
- API para realizar a comunica\u00e7\u00e3o com sistemas\/usu\u00e1rios externos<\/li>\n
- Servi\u00e7o de valida\u00e7\u00e3o de pedidos<\/li>\n
- Servi\u00e7o de valida\u00e7\u00e3o de estoque<\/li>\n
- Servi\u00e7o de pagamento<\/li>\n<\/ol>\n\n
Nesse caso, supondo um fluxo de \u201ca\u201d para \u201cd\u201d, se ocorrer algum erro, por exemplo, n\u00e3o ter o produto em estoque, a ordem de compra deve ser inteira cancelada. Esse rollback distribu\u00eddo \u00e9 uma opera\u00e7\u00e3o cr\u00edtica e muito mais complexa do que se tudo estivesse concentrado em apenas um monolito, pois surge a necessidade de comunica\u00e7\u00e3o entre os microservices de forma coordenada.<\/p>\n\n
\n \n \n Comunica\u00e7\u00e3o Ass\u00edncrona entre Microservices\n<\/h3>\n\n
Para sanar a necessidade de comunica\u00e7\u00e3o, e levando em conta que estamos trabalhando com sistemas distribu\u00eddos, nada melhor do que usarmos um sistema de comunica\u00e7\u00e3o que permita comunica\u00e7\u00e3o ass\u00edncrona entre aplica\u00e7\u00f5es. Nesses casos, me v\u00eam \u00e0 mente servi\u00e7os como Kafka e RabbitMQ, dois brokers de mensagens amplamente utilizados, mas qual devo utilizar?<\/p>\n\n
\n \n \n Compara\u00e7\u00e3o entre RabbitMQ e Kafka\n<\/h3>\n\n
A escolha entre RabbitMQ e Kafka deve ser feita levando em conta o contexto da aplica\u00e7\u00e3o e o objetivo da comunica\u00e7\u00e3o ass\u00edncrona entre as aplica\u00e7\u00f5es.<\/p>\n\n
- \n
- \nRabbitMQ<\/strong> trabalha com um sistema muito parecido com uma fila (estrutura de dados), excluindo a mensagem ap\u00f3s ser consumida.<\/li>\n
- \nKafka<\/strong> trabalha com a ideia de Pub\/Sub, onde produtores publicam mensagens (eventos) em t\u00f3picos e consumidores se inscrevem nesses t\u00f3picos para receber os eventos que ser\u00e3o transmitidos nesse t\u00f3pico. O Kafka tamb\u00e9m trabalha com parti\u00e7\u00f5es em seus t\u00f3picos, permitindo a distribui\u00e7\u00e3o de eventos em paralelo, ampliando a capacidade de leitura e escrita de um t\u00f3pico.<\/li>\n<\/ul>\n\n
Para esse exemplo, vou utilizar o Kafka devido \u00e0 sua capacidade de reten\u00e7\u00e3o de eventos.<\/p>\n\n
\n \n \n Implementa\u00e7\u00e3o de Padr\u00e3o SAGA em Microservices\n<\/h3>\n\n
Ok, temos a estrutura de microservices definidas e a forma de comunica\u00e7\u00e3o entre eles, mas ainda precisamos fazer algo em rela\u00e7\u00e3o ao fluxo de transa\u00e7\u00e3o distribu\u00edda.<\/p>\n\n
Para auxiliar no problema de transa\u00e7\u00e3o que temos, podemos utilizar o padr\u00e3o de microservices chamado de SAGA<\/strong>, que aparece para garantir que a execu\u00e7\u00e3o de um fluxo de transa\u00e7\u00e3o distribu\u00edda ocorra de forma correta e que, em caso de falhas, todos os rollbacks sejam executados.<\/p>\n\n
\n \n \n SAGA Orquestrado vs. SAGA Coreografado\n<\/h3>\n\n
As duas formas de implementa\u00e7\u00e3o do padr\u00e3o SAGA entregam o mesmo resultado, por\u00e9m existem particularidades em cada uma.<\/p>\n\n
- \n
- \nSAGA Orquestrado<\/strong>: Parte da adi\u00e7\u00e3o de um novo microservice na arquitetura de microservice presente, respons\u00e1vel por centralizar todos os eventos nele e realizar de fato a orquestra\u00e7\u00e3o desses eventos (SEC - Saga Execution Controller).<\/li>\n
- \nSAGA Coreografado<\/strong>: Nessa abordagem, cada microservice tem conhecimento do servi\u00e7o anterior e posterior a ele para que consiga executar o fluxo em casos de sucesso e de rollbacks.<\/li>\n<\/ul>\n\n
Para esse exemplo, vou utilizar o padr\u00e3o SAGA orquestrado e a organiza\u00e7\u00e3o de t\u00f3picos ficar\u00e1 da seguinte maneira:<\/p>\n\n
- \n
- Todos os microservices v\u00e3o gerar eventos para o t\u00f3pico \u201cORQUESTRADOR\u201d, t\u00f3pico consumido pelo SEC.<\/li>\n
- Cada microservice vai receber eventos de dois t\u00f3picos, um para o caso de realizar uma a\u00e7\u00e3o com sucesso e outro para realizar o rollback do evento da vez.<\/li>\n<\/ol>\n\n
Exemplo de arquitetura.
\n![\"Exemplo](\"https:\/\/media.dev.to\/cdn-cgi\/image\/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto\/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F3lna7qd6iiun1wq70h1d.png\")
<\/a><\/p>\n\n\n \n \n Considera\u00e7\u00f5es Finais\n<\/h3>\n\n
Um ponto que se deve levar em conta \u00e9 a idempot\u00eancia de eventos<\/strong>, ou seja, um evento de pagamento, por exemplo, n\u00e3o deve ser executado duas vezes, ent\u00e3o mecanismos como identificador \u00fanico e verifica\u00e7\u00f5es em banco de dados devem ser implementados, principalmente em ambientes com redund\u00e2ncia a n\u00edvel de cluster do Kafka.<\/p>\n\n
\n \n \n Recursos extras\n<\/h2>\n\n
- \n
- Padr\u00e3o SAGA: padrao-saga<\/a>\n<\/li>\n
- ACID: ACID<\/a>\n<\/li>\n
- Microservices: microservices<\/a>\n<\/li>\n
- Repo com c\u00f3digo de exemplo: joserafaelSH\/first-saga-pattern-app<\/a>\n<\/li>\n
- kafka-x-rabbitmq : kafka-x-rabbitmq<\/a>\n<\/li>\n<\/ul>\n\n"},{"title":"Caso de uso: LocalStack","pubDate":"Fri, 05 Jul 2024 02:46:39 +0000","link":"https:\/\/dev.to\/joserafaelsh\/caso-de-uso-localstack-3gc5","guid":"https:\/\/dev.to\/joserafaelsh\/caso-de-uso-localstack-3gc5","description":"
\n \n \n Um pouco sobre o LocalStack\n<\/h2>\n\n
O LocalStack<\/strong> \u00e9 um emulador de servi\u00e7os AWS<\/strong> que abrange seus principais servi\u00e7os, alguns de forma gratuita e outros n\u00e3o. O objetivo dessa ferramenta \u00e9 facilitar o desenvolvimento de aplica\u00e7\u00f5es que utilizam servi\u00e7os da AWS<\/strong>, aumentando a seguran\u00e7a em rela\u00e7\u00e3o a custos de desenvolvimento, melhorando a experi\u00eancia do desenvolvedor em rela\u00e7\u00e3o a problemas de configura\u00e7\u00f5es de permiss\u00f5es com o IAM<\/strong> e permitindo a exist\u00eancia de um ambiente de testes, visando tanto a parte de aprendizado e experimenta\u00e7\u00e3o dos servi\u00e7os da AWS<\/strong>, quanto processos como CI<\/strong> com integra\u00e7\u00f5es com o Github Actions.<\/p>\n\n
- ACID: ACID<\/a>\n<\/li>\n
- Padr\u00e3o SAGA: padrao-saga<\/a>\n<\/li>\n
- \nSAGA Coreografado<\/strong>: Nessa abordagem, cada microservice tem conhecimento do servi\u00e7o anterior e posterior a ele para que consiga executar o fluxo em casos de sucesso e de rollbacks.<\/li>\n<\/ul>\n\n
- \nKafka<\/strong> trabalha com a ideia de Pub\/Sub, onde produtores publicam mensagens (eventos) em t\u00f3picos e consumidores se inscrevem nesses t\u00f3picos para receber os eventos que ser\u00e3o transmitidos nesse t\u00f3pico. O Kafka tamb\u00e9m trabalha com parti\u00e7\u00f5es em seus t\u00f3picos, permitindo a distribui\u00e7\u00e3o de eventos em paralelo, ampliando a capacidade de leitura e escrita de um t\u00f3pico.<\/li>\n<\/ul>\n\n
- \nRabbitMQ<\/strong> trabalha com um sistema muito parecido com uma fila (estrutura de dados), excluindo a mensagem ap\u00f3s ser consumida.<\/li>\n
- \nPontos de Falhas:<\/strong> Quanto mais microservices o sistema tiver, mais pontos de falhas ele pode ter.<\/li>\n
- \nPromo\u00e7\u00e3o de T\u00e9cnicas de CI\/CD:<\/strong> Como um mesmo sistema possui suas funcionalidades distribu\u00eddas em servi\u00e7os independentes, a integra\u00e7\u00e3o e implanta\u00e7\u00e3o de c\u00f3digo tamb\u00e9m ser\u00e3o independentes, permitindo deploys a qualquer momento de qualquer parte do sistema.<\/li>\n