Upload
tiago-marchetti-dolphine
View
290
Download
0
Embed Size (px)
Citation preview
MicroservicesTiago Dolphine
Agenda
• O que é ? como surgiu? Porque?
• Decompondo uma aplicação em microservices
• Comunicação e integração
• Estrutura básica
• Desafios (micro?)
• Case de arquitetura microservices
Vamos imaginar que estamos desenvolvendo uma loja virtual ...
Browser / Mobile App
App Server/Container (Tomcat/Jetty)
Framework (Spring/JavaEE)
LB
X Scaling
DB
Front EndFramework
Product Svc
Order Svc
Pricing Svc
Stock Svc
OR
M(H
iber
nat
e)
Aplicação Monolítica
Simplicidade em:• Desenvolver• Testar• Deploy• Escalar
É natural pois é como aprendemos !
Aplicação Monolítica
Porém...
• Crescimento do negócio
• Aumento da complexidade do negócio
E para os desenvolvedores?
E para os desenvolvedores?
Enquanto isso em nossa loja virtual ...
Aumento de vendas
Serviço de Pedidos Gargalo
Vamos escalar nossa aplicação !
App Server/Container (Tomcat/Jetty)
Framework (Spring/JavaEE)
Front EndFramework
Product Svc
Order Svc
Pricing Svc
Stock Svc
OR
M(H
iber
nat
e)
App Server/Container (Tomcat/Jetty)
Framework (Spring/JavaEE)
Front EndFramework
Product Svc
Order Svc
Pricing Svc
Stock Svc
OR
M(H
iber
nat
e)
App Server/Container (Tomcat/Jetty)
Framework (Spring/JavaEE)
Front EndFramework
Product Svc
Order Svc
Pricing Svc
Stock Svc
OR
M(H
iber
nat
e)
App Server/Container (Tomcat/Jetty)
Framework (Spring/JavaEE)
Front EndFramework
Product Svc
Order Svc
Pricing Svc
Stock Svc
OR
M(H
iber
nat
e)
• Custos desnecessários (Cloud $$)
• Subaproveitamento de recurso computacional
Preciso escalar toda a aplicação !
http://microservices.io/articles/scalecube.html
Alguns pontos negativos
• Redeploy de toda a aplicação para pequenas mudanças
• Alto tempo de interrupções
• Risco de falhas
• Dificulta mudanças
• Updates menos frequentes
A microservice architecture builds software as suites of collaborating services.
(Martin Fowler)
O que é? Qual vantagem?
• Conjunto de pequenos serviços
• Foco em funcionalidade
• Independência
• Tecnologias heterogêneas e poliglotas
• Escalabilidade em gargalos
• DRY Reuso de funcionalidades
• Deploy independente (favorece CI/CD)
• Equipes menores e focadas
Como definir um bom microservice?
• Funcionalidades relacionados devem ficar juntas
• Baixo acoplamento / Alta coesão
• Estudar e delimitar o escopo do serviço
• Modelar pensando em funcionalidades, não nos dados
• Bounded Contexts (modelo interno e modelo exposto)
• Módulos (app monólítica) candidatos a microservices
O menor possível, porém grande o suficiente para representar o seu domínio
Como ficaria nossa loja virtual?
Browser / Mobile App
LB
Y Scaling
DB
Micro container framework
Order Svc
DB
Stock Svc
Front End
DB
Product Svc
DB
Pricing Svc
http://microservices.io/articles/scalecube.html
Integração e comunicação
• Como um serviço se comunica com outro?
Chamada à funções Chamadas à APIs remotas
• Síncrono: request/response
• Assíncrono: request/callback
Orquestração vs coreografia
Vamos pensar no processo de criação de um novo cliente
Um serviço gerencia quando tomar ações Cada serviço sabe quando tomar ações diante de um evento
REST
• Mecanismo síncrono
• Recurso É o foco do serviço
• Desacoplamento do exposto para o armazenado
• HTTP• Semântica e verbos (ex: GET, POST, PUT, DELETE)
• Caching proxies
• Load balancers
• Ferramentas de monitoramento
• Métodos de segurança
API Gateway
APIGW
Web App
Mobile App
Customer
Product
Stock
Pricing
• Ponto único de entrada• Agregação de dados• API otimizada para diferentes
clientes• Evita exposição de dados
desnecessários• Tradução de protocolo• Cross domain e Same-origin policy
Mensageria
• Mecanismo assíncrono (baseado em eventos)
• Publish/Subscribe
• Incentiva a coreografia e baixo acoplamento
• Padrões para mensagens (AMQP, JMS...)
• Message Broker (RabbitMQ, ActiveMQ, HornetQ...)
• Aumenta complexidade
Híbrido
Stock
Pricing
TopicOrderFrontEnd
Product
CustomerDB
REST/HTTP
Vamos pensar num fluxo de compra
Falhas são inevitáveis
• Estar preparado para falhas
• Assumir que as chamadas e serviços podem falhar
• Rede é instável
• Recuperação à falhas
• Adotar este pensamento em tudo que for desenvolvido
Estrutura básica de um Microservice
Recursos
Serviço
Modelodo Domínio
Repositórios
ORM / Framework Dados
Gat
eway
Rec
urs
os
Serv
iço
Mo
del
od
o D
om
ínio
Rep
osi
tóri
os
OR
M /
Fra
mew
ork
D
ado
s
Gateway
Deploy
• Instância• Serviços isolados
• Sem conflito de recursos
• Aloca todo recurso disponível
• Virtual Machine• Facilidade de escalar add mais VMs
• Controle de CPU e memória
• VM lenta de buildar e startar
• Container• Rápido para buildar e startar
• Não necessita startar todo SO, apenas o processo do serviço
E como ficam os times de desenvolvimento?
"Qualquer empresa que projeta um sistema, inevitavelmente produz um projeto cuja estrutura é uma cópia da estrutura de comunicação da organização“...
• Times multidisciplinares
• Paraleliza mais facilmente o desenvolvimento• Cada time é responsável (dono) por cada microservice
Microservices no ifood...
Vamos a um exemplo de código... com Spring boot
https://github.com/tiagodolphine/microservices
Concluindo...
• Maior complexidade!
• Preciso de microservices para o meu problema?
• Estar sempre ciente dos desafios que terei que enfrentar!• Descoberta de serviços
• Operações transacionais
• Testes
• Monitoramento
• Teorema CAP (consistency, availability, partition tolerance)
• Dia a dia do desenvolvedor mais agitado e divertido
Algumas referências
• Microservices (Martin Fowler e James Lewis)
• microservices.io (Chris Richardson)
• Building "Bootiful" Microservices with Spring Boot (Josh Long)
• Testing Strategies in a Microservice Architecture (Toby Clemson)
• Building MicroservicesDesigning Fine Grained Systems (Sam Newman) fev/2015
Algumas idéias de tecnologias
• Micro container: Spring Boot, Play, DropWizard
• Comunicação:
• REST : Spring MVC, JAX-RS
• Mensageria: Spring AMQP com RabbitMQ
• Deploy: Container com Docker
• Monitoramento: Logstash, Kibana, NewRelic, Consul
• Service Discovery: Consul