DevTalk 08/2019
Transferir como PPTX, PDF1 gostou77 visualizações
O documento discute arquitetura de microsserviços, incluindo pros e contras de microsserviços, APIs da plataforma Zoox, definições importantes como bounded context e UUID, e boas práticas de arquitetura como separação de preocupações.
DevTalk 08/2019
- 1. DEVTALK DESENVOLVIMENTO, SEGURANÇA, ARQUITETURA E INFRAESTRUTURA ZOOX - AGO/2019
- 6. MICROSERVIÇOS PRÓS • Aumento de resiliência • Escalabilidade independente • Deploy fácil, independente e frequente (CI/CD) • Independência de tecnologias e de fácil migração • Fácil debug específico • Pequenos times especializados • Testes automatizados • Fácil para dev novo no time • Reusabilidade e Composição • Desacoplamento e alta coesão CONTRAS • Manutenção (DevOps) • Versionamento (cuidado) • Latência • Transação entre serviços • Testes de integração e monitoramento • Integração entre times • Documentação (api) • Tratar falhas • Cuidado com granuralidade (quantidade serviços)
- 7. 11/2015
- 9. DEFINIÇÕES IMPORTANTES • Bounded Context • UUID • Versionamento (semver.org) • Síncrono (request/response) X Assíncrono (event-based) • REST
- 11. PROBLEMAS DO ID AUTOINCREMENT • Fácil extrair certas informações (cria um usuário novo e pelo id você sabe quantos usuários tem na base) • Enumerar entidades (se não tiver tratamento, basta trocar o id na url para outro número) • Não é único entre as tabelas (existe uma entidade 1 em todas as tabelas) • Não é possível usar em sistemas distribuídos • Muito difícil migrar dados para outro banco ou usar como replicação (MySQL para Elasticsearch por exemplo)
- 12. EXEMPLO
- 13. UUID • V4: 362e80f5-af9a-4d68-86da-5bf014dcafc1 • V4 COMB • 8e208169-a0d1-419d-b17f-913b9985b8ac • 8e21f643-a18e-4800-9c8d-4a71916a886b • Geração pode ser descentralizada. • Você não consegue enumerar as entidades • Você não sabe quantos registros tem na tabela • Você não precisa falar com a database para gerar um valor “The number of random version-4 UUIDs which need to be generated in order to have a 50% probability of at least one collision is 2.71 quintillion. This number is equivalent to generating 1 billion UUIDs per second for about 85 years.” - Wikipedia
- 14. VERSIONAMENTO
- 16. OPÇÕES DE VERSIONAMENTO • URI 1. region.zooxwifi.local/v1/city 2. region.zooxwifi.local/v2/city • Header customizado 1. Accept-version: v1 2. Accept-version: v2 • Header Accept 1. Accept: application/vnd.region.v1+json 2. Accept: application/vnd.region.v2+json
- 17. SYNC X ASYNC
- 18. SÍNCRONO PRÓS • Baixa complexidade • Fácil tratamento de erro • Resposta em “real-time” CONTRAS • Cada serviço tem que estar disponível • Resposta lenta
- 19. ASSÍNCRONO PRÓS • Resposta imediada, não precisa esperar todos os serviços responderem • Desacoplamento entre os serviços • Serviço pode não estar disponível na hora • Isolamento de falha CONTRAS • Arquitetura complicada • Tratamento de erro • Acoplamento ao “message broker” • Alta latência se fila cheia • Custo de monitoramento • Nem sempre possível (listar itens na tela)
- 20. REST API
- 21. GET ENTITY
- 22. GET COLLECTION
- 23. ERRO AO CRIAR
- 24. API - STATUS HTTP 2XX • 200 – OK • 201 – CREATED • 202 – ACCEPTED • 204 – NO CONTENT 4XX • 400 – BAD REQUEST • 401 – UNAUTHORIZED • 403 – FORBIDDEN • 404 – NOT FOUND • 405 – METHOD NOT ALLOWED • 409 – CONFLICT • 422 – UNPROCESSABLE ENTITY • 429 – TOO MANY REQUESTS 5XX • 500 – INTERNAL SERVER ERROR • 502 – BAD GATEWAY • 503 – SERVICE UNAVAILABLE • 504 – GATEWAY TIMEOUT
- 25. SEGURANÇA • Não confie em ninguém (filtrar/validar toda entrada, escapar toda saída) • Se prepare para o pior cenário • Princípio do menor privilégio • Se não testou, não assuma que funciona • SQL Injection • Cross-Site Scripting (XSS) • https://www.acunetix.com/websitesecurity/php-security-1/ (exemplos)
- 26. INJEÇÃO DE DEPENDÊNCIA – NODE - TYPEDI
- 27. INJEÇÃO DE DEPENDÊNCIA – PHP – PSR-11
- 28. INJEÇÃO DE CONFIGURAÇÃO – PERMITE EXPANSÃO
- 29. INTERFACE – FACILITA TESTES E NOVAS FEATURES
- 30. THE SEPARATION OF CONCERNS (SOC) PRINCIPLE Os conceitos ou preocupações são os diferentes aspectos da funcionalidade do software. Por exemplo, a "lógica de negócios" do software é uma conceitos, e a interface pela qual uma pessoa usa essa lógica é outra conceitos. A separação de conceitos é manter o código para cada uma dessas responsabilidades separadas. Alterar a interface não deve exigir a alteração do código de lógica de negócios e vice-versa.
- 31. ARQUITETURA DE 3 CAMADAS Idéia de usar SoC, é mover sua regra de negócio para fora da sua camada de roteamento (resources)
- 32. BOAS PRÁTICAS • Não coloque sua regra de negócios dentro dos controladores! • Um dia você pode precisar reutilizar em um outro lugar. • Seu código fica mais “macarrônico” • Dificulta a construção de teste unitário • Dificulta a legibilidade do código • Coloque seus SQL/DataAccess na camada correta
- 33. EXEMPLO
- 35. USE A CAMADA PUB/SUB O padrão pub/sub vai além da arquitetura clássica de 3 camadas, mas é extremamente útil. Um endpoint simples que cria um usuário agora, pode querer chamar serviços de terceiros, talvez para um serviço de análise ou talvez iniciar uma sequência de e-mail. Mais cedo ou mais tarde, essa simples operação de "criação" estará fazendo várias coisas e você terá 1000 linhas de código, tudo em uma única função. Isso viola o princípio da responsabilidade única.
- 36. EXEMPLO
- 37. Chamadas imperativas não é a melhor maneira de fazer isso. Uma abordagem melhor é emitir um evento, ou seja, "um usuário se inscreveu com este e-mail". E você está feito, agora é da responsabilidade dos ouvintes fazer o trabalho deles.
- 38. EXEMPLO
- 39. • Agora você pode separa seu eventos em vários arquivos, de acordo com a afinidade de cada um
- 40. FUJA DO ASYNC/AWAIT HELL! • Encontre funções que dependam da execução de outras declarações • Agrupe códigos dependentes em funções assíncronas • Execute estas funções assíncronas simultaneamente