Slides
Transcrição
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