Arquitetura de Microserviços

DXC Proprietary and Confidential
March 5, 2018
Arquitetura de
Microserviços
Norberto Enomoto
Integration | SOA | IoT Architect
norberto.enomoto@dxc.com

March 5, 2018 2DXC Proprietary and Confidential
Agenda
1. Introdução
2. Histórico dos Microserviços
3. Pré Requisitos de Arquitetura

Introdução

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.

Arquitetura de Microserviços
Monolítico Microserviço

•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

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

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

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

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

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

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 decomporuma
aplicação monolítica existente em uma
aplicação baseada na Arquitetura de
Microserviços
Eu quero construir uma nova
aplicação baseada na Arquitetura de Microserviços
a partir do zero

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

História dos Microserviços

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

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

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

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

Pré Requisitos de Arquitetura

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.

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

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

Orquestração x Coreografia
Orquestração Coreografia
Livro: Building Microservices – Sam Newman

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 =

DXC Proprietary and Confidential
Obrigado.

Arquitetura de Microserviços

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Arquitetura de Microserviços

Semelhante a Arquitetura de Microserviços (20)

Mais de Norberto Enomoto

Mais de Norberto Enomoto (12)

Último

Último (8)

Arquitetura de Microserviços