Arquitetura de Microservicos

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
Introdução

Internal Use Only
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
Arquitetura de Microserviços
Monolítico Microserviço

Internal Use Only

Internal Use Only
• 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
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
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
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
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
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
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
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
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
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
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
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
História dos Microserviços
3/5/2018

Internal Use Only
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
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
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
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
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

Internal Use Only
Pré Requisitos não técnicos
3/5/2018

Internal Use Only
Lei Conway
“Qualquer pedaço de software
reflete a Estrutura
Organizacional que o
produziu”
Melvin Conway
1968

Internal Use Only
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
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
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
Pré Requisitos de Arquitetura
3/5/2018

Internal Use Only
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
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
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
Orquestração x Coreografia
Orquestração Coreografia
Livro: Building Microservices – Sam Newman

Internal Use Only
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
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
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
Data Center
API Gateway
– 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
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
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
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
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
Desenho de API - Swagger

Internal Use Only
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
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
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
Exemplo: API Elasticsearch
• https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html
• https://www.havenondemand.com/

Internal Use Only
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/

Arquitetura de Microservicos

Mais conteúdo relacionado

Mais procurados

Semelhante a Arquitetura de Microservicos

Mais de Norberto Enomoto

Arquitetura de Microservicos