Microservices
4 gostaram992 visualizações
Este documento discute os principais conceitos e benefícios da arquitetura de microserviços, incluindo isolamento de times e recursos para permitir entregas independentes, e eventual consistência para lidar com transações distribuídas.
Microservices
- 1. MicroServices @diego_pacheco Software Architect | Agile Coach
- 4. Monoliticos
- 5. MSA veio depois de SOA
- 6. Microservices: Cases - Benchmark ~600 microservices ~150 microservices para uma página
- 8. Microservices: Independent + Re-usable
- 10. Unix Philosophy: Dumb Pipes & Smart Endpoints
- 13. Isolamento
- 14. Isolamento: Beneficios Times Recursos Gestão
- 15. Isolamento: Beneficios Times Ter multiplos times trabalhando ao mesmo tempo em coisas diferente, sem merge É possível ter times por serviços Cada time pode trabalhar com técnologias diferentes Cada time pode trabalhar de formas diferentes por a dependencia dos times vira por serviços e não pro pessoas. É possível ter times fazendo delivery de business e outros atualizando tecnologias ou fazendo melhorias de performance.
- 16. Isolamento: Beneficios Recursos Hardware diferente por serviço Serviços podem usar mais ou menos recursos Serviços não afetam os outros em runtime, tem mais resiliencia. Isolamento de banco permite atualizaçoes no modelo e tecnolgoia de dados sem impactos e outros serviços. Isolamento de CPU, Threads, Memoria, Rede faz com que o serviço sejá autocontido e indepente assim tendo mais facilidade para portar de um lugar para outro até mesmo do DS local para Cloud ou vice-versa.
- 17. Isolamento: Beneficios Gestão Diferentes prioridades do negócio podem ser feitas ao mesmo tempo de um jeito melhor. Releases podem acontecer em simultaneo, sem necessidade de tanta coordenação e bloqueio como em outros modelos. Podem se priorizar melhor: Bugs, Débitos Técnicos, melhorias de tecnologias e migrações. Times tem mais produtividade e menos dependencias. Velocidade de deploy e test / experimentação de funcionalidades.
- 18. Balanceamento
- 19. Anti-Patterns: Entendimentos Errados, Ideias Ruins entre outros…
- 20. ANTI-Pattern: 1 Serviço para cada coisa. EX: 1 WS pro operação.
- 21. ANTI-Pattern: 1 Serviço tem que ser sempre pequeno.
- 22. ANTI-Pattern: MSA é SOA, não ignore os principios. SOC Backward Compatibility Contracts Versioning Governance
- 23. ANTI-Pattern: NanoServices <= 10..100 LOC. “nem todos concordam” NanoService or Function as a Service?
- 24. Case: Netflix
- 25. Case: Twitter
- 26. Case: HailO
- 27. Case: Gilt
- 28. DDD: Domain Driven Design
- 29. Usando REST para Microservices
- 30. Spring Boot + REST
- 31. Node The JS way
- 32. Dropwizard+ REST
- 33. Netflix OSS - IPC
- 34. Akka as Microservice solution
- 35. Actors VS RPC
- 36. Colossus: nio + akka
- 37. Spray: Akka + HTTP
- 38. Muitas requests? Mobile? API Gateway Model
- 39. API Gateway Model: Como fica a UI?
- 40. IPC-ish, point-2-point, Brokerless solutions. Ribbon Quasar
- 42. Big Fat Jar: $ java –jar service.jar | OneJar, Assembler, Packager, RPM…
- 44. Tudo é sobre processos baratos.
- 48. Multiples DBs & TX Users Service Images Service Comments Service
- 49. Eventual Consistency Alternativa a TX distribuidas Trabalha com eventos Os Serviços tem que ouvir esses eventos e aplicar as mudanças nos dados. Soluções: CQRS + Event Sourcing Topicos / Pub-Sub (JMS) Akka É Possível ter TX local
- 51. Log Centralizado – ELK Stack
- 52. Log Centralizado – Graphite + Grafana http://grafana.org/
- 53. Log Centralizado – Graylog https://www.graylog.org/overview/
- 54. Back Pressure / Throttling / Spooling
- 55. Runtime Isolation + Metrics
- 57. Runtime Isolation: Circuit Breaker
- 59. Todos os microservicos tem que ter o seu proprio pipeline.
- 60. Sistema como um organismo vivo.
- 62. MicroServices @diego_pacheco Software Architect | Agile Coach Obrigado! Thank you!