none
Arquitetura de microserviços RRS feed

  • Pergunta

  • Boa tarde !

    Estamos desenvolvendo uma arquitetura de microserviços no trabalho, e gostaria de saber como posso usar transação nesta arquitetura, imagina que eu tenho:

    Microserviço A

    Microserviço B

    A aplicação web chama o microserviço A, passando um objeto A para gravar no banco, porém este objeto possui uma lista de um determinado objeto B, que é de responsabilidade do microserviço B gravar, como eu poderia garantir a transação neste caso ?

    Visto que são serviços distintos em webapplications distintas no IIS ?

    Atualmente ele está chegando no gateway e mandando gravar em uma api o objeto A, ele pega o retorno da gravação do objeto A e o gateway chama o proxy passando uma lista do objeto B para a api do microserviço B.

    Grava e retorna para a tela.

    Porém se da erro no microserviço B, como eu deveria atuar ?

    Como fazer "rollback" do que foi feito no microserviço A ?

    Obrigado.

    Marco.

    sexta-feira, 9 de outubro de 2015 18:23

Respostas

  • A primeira coisa que deve ser dita é que os microserviços são independentes entre si, criar esse tipo de dependência fere completamente o princípio da Arquitetura de Microserviços.

    Essa sua dúvida significa que vocês precisam ver melhor as regras de negócio aplicadas à esses dois microserviços e verificar se não está havendo alguma sobreposição de regras, pois essa dependência não pode existir.

    E o que eu entendi também foi o seguinte: você tem dois microserviços separados em IIS, mas tem apenas uma Gateway API? se a sua resposta for não, então você também precisa rever isto, pois deve existir apenas um gateway API centralizando seus microserviços.

    Coloco aqui o link sobre uma hangout que fizemos, eu, o Renato Groff e o Joel Rodrigues sobre essa Arquitetura, é um hang introdutório e acho que pode ser muito útil pra você.

    Segue: Arquitetura de Microserviços

    Qualquer coisa, pode perguntar por aqui que te ajudo com o maior prazer.

    Forte Abraço


    • Editado Gabriel Simas domingo, 11 de outubro de 2015 00:57 Escrevi coisa errada
    • Sugerido como Resposta Renato GroffeMVP domingo, 11 de outubro de 2015 01:24
    • Marcado como Resposta Marco_Alexandre segunda-feira, 12 de outubro de 2015 02:56
    domingo, 11 de outubro de 2015 00:55
  • Concordo com o que o Gabriel comentou e ainda gostaria de lembrar que abordagens como SOA e REST, além de Microservices que surgiu a partir das mesmas, pregam a implementação de serviços stateless.

    Essa independência de estados é fundamental em questões envolvendo isolamento de serviços, além de facilitar outros aspectos como melhor escalabilidade e facilidade de mudanças futuras em um projeto.

    • Marcado como Resposta Marco_Alexandre segunda-feira, 12 de outubro de 2015 02:56
    domingo, 11 de outubro de 2015 01:01
  • Boa noite Gabriel !

    Obrigado pela explicação, na verdade como você deve imaginar, de fato há outros microservicos na aplicação, porém coloquei A e B só para exemplificar, vejamos por exemplo estes cenários:

    Cenário1: Eu vou gravar um objeto de cupom de venda, e este cupom possui itens em seu cupom, neste caso eu poderia gravar no mesmo microservico de cupom (cupom e itens de cupom), mas imagina que neste mesmo objeto de cupom e durante esta operação de gravação do cupom, eu teria outras operações envolvidas que refletem no ERP em geral, por exemplo operações de gravação de dados de impostos do cupom, etc....
    Imposto para mim ja seria um outro microserviço de impostos, eu fico pensando, como eu garantiria a Atomicidade.


    Marco.

    Você está pensando como Microserviços de forma macro, e isso é ótimo, significa que você está compreendendo bem o que eles podem fazer, esse tipo de dúvida é pertinente ao extremo, deixa eu ver se eu posso te ajudar.

    Resposta do Cenário 1)
    Lembrando que você precisa ter uma Gateway API só aí você pode utilizar os métodos de chamada que quiser.

    No trecho "Eu vou gravar um objeto de cupom de venda, e este cupom possui itens em seu cupom, neste caso eu poderia gravar no mesmo microservico de cupom (cupom e itens de cupom)"

    Perfeito seu raciocínio, você teria um microserviço para controlar o cupom e seus itens, mas isso vai depender do seu domínio, ou seja, um microserviço nada mais é do que um "pacote" contendo todas as suas regras de negócio dentro de um contexto específico.

    Depois "...mas imagina que neste mesmo objeto de cupom e durante esta operação de gravação do cupom, eu teria outras operações envolvidas que refletem no ERP em geral, por exemplo operações de gravação de dados de impostos do cupom, etc...."
    Se isso acontecer, caímos em um assunto nevrálgico de microservicos: Duplicação dos dados ou integração via Mensageria. Como dissemos, um microserviço, de acordo com a regra deve ter uma base de dados só pra ele, isso mesmo base de dados e não uma tabela apenas, mas, essa regra podemos bypassá-la em detrimento do projeto como sempre.
    Nesse caso, temos duas opções: 
    1) observar a sua regra de negócios e ver se realmente o Imposto faz parte da regra de negócio de cupons, se fizer, você vai precisar adequar isso ao seu microserviço de cupons.
    2) Ou se você quiser, ser mais rápido, separar as ações e na camada de UI você executar essas operações em ordem oriundas de microserviços diferentes, um exemplo, imaginemos que temos a UI abaixo:
    1) Cliente salva o cupom utilizando o Microserviço de cupons
    2) após isso um método na UI, seja por camada de infra, BLL ou o que for, acessar o microserviço de imposto e utilizá-lo, tudo de forma sequencial dentro da UI.
    É também uma regra que Microserviço não acesso microserviço diretamente.
    Com relação à atomicidade, ela só é garantida dentro do Microserviço.

    Compreendeu?

    Luis Gabriel N. Simas Arquiteto de Software

    • Marcado como Resposta Marco_Alexandre terça-feira, 13 de outubro de 2015 17:41
    terça-feira, 13 de outubro de 2015 15:18
  • Boa noite Gabriel !

    Cenário2: Imagina que eu vou gravar o cadastro de uma pessoa e chamo o método do microserviço para gravação, agora imagina que esta pessoa possua, endereço, telefone, outros dados, etc...

    Estes modelos:Endereco, telefone por exemplo, seriam microserviços distintos ou estariam no microserviço de cadastro também ?

    Obs: Não são estes os cenários que estamos nos deparando, é só para exemplificar

    Ainda é um conceito novo para mim, trabalho normalmente sem esta arquitetura de microserviços, e com WCF, que fica mais facil garantir isso, mas, nada que um pouco de pesquisa e ja iremos chegar num denominador comum la no trabalho.

    Ainda não assisti todo o hangout, mas obrigado pelo material.

    Até mais.

    Marco

    Marco.

    Você, para criar um microserviço, precisa ter uma regra de negócio, pois é ela que irá virar um microserviço. Microserviço não são métodos esparsos, mas uma funcionalidade que você une o acesso aos dados, a regra de negócio e as expõe via Rest e faz o intercâmbio através de um DTO.

    Então, um exemplo, você tem a regra de negócio ManterPessoa, logo, manter pessoa você tem esse CRUD básico e mais algumas coisas que você precisar, logo, dentro de ManterPessoa, você terá todos os objetos desse domínio, incluind os repositórios, o que você vai expôr ao cliente é o método da regra de negócio, como no seu exemplo: Cadastrar Pessoa(pessaodto), bem o que você tem dentro do domínio de Pessoa que possa fazer parte da regra de negócios dela? partindo desse princípio, você aglutina tudo o que é relativo à isso e então cria um microserviço.

    UI -> CadastrarPessoa(pessoaDto) -> Microservico_ManterPessoa -> Base de dados 

    Compreendeu?


    Luis Gabriel N. Simas Arquiteto de Software

    • Marcado como Resposta Marco_Alexandre terça-feira, 13 de outubro de 2015 17:41
    terça-feira, 13 de outubro de 2015 15:23
  • Boa noite !

    Pois é, talvez tenhamos que repensar a forma como estamos gravando estes objetos no banco e até a forma que desenvolvemos as nossas páginas atualmente.

    Muda-se o conceito, muda-se o modelo, é provavel que tenhamos que mudar a UI também...

    Até

    Marco

    Marco.

    Não se sinta pressionado ok? podemos te ajudar no que for preciso.

    Eu escrevi uma série com dois Posts na DevMedia, mais precisamente para a Revista .NET Magazine falando um pouco sobre a Arquitetura de Microserviços, está bem mastigada. Seguem os links

    Parte 1) http://www.devmedia.com.br/arquitetura-de-microservicos-em-net-parte-1/32817

    Parte 2) http://www.devmedia.com.br/arquitetura-de-microservicos-em-net-parte-2/33034

    O Renato Groffe também fez uma apresentação sobre microserviços e têm uns slides no SlideShare, seguem: http://pt.slideshare.net/renatogroff1/servios-na-plataforma-net-soa-rest-microservices-wcf-web-api

    Lembrando que dá trabalho no início, mas depois do microserviço publicado em ambiente de testes, você verá que a produtividade de vocês e a divisão da equipe fará com que o projeto ande muito mais rápido.

    Qualquer dúvida, pode colocar aqui que vamos te ajudar.


    Luis Gabriel N. Simas Arquiteto de Software

    • Marcado como Resposta Marco_Alexandre terça-feira, 13 de outubro de 2015 17:41
    terça-feira, 13 de outubro de 2015 15:25
  • Boa noite !

    Pois é, talvez tenhamos que repensar a forma como estamos gravando estes objetos no banco e até a forma que desenvolvemos as nossas páginas atualmente.

    Muda-se o conceito, muda-se o modelo, é provavel que tenhamos que mudar a UI também...

    Até

    Marco

    Marco.

    Não será necessária a mudança na camada de apresentação, o que deve  mudar são as camadas mais inferiores, pois elas somem e vão para dentro do Microserviço. Dá uma lida no meu artigo que você vai entender melhor, ele mostrar uma aplicação monolítica e depois eu a refatoro para microserviços. Isso pode te ajudar muito.

    Qualquer dúvida, estamos aqui.

    Forte Abraço


    Luis Gabriel N. Simas Arquiteto de Software

    • Marcado como Resposta Marco_Alexandre terça-feira, 13 de outubro de 2015 17:41
    terça-feira, 13 de outubro de 2015 15:27
  • Boa tarde !

    Sim, entendi, como comentei, ainda estamos começando com esta arquitetura, e é o primeiro projeto, por sorte estamos começando "do começo" este projeto, portanto não há o que alterar de classes existentes, fica mais fácil.

    Ja em resposta às outras respostas, compreendi a idéia de colocar as tarefas relativas ao contexto, por exemplo no caso da pessoa, dentro de um mesmo Microserviço.

    Li parte dos artigos e achei bem interessante e muito bons, é que esta pequena mudança de alguns conceitos no início fica um pouco confusa, mas nada que com um tempinho e "batendo cabeça" um pouco ja não pegamos o jeito.

    A saga continua......

    Até mais e obrigado pelos novos artigos.

    Marco.

    Sim, claro, como é algo novo pra gente... a gente fica meio confuso e tenta correlacionar ao máximo com o que já sabemos para diminuir um pouco essa curva de aprendizado... 

    O que você precisar, pode contar com a gente.

    Forte Abraço


    Luis Gabriel N. Simas Arquiteto de Software

    • Marcado como Resposta Marco_Alexandre quarta-feira, 21 de outubro de 2015 23:54
    terça-feira, 13 de outubro de 2015 19:38

