SlideShare uma empresa Scribd logo
Arquitetura de
Microserviços
Norberto Enomoto
SOA | Integration | IoT Architect
norberto.enomoto@hpe.com
18/08/2016
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 2
Agenda
• Introdução
• História dos Microserviços
• Pré Requisitos não técnicos
• Pré Requisitos de Arquitetura
• Desenho de API – Swagger
• Perguntas e Respostas
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 3
Introdução
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 4
Arquitetura de Microserviço
É um Estilo de Arquitetura que enfatiza a decomposição de aplicativos em
microserviços de baixo acoplamento gerido por equipes multifuncionais, para a
entrega e manutenção de sistemas de software complexos com a velocidade e
qualidade exigida pelos negócios digitais de hoje.
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 5
Arquitetura de Microserviços
Monolítico Microserviço
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 6
Arquitetura de Microserviços
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 7
Arquitetura de Microserviços
• As aplicações são composições de processos pequenos e independentes
• Esses processos se comunicam através de um API em Restfull (HTTP / JSON)
• Normalmente a aplicação front-end (Angular, React e etc) irá utilizar a resposta JSON para
construir a página HTML
• Uma APP desenvolvida em IOS ou Android irá construir suas “views” usando a resposta JSON
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 8
Arquiteturas Existentes tem suas Limitações
Devagar
Equipes divididas por função – UI,
Aplicação, Middleware, Banco de
Dados, etc. Leva uma eternidade
para fazer qualquer coisa devido ao
“cross-ticketing”
Frágil
Uma falha (bug) poderá rapidamente
“derrubar” toda a aplicação. Pouco
Resiliente
Testes Ineficientes
Toda vez que você alterar sua aplicação,
você terá que retestar tudo. Difícil
suportar a Entrega Contínua
Sem Dono
Quando não existe um dono, você
tem negligência
Complexa
Aplicações tendem a ficar tão grandes e
complexas para o Desenvolvedor entender ao
longo do tempo. Camadas compartilhadas
(ORM, Mensageria, etc) precisam gerenciar
100% dos casos de usos.
Sem
Dono
Devagar
Sem
Especialização
Complexa
Teste
Ineficientes
Frágil
Sem Especialização
Diferentes partes da aplicação
possuem diferentes necessidades –
mais CPU, mais memória, rede, etc
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 9
Caraterística de uma Aplicação de N Camadas
Hardware
Sistema Operacional
Hypervisor
Sistema Operacional
Servidor de Aplicação
Aplicação Monolítica Grande
Um arquivo grande, incluindo
a camada de apresentação
(UI) e o código da aplicação
VM
• 3 camadas
• Somente uma linguagem
de programação
• Tudo centralizado -
mensageria,
armazenamento, banco
de dados e etc
Rico em recursos – suporta
grandes e complexas
aplicações, vários casos de
uso
Provê 100% de isolamento
Configuração manual
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 10
O que são Microserviços
Arquitetura N Camadas Microserviços
Aplicação Monolítica
Precisa implantar (deploy) de toda a aplicação
Um banco de dados para a aplicação inteira
Chamada “In-process”, SOAP externamente
Organizado em torno das camadas de Tecnologia
Desenvolvedores não fazem suporte a “operação”
Uma Tecnologia para toda a aplicação
Vários, pequenos Microserviços com função mínima
Pode implantar (deploy) cada Microserviço de forma independente
Cada Microserviço possui seu próprio banco de dados
Chamadas REST sobre HTTP, Mensageria
Organizado em torno das “Business Capabilities”
Desenvolvedores também suportam a “operação”
Escolha de uma Tecnologia para cada Microserviço
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 11
Microserviços são parecidos com as ferramentas do Unix
Mesmo conceito, décadas diferente – “Do One Thing and Do It Well”
Doug McIlroy
Inventor do Unix Pipe
“Escrever programas que executem algo e de forma
bem feita. Escrever programas para trabalhar em
conjunto. Escrever programas para lidar com fluxos de
texto, porque isso é uma interface universal.”
curl -v -H "Accept: application/json” -H "Content-type: application/json” -X POST
-d ’{"productId":645887","quantity":"1"}'
"http://localhost:8840/rest/ShoppingCart/”
• Executável Unix: Executa algo e de forma bem feito
• É executado independentemente de outros comandos
• Produz uma resposta baseado em texto
• Microserviço: Executa algo e de forma bem feito
• É executado independetemente de outros Microserviços
• Produz resposta baseado em texto para os clientes
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 12
Microserviços são Desenvolvidos / Implantados Independentemente
Interface do usuário
Aplicação
Banco de Dados
Infraestrutura
Aplicação N Camadas
Aplicação Monolítica
Microserviços
Vários pequenos Microserviços
API
Aplicação
Banco de Dados
Infraestrutra
Microserviço
Estoque
API
Aplicação
Banco de Dados
Infraestrutura
Microserviço
Pagamento
API
Applicação
Banco de Dados
Infraestrura
Microseriço
Perfil
API
Applicação
Banco de Dados
Infraestrura
Microserviço
Catálogo de Produtos
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 13
Fundamentalmente, Microserviços é uma troca
Implantação mais fácil Desenv. Mais fácil
Você quer...
Desenv. Tradicional de aplicação Microserviços
• Um grande bloco de código,
às vezes, divididas em
módulos
• Complexidade gerenciada
dentro do grande bloco de
código
• Cada bloco de código é difícil
de desenvolver, mas fácil
para implantar.
• Vários pequenos blocos de
códigos, cada um
desenvolvido e implantados
de forma independente
• Complexidade encapsulada
dentro de cada Microserviço
• Cada Microserviço é facil de
desenvolver, mas difícil de
implantar
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 14
1. 100+ desenvolvedores para uma aplicação
2. 5m linhas de código para uma aplicação
3. Releases mensais ou trimestrais para
produção
4. > 1 backlog por trimestre para o
desenvolvimento
5. > 20% turnover de desenvolvedores
5 Sinais que mostram que é hora para pensar em
Microserviços
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 15
Casos de Usos para adoção de Microserviços
Eu quero extender
minha aplicação monolítica
existente adicionando
Microserviços na sua periferia
Eu quero decompor
uma aplicação monolítica
existente em uma aplicação
baseada na Arquitetura de
Microserviços
E quero construir
uma nova
aplicação baseada na
Arquitetura de Microserviços a
partir do zero
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 16
As vezes Aplicações Monolíticas ainda são uma boa Abordagem
• Para aplicações menos complexas, monólitos são
sempre melhores, tanto no curto quanto a longo prazo
• Para aplicações moderadamente complexas, monólitos
ainda são provavelmente melhor, tanto no curto quanto a
longo prazo
• Para aplicações complexas, Microserviços podem-se
pagar ao longo do tempo, mas levam-se muito tempo
para compensar o maior investimento inicial necessário
para implementá-lo
Microserviços adiciona complexidade
Tempo
Complexidade
Complex. ao Longo do Tempo
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 17
Fazer algo e fazê-lo
bem feito
Foco na “Business
Capabilities”
Evitar
Interdependências
Qual o tamanho de um Microserviço?
Pode ter centenas de Microserviços para uma Aplicação grande
Grande
Médio
Pequeno
11-15 Pessoas
Exemplo: Microserviço de Pedido
4-10 Pessoas
Exemplo: Microserviço de Estoque
1-3 Pessoas
Exemplo: Microserviço Status de
Pedido
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 18
Guia Definitivo para decidir o Tamanho de um Microserviço
• “Bounded Context” é um padrão central no Domain-Driven Design
• Lida com o design do software com base no domínio subjacente
• Você não pode construir um grande modelo de domínio unificado
para todo um sistema
• Divide um grande sistema em “Bounded Contexts”, cada um dos
quais pode ter um modelo unificado
– http://eduardopires.net.br/2016/03/ddd-bounded-context/
Domain-Driven Design: Atacando as Complexidades do Software - Eric Evans
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 19
História dos Microserviços
3/5/2018
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 20
Os Princípios de Microserviços tem estado conosco por
Décadas
Os Princípios por trás dos Microserviços
muitas vezes são apenas bons Princípios
de Arquitetura
Baixo
Acoplamento
Foco na
“Business
Capabilities” e
não nas
Camadas de
Tecnologias
Reduz a
Complexidade
através da
Modularização
Fazer algo e fazê-lo
bem feito
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 21
MicroserviçosMódulo
Modularidade sempre foi um Objetivo da Arquitetura
Mas Microserviços reforça a modularidade através da implantação de cada
Microserviços separadamente
 In process
 Chamadas Locais
 Não é independentemente Implantável
 A fronteira é fortemente reforçada
 Mesma Linguagem
 Fortemente acoplado
 Out-of-process
 Chamadas Remotas
 Independentemente Implantável
 A fronteira não é fortemente reforçada
 Diferente Linguagens
 Baixo Acomplamento
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 22
SOA vs. Microserviços
SOA é uma idéia geral, onde Microserviços são uma maneira muito específica
de implementá-los
 Favorece a Orquestração Centralizada
 SOAP + HTTP
SOA
Microserviços
 Favorece a Coreografia Distribuída
 REST + HTTP/S = simples
Diferenças de Implementação
Todos os Princípios de SOA também
se aplicam à Microserviços
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 23
SOA vs. Microserviços - Equívocos
“Microserviços eliminam a
necessidade de Enterprise
Service Bus”
Não confuda Produto com o Padrão
“Microserviços resolvem os
problemas de SOA”
Não confuda implementações mal
sucessidas de SOA com problemas
de SOA
“Empresas como Netflix e
Linkedin usam Microserviços,
então nós devemos usar
também”
Netflix e LinkedIn são uma plataforma de
negócios. Qual é o seu negócio?
“Devemos escolher
Microserviços ou SOA”
Utilize ambos
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 24
Princípios de Microserviços são Antigos. A Implementação é Nova
Microserviços não é apenas um novo nome para SOA
• Times independentes: Arquiteto, Desenvolvedor, Operação para manter cada Microserviço
• Cada Microserviço tem o seu próprio Banco de Dados, que pode não estar sempre 100% atualizado
• Respostas de Microserviço não são manipuladas por um intermediário, por exemplo, um ESB
• Microserviços favorecem transportes simples – XML ou JSON sobre HTTP / S. Não SOAP
• Qualquer instância de um Microserviço é Stateless
• Microserviços são Poliglotas, cada time de um Microserviço é livre para escolher a melhor Tecnologia
• Princípios DevOps – instalação automatizada e Desenvolvedores dando suporte a produção
• Uso de Containers, que permite o empacotameno de uma aplicação e o rápido tempo de inicialização
• Uso da Nuvem, para um infraestrutura Elástica
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 25
Arquitetura de Microserviços
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 26
Pré Requisitos não técnicos
3/5/2018
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 27
Lei Conway
“Qualquer pedaço de software
reflete a Estrutura
Organizacional que o
produziu”
Melvin Conway
1968
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 28
Lei de Conway em Ação
Qualquer pedaço de software reflete a Estrurura Organizacional que o
produziu
Interface do Usuário
Aplicação
Banco de Dados
Infraestrutura
Software ResultanteTipica Estrutura Organizacional Corporativa
Head of IT
Head of
Operations
Head of
DBAs
Head of
Infrastructure
Head of App
Dev
Head of UI
Head of
Development
Um Enorme Monólíto
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 29
Reestruture sua Organização
Construir pequenas equipes com foco em Produtos
Software ResultanteEstrutura Organiz. baseada em Microserviços
Product
Lead
Developer Sys Admin DBA
JavaScript
Developer
Vários pequenos Microserviços
Developer
Developer
Sys Admin
Storage
Admin
Graphic
Artist
NoSQL
Admin
API
Aplicação
Banco de Dados
Infraestrutura
API
Aplicação
Banco de Dados
Infraestrutura
API
Aplicação
Banco de Dados
Infraestrutura
API
Aplicação
Banco de Dados
Infraestrutura
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 30
Características dos diferentes Tipos de Organização
 Produz Microserviços
 Pequenas equipes podem fazer
quaisquer mudanças que queiram em
um determinado Microserviço
 Arquitetura “limpa” porque os
Desenvolvedores têm 100% do
controle
 Verdadeiro dono
 Produz Monólitos
 Uma simples mudança exige uma
ampla coordenação entre todas as
diferentes camadas
 A lógica de negócios esta espalhada
em todos os lugares porque é mais
fácil de implementar na sua camada
 Sem dono real
Organizações Centralizadas
Focada em Camadas de Tecnologia
Organizações Distribuídas
Focada em Produtos
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 31
Pré Requisitos de Arquitetura
3/5/2018
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 32
Microserviços Força Mudança para Computação Distribuída
Introduz enorme complexidade – monólitos não sofre disto
API
Aplicação
Banco de Dados
Infraestrutura
API
Aplicação
Banco de Dados
Infraestrutura
API
Aplicação
Banco de Dados
Infraestrutura
API
Aplicação
Banco de Dados
Infraestrutura
Microserviço A Microserviço B Microserviço C Microserviço D
• A Computação Distribuída é uma consequência natural dos
Microserviços, visto que cada Microserviços tem seu próprio
banco de dados
• Compartilhamento de banco de dados através de Microserviços
introduz acoplamento - muito ruim!
• Haverá sempre Latência entre Microserviços
• Toda a troca de dados entre
Microserviços deve ser
através da camada da API –
não ao acesso aos banco
de dados entre
Microserviços
• Deve-se implementar
mensagens de alta
velocidade entre
Microserviços utilizando
REST + HTTP. Provalmente
isso não será suficiente.
• Talvez existirá dados
duplicados entre os banco
de dados. Exemplo: dados
do cliente.
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 33
Chamadas Síncronas com Microserviços são muito ruins
Catálogo de
Produtos
Produto Preço Estoque
Encadeamento == Acomplamento == Downtime
A disponibilidade do Microserviço A depende do B, B depende do C, etc
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 34
Orquestração x Coreografia
• Orquestração: é a composição de serviços para criar um novo serviço ou para resolver uma
tarefa de um processo de negócio. Neste caso, sempre há a figura de um ponto central. Um
serviço ou uma atividade de negócio que coordena a chamada de outros serviços para compor
uma função de maior granularidade. A orquestração de serviços é análoga a um método da
orientação a objetos que faz chamadas de outros métodos.
• Coreografia: a coreografia já é pré-determinada antes da sua execução. Por exemplo, quando
um serviço é acionado e envia uma mensagem, outros serviços podem estar programados de
ante-mão para receber ou não essa mensagem e dispararem outras ações. Chamamos este
processo de evento. Serviços são acionados conforme a classe de eventos que ocorrem.
Característica básica da Arquitetura Orientada a Eventos. Em um Middleware é possível atribuir
esta característica através da criação de fluxos Publish/Subscribe
3/5/2018 Oracle Confidential – 3
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 35
Orquestração x Coreografia
Orquestração Coreografia
Livro: Building Microservices – Sam Newman
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 36
Orquestração
• Usado em aplicações
centralizadas, monolíticas
• Frágil – centralizado por
natureza
• Cada “ação” interage com
o sistema centralizado –
ponto único de falha que
não é muito flexível
Coreografia
• Usado em aplicações de
Microserviços distribuídos
• Resiliente – distribuído por
natureza
• Cada Microserviço
assincronamente lança uma
messagem que outro
Microserviço pode consumir
Microserviços Força Coreografia ao invés de Orquestração
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 37
Microserviços Força Muitas Chamadas de Rede
• Microserviços aumenta exponencialmente
chamadas de rede
• Cada tipo de chamada tem um requerimento
único
• Síncrono / Assíncrono
• Performance
• Throughput
• Latência
• Segurança
Monólitos na maioria das vezes fazem chamadas locais dentro de um único
processo
Cliente
Banco de
Dados
Banco de
Dados
Microserviço Microserviço
API Gateway
Síncrono
Assíncrono
Internet Pública
Data Center
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 38
API Gateways faz o Balancemanto de Carga e Agregação das
Respostas
API gateways fornece um "backend” para cada “frontend"
Cliente
Internet Pública
Microserviço Microserviço Microserviço
Microserviço Microserviço Microserviço
Data Center
API Gateway
Microserviço Microserviço Microserviço
– Constrói uma resposta XML ou JSON para cada
tipo de cliente - web, celular, etc
– Chamadas Assíncronas para cada um dos N
Microserviços necessários para construir a
resposta
– Gerencia Segurança e esconde o “back-end”
– Balanceamento de carga
– Métricas das APIs
– Logs centralizados
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 39
REST: Representational State Transfer
Fortemente associado com Microserviços, mas não é um requisite técnico
HTTP
REST
XML ou
JSON
HTTP
Response
Codes
• Alternativa muito mais simples que o SOAP
• Utiliza GET, POST, PUT, DELETE, etc – Assim
como os navegadores WEB
• Versões de APIs - /v1.2/cliente
• Pode utilizar XML or JSON
• XML é muitas vezes melhor - suporte XPath,
seletores de CSS
• Não pode gerar “stubs” fortemente tipados
REST =
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 40
Circuit Breakers para prevenção de falhas em cascatas
• Regra #1 de Microserviços – Evite Acomplamento
• Síncrono = 2 sistemas estão acoplados
• Assíncrono = não tem acomplamento
• Falhas em cascatas acontecem quando uma thread que gerencia um request esta
aguardando a resposta de uma aplicação remota
• Circuit breakers realizam chamadas assíncronas para um outro pool de thread para
evitar stuck threads
• Hystrix (Java) é bem conhecido e resolve este problema
Falhas em cascata são muito comum com Microserviços
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 41
Logging: Microserviços torna mais difícil
• Mais aplicações, mais containers/VMs/hosts, mais Banco de Dados, mais tudo
• Mais pontos de falhas
• Mais fácil ter falhas em cascata
Logging é muito importante1
• Deve-se implementar o recurso de log em todos os pontos ao longo dos
Microserviços.
• Os logs devem ser enviados para um repositório central
• Deve-se centralizar todos os logs para formar uma visão centralizada
Requisitos2
• Colete, análise e transforme arquivos de log: Logstash, Splunk
• Agrege os arquivos de logs: ElasticSearch, Splunk
• Visualização, métricas: Kibana, Splunk
Soluções3
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 42
O que / como Monitorar
Monitorar um Monólito e relativamente simples – uma aplicação.
Microserviços = várias aplicações
Req. para monitoração de Microserviços
1. Monitorar throughput,
performance e métricas de
negócios
2. Monitorar cada request para cada
Microserviço – end-to-end
3. Acompanhar a saúde das
dependências
4. Monitorar cada processo, OS,
host, etc
Dropwizard Metrics
Ferramentas Populares
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 43
Desenho de API - Swagger
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 44
Arquitetura REST
• É um termo definido por Roy Fielding em sua tese de doutorado, no qual ele descreve um estilo
de arquitetura de software sobre um sistema operado em rede. REST é um acrônimo para
"Transferência de Estado Representacional" (Representational State Transfer).
• Vê cada aplicação web como um conjunto de recursos que representam um estado particular
de um aplicativo. Quando você acessa este recurso, transfere-se o estado (conteúdo), e talvez
altera-se o seu estado.
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 45
RESTFul
• RESTful é uma implementação de um "web service" simples utilizando o HTTP e os principios REST
• Normalmente utiliza o formato JSON (JavaScript Object Notation):
{
"name": "read-node",
"cluster_name": "apache-cluster",
"version": {
"number": "2.1.0",
"build_hash": "72cd1f1a3eee09505e036106146dc1949dc5dc87",
"build_timestamp": "2015-11-18T22:40:03Z",
"build_snapshot": false,
"lucene_version": "5.3.1"
},
"tagline": "You Know, for Search"
}
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 46
JSON
Dados
"nome":"Roberto Carlos"
Objetos
{
"nome": "Roberto Carlos",
"documento": "879.728"
}
Array
"clientes":[
{"nome":"Kibana",
"documento":"258.741"},
{"nome":“Kitri”,
"documento":"789.456"},
{"nome":"Prince",
"documento":"258.321"}
]
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 47
Exemplo: API Elasticsearch
• https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html
• https://www.havenondemand.com/
Internal Use Only
© Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 48
Desenho API - Swagger
• Ferramenta para desenho de RESTful API
• Utiliza sintaxe YAML
• 100% Open Source
• Gera código para várias linguaguens de programação: back end e client sdk
• http://editor.swagger.io/
• Outros ferramentas/frameworks:
• http://raml.org/
• https://apiblueprint.org/
Perguntas e Repostas
Obrigado

Mais conteúdo relacionado

Mais procurados

Tdc 2020 gerenciamento de incidente neste novo mundo
Tdc 2020   gerenciamento de incidente neste novo mundoTdc 2020   gerenciamento de incidente neste novo mundo
Tdc 2020 gerenciamento de incidente neste novo mundo
Felipe Klerk Signorini
 
Um método para o desenvolvimento de software baseado em microsserviços
Um método para o desenvolvimento de software baseado em microsserviçosUm método para o desenvolvimento de software baseado em microsserviços
Um método para o desenvolvimento de software baseado em microsserviços
Thiago Pereira
 
Workshop soa, microservices e devops
Workshop soa, microservices e devopsWorkshop soa, microservices e devops
Workshop soa, microservices e devops
Diego Pacheco
 
Vantagens e desvantagens de uma arquitetura microservices
Vantagens e desvantagens de uma arquitetura microservicesVantagens e desvantagens de uma arquitetura microservices
Vantagens e desvantagens de uma arquitetura microservices
Fábio Rosato
 
Microservices
MicroservicesMicroservices
Microservices
Rafael Sousa
 
TheDevConf - Implantando Arquitetura de Microsserviços em Alta Disponibilidad...
TheDevConf - Implantando Arquitetura de Microsserviços em Alta Disponibilidad...TheDevConf - Implantando Arquitetura de Microsserviços em Alta Disponibilidad...
TheDevConf - Implantando Arquitetura de Microsserviços em Alta Disponibilidad...
André Dias
 
Phprs meetup - deploys automatizados com gitlab
Phprs   meetup - deploys automatizados com gitlabPhprs   meetup - deploys automatizados com gitlab
Phprs meetup - deploys automatizados com gitlab
Jackson F. de A. Mafra
 
MVP Show Cast 2013 - Desvendando o Windows Azure Media Services
MVP Show Cast 2013 - Desvendando o Windows Azure Media ServicesMVP Show Cast 2013 - Desvendando o Windows Azure Media Services
MVP Show Cast 2013 - Desvendando o Windows Azure Media Services
Vitor Meriat
 
Boas Práticas em Aplicações na Nuvem: Twelve-Factor App - Março-2021
Boas Práticas em Aplicações na Nuvem: Twelve-Factor App - Março-2021Boas Práticas em Aplicações na Nuvem: Twelve-Factor App - Março-2021
Boas Práticas em Aplicações na Nuvem: Twelve-Factor App - Março-2021
Renato Groffe
 
Desvendando o Windows Azure Media Services - O que é possível fazer? [MVP Sho...
Desvendando o Windows Azure Media Services - O que é possível fazer? [MVP Sho...Desvendando o Windows Azure Media Services - O que é possível fazer? [MVP Sho...
Desvendando o Windows Azure Media Services - O que é possível fazer? [MVP Sho...
MVP ShowCast
 
Boas Práticas em Aplicações na Nuvem: Twelve-Factor App | MVPConf Latam 2021
Boas Práticas em Aplicações na Nuvem: Twelve-Factor App | MVPConf Latam 2021Boas Práticas em Aplicações na Nuvem: Twelve-Factor App | MVPConf Latam 2021
Boas Práticas em Aplicações na Nuvem: Twelve-Factor App | MVPConf Latam 2021
Renato Groffe
 
Boas Práticas em Aplicações na Nuvem: Twelve-Factor App | TDC Connections 2021
Boas Práticas em Aplicações na Nuvem: Twelve-Factor App | TDC Connections 2021Boas Práticas em Aplicações na Nuvem: Twelve-Factor App | TDC Connections 2021
Boas Práticas em Aplicações na Nuvem: Twelve-Factor App | TDC Connections 2021
Renato Groffe
 
Arquitetura de Micro Serviços
Arquitetura de Micro ServiçosArquitetura de Micro Serviços
Arquitetura de Micro Serviços
Fernando Ike
 
Netshoes - API Gateway
Netshoes - API GatewayNetshoes - API Gateway
Netshoes - API Gateway
Marcos Barbero
 
Microserviços com DevOps
Microserviços com DevOpsMicroserviços com DevOps
Microserviços com DevOps
Matheus Hunsche
 
Microservices: Mais que uma arquitetura de software, uma filosofia de desenvo...
Microservices: Mais que uma arquitetura de software, uma filosofia de desenvo...Microservices: Mais que uma arquitetura de software, uma filosofia de desenvo...
Microservices: Mais que uma arquitetura de software, uma filosofia de desenvo...
Emmanuel Neri
 
Aplicações Distribuídas com .NET e Apache Kafka
Aplicações Distribuídas com .NET e Apache KafkaAplicações Distribuídas com .NET e Apache Kafka
Aplicações Distribuídas com .NET e Apache Kafka
Gustavo Bellini Bigardi
 
DevOps & Docker com a stack Microsoft
DevOps & Docker com a stack MicrosoftDevOps & Docker com a stack Microsoft
DevOps & Docker com a stack Microsoft
Graziella Bonizi
 
Go e Microserviços - Nascidos um para o outro
Go e Microserviços - Nascidos um para o outroGo e Microserviços - Nascidos um para o outro
Go e Microserviços - Nascidos um para o outro
Elton Minetto
 
O que há de Interop no Windows Server 2012 R2 [MVP ShowCast 2013 - IT - Inter...
O que há de Interop no Windows Server 2012 R2 [MVP ShowCast 2013 - IT - Inter...O que há de Interop no Windows Server 2012 R2 [MVP ShowCast 2013 - IT - Inter...
O que há de Interop no Windows Server 2012 R2 [MVP ShowCast 2013 - IT - Inter...
MVP ShowCast
 

Mais procurados (20)

Tdc 2020 gerenciamento de incidente neste novo mundo
Tdc 2020   gerenciamento de incidente neste novo mundoTdc 2020   gerenciamento de incidente neste novo mundo
Tdc 2020 gerenciamento de incidente neste novo mundo
 
Um método para o desenvolvimento de software baseado em microsserviços
Um método para o desenvolvimento de software baseado em microsserviçosUm método para o desenvolvimento de software baseado em microsserviços
Um método para o desenvolvimento de software baseado em microsserviços
 
Workshop soa, microservices e devops
Workshop soa, microservices e devopsWorkshop soa, microservices e devops
Workshop soa, microservices e devops
 
Vantagens e desvantagens de uma arquitetura microservices
Vantagens e desvantagens de uma arquitetura microservicesVantagens e desvantagens de uma arquitetura microservices
Vantagens e desvantagens de uma arquitetura microservices
 
Microservices
MicroservicesMicroservices
Microservices
 
TheDevConf - Implantando Arquitetura de Microsserviços em Alta Disponibilidad...
TheDevConf - Implantando Arquitetura de Microsserviços em Alta Disponibilidad...TheDevConf - Implantando Arquitetura de Microsserviços em Alta Disponibilidad...
TheDevConf - Implantando Arquitetura de Microsserviços em Alta Disponibilidad...
 
Phprs meetup - deploys automatizados com gitlab
Phprs   meetup - deploys automatizados com gitlabPhprs   meetup - deploys automatizados com gitlab
Phprs meetup - deploys automatizados com gitlab
 
MVP Show Cast 2013 - Desvendando o Windows Azure Media Services
MVP Show Cast 2013 - Desvendando o Windows Azure Media ServicesMVP Show Cast 2013 - Desvendando o Windows Azure Media Services
MVP Show Cast 2013 - Desvendando o Windows Azure Media Services
 
Boas Práticas em Aplicações na Nuvem: Twelve-Factor App - Março-2021
Boas Práticas em Aplicações na Nuvem: Twelve-Factor App - Março-2021Boas Práticas em Aplicações na Nuvem: Twelve-Factor App - Março-2021
Boas Práticas em Aplicações na Nuvem: Twelve-Factor App - Março-2021
 
Desvendando o Windows Azure Media Services - O que é possível fazer? [MVP Sho...
Desvendando o Windows Azure Media Services - O que é possível fazer? [MVP Sho...Desvendando o Windows Azure Media Services - O que é possível fazer? [MVP Sho...
Desvendando o Windows Azure Media Services - O que é possível fazer? [MVP Sho...
 
Boas Práticas em Aplicações na Nuvem: Twelve-Factor App | MVPConf Latam 2021
Boas Práticas em Aplicações na Nuvem: Twelve-Factor App | MVPConf Latam 2021Boas Práticas em Aplicações na Nuvem: Twelve-Factor App | MVPConf Latam 2021
Boas Práticas em Aplicações na Nuvem: Twelve-Factor App | MVPConf Latam 2021
 
Boas Práticas em Aplicações na Nuvem: Twelve-Factor App | TDC Connections 2021
Boas Práticas em Aplicações na Nuvem: Twelve-Factor App | TDC Connections 2021Boas Práticas em Aplicações na Nuvem: Twelve-Factor App | TDC Connections 2021
Boas Práticas em Aplicações na Nuvem: Twelve-Factor App | TDC Connections 2021
 
Arquitetura de Micro Serviços
Arquitetura de Micro ServiçosArquitetura de Micro Serviços
Arquitetura de Micro Serviços
 
Netshoes - API Gateway
Netshoes - API GatewayNetshoes - API Gateway
Netshoes - API Gateway
 
Microserviços com DevOps
Microserviços com DevOpsMicroserviços com DevOps
Microserviços com DevOps
 
Microservices: Mais que uma arquitetura de software, uma filosofia de desenvo...
Microservices: Mais que uma arquitetura de software, uma filosofia de desenvo...Microservices: Mais que uma arquitetura de software, uma filosofia de desenvo...
Microservices: Mais que uma arquitetura de software, uma filosofia de desenvo...
 
Aplicações Distribuídas com .NET e Apache Kafka
Aplicações Distribuídas com .NET e Apache KafkaAplicações Distribuídas com .NET e Apache Kafka
Aplicações Distribuídas com .NET e Apache Kafka
 
DevOps & Docker com a stack Microsoft
DevOps & Docker com a stack MicrosoftDevOps & Docker com a stack Microsoft
DevOps & Docker com a stack Microsoft
 
Go e Microserviços - Nascidos um para o outro
Go e Microserviços - Nascidos um para o outroGo e Microserviços - Nascidos um para o outro
Go e Microserviços - Nascidos um para o outro
 
O que há de Interop no Windows Server 2012 R2 [MVP ShowCast 2013 - IT - Inter...
O que há de Interop no Windows Server 2012 R2 [MVP ShowCast 2013 - IT - Inter...O que há de Interop no Windows Server 2012 R2 [MVP ShowCast 2013 - IT - Inter...
O que há de Interop no Windows Server 2012 R2 [MVP ShowCast 2013 - IT - Inter...
 

Semelhante a Arquitetura de Microservicos

Arquitetura de Microserviços - Tecnologia na Prática - Julho/2017
Arquitetura de Microserviços - Tecnologia na Prática - Julho/2017Arquitetura de Microserviços - Tecnologia na Prática - Julho/2017
Arquitetura de Microserviços - Tecnologia na Prática - Julho/2017
Renato Groff
 
Plataforma Android: Produtividade Além do SDK
Plataforma Android: Produtividade Além do SDKPlataforma Android: Produtividade Além do SDK
Plataforma Android: Produtividade Além do SDK
Ryan Padilha
 
Microserviços - Universidade Metodista - EETI 2016
Microserviços - Universidade Metodista - EETI 2016Microserviços - Universidade Metodista - EETI 2016
Microserviços - Universidade Metodista - EETI 2016
Renato Groff
 
[JS EXPERIENCE 2018] Do jQuery aos microfrontends: os desafios de manter uma ...
[JS EXPERIENCE 2018] Do jQuery aos microfrontends: os desafios de manter uma ...[JS EXPERIENCE 2018] Do jQuery aos microfrontends: os desafios de manter uma ...
[JS EXPERIENCE 2018] Do jQuery aos microfrontends: os desafios de manter uma ...
iMasters
 
Arquitetura de Microserviços - Stone Tech Saturday - Março/2017
Arquitetura de Microserviços - Stone Tech Saturday - Março/2017Arquitetura de Microserviços - Stone Tech Saturday - Março/2017
Arquitetura de Microserviços - Stone Tech Saturday - Março/2017
Renato Groff
 
Micro frontend de um jeito que você nunca viu
Micro frontend de um jeito que você nunca viuMicro frontend de um jeito que você nunca viu
Micro frontend de um jeito que você nunca viu
Wagner Souza
 
Plataformas Monolíticas, redescobrindo o Desktop e sendo Ágil para Web.
Plataformas Monolíticas, redescobrindo o Desktop e sendo Ágil para Web.Plataformas Monolíticas, redescobrindo o Desktop e sendo Ágil para Web.
Plataformas Monolíticas, redescobrindo o Desktop e sendo Ágil para Web.
Cristofer Sousa
 
Introdução ao IBM Bluemix - Silvia Matsuora (Solution IT Architect - Ecosyste...
Introdução ao IBM Bluemix - Silvia Matsuora (Solution IT Architect - Ecosyste...Introdução ao IBM Bluemix - Silvia Matsuora (Solution IT Architect - Ecosyste...
Introdução ao IBM Bluemix - Silvia Matsuora (Solution IT Architect - Ecosyste...
Victor Cavalcante
 
Engenharia de Software Aula 1 - Intro
Engenharia de Software Aula 1 - IntroEngenharia de Software Aula 1 - Intro
Engenharia de Software Aula 1 - Intro
Rudson Kiyoshi Souza Carvalho
 
Introdução C#
Introdução C#Introdução C#
Introdução C#
Luis Fernando Marques
 
ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122
ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122
ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122
Bruno Souza
 
Microservices 2
Microservices 2Microservices 2
Microservices 2
Filipe Nunes
 
MVC e Frameworks MVC
MVC e Frameworks MVCMVC e Frameworks MVC
MVC e Frameworks MVC
Leandro Rodrigues
 
Escalando apps com React e Type Script e SOLID
Escalando apps com React e Type Script e SOLIDEscalando apps com React e Type Script e SOLID
Escalando apps com React e Type Script e SOLID
Ruben Marcus Luz Paschoarelli
 
Introdução a arquitetura de sistemas com .NET
Introdução a arquitetura de sistemas com .NETIntrodução a arquitetura de sistemas com .NET
Introdução a arquitetura de sistemas com .NET
Mário Meyrelles
 
APRESENTACAO WALANEM ANDROID (1)
APRESENTACAO WALANEM ANDROID (1)APRESENTACAO WALANEM ANDROID (1)
APRESENTACAO WALANEM ANDROID (1)
Walanem Figueiredo
 
WebSphere 8 Intro (pt-BR)
WebSphere 8 Intro (pt-BR)WebSphere 8 Intro (pt-BR)
WebSphere 8 Intro (pt-BR)
Juarez Junior
 
Microserviços na vida real
Microserviços na vida realMicroserviços na vida real
Microserviços na vida real
Criciúma Dev
 
Conheça o Cloud Foundry no HCP
Conheça o Cloud Foundry no HCPConheça o Cloud Foundry no HCP
Conheça o Cloud Foundry no HCP
Jose Nunes
 
Desenvolvimento web - conceitos, tecnologia e tendências.
Desenvolvimento web - conceitos, tecnologia e tendências.Desenvolvimento web - conceitos, tecnologia e tendências.
Desenvolvimento web - conceitos, tecnologia e tendências.
Valmir Justo
 

Semelhante a Arquitetura de Microservicos (20)

Arquitetura de Microserviços - Tecnologia na Prática - Julho/2017
Arquitetura de Microserviços - Tecnologia na Prática - Julho/2017Arquitetura de Microserviços - Tecnologia na Prática - Julho/2017
Arquitetura de Microserviços - Tecnologia na Prática - Julho/2017
 
Plataforma Android: Produtividade Além do SDK
Plataforma Android: Produtividade Além do SDKPlataforma Android: Produtividade Além do SDK
Plataforma Android: Produtividade Além do SDK
 
Microserviços - Universidade Metodista - EETI 2016
Microserviços - Universidade Metodista - EETI 2016Microserviços - Universidade Metodista - EETI 2016
Microserviços - Universidade Metodista - EETI 2016
 
[JS EXPERIENCE 2018] Do jQuery aos microfrontends: os desafios de manter uma ...
[JS EXPERIENCE 2018] Do jQuery aos microfrontends: os desafios de manter uma ...[JS EXPERIENCE 2018] Do jQuery aos microfrontends: os desafios de manter uma ...
[JS EXPERIENCE 2018] Do jQuery aos microfrontends: os desafios de manter uma ...
 
Arquitetura de Microserviços - Stone Tech Saturday - Março/2017
Arquitetura de Microserviços - Stone Tech Saturday - Março/2017Arquitetura de Microserviços - Stone Tech Saturday - Março/2017
Arquitetura de Microserviços - Stone Tech Saturday - Março/2017
 
Micro frontend de um jeito que você nunca viu
Micro frontend de um jeito que você nunca viuMicro frontend de um jeito que você nunca viu
Micro frontend de um jeito que você nunca viu
 
Plataformas Monolíticas, redescobrindo o Desktop e sendo Ágil para Web.
Plataformas Monolíticas, redescobrindo o Desktop e sendo Ágil para Web.Plataformas Monolíticas, redescobrindo o Desktop e sendo Ágil para Web.
Plataformas Monolíticas, redescobrindo o Desktop e sendo Ágil para Web.
 
Introdução ao IBM Bluemix - Silvia Matsuora (Solution IT Architect - Ecosyste...
Introdução ao IBM Bluemix - Silvia Matsuora (Solution IT Architect - Ecosyste...Introdução ao IBM Bluemix - Silvia Matsuora (Solution IT Architect - Ecosyste...
Introdução ao IBM Bluemix - Silvia Matsuora (Solution IT Architect - Ecosyste...
 
Engenharia de Software Aula 1 - Intro
Engenharia de Software Aula 1 - IntroEngenharia de Software Aula 1 - Intro
Engenharia de Software Aula 1 - Intro
 
Introdução C#
Introdução C#Introdução C#
Introdução C#
 
ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122
ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122
ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122
 
Microservices 2
Microservices 2Microservices 2
Microservices 2
 
MVC e Frameworks MVC
MVC e Frameworks MVCMVC e Frameworks MVC
MVC e Frameworks MVC
 
Escalando apps com React e Type Script e SOLID
Escalando apps com React e Type Script e SOLIDEscalando apps com React e Type Script e SOLID
Escalando apps com React e Type Script e SOLID
 
Introdução a arquitetura de sistemas com .NET
Introdução a arquitetura de sistemas com .NETIntrodução a arquitetura de sistemas com .NET
Introdução a arquitetura de sistemas com .NET
 
APRESENTACAO WALANEM ANDROID (1)
APRESENTACAO WALANEM ANDROID (1)APRESENTACAO WALANEM ANDROID (1)
APRESENTACAO WALANEM ANDROID (1)
 
WebSphere 8 Intro (pt-BR)
WebSphere 8 Intro (pt-BR)WebSphere 8 Intro (pt-BR)
WebSphere 8 Intro (pt-BR)
 
Microserviços na vida real
Microserviços na vida realMicroserviços na vida real
Microserviços na vida real
 
Conheça o Cloud Foundry no HCP
Conheça o Cloud Foundry no HCPConheça o Cloud Foundry no HCP
Conheça o Cloud Foundry no HCP
 
Desenvolvimento web - conceitos, tecnologia e tendências.
Desenvolvimento web - conceitos, tecnologia e tendências.Desenvolvimento web - conceitos, tecnologia e tendências.
Desenvolvimento web - conceitos, tecnologia e tendências.
 

Mais de Norberto Enomoto

Resilience4j
Resilience4jResilience4j
Resilience4j
Norberto Enomoto
 
Azure Pipeline
Azure PipelineAzure Pipeline
Azure Pipeline
Norberto Enomoto
 
AWS ECS vs EKS
AWS ECS vs EKSAWS ECS vs EKS
AWS ECS vs EKS
Norberto Enomoto
 
Workshop Azure DevOps | Docker | Azure Kubernetes Services
Workshop Azure DevOps | Docker | Azure Kubernetes ServicesWorkshop Azure DevOps | Docker | Azure Kubernetes Services
Workshop Azure DevOps | Docker | Azure Kubernetes Services
Norberto Enomoto
 
Workshop Azure DevOps Repos
Workshop Azure DevOps ReposWorkshop Azure DevOps Repos
Workshop Azure DevOps Repos
Norberto Enomoto
 
Criação de uma API RESTful Multitenat em Spring Boot e Oracle database utiliz...
Criação de uma API RESTful Multitenat em Spring Boot e Oracle database utiliz...Criação de uma API RESTful Multitenat em Spring Boot e Oracle database utiliz...
Criação de uma API RESTful Multitenat em Spring Boot e Oracle database utiliz...
Norberto Enomoto
 
Protocolo MQTT: Message Queuing Telemetry Transport
Protocolo MQTT: Message Queuing Telemetry TransportProtocolo MQTT: Message Queuing Telemetry Transport
Protocolo MQTT: Message Queuing Telemetry Transport
Norberto Enomoto
 
HP Communications and Media | Solutions IoT Platform
HP Communications and Media | Solutions IoT Platform HP Communications and Media | Solutions IoT Platform
HP Communications and Media | Solutions IoT Platform
Norberto Enomoto
 
Web Services
Web ServicesWeb Services
Web Services
Norberto Enomoto
 
MQTT: Message Queuing Telemetry Transport (IoT)
MQTT: Message Queuing Telemetry Transport (IoT)MQTT: Message Queuing Telemetry Transport (IoT)
MQTT: Message Queuing Telemetry Transport (IoT)
Norberto Enomoto
 
Overview Governança SOA - HP Brazil
Overview Governança SOA - HP BrazilOverview Governança SOA - HP Brazil
Overview Governança SOA - HP Brazil
Norberto Enomoto
 
Oracle Service Bus - HP Brazil
Oracle Service Bus - HP BrazilOracle Service Bus - HP Brazil
Oracle Service Bus - HP Brazil
Norberto Enomoto
 

Mais de Norberto Enomoto (12)

Resilience4j
Resilience4jResilience4j
Resilience4j
 
Azure Pipeline
Azure PipelineAzure Pipeline
Azure Pipeline
 
AWS ECS vs EKS
AWS ECS vs EKSAWS ECS vs EKS
AWS ECS vs EKS
 
Workshop Azure DevOps | Docker | Azure Kubernetes Services
Workshop Azure DevOps | Docker | Azure Kubernetes ServicesWorkshop Azure DevOps | Docker | Azure Kubernetes Services
Workshop Azure DevOps | Docker | Azure Kubernetes Services
 
Workshop Azure DevOps Repos
Workshop Azure DevOps ReposWorkshop Azure DevOps Repos
Workshop Azure DevOps Repos
 
Criação de uma API RESTful Multitenat em Spring Boot e Oracle database utiliz...
Criação de uma API RESTful Multitenat em Spring Boot e Oracle database utiliz...Criação de uma API RESTful Multitenat em Spring Boot e Oracle database utiliz...
Criação de uma API RESTful Multitenat em Spring Boot e Oracle database utiliz...
 
Protocolo MQTT: Message Queuing Telemetry Transport
Protocolo MQTT: Message Queuing Telemetry TransportProtocolo MQTT: Message Queuing Telemetry Transport
Protocolo MQTT: Message Queuing Telemetry Transport
 
HP Communications and Media | Solutions IoT Platform
HP Communications and Media | Solutions IoT Platform HP Communications and Media | Solutions IoT Platform
HP Communications and Media | Solutions IoT Platform
 
Web Services
Web ServicesWeb Services
Web Services
 
MQTT: Message Queuing Telemetry Transport (IoT)
MQTT: Message Queuing Telemetry Transport (IoT)MQTT: Message Queuing Telemetry Transport (IoT)
MQTT: Message Queuing Telemetry Transport (IoT)
 
Overview Governança SOA - HP Brazil
Overview Governança SOA - HP BrazilOverview Governança SOA - HP Brazil
Overview Governança SOA - HP Brazil
 
Oracle Service Bus - HP Brazil
Oracle Service Bus - HP BrazilOracle Service Bus - HP Brazil
Oracle Service Bus - HP Brazil
 

Último

Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdfEscola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Gabriel de Mattos Faustino
 
Guardioes Digitais em ação: Como criar senhas seguras!
Guardioes Digitais em ação: Como criar senhas seguras!Guardioes Digitais em ação: Como criar senhas seguras!
Guardioes Digitais em ação: Como criar senhas seguras!
Jonathas Muniz
 
Segurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas PráticasSegurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas Práticas
Danilo Pinotti
 
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
Faga1939
 
Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
Momento da Informática
 
História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
TomasSousa7
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
Momento da Informática
 

Último (7)

Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdfEscola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
 
Guardioes Digitais em ação: Como criar senhas seguras!
Guardioes Digitais em ação: Como criar senhas seguras!Guardioes Digitais em ação: Como criar senhas seguras!
Guardioes Digitais em ação: Como criar senhas seguras!
 
Segurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas PráticasSegurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas Práticas
 
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
 
Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
 
História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
 

Arquitetura de Microservicos

  • 1. Arquitetura de Microserviços Norberto Enomoto SOA | Integration | IoT Architect norberto.enomoto@hpe.com 18/08/2016
  • 2. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 2 Agenda • Introdução • História dos Microserviços • Pré Requisitos não técnicos • Pré Requisitos de Arquitetura • Desenho de API – Swagger • Perguntas e Respostas
  • 3. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 3 Introdução
  • 4. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 4 Arquitetura de Microserviço É um Estilo de Arquitetura que enfatiza a decomposição de aplicativos em microserviços de baixo acoplamento gerido por equipes multifuncionais, para a entrega e manutenção de sistemas de software complexos com a velocidade e qualidade exigida pelos negócios digitais de hoje.
  • 5. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 5 Arquitetura de Microserviços Monolítico Microserviço
  • 6. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 6 Arquitetura de Microserviços
  • 7. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 7 Arquitetura de Microserviços • As aplicações são composições de processos pequenos e independentes • Esses processos se comunicam através de um API em Restfull (HTTP / JSON) • Normalmente a aplicação front-end (Angular, React e etc) irá utilizar a resposta JSON para construir a página HTML • Uma APP desenvolvida em IOS ou Android irá construir suas “views” usando a resposta JSON
  • 8. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 8 Arquiteturas Existentes tem suas Limitações Devagar Equipes divididas por função – UI, Aplicação, Middleware, Banco de Dados, etc. Leva uma eternidade para fazer qualquer coisa devido ao “cross-ticketing” Frágil Uma falha (bug) poderá rapidamente “derrubar” toda a aplicação. Pouco Resiliente Testes Ineficientes Toda vez que você alterar sua aplicação, você terá que retestar tudo. Difícil suportar a Entrega Contínua Sem Dono Quando não existe um dono, você tem negligência Complexa Aplicações tendem a ficar tão grandes e complexas para o Desenvolvedor entender ao longo do tempo. Camadas compartilhadas (ORM, Mensageria, etc) precisam gerenciar 100% dos casos de usos. Sem Dono Devagar Sem Especialização Complexa Teste Ineficientes Frágil Sem Especialização Diferentes partes da aplicação possuem diferentes necessidades – mais CPU, mais memória, rede, etc
  • 9. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 9 Caraterística de uma Aplicação de N Camadas Hardware Sistema Operacional Hypervisor Sistema Operacional Servidor de Aplicação Aplicação Monolítica Grande Um arquivo grande, incluindo a camada de apresentação (UI) e o código da aplicação VM • 3 camadas • Somente uma linguagem de programação • Tudo centralizado - mensageria, armazenamento, banco de dados e etc Rico em recursos – suporta grandes e complexas aplicações, vários casos de uso Provê 100% de isolamento Configuração manual
  • 10. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 10 O que são Microserviços Arquitetura N Camadas Microserviços Aplicação Monolítica Precisa implantar (deploy) de toda a aplicação Um banco de dados para a aplicação inteira Chamada “In-process”, SOAP externamente Organizado em torno das camadas de Tecnologia Desenvolvedores não fazem suporte a “operação” Uma Tecnologia para toda a aplicação Vários, pequenos Microserviços com função mínima Pode implantar (deploy) cada Microserviço de forma independente Cada Microserviço possui seu próprio banco de dados Chamadas REST sobre HTTP, Mensageria Organizado em torno das “Business Capabilities” Desenvolvedores também suportam a “operação” Escolha de uma Tecnologia para cada Microserviço
  • 11. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 11 Microserviços são parecidos com as ferramentas do Unix Mesmo conceito, décadas diferente – “Do One Thing and Do It Well” Doug McIlroy Inventor do Unix Pipe “Escrever programas que executem algo e de forma bem feita. Escrever programas para trabalhar em conjunto. Escrever programas para lidar com fluxos de texto, porque isso é uma interface universal.” curl -v -H "Accept: application/json” -H "Content-type: application/json” -X POST -d ’{"productId":645887","quantity":"1"}' "http://localhost:8840/rest/ShoppingCart/” • Executável Unix: Executa algo e de forma bem feito • É executado independentemente de outros comandos • Produz uma resposta baseado em texto • Microserviço: Executa algo e de forma bem feito • É executado independetemente de outros Microserviços • Produz resposta baseado em texto para os clientes
  • 12. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 12 Microserviços são Desenvolvidos / Implantados Independentemente Interface do usuário Aplicação Banco de Dados Infraestrutura Aplicação N Camadas Aplicação Monolítica Microserviços Vários pequenos Microserviços API Aplicação Banco de Dados Infraestrutra Microserviço Estoque API Aplicação Banco de Dados Infraestrutura Microserviço Pagamento API Applicação Banco de Dados Infraestrura Microseriço Perfil API Applicação Banco de Dados Infraestrura Microserviço Catálogo de Produtos
  • 13. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 13 Fundamentalmente, Microserviços é uma troca Implantação mais fácil Desenv. Mais fácil Você quer... Desenv. Tradicional de aplicação Microserviços • Um grande bloco de código, às vezes, divididas em módulos • Complexidade gerenciada dentro do grande bloco de código • Cada bloco de código é difícil de desenvolver, mas fácil para implantar. • Vários pequenos blocos de códigos, cada um desenvolvido e implantados de forma independente • Complexidade encapsulada dentro de cada Microserviço • Cada Microserviço é facil de desenvolver, mas difícil de implantar
  • 14. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 14 1. 100+ desenvolvedores para uma aplicação 2. 5m linhas de código para uma aplicação 3. Releases mensais ou trimestrais para produção 4. > 1 backlog por trimestre para o desenvolvimento 5. > 20% turnover de desenvolvedores 5 Sinais que mostram que é hora para pensar em Microserviços
  • 15. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 15 Casos de Usos para adoção de Microserviços Eu quero extender minha aplicação monolítica existente adicionando Microserviços na sua periferia Eu quero decompor uma aplicação monolítica existente em uma aplicação baseada na Arquitetura de Microserviços E quero construir uma nova aplicação baseada na Arquitetura de Microserviços a partir do zero
  • 16. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 16 As vezes Aplicações Monolíticas ainda são uma boa Abordagem • Para aplicações menos complexas, monólitos são sempre melhores, tanto no curto quanto a longo prazo • Para aplicações moderadamente complexas, monólitos ainda são provavelmente melhor, tanto no curto quanto a longo prazo • Para aplicações complexas, Microserviços podem-se pagar ao longo do tempo, mas levam-se muito tempo para compensar o maior investimento inicial necessário para implementá-lo Microserviços adiciona complexidade Tempo Complexidade Complex. ao Longo do Tempo
  • 17. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 17 Fazer algo e fazê-lo bem feito Foco na “Business Capabilities” Evitar Interdependências Qual o tamanho de um Microserviço? Pode ter centenas de Microserviços para uma Aplicação grande Grande Médio Pequeno 11-15 Pessoas Exemplo: Microserviço de Pedido 4-10 Pessoas Exemplo: Microserviço de Estoque 1-3 Pessoas Exemplo: Microserviço Status de Pedido
  • 18. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 18 Guia Definitivo para decidir o Tamanho de um Microserviço • “Bounded Context” é um padrão central no Domain-Driven Design • Lida com o design do software com base no domínio subjacente • Você não pode construir um grande modelo de domínio unificado para todo um sistema • Divide um grande sistema em “Bounded Contexts”, cada um dos quais pode ter um modelo unificado – http://eduardopires.net.br/2016/03/ddd-bounded-context/ Domain-Driven Design: Atacando as Complexidades do Software - Eric Evans
  • 19. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 19 História dos Microserviços 3/5/2018
  • 20. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 20 Os Princípios de Microserviços tem estado conosco por Décadas Os Princípios por trás dos Microserviços muitas vezes são apenas bons Princípios de Arquitetura Baixo Acoplamento Foco na “Business Capabilities” e não nas Camadas de Tecnologias Reduz a Complexidade através da Modularização Fazer algo e fazê-lo bem feito
  • 21. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 21 MicroserviçosMódulo Modularidade sempre foi um Objetivo da Arquitetura Mas Microserviços reforça a modularidade através da implantação de cada Microserviços separadamente  In process  Chamadas Locais  Não é independentemente Implantável  A fronteira é fortemente reforçada  Mesma Linguagem  Fortemente acoplado  Out-of-process  Chamadas Remotas  Independentemente Implantável  A fronteira não é fortemente reforçada  Diferente Linguagens  Baixo Acomplamento
  • 22. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 22 SOA vs. Microserviços SOA é uma idéia geral, onde Microserviços são uma maneira muito específica de implementá-los  Favorece a Orquestração Centralizada  SOAP + HTTP SOA Microserviços  Favorece a Coreografia Distribuída  REST + HTTP/S = simples Diferenças de Implementação Todos os Princípios de SOA também se aplicam à Microserviços
  • 23. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 23 SOA vs. Microserviços - Equívocos “Microserviços eliminam a necessidade de Enterprise Service Bus” Não confuda Produto com o Padrão “Microserviços resolvem os problemas de SOA” Não confuda implementações mal sucessidas de SOA com problemas de SOA “Empresas como Netflix e Linkedin usam Microserviços, então nós devemos usar também” Netflix e LinkedIn são uma plataforma de negócios. Qual é o seu negócio? “Devemos escolher Microserviços ou SOA” Utilize ambos
  • 24. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 24 Princípios de Microserviços são Antigos. A Implementação é Nova Microserviços não é apenas um novo nome para SOA • Times independentes: Arquiteto, Desenvolvedor, Operação para manter cada Microserviço • Cada Microserviço tem o seu próprio Banco de Dados, que pode não estar sempre 100% atualizado • Respostas de Microserviço não são manipuladas por um intermediário, por exemplo, um ESB • Microserviços favorecem transportes simples – XML ou JSON sobre HTTP / S. Não SOAP • Qualquer instância de um Microserviço é Stateless • Microserviços são Poliglotas, cada time de um Microserviço é livre para escolher a melhor Tecnologia • Princípios DevOps – instalação automatizada e Desenvolvedores dando suporte a produção • Uso de Containers, que permite o empacotameno de uma aplicação e o rápido tempo de inicialização • Uso da Nuvem, para um infraestrutura Elástica
  • 25. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 25 Arquitetura de Microserviços
  • 26. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 26 Pré Requisitos não técnicos 3/5/2018
  • 27. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 27 Lei Conway “Qualquer pedaço de software reflete a Estrutura Organizacional que o produziu” Melvin Conway 1968
  • 28. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 28 Lei de Conway em Ação Qualquer pedaço de software reflete a Estrurura Organizacional que o produziu Interface do Usuário Aplicação Banco de Dados Infraestrutura Software ResultanteTipica Estrutura Organizacional Corporativa Head of IT Head of Operations Head of DBAs Head of Infrastructure Head of App Dev Head of UI Head of Development Um Enorme Monólíto
  • 29. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 29 Reestruture sua Organização Construir pequenas equipes com foco em Produtos Software ResultanteEstrutura Organiz. baseada em Microserviços Product Lead Developer Sys Admin DBA JavaScript Developer Vários pequenos Microserviços Developer Developer Sys Admin Storage Admin Graphic Artist NoSQL Admin API Aplicação Banco de Dados Infraestrutura API Aplicação Banco de Dados Infraestrutura API Aplicação Banco de Dados Infraestrutura API Aplicação Banco de Dados Infraestrutura
  • 30. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 30 Características dos diferentes Tipos de Organização  Produz Microserviços  Pequenas equipes podem fazer quaisquer mudanças que queiram em um determinado Microserviço  Arquitetura “limpa” porque os Desenvolvedores têm 100% do controle  Verdadeiro dono  Produz Monólitos  Uma simples mudança exige uma ampla coordenação entre todas as diferentes camadas  A lógica de negócios esta espalhada em todos os lugares porque é mais fácil de implementar na sua camada  Sem dono real Organizações Centralizadas Focada em Camadas de Tecnologia Organizações Distribuídas Focada em Produtos
  • 31. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 31 Pré Requisitos de Arquitetura 3/5/2018
  • 32. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 32 Microserviços Força Mudança para Computação Distribuída Introduz enorme complexidade – monólitos não sofre disto API Aplicação Banco de Dados Infraestrutura API Aplicação Banco de Dados Infraestrutura API Aplicação Banco de Dados Infraestrutura API Aplicação Banco de Dados Infraestrutura Microserviço A Microserviço B Microserviço C Microserviço D • A Computação Distribuída é uma consequência natural dos Microserviços, visto que cada Microserviços tem seu próprio banco de dados • Compartilhamento de banco de dados através de Microserviços introduz acoplamento - muito ruim! • Haverá sempre Latência entre Microserviços • Toda a troca de dados entre Microserviços deve ser através da camada da API – não ao acesso aos banco de dados entre Microserviços • Deve-se implementar mensagens de alta velocidade entre Microserviços utilizando REST + HTTP. Provalmente isso não será suficiente. • Talvez existirá dados duplicados entre os banco de dados. Exemplo: dados do cliente.
  • 33. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 33 Chamadas Síncronas com Microserviços são muito ruins Catálogo de Produtos Produto Preço Estoque Encadeamento == Acomplamento == Downtime A disponibilidade do Microserviço A depende do B, B depende do C, etc
  • 34. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 34 Orquestração x Coreografia • Orquestração: é a composição de serviços para criar um novo serviço ou para resolver uma tarefa de um processo de negócio. Neste caso, sempre há a figura de um ponto central. Um serviço ou uma atividade de negócio que coordena a chamada de outros serviços para compor uma função de maior granularidade. A orquestração de serviços é análoga a um método da orientação a objetos que faz chamadas de outros métodos. • Coreografia: a coreografia já é pré-determinada antes da sua execução. Por exemplo, quando um serviço é acionado e envia uma mensagem, outros serviços podem estar programados de ante-mão para receber ou não essa mensagem e dispararem outras ações. Chamamos este processo de evento. Serviços são acionados conforme a classe de eventos que ocorrem. Característica básica da Arquitetura Orientada a Eventos. Em um Middleware é possível atribuir esta característica através da criação de fluxos Publish/Subscribe 3/5/2018 Oracle Confidential – 3
  • 35. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 35 Orquestração x Coreografia Orquestração Coreografia Livro: Building Microservices – Sam Newman
  • 36. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 36 Orquestração • Usado em aplicações centralizadas, monolíticas • Frágil – centralizado por natureza • Cada “ação” interage com o sistema centralizado – ponto único de falha que não é muito flexível Coreografia • Usado em aplicações de Microserviços distribuídos • Resiliente – distribuído por natureza • Cada Microserviço assincronamente lança uma messagem que outro Microserviço pode consumir Microserviços Força Coreografia ao invés de Orquestração
  • 37. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 37 Microserviços Força Muitas Chamadas de Rede • Microserviços aumenta exponencialmente chamadas de rede • Cada tipo de chamada tem um requerimento único • Síncrono / Assíncrono • Performance • Throughput • Latência • Segurança Monólitos na maioria das vezes fazem chamadas locais dentro de um único processo Cliente Banco de Dados Banco de Dados Microserviço Microserviço API Gateway Síncrono Assíncrono Internet Pública Data Center
  • 38. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 38 API Gateways faz o Balancemanto de Carga e Agregação das Respostas API gateways fornece um "backend” para cada “frontend" Cliente Internet Pública Microserviço Microserviço Microserviço Microserviço Microserviço Microserviço Data Center API Gateway Microserviço Microserviço Microserviço – Constrói uma resposta XML ou JSON para cada tipo de cliente - web, celular, etc – Chamadas Assíncronas para cada um dos N Microserviços necessários para construir a resposta – Gerencia Segurança e esconde o “back-end” – Balanceamento de carga – Métricas das APIs – Logs centralizados
  • 39. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 39 REST: Representational State Transfer Fortemente associado com Microserviços, mas não é um requisite técnico HTTP REST XML ou JSON HTTP Response Codes • Alternativa muito mais simples que o SOAP • Utiliza GET, POST, PUT, DELETE, etc – Assim como os navegadores WEB • Versões de APIs - /v1.2/cliente • Pode utilizar XML or JSON • XML é muitas vezes melhor - suporte XPath, seletores de CSS • Não pode gerar “stubs” fortemente tipados REST =
  • 40. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 40 Circuit Breakers para prevenção de falhas em cascatas • Regra #1 de Microserviços – Evite Acomplamento • Síncrono = 2 sistemas estão acoplados • Assíncrono = não tem acomplamento • Falhas em cascatas acontecem quando uma thread que gerencia um request esta aguardando a resposta de uma aplicação remota • Circuit breakers realizam chamadas assíncronas para um outro pool de thread para evitar stuck threads • Hystrix (Java) é bem conhecido e resolve este problema Falhas em cascata são muito comum com Microserviços
  • 41. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 41 Logging: Microserviços torna mais difícil • Mais aplicações, mais containers/VMs/hosts, mais Banco de Dados, mais tudo • Mais pontos de falhas • Mais fácil ter falhas em cascata Logging é muito importante1 • Deve-se implementar o recurso de log em todos os pontos ao longo dos Microserviços. • Os logs devem ser enviados para um repositório central • Deve-se centralizar todos os logs para formar uma visão centralizada Requisitos2 • Colete, análise e transforme arquivos de log: Logstash, Splunk • Agrege os arquivos de logs: ElasticSearch, Splunk • Visualização, métricas: Kibana, Splunk Soluções3
  • 42. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 42 O que / como Monitorar Monitorar um Monólito e relativamente simples – uma aplicação. Microserviços = várias aplicações Req. para monitoração de Microserviços 1. Monitorar throughput, performance e métricas de negócios 2. Monitorar cada request para cada Microserviço – end-to-end 3. Acompanhar a saúde das dependências 4. Monitorar cada processo, OS, host, etc Dropwizard Metrics Ferramentas Populares
  • 43. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 43 Desenho de API - Swagger
  • 44. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 44 Arquitetura REST • É um termo definido por Roy Fielding em sua tese de doutorado, no qual ele descreve um estilo de arquitetura de software sobre um sistema operado em rede. REST é um acrônimo para "Transferência de Estado Representacional" (Representational State Transfer). • Vê cada aplicação web como um conjunto de recursos que representam um estado particular de um aplicativo. Quando você acessa este recurso, transfere-se o estado (conteúdo), e talvez altera-se o seu estado.
  • 45. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 45 RESTFul • RESTful é uma implementação de um "web service" simples utilizando o HTTP e os principios REST • Normalmente utiliza o formato JSON (JavaScript Object Notation): { "name": "read-node", "cluster_name": "apache-cluster", "version": { "number": "2.1.0", "build_hash": "72cd1f1a3eee09505e036106146dc1949dc5dc87", "build_timestamp": "2015-11-18T22:40:03Z", "build_snapshot": false, "lucene_version": "5.3.1" }, "tagline": "You Know, for Search" }
  • 46. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 46 JSON Dados "nome":"Roberto Carlos" Objetos { "nome": "Roberto Carlos", "documento": "879.728" } Array "clientes":[ {"nome":"Kibana", "documento":"258.741"}, {"nome":“Kitri”, "documento":"789.456"}, {"nome":"Prince", "documento":"258.321"} ]
  • 47. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 47 Exemplo: API Elasticsearch • https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html • https://www.havenondemand.com/
  • 48. Internal Use Only © Copyright 2015 Hewlett Packard Enterprise Development LP. All rights reserved.. 48 Desenho API - Swagger • Ferramenta para desenho de RESTful API • Utiliza sintaxe YAML • 100% Open Source • Gera código para várias linguaguens de programação: back end e client sdk • http://editor.swagger.io/ • Outros ferramentas/frameworks: • http://raml.org/ • https://apiblueprint.org/