Slides

Web APIs e delivery
Matando a fome de 1 milhão
de pedidos mensais no
Tiago Dolphine
Tiago Dolphine ...
Online Delivery
Restaurant receives
the order
Customer search
for restaurants
APIs
Order food from
App or Web
Confirms the order
and prepare
Back office
operators
4
5
Elasticidade para delivery
Almoço
Jantar
Elasticidade para delivery
Almoço
+
Jantar
Campanhas de Marketing : push app, comerciais, jogos de futebol ...
Primeiras APIs
Mobile App
SOAP/WSDL
28k
14k
2011
2012
11
Web APIs e REST (WS CORE)
●
Padronizar comunicação
●
Centralizar regras de negócio
●
Modelo de dados padronizado
●
API Credential (permissões)
●
SDK para uso das APIs
●
●
Rapidez na inserção de features
Deploy facilitado
API recepção de pedidos
●
Foco bem específico
●
Acesso por restaurantes
●
Polling
●
Confirmação de pedido
●
Otimização e Caching
●
Acesso ao DB
APIs públicas
Integrações (3rd party)
●
●
●
●
●
●
Restaurantes
Cardápios
Clientes
Pedidos
Controle de acesso
Conquista de novos parceiros e negócios
Começam os problemas...
●
Gargalos e load elevado
●
Busca de endereços
●
Processamento síncrono
●
Jobs e processamentos em background
●
Muito acesso ao DB
●
Comprometimento do sistema no lançamento de novas features
Como solucionamos problema com demora na
busca de endereços?
~4x mais rapido
Alívio de queries ao DB
WS
Job para indexar
Endereços e CEPs
Base relacional própria com
mapeamento de endereços
Como solucionamos o impacto de novas features
em produção?
Feature Toggles
Novas funcionalidades em produção
Rapidez e segurança para publicação
Validação controlada, no mundo real
Comparação de cenários
Chaveamento automático
http://martinfowler.com/articles/feature-toggles.html
Como reduzimos excesso de processamento e
tempo de resposta nas APIs?
Event-driven messaging
Redução de processamento síncrono com
menos orquestração e mais coreografia
Alguns cenários:
●
●
●
●
●
Envio de emails
Notificações
Cancelamentos
Captura de pagamentos
Analytics
Events-driven messaging
O que ganhamos?
●
Alivio de processamento na aplicação
●
Deploy independente
●
Pontos de falha mais isolados
●
Escala com a demanda
AWS
Aplicações
A
Afunilamento
no banco de dados
Aplicações e serviços
Cache Local
A
Afunilamento
no banco de dados
Aplicações e serviços
Cache Local
A
Afunilamento
no banco de dados
Read Only
Caching
In-Memory => rápido
Redução de queries
Respostas mais rápidas das APIs
Maior throughput por instância
Planejamento de TTL com a regra de negócio
~800
k
450
k
108
k
14k
2011
28k
2013
201
201
29
800k
450k
108k
14k
2011
28k
2013
2014
2015
30
Mais problemas surgem com o crescimento...
●
Número de acessos +++
●
Acúmulo de threads
●
Tempo de resposta comprometido
●
Alto consumo de memória + muito GC
●
Muito load em momentos de pico
●
Pontos de concorrência entre instâncias
Microservices
daqui a pouco….
Lock Distribuído
Permitir que apenas um processo/thread
em um sistema distribuído acesse
determinado recurso.
Instance1
Instance5
●
Get/Set Lock
●
Release Lock
●
Lock TTL
Instance2
Instance4
Instance3
Cache Distribuído
Aumento do uso de cache
Melhorias de estratégia de caching
Alívio de memoria na aplicação
Compartilhamento de refresh do cache
Dependência total do cache
Disponibilidade + Alta perfomance
Migrando para Aerospike
Testes e validação
Abstração de caching nas aplicações
Criação de cluster
Monitoramento
Testes de failover
Atualmente ~15k hits/s
3GB consumo
Migrando para Microservices
●
Deploy segmentado
●
Falhas isoladas
●
Escalar pontos necessários
●
Segmentar Database (DB per Service)
●
Tecnologías específicas para cada problema
●
Times menores
Times especializados
● Mais focados nos requisitos
● Conhecem profundamente o serviço
● Tecnologias específicas
● Melhor gerenciamento
● Responsabilidade pelos deploys
Estratégia inicial para microservices
●
Encontrar os maiores problemas
●
Delimitando escopos (bounded contexts)
●
Padronização e stack
●
Definir tecnologias especificas
●
Mudança de paradigmas (chamadas remotas)
●
Falha inevitável
●
Preferir coreografia
Autenticação Centralizada
●
●
●
●
●
Padrão de autenticação entre microservices
Spring Security OAuth2
Authorization Server
Applications: OAuth2 SDK
Client: fácil uso respeitando fluxo OAuth2
“Authorization: Bearer 8ba887c0-90d8-423f-99d3-ce878e48d3e7”
BFF Backends for Frontends
Restaurant
Auxilia no processo de migração
BFF
Order
Sem alteração no Frontend
API se mantém constante
Backend pode ser alterado conforme evolução dos
Microservices
Reduz chamadas remotas entre clientes
externos/server
http://samnewman.io/patterns/architectural/bff/
Account
Um pouco do que estamos usando...
(Boot , MVC, Cache, Messaging, Data, Actuator, OAuth2 ...)
DevOps...
●
●
●
●
●
●
●
Continuous Integration
Continuous Deployment
Orchestrated deploy process
Quick Releases
Service per host
Chef
AWS Auto scaling
CI / CD Process
Get deploy artifact
Deploy Artifact
Get Instances
Au
tos
Sync Repository
g
lin
ca
Orchestrated deploy
Libs
Applications
Monitoramento !
Alertas
Logs Centralizados
Monitoramento
48
Problemas encontrados e aprendizados:
●
●
●
●
●
●
●
●
CI/CD necessário !
Plano de rollback
Time precisa estar envolvido em todo processo
Log não centralizados
Controle de versões entre serviços
Desenvolvimento e testes com sistemas distribuídos
Identificação de bugs em produção
Pontos concorrência: necessário distributed lock !
http://martinfowler.com/articles/microservice-trade-offs.html
Cuidado !
Monolith First
http://martinfowler.com/bliki/MonolithFirst.html
Hoje ! 2016
❖ 1.4 milhões++ / mês
Orders
Payments
Restaurants
Locations
Menu
Accounts
Microservices
Tiago Dolphine
[email protected]
/tiagodolphine
/tiagodolphine
/tiagodolphine
Further Reading
●
●
●
●
●
http://martinfowler.com/articles/feature-toggles.html
http://samnewman.io/patterns/architectural/bff/
http://martinfowler.com/articles/dont-start-monolith.html
https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html
http://martinfowler.com/articles/microservice-trade-offs.html