Todas as Respostas

  • A primeira coisa que deve ser dita é que os microserviços são independentes entre si, criar esse tipo de dependência fere completamente o princípio da Arquitetura de Microserviços.

    Essa sua dúvida significa que vocês precisam ver melhor as regras de negócio aplicadas à esses dois microserviços e verificar se não está havendo alguma sobreposição de regras, pois essa dependência não pode existir.

    E o que eu entendi também foi o seguinte: você tem dois microserviços separados em IIS, mas tem apenas uma Gateway API? se a sua resposta for não, então você também precisa rever isto, pois deve existir apenas um gateway API centralizando seus microserviços.

    Coloco aqui o link sobre uma hangout que fizemos, eu, o Renato Groff e o Joel Rodrigues sobre essa Arquitetura, é um hang introdutório e acho que pode ser muito útil pra você.

    Segue: Arquitetura de Microserviços

    Qualquer coisa, pode perguntar por aqui que te ajudo com o maior prazer.

    Forte Abraço


    • Editado Gabriel Simas domingo, 11 de outubro de 2015 00:57 Escrevi coisa errada
    • Sugerido como Resposta Renato GroffeMVP domingo, 11 de outubro de 2015 01:24
    • Marcado como Resposta Marco_Alexandre segunda-feira, 12 de outubro de 2015 02:56
    domingo, 11 de outubro de 2015 00:55
  • Concordo com o que o Gabriel comentou e ainda gostaria de lembrar que abordagens como SOA e REST, além de Microservices que surgiu a partir das mesmas, pregam a implementação de serviços stateless.

    Essa independência de estados é fundamental em questões envolvendo isolamento de serviços, além de facilitar outros aspectos como melhor escalabilidade e facilidade de mudanças futuras em um projeto.

    • Marcado como Resposta Marco_Alexandre segunda-feira, 12 de outubro de 2015 02:56
    domingo, 11 de outubro de 2015 01:01
  • Boa noite Gabriel !

    Obrigado pela explicação, na verdade como você deve imaginar, de fato há outros microservicos na aplicação, porém coloquei A e B só para exemplificar, vejamos por exemplo estes cenários:

    Cenário1: Eu vou gravar um objeto de cupom de venda, e este cupom possui itens em seu cupom, neste caso eu poderia gravar no mesmo microservico de cupom (cupom e itens de cupom), mas imagina que neste mesmo objeto de cupom e durante esta operação de gravação do cupom, eu teria outras operações envolvidas que refletem no ERP em geral, por exemplo operações de gravação de dados de impostos do cupom, etc....
    Imposto para mim ja seria um outro microserviço de impostos, eu fico pensando, como eu garantiria a Atomicidade.

    Cenário2: Imagina que eu vou gravar o cadastro de uma pessoa e chamo o método do microserviço para gravação, agora imagina que esta pessoa possua, endereço, telefone, outros dados, etc...
    Estes modelos:Endereco, telefone por exemplo, seriam microserviços distintos ou estariam no microserviço de cadastro também ?

    Obs: Não são estes os cenários que estamos nos deparando, é só para exemplificar

    Ainda é um conceito novo para mim, trabalho normalmente sem esta arquitetura de microserviços, e com WCF, que fica mais facil garantir isso, mas, nada que um pouco de pesquisa e ja iremos chegar num denominador comum la no trabalho.

    Ainda não assisti todo o hangout, mas obrigado pelo material.

    Até mais.

    Marco

    segunda-feira, 12 de outubro de 2015 03:16
  • Boa noite !

    Pois é, talvez tenhamos que repensar a forma como estamos gravando estes objetos no banco e até a forma que desenvolvemos as nossas páginas atualmente.

    Muda-se o conceito, muda-se o modelo, é provavel que tenhamos que mudar a UI também...

    Até

    Marco

    segunda-feira, 12 de outubro de 2015 03:19
  • Boa noite Gabriel !

    Obrigado pela explicação, na verdade como você deve imaginar, de fato há outros microservicos na aplicação, porém coloquei A e B só para exemplificar, vejamos por exemplo estes cenários:

    Cenário1: Eu vou gravar um objeto de cupom de venda, e este cupom possui itens em seu cupom, neste caso eu poderia gravar no mesmo microservico de cupom (cupom e itens de cupom), mas imagina que neste mesmo objeto de cupom e durante esta operação de gravação do cupom, eu teria outras operações envolvidas que refletem no ERP em geral, por exemplo operações de gravação de dados de impostos do cupom, etc....
    Imposto para mim ja seria um outro microserviço de impostos, eu fico pensando, como eu garantiria a Atomicidade.


    Marco.

    Você está pensando como Microserviços de forma macro, e isso é ótimo, significa que você está compreendendo bem o que eles podem fazer, esse tipo de dúvida é pertinente ao extremo, deixa eu ver se eu posso te ajudar.

    Resposta do Cenário 1)
    Lembrando que você precisa ter uma Gateway API só aí você pode utilizar os métodos de chamada que quiser.

    No trecho "Eu vou gravar um objeto de cupom de venda, e este cupom possui itens em seu cupom, neste caso eu poderia gravar no mesmo microservico de cupom (cupom e itens de cupom)"

    Perfeito seu raciocínio, você teria um microserviço para controlar o cupom e seus itens, mas isso vai depender do seu domínio, ou seja, um microserviço nada mais é do que um "pacote" contendo todas as suas regras de negócio dentro de um contexto específico.

    Depois "...mas imagina que neste mesmo objeto de cupom e durante esta operação de gravação do cupom, eu teria outras operações envolvidas que refletem no ERP em geral, por exemplo operações de gravação de dados de impostos do cupom, etc...."
    Se isso acontecer, caímos em um assunto nevrálgico de microservicos: Duplicação dos dados ou integração via Mensageria. Como dissemos, um microserviço, de acordo com a regra deve ter uma base de dados só pra ele, isso mesmo base de dados e não uma tabela apenas, mas, essa regra podemos bypassá-la em detrimento do projeto como sempre.
    Nesse caso, temos duas opções: 
    1) observar a sua regra de negócios e ver se realmente o Imposto faz parte da regra de negócio de cupons, se fizer, você vai precisar adequar isso ao seu microserviço de cupons.
    2) Ou se você quiser, ser mais rápido, separar as ações e na camada de UI você executar essas operações em ordem oriundas de microserviços diferentes, um exemplo, imaginemos que temos a UI abaixo:
    1) Cliente salva o cupom utilizando o Microserviço de cupons
    2) após isso um método na UI, seja por camada de infra, BLL ou o que for, acessar o microserviço de imposto e utilizá-lo, tudo de forma sequencial dentro da UI.
    É também uma regra que Microserviço não acesso microserviço diretamente.
    Com relação à atomicidade, ela só é garantida dentro do Microserviço.

    Compreendeu?

    Luis Gabriel N. Simas Arquiteto de Software

    • Marcado como Resposta Marco_Alexandre terça-feira, 13 de outubro de 2015 17:41
    terça-feira, 13 de outubro de 2015 15:18
  • Boa noite Gabriel !

    Cenário2: Imagina que eu vou gravar o cadastro de uma pessoa e chamo o método do microserviço para gravação, agora imagina que esta pessoa possua, endereço, telefone, outros dados, etc...

    Estes modelos:Endereco, telefone por exemplo, seriam microserviços distintos ou estariam no microserviço de cadastro também ?

    Obs: Não são estes os cenários que estamos nos deparando, é só para exemplificar

    Ainda é um conceito novo para mim, trabalho normalmente sem esta arquitetura de microserviços, e com WCF, que fica mais facil garantir isso, mas, nada que um pouco de pesquisa e ja iremos chegar num denominador comum la no trabalho.

    Ainda não assisti todo o hangout, mas obrigado pelo material.

    Até mais.

    Marco

    Marco.

    Você, para criar um microserviço, precisa ter uma regra de negócio, pois é ela que irá virar um microserviço. Microserviço não são métodos esparsos, mas uma funcionalidade que você une o acesso aos dados, a regra de negócio e as expõe via Rest e faz o intercâmbio através de um DTO.

    Então, um exemplo, você tem a regra de negócio ManterPessoa, logo, manter pessoa você tem esse CRUD básico e mais algumas coisas que você precisar, logo, dentro de ManterPessoa, você terá todos os objetos desse domínio, incluind os repositórios, o que você vai expôr ao cliente é o método da regra de negócio, como no seu exemplo: Cadastrar Pessoa(pessaodto), bem o que você tem dentro do domínio de Pessoa que possa fazer parte da regra de negócios dela? partindo desse princípio, você aglutina tudo o que é relativo à isso e então cria um microserviço.

    UI -> CadastrarPessoa(pessoaDto) -> Microservico_ManterPessoa -> Base de dados 

    Compreendeu?


    Luis Gabriel N. Simas Arquiteto de Software

    • Marcado como Resposta Marco_Alexandre terça-feira, 13 de outubro de 2015 17:41
    terça-feira, 13 de outubro de 2015 15:23
  • Boa noite !

    Pois é, talvez tenhamos que repensar a forma como estamos gravando estes objetos no banco e até a forma que desenvolvemos as nossas páginas atualmente.

    Muda-se o conceito, muda-se o modelo, é provavel que tenhamos que mudar a UI também...

    Até

    Marco

    Marco.

    Não se sinta pressionado ok? podemos te ajudar no que for preciso.

    Eu escrevi uma série com dois Posts na DevMedia, mais precisamente para a Revista .NET Magazine falando um pouco sobre a Arquitetura de Microserviços, está bem mastigada. Seguem os links

    Parte 1) http://www.devmedia.com.br/arquitetura-de-microservicos-em-net-parte-1/32817

    Parte 2) http://www.devmedia.com.br/arquitetura-de-microservicos-em-net-parte-2/33034

    O Renato Groffe também fez uma apresentação sobre microserviços e têm uns slides no SlideShare, seguem: http://pt.slideshare.net/renatogroff1/servios-na-plataforma-net-soa-rest-microservices-wcf-web-api

    Lembrando que dá trabalho no início, mas depois do microserviço publicado em ambiente de testes, você verá que a produtividade de vocês e a divisão da equipe fará com que o projeto ande muito mais rápido.

    Qualquer dúvida, pode colocar aqui que vamos te ajudar.


    Luis Gabriel N. Simas Arquiteto de Software

    • Marcado como Resposta Marco_Alexandre terça-feira, 13 de outubro de 2015 17:41
    terça-feira, 13 de outubro de 2015 15:25
  • Boa noite !

    Pois é, talvez tenhamos que repensar a forma como estamos gravando estes objetos no banco e até a forma que desenvolvemos as nossas páginas atualmente.

    Muda-se o conceito, muda-se o modelo, é provavel que tenhamos que mudar a UI também...

    Até

    Marco

    Marco.

    Não será necessária a mudança na camada de apresentação, o que deve  mudar são as camadas mais inferiores, pois elas somem e vão para dentro do Microserviço. Dá uma lida no meu artigo que você vai entender melhor, ele mostrar uma aplicação monolítica e depois eu a refatoro para microserviços. Isso pode te ajudar muito.

    Qualquer dúvida, estamos aqui.

    Forte Abraço


    Luis Gabriel N. Simas Arquiteto de Software

    • Marcado como Resposta Marco_Alexandre terça-feira, 13 de outubro de 2015 17:41
    terça-feira, 13 de outubro de 2015 15:27
  • Boa tarde !

    Sim, entendi, como comentei, ainda estamos começando com esta arquitetura, e é o primeiro projeto, por sorte estamos começando "do começo" este projeto, portanto não há o que alterar de classes existentes, fica mais fácil.

    Ja em resposta às outras respostas, compreendi a idéia de colocar as tarefas relativas ao contexto, por exemplo no caso da pessoa, dentro de um mesmo Microserviço.

    Li parte dos artigos e achei bem interessante e muito bons, é que esta pequena mudança de alguns conceitos no início fica um pouco confusa, mas nada que com um tempinho e "batendo cabeça" um pouco ja não pegamos o jeito.

    A saga continua......

    Até mais e obrigado pelos novos artigos.

    terça-feira, 13 de outubro de 2015 17:52
  • Boa tarde !

    Sim, entendi, como comentei, ainda estamos começando com esta arquitetura, e é o primeiro projeto, por sorte estamos começando "do começo" este projeto, portanto não há o que alterar de classes existentes, fica mais fácil.

    Ja em resposta às outras respostas, compreendi a idéia de colocar as tarefas relativas ao contexto, por exemplo no caso da pessoa, dentro de um mesmo Microserviço.

    Li parte dos artigos e achei bem interessante e muito bons, é que esta pequena mudança de alguns conceitos no início fica um pouco confusa, mas nada que com um tempinho e "batendo cabeça" um pouco ja não pegamos o jeito.

    A saga continua......

    Até mais e obrigado pelos novos artigos.

    Marco.

    Sim, claro, como é algo novo pra gente... a gente fica meio confuso e tenta correlacionar ao máximo com o que já sabemos para diminuir um pouco essa curva de aprendizado... 

    O que você precisar, pode contar com a gente.

    Forte Abraço


    Luis Gabriel N. Simas Arquiteto de Software

    • Marcado como Resposta Marco_Alexandre quarta-feira, 21 de outubro de 2015 23:54
    terça-feira, 13 de outubro de 2015 19:38
  • Ok Obrigado.
    quarta-feira, 21 de outubro de 2015 23:54