Embed Size (px)
Citation preview
Web APIs e delivery
Matando a fome de 1 milhão de pedidos mensais no
Tiago Dolphine
Tiago Dolphine ...
Order food from App or Web
Restaurant receives the order
Confirms the order and prepare
Back office operators
Customer search for restaurants
APIs
Online Delivery
4
5
Elasticidade para delivery
Almoço Jantar
Elasticidade para delivery
Almoço Jantar
+ Campanhas de Marketing : push app, comerciais, jogos de futebol ...
Primeiras APIsMobile App
SOAP/WSDL
11
2011 2012
14k
28k
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?
Job para indexar Endereços e CEPs
WS
Base relacional própria com mapeamento de endereços
~4x mais rapidoAlívio de queries ao DB
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 commenos 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
AAfunilamento no banco de dados
Aplicações e serviços
AAfunilamento no banco de dados
Cache Local
Aplicações e serviços
AAfunilamento no banco de dados
Read Only
Aplicações e serviços
Cache Local
CachingIn-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
29
14k28k
108k
2012013 201
450k
~800k
2011
30
14k28k
108k
20142013 2015
450k
800k
2011
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
Instance5
Instance4 Instance3
Instance2
Instance1
● Get/Set Lock
● Release Lock
● Lock TTL
Permitir que apenas um processo/thread em um sistema distribuído acesse
determinado recurso.
Cache DistribuídoAumento 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 AerospikeTestes 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”
Auxilia no processo de migração
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/
BFF Backends for Frontends
BFF
Restaurant
Order
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
Autoscaling
Applications
Deploy Artifact
Libs
Sync Repository
Get Instances
Orchestrated deploy
Get deploy artifact
Monitoramento !
Logs CentralizadosAlertas
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
Microservices
OrdersPaymentsLocations
Restaurants
AccountsMenu
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
