September 27, 2019

Arquitetura de
Microserviços

Bernhard Ferraz
Bernhard.ferraz@ifg.edu.br
 Agenda

1. Introdução
2. Histórico dos Microserviços
3. Pré Requisitos não Técnicos
4. Pré Requisitos de Arquitetura
5. Desenho de API – Swagger
6. Referências
7. Dúvidas

September 27, 2019 2

DXC Proprietary and
Confidential
 1. Introduçã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.

3
Arquitetura de Microserviços
Monolítico Microserviço

4
Arquitetura de Microserviços

5
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
• 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

6
Arquiteturas Existentes tem suas Limitações

Complexa Sem Especialização

Aplicações tendem a ficar tão grandes e Diferentes partes da aplicação
complexas para o Desenvolvedor entender ao possuem diferentes necessidades –
longo do tempo. Camadas compartilhadas Complexa Sem mais CPU, mais memória, rede, etc
(ORM, Mensageria, etc) precisam gerenciar Especialização
100% dos casos de usos.
Devagar Sem Dono
Devagar Sem
Equipes divididas por função – UI, Dono Quando não existe um dono, você
Aplicação, Middleware, Banco de tem negligência
Dados, etc. Leva uma eternidade
para fazer qualquer coisa devido ao
“cross-ticketing” Frágil Teste
Ineficientes
Frágil Testes Ineficientes
Uma falha (bug) poderá rapidamente Toda vez que você alterar sua aplicação,
“derrubar” toda a aplicação. Pouco você terá que retestar tudo. Difícil
Resiliente suportar a Entrega Contínua

7
Caraterística de uma Aplicação de N Camadas

Um arquivo grande, incluindo a

• 3 camadas Aplicação Monolítica Grande camada de apresentação (UI) e
o código da aplicação
• Somente uma linguagem Servidor de Aplicação Rico em recursos – suporta
de programação
grandes e complexas
• Tudo centralizado - Sistema Operacional aplicações, vários casos de
mensageria, uso
armazenamento, banco de
dados e etc VM
Hypervisor Provê 100% de isolamento

Sistema Operacional

Hardware Configuração manual

8
 O que são Microserviços

Arquitetura N Camadas Microserviços

Aplicação Monolítica Vários, pequenos Microserviços com função mínima

Precisa implantar (deploy) de toda a aplicação Pode implantar (deploy) cada Microserviço de forma independente

Um banco de dados para a aplicação inteira Cada Microserviço possui seu próprio banco de dados

Chamada “In-process”, SOAP externamente Chamadas REST sobre HTTP, Mensageria

Organizado em torno das camadas de Tecnologia Organizado em torno das “Business Capabilities”
Desenvolvedores não fazem suporte a “operação” Desenvolvedores também suportam a “operação”

Uma Tecnologia para toda a aplicação Escolha de uma Tecnologia para cada Microserviço

9
Microserviços são Desenvolvidos / Implantados
Independentemente
Aplicação N Camadas Microserviços
API API

Interface do usuário Aplicação Aplicação

Banco de Dados Banco de Dados
Infraestrutra Infraestrutura
Aplicação Microserviço Microserviço
Estoque Pagamento

API API
Banco de Dados
Applicação Applicação
Banco de Dados Banco de Dados
Infraestrutura Infraestrura Infraestrura
Microseriço Microserviço
Perfil Catálogo de Produtos

Aplicação Monolítica Vários pequenos Microserviços

10
Fundamentalmente, Microserviços é uma troca
Você quer...

Desenv. Tradicional de aplicação Microserviços

Implantação mais fácil
• 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.
Desenv. Mais fácil
• 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

11
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

Eu quero construir uma nova

aplicação baseada na Arquitetura de Microserviços
a partir do zero

12
As vezes Aplicações Monolíticas ainda são uma boa
Abordagem
Microserviços adiciona complexidade
• Para aplicações menos complexas, monólitos são
sempre melhores, tanto no curto quanto a longo Complex. ao Longo do Tempo
prazo
• Para aplicações moderadamente complexas,

Complexidade
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

Tempo
13
Qual o tamanho de um Microserviço?
Pode ter centenas de Microserviços para uma Aplicação grande

Grande 11-15 Pessoas

Exemplo: Microserviço de Pedido
Fazer algo e fazê-lo
bem feito Médio 4-10 Pessoas
Exemplo: Microserviço de Estoque

