Sistemas Distribuidos Escaláveis com Microserviços

Sistemas Distribuidos Escaláveis com Microserviços

Transcript

1. Orquestração Database Sistemas Distribuídos Escaláveis com Microserviços HTTP Autenticação
2. @reinaldob • Programador na Spree Commerce Inc. • Empresa focada em eCommerce • Equipe distribuída • 99% home office
4. Conceitos :)
5. O que são microserviços?
7. Quando eu deveria utilizá- lo?
8. Quando dá mais trabalho manter o sistema junto do que ter ele separado.
9. Trabalho • Vários times mexendo no mesmo código • 1 app importante e estável send “deployada" junto com 1 app que muda frequentemente • API junto com APP, requisitos de segurança diferentes • etc…
10. Junto • Mesmo deploy • Mesmo codebase • Mesma equipe
11. Separado • Deploy separado • Codebase separado • Mesmo que esteja na mesma máquina!
12. Como criar uma aplicação utilizando esse modelo arquitetural?
14. Don't Tell Me What To Do https://medium.com/@danielfilho
15. Sem bala de prata • Estudar o contexto • Perfil da equipe de Dev • Equipe Devops • Conways law • Tamanho dos times • Melhores protocolos • A lista é grande…
16. Quem está usando hoje em dia?
17. TODO MUNDO!
18. • Netflix • SoundCloud • Amazon • eBay • …
19. Preciso utilizar?
20. NÃO
21. Wombat
22. Um pouco de história
23. Storefront Wombat Order Payment Shipment Fulfilment Replicate ready, complete, paid ready, approved, rejected ready, delivered, completed completed, cancelled Order Payment Shipment Fulfilment ready, complete, paid ready, approved, rejected ready, delivered, completed completed, cancelled
24. Order pedido incluso pronto -> pago pago -> cancelado pago -> completo Email de confirmação Contas a receber Email, Baixa do contas a receber Email, Baixa do estoque
25. Integrações • STOREFRONT INTEGRATIONS • BigCommerce • Magento • NuORDER • Shopify • ACCOUNTING AND ERP • Abacos • Netsuite • Odoo • Quickbooks Desktop • Quickbooks Integration • Microsoft Dynamics • FULFILLMENT AND INVENTORY • Aftership • DotCom • Fifth Gear • Fosdick • MDS Fulfillment • COMMUNICATION AND CUSTOMER SERVICE • Amazon SES • Bronto • Desk.com • ExactTarget • MailChimp • Mandrill • DATA, ANALYTICS, AND CRM INTEGRATIONS • Amazon S3 • Highrise • Jirafe • MK Data Services • Salesforce • SugarCRM • POINT OF SALE (POS) • Square • Vend • AccuPOS • LightSpeed • Microsoft RMS
26. Contexto • Alto volume • Um engine complexo(que não pode falhar) • MUITAS integrações
27. Push API Wombat Engine Integrations Storefront (client) HTTP SNS/SQS HTTP SQS Push API Push API Wombat Engine Wombat Engine Integrations Integrations SQS
28. Push API • Sinatra • Redis • Controle de acesso (throttle) • Docker
29. Wombat Engine • Rails • Redis • Shoryuken(SQS) • Mongo • Controle de acesso (throttle) usando SQS • Docker
30. Integrations • Sinatra (stateless) • Docker, Heroku, Rackspace, Standalone, etc… • Open Source
31. Comunicação
32. JSON
33. HTTP • HMAC Auth e Token Auth • Nada fancy, simples POST
34. SQS • Assíncrono • Várias filas para cada processo • Dividir o numero de mensagens por min, regulando o bottleneck por cliente • Visibility Timeout • https://github.com/phstc/shoryuken
35. Engine Listener Evento SQS O bjeto + Evento Objeto + Evento Erro ou Throttle Persistência SQS REDIS Controle de Throttle Notificações SQS Delivery SQS Status Objeto + Evento
36. Ganhamos • Integrações Dinâmicas • Liberdade pra habilitar quantos nodes precisar por integração, dependendo do nível de uso • Delegamos o trabalho pra AWS, menos devops • Garantia de falha e multi-AZ • Deploys separados \o/
37. Perdemos • Ambiente local é complexo de montar • Testes complexos e demorados, nosso ambiente de CI é bem hackeado • Dependencia da AWS
38. Custo/Benefício
39. Dicas • http://putsreq.com • https://ngrok.com • Use ferramentas simples (cURL) e formatos simples (JSON)
40. Obrigado :) Dúvidas?