Pessoal, alguem aqui trabalha com microservices e pode me dar uma luz, estou estudando para implementar isso, mas estou com algumas duvidas basicas, por exemplo:
1 - Todo microservicos precisaria de uma autenticação para ser chamado (sei que isso pode ser bloqueado para receber apenas de um ip fixo ou localhost) mas essa autenticacao seria como? oauth, login e senha fixa, etc?
2 - preciso replicar todos os dados? por exemplo, os dados do usuario, replico esses dados(codigo, nome e etc) em cada microservicos que for trabalhar com ele, ou tenho um microservico que so trabalha com usuario, e ai nesse outros microservices eu tenho apenas um id que quando ele precisar dos dados mais complexos (por exemplo gerar um boleto no nome do usuario) eu peco para o microservice de usuarios os dados?
3 - como disponibilizar esses microservices? jogos todos dentro do mesmo tomcat? ou empacoto um container para cada micro service? qual container? tomcat? existe um proprior?
4 - caso eu tenha um container para cada servico, se eu subir todos na mesma maquina preciso me preocupar com as portas dos containers, e outra isso nao pode sobrecarregar o meu computador?
5 - alguem utiliza o spring-boot para microservices ou tem algum outro framework melhor?
Voce pode ter um projeto com vários microservices, cada microservice é um endpoint. Pra ter autenticacao, dependendo do requisito, pode usar basic auth mesmo, aí na chamada ele precisa passar um usuario e senha (Ex: curl -u user:user -X GET localhost:8080/bla/bla?q=1)
O Spring Boot é apenas um framework facilitador pra trabalhar com o Spring framework, nele vc pode usar Spring MVC pra criar seus microservicos, ou Jersey, ou qualquer outra coisa.
Item 1 : nada impede que você tenha microserviços públicos. O requisito de autenticação ou não é uma decisão de negócio (ou sua).
Item 2: conceitualmente, um micrososerviço deveria ser auto suficiente, para ser escalável, etc. Neste caso, sim, o ideal é ser SOLID (S = Simple Responsability).
Item 3: a implantação fica a seu critério, na sua arquitetura.
concordo com você FabioQB, no login eu vejoque o melhor seria utilizar SSO(Single Sign-on), já deve ter alguma implementação boa no mercado, tem uma ferramenta que a muito quero testar para microservices OAUTH-2.0 . Eu penso que microservices se encaixa melhor em um contexto distribuido, com cluster, utilizando um container javaEE full como jboss configurarando o AJP com load balancing, estilo um Netflix, agora montar tudo isso para rodar em um servlet-container não vejo com bons olhos, para um tomcat da vida prefiro apps monolíticas.
Porque existem os famosos early adopters, como Wildfly, Glassfish e IBM Liberty Profile, que lançam versões FREE para comunidade mundial testar (gratuitamente), eles corrigirem bugs e posteriormente lançaram suas versões Enterprise ($$).
Versões Enterprise requerem maturidade do produto, pois as empresas vendem seus softwares com suporte.
É algo que venho pesquisando, e cheguei a ver alguns casos de uso com o Spring Boot, que sinceramente fico até espantado de como é aplicado coreografia e orquestração em tudo isso. Alguns casos onde são utilizados tomcats embedded, com vários JARs com responsabilidades únicas (clientes, produtos, pedidos, relatórios e etc), bancos de dados únicos e expondo diferentes endpoints e cada JAR dentro de um container Docker.
Utilização de replicação assíncrona baseada em eventos usando message broker, de API Gateway e por ai vai.
Alguém já chegou a trabalhar, ou estudar que seja um cenário parecido?
Como manter a integridade das informações em um cenário distruído assim?
@fabioqb , o nome do conceito é S.O.L.I.D, pois cada letra é outro conceito. O S é Single Responsability, que diz respeito a responsabilidade única. Segue um artigo bacana sobre SOLID: http://www.itexto.net/devkico/?p=1105
Oi @fabioebner, tudo bem ?
Antes de pensar em como fazer, é entender o conceito por trás dos microserviços e sua real necessidade. Já vi pessoas caminhando por esta estrada sem qualquer necessidade, apenas porque virou “moda”. Então uma anális sucinta do negócio deve ser feita antes de pensar nesta arquitetura, que não é perfeita.
Depende do seu negócio. Será uma URL pública ? Que tipo de dados estarão expostos ? São duas perguntas simples, mas para tu ter ideia de como vai buscar a resposta;
Não. Se você tem que replicar dados você não tem microserviços. Cada microserviço deve ter uma única responsabilidade, deve executar uma única tarefa. Então se tu tem um microserviço que gerencia seus usuários, qualquer outro serviço que precisar de informações de usuários vai consultar este microserviço, mas não para ficar replicando dados. Óbvio que você pode salvar informações em comum, mas não uma replicação por inteira;
A disponibilização vai depender de sua necessidade. Eu ouvi boatos que a Netflix disponibilizava/disponibiliza todos os seus microserviços no mesmo servidor, agora, se era no mesmo container eu não sei. De qualquer forma, tu tem que avaliar. Se tu concentra todos os microserviços em um únio container, tu tem um único ponto de falha. Se precisar parar e subir ele, você derruba todos os microserviços, por exemplo. Eu sempre sou a favor de ter tudo separado, servidor, container e etc, isolar por completo um microserviço, porém, já passei pela experiência do custo que estava cada dia mais elevado, principalmente porque era pago em dólar. Cada instância era mais dinheiro e assim sucessivamente. Portanto, é mais uma análise que você deve fazer, analisando os prós e contras;
Sem dúvidas. Como vai subir 3 containers na porta 8080 no mesmo computador ? Eu não consigo visualizar como. E óbvio, quanto mais microserviços na mesma máquina, mas do hardware será exigido;
Não sei te responder pois nunca usei e trabalho com os mesmo, apenas com o Wildfly pois usava JEE full.
Acredito que colocar tudo em uma máquina só elimina grande parte das supostas vantagens de uma arquitetura de micro-serviços, como a escalabilidade horizontal de serviços específicos.
No geral, o hype em torno de micro-serviços me parece exagerado demais. Tudo o que li a respeito me parece apenas uma roupagem nova para um assunto velho: componentização.
@esmiralha eu penso que um problema clássico, que não vale apenas para microservices, é a famosa “bala de prata”. Quando surgiu o conceito de REST, eu li muito sobre “matem o SOAP e migrem para REST!”. Não funciona assim, não mesmo.
O microservice nasceu principalmente devido as arquiteturas SaaS, mas e as empresas que vendem produtos on premise ? Sim, aqueles que instalamos na “casa do cliente” ? O que eu já vi são pessoas ou times que implementam conceitos simplesmente pelo fato de ser novo e acharem “legal”, sem antes executar todo um levantamento, com POCs e afins para avaliar os reais ganhos, os prós e contras. É por estas e outras que lá no futuro (que pode ser curto, diga-se de passagem), encontram problemas sérios ao invés de soluções.
O artigo que citei acima do Martin Fowler é bem bacana e fala sobre isso. Tem um do Robert Martin que fala sobre isso também, bem interessante.
@nel Se o artigo do Uncle Bob for o mesmo que eu li (sobre um compilador FORTRAN na década de 60), achei uma postura muito sóbria com relação a mais uma “grande novidade do verão”.
Partilho da mesma idéia que você, ainda tem outras questões que devem ser analisadas antes de decidir por este modelo de arquitetura , ex: a view, se você tem mais de uma app web servindo a serviços diferentes não escapa de uma replicação de código na parte da view. Outro ponto são as conexões com o database, um SSO é necessário para gerenciar os usuários e seus diferentes papéis na aplicação como um todo. Hoje em dia o pessoal sai divindo a aplicação em várias partes e acredita estarem utilizando microserviços mas não é assim, no próprio post do Fowler ele diz em outras palavras que: se você não tem o negócio bem definido, que se você não tem uma equipe de seniors onde você possa expor suas idéias, onde todos compartilhem conhecimento e principalmente por no papel é um projeto destinado ao fracasso.
Concordo com vcs, sempre antes de um projeto tem que levantar todos requisitos e analisar sempre a melhor solução. Nunca vai existir uma tecnologia que seja uma “bala de prata”. Meu caso foi mais pesquisas sobre e achei bastante interessante o conceito.
Por exemplo, sei que o padrão de integração “Shared Database”, não é um dos mais recomendados, muita gente fala que hoje não se utiliza mais devido a ‘n’ problemas. Porém, teve uma situação em uma aplicação onde este padrão me resolveu um problema de um cliente. E esta funcionando a anos já sem problemas.
Oi @esmiralha, o artigo é este aqui: http://blog.cleancoder.com/uncle-bob/2014/09/19/MicroServicesAndJars.html
O que gostei foi o final dele: “Don’t leap into microservices just because it sounds cool. Segregate the system into jars using a plugin architecture first. If that’s not sufficient, then consider introducing service boundaries at strategic point.”
Em particular “sounds cool”. Que é exatamente o que comentei anteriormente.
Tava vendo um tiozinho da programação funcional explicando o que é um micro-serviço. Segundo ele, é um serviço com “micro” na frente. Achei honesta a explicação.
Então, sem me estender, um forma bacana de análise é o DDD (Domain Driven Design), no qual tu defini por regiões teu software. Estas regiões/fronteiras devem estar absolutamente bem definidas antes de pensar em seguir para microservices.
Quanto mais sólida sua base estiver, maiores as chances de sucesso e menores as chances de dores de cabeça.
Quem tem máquinas pra operar in-house, ou em um datacenter, e quer usar microservice, provavelmente está aderindo ao conceito só por modismo. Microservices é para aplicações que rodam em instâncias efêmeras na nuvem.
Hmmm, para mim essa “nuvem” pode ser privada e nada mudaria. O ponto dos “micro-serviços” é poder implantar e escalar partes da solução de forma independente. Você pode fazer isso em uma infra interna sem maiores problemas, se tiver virtualização e automação.