Evitar
Interdependências Pequeno 1-3 Pessoas
Exemplo: Microserviço Status de Pedido

Foco na “Business
Capabilities”

14
2. História dos Microserviços
Os Princípios de Microserviços tem estado conosco
por Décadas

Foco na
Baixo Fazer algo e fazê-lo “Business
Reduz a Acoplamento bem feito Capabilities” e
Complexidade não nas
através da Camadas de
Modularização Tecnologias

Os Princípios por trás dos Microserviços

muitas vezes são apenas bons Princípios
de Arquitetura
16
Modularidade sempre foi um Objetivo da Arquitetura
Mas Microserviços reforça a modularidade através da implantação
de cada Microserviços separadamente

Módulo Microserviços
 In process  Out-of-process

 Chamadas Locais  Chamadas Remotas

 Não é independentemente Implantável  Independentemente Implantável

 A fronteira é fortemente reforçada  A fronteira não é fortemente reforçada

 Mesma Linguagem  Diferente Linguagens

 Fortemente acoplado  Baixo Acomplamento

17
SOA vs. Microserviços
SOA é uma idéia geral, onde Microserviços são uma maneira
muito específica de implementá-los

Todos os Princípios de SOA também se

aplicam à Microserviços
SOA

Diferenças de Implementação
 Favorece a Orquestração Centralizada
 SOAP + HTTP
Microserviços
 Favorece a Coreografia Distribuída
 REST + HTTP/S = simples

18
SOA vs. Microserviços - Equívocos
“Microserviços eliminam a
necessidade de Enterprise Não confuda Produto com o Padrão
Service Bus”

Não confuda implementações mal

“Microserviços resolvem os sucessidas de SOA com problemas de SOA
problemas de SOA”

“Empresas como Netflix e

Netflix e LinkedIn são uma plataforma de
Linkedin usam Microserviços, negócios. Qual é o seu negócio?
então nós devemos usar
também”

Utilize ambos
“Devemos escolher
Microserviços ou SOA”

19
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

20
3. Pré Requisitos não Técnico

21
Lei Conway

“Qualquer pedaço de software

reflete a Estrutura
Organizacional que o
produziu”
Melvin
Conway
1968 25
 Lei de Conway em Ação
Qualquer pedaço de software reflete a Estrurura Organizacional que o
produziu

Tipica Estrutura Organizacional Corporativa Software Resultante

Head of IT
Interface do Usuário

Head of Head of Aplicação

Operations Development
Banco de Dados
Head of Head of Head of App
Head of UI
DBAs Infrastructure Dev
Infraestrutura

Um Enorme Monólíto
September 27, 2019 23
 Reestruture sua Organização
Construir pequenas equipes com foco em Produtos

Estrutura Organiz. baseada em Microserviços Software Resultante

Product API API
Lead
Aplicação Aplicação

Banco de Dados Banco de Dados

JavaScript Infraestrutura Infraestrutura

Developer Sys Admin DBA
Developer
API API
NoSQL Graphic
Developer Sys Admin
Admin Artist Aplicação Aplicação

Storage Banco de Dados Banco de Dados

Developer
Admin Infraestrutura Infraestrutura

Vários pequenos Microserviços

24
4. Pré Requisitos de Arquitetura

25
Microserviços Força Mudança para Computação Distribuída
Introduz enorme complexidade – monólitos não sofre disto

Microserviço A Microserviço B Microserviço C Microserviço D

API API API API

Aplicação Aplicação Aplicação Aplicação

Banco de Dados Banco de Dados Banco de Dados Banco de Dados

Infraestrutura Infraestrutura Infraestrutura Infraestrutura

• Toda a troca de dados entre

Microserviços deve ser através
• A Computação Distribuída é uma consequência natural dos Microserviços, da camada da API – não ao
visto que cada Microserviços tem seu próprio banco de dados acesso aos banco de dados
entre Microserviços
• Compartilhamento de banco de dados através de Microserviços introduz
• Deve-se implementar
acoplamento - muito ruim!
mensagens de alta velocidade
• Haverá sempre Latência entre Microserviços 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. 26
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. 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.

27
Microserviços Força Coreografia ao invés de
Orquestração
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
28
Circuit Breakers para prevenção de falhas em cascatas
Falhas em cascata são muito comum com Microserviços

• 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

29
Arquitetura de Microserviços

30