Microserviços

Programação Java
#1

Pelo que entendi, os microserviços são separados.

Exemplo:

  1. Usuários. usuario/:id, WAR único;
  2. Clientes. cliente/:id, WAR único;
  3. Contas a pagar. contaPagar/:id, WAR único.

Pelo que entendi eles são desenvolvidos em projetos diferentes, mas utilizando o mesmo banco de dados. Sendo assim para buscar um cliente no micro serviço de conta a pagar, tenho que acessar localhost:8080/cliente/:id, sendo que estou no endereço localhost:8080/contaPagar.

Assim, eu não tenho métodos para clientes no módulo de contas a pagar. Assim tudo deste módulo está neste projeto. Salvar, Alterar, Excluir e todos os tipos de pesquisa.

Meu pensamento está correto ?

#2

Está usando só por moda pra trazer problemas ou é real necessidade?

1 curtida
#3

Os micro-serviços não necessariamente são desenvolvidos com o mesmo banco, o conceito de micro-serviços é basicamente isso:

  • Ter um front-end isolado do back-end
  • Ter um endpoint no back-end para consumir o que vem do front e devolver informações para o front, normalmente essas informações são enviados no formato JSON.

Não necessariamente será o mesmo ip da aplicação front-end, pode ser que o front-end esteja no ip localhost:4200 e o back-end no localhost:8080. Esses ips ai seria usado em ambiente de dev (por causa do localhost)

No ambiente de produção pode ser algo assim:
Front-end em: meufrontend.com.br ou 10.8.12.123
Back-end em: meubackend.com.br/cadastrar/cliente ou 10.8.12.124/cadastrar/cliente

#4

Entendi sobre ser o mesmo IP, banco de dados.

Entendi um pouco sobre micro serviços.

Mas o que eu quero saber.

Exemplo tenho um erp, e gera um erp-web.war.

Nele tenho os end-points.

@RestController
@RequestMapping("/admin/seg/agencia")
@CrossOrigin(origins = "*")
public class AgenciaController {
    **Aqui tenho todas as operações para cliente**, salvar, excluir, alterar, etc, para a entidade agência
}

e

@RestController
@RequestMapping("/admin/seg/cliente")
@CrossOrigin(origins = "*")
public class AgenciaController {
    **Aqui tenho todas as operações para cliente**, salvar, excluir, alterar, etc, para a entidade cliente
}

Mas no modelo de cliente, por exemplo tenho a entidade agencia.

Lembrando que todos os métodos GET, POST, etc…
@PostMapping(value = “/pesquisar”, produces = MediaType.APPLICATION_JSON_UTF8_VALUE)
ou
@GetMapping(value = “/{id}”, produces = MediaType.APPLICATION_JSON_UTF8_VALUE)*
ou
@DeleteMapping(value = “/{id}”, produces = MediaType.APPLICATION_JSON_UTF8_VALUE)

O back end é angular e é no servidor localhost:4200 e o servidor fica em localhost:8080. Tanto para homologação é produção.

Para ser micro serviços, tenho que ter dois war ou um somente?

#5

Entenderam o que eu quis dizer ?

O meu exemplo já é um microserviço ?

#6

Um war apenas já é o suficiente, o importante é cada endpoint ter apenas uma responsabilidade, dai vem o termo “micro”

Eu diria que se os seus endpoints fazem só aquilo que é proposto para fazer, então é um microserviço

Exemplo com JAX-RS:

@Path("/consulta-conta-bancaria")
@POST
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public Response consultaContaBancaria(JSONObject json) {
     ContaBancariaFiltro filtro = new Gson().fromJson(json.toString(), ContaBancariaFiltro.class);
     ContaBancaria contaBancaria = contaBancariaService.consulta(filtro);

     return Response.status(Status.OK).entity(saldo).build();
}

Se o seu front-end esta isolado do back-end, utiliza endpoints que servem para fazer apenas uma coisa (como o exemplo acima) e consegue consumir esses endpoints em outras páginas, então é um micro-serviço na minha opinião e pelo que eu vi é micro-serviço sim

#7

Então, para objeto de entidade tem um @RestController. Nele concentro tudo que serve para ele.

Se eu preciso filtrar estados por município, o endpoint construo no @RestController de estado.

#8

Nao é microserviço e provavelmente nao precisa ser.

Quando se fala em microserviços, se está falando numa arquitetura com múltiplos sistemas separados, que permitem entre coisas: times diferentes trabalhando com cada sistema, fazer deploy separado, etc.

No seu caso é um sistema só, onde o deploy ocorre via esse war gerado.

O que está tentando fazer?

2 curtidas
#9

Só estou querendo entender.

Mas um outro exemplo.

Tenho um módulo de contabilidade, produto, licitação, pessoas, isto é, sistemas separados e podendo ser equipe separado. Para cada um tenho um war.

Só que no sistema de licitação, preciso buscar um produto, uma pessoa e o item da contabilidade.

Ao invez do sistema de licitação eu ter endpoints de busca de produtos, pessoa e contabilidade eu chamo o war de cada utilizando o método correto e retornando o produto, pessoa e o item da contabilidade.

Este exemplo seria microserviço ?

lembrando que é angular e JAVA todos os módulos/sistema.

#10

Pense assim:

  • Sistema (não importa se eh jar, war, ear, etc.): Aqui terá as telas do sistema com as funcionalidades que irão atender o negócio

  • Na arquitetura de microserviço, voce terá uma gateway onde será a porta de entrada das requisições vindas das tela (nesse caso) que irá invocar os microserviços.

  • Existem tecnologias que funcionam como barramento (eureka eh um deles) onde os micro serviços ficam registrados para poderem serem acessados (vc pode manter n instancias de cada serviço se quiser)

  • E no final ficam os serviços propriamente ditos, ex.: Usuario, Produto, Venda, etc. (a parte mais difícil aqui eh dividir os microserviços negocialmente - acredito que seja mais dificil fazer isso do que implementar essa arquitetura, por isso muita gente estuda e usa conceitos de DDD na arquitetura de cada microserviço). Obs.: Na real, cada microserviço tem seu proprio schema de banco, são completamente isolados tecnicamente, por isso a divisão negocial tem que ser muito bem feita, senão eh soh problema.

3 curtidas
#11

Complementando o que o @Lucas_Camara disse sobre a organização da arquitetura: é essencial que a parte negocial esteja extremamente madura, caso contrário, não invente, vá de monolito mesmo.

2 curtidas