dev-summit-iv-Microsserviços: conceitos, boas práticas e padrões

Transcript

1. Microsserviços: conceitos, boas práticas e padrões Kamila Santos
2. Nesta palestra Boas práticas de se adotar em microsserviços O que são microsserviços? Características de microsserviços 1 3 2
3. Nesta palestra Vamos ao código! Padrões de microsserviços Spring Cloud 4 6 5
4. São uma abordagem de arquitetura na qual o software é composto de pequenos serviços independentes que se comunicam entre si e são organizados de acordo com seus domínios de negócio. O que são microsserviços?
5. Autônomos - Cada serviço pode ser desenvolvido, escalado e implantado sem interferir em outros serviços. Características dos microsserviços
6. Autônomos - Não é necessário compartilhar nenhum código e a comunicação acontece por meio de chamadas as APIs (síncronas) ou de forma assíncrona. Características dos microsserviços
7. Especialistas - Cada serviço é desenhado para resolver um problema específico, se começar a ser necessário ter outras responsabilidades, é indicado que se crie um novo serviço. Características dos microsserviços
8. Resilientes - A independência do serviço aumenta a resiliência a falhas na arquitetura , se um deles tiver algum problema , só afetará alguma parte do fluxo. Características dos microsserviços
9. Reutilização de código - A divisão em módulos com responsabilidades bem definidas permite que funções específicas de algum serviço possam ser utilizadas para complementar features em outros sem precisar reescrever o código. Características dos microsserviços
10. As características apresentadas aqui são as mesmas apresentadas no livro Microsserviços prontos para produção Boas práticas de se adotar em microsserviços
12. Um microsserviço considerado estável é aquele que durante o desenvolvimento, deploy, inclusão de novas tecnologias e desativação de outros serviços não resulta em instabilidade do ecossistemas de microsserviços que ele faz parte. Estabilidade
13. Um microsserviço confiável é aquele que outros microsserviços daquele ecossistema podem confiar. Confiabilidade
14. Tem um ciclo de desenvolvimento padronizado (para se proteger de más práticas de desenvolvimento) Um microsserviço pode ser considerado estável e confiável quando
15. O código é submetido a testes de unidade, integração, e2e, regras de coverage (o tanto que um teste é coberto por testes) etc. Um microsserviço pode ser considerado estável e confiável quando
16. Possui seus clientes (serviços que o consomem) conhecidos. Um microsserviço pode ser considerado estável e confiável quando
17. Nunca deve existir uma parte do ecossistema de microsserviços que uma falha pode parar todo o fluxo. Tolerância a falhas
18. Também não deve haver qualquer parte individual dentro da arquitetura de um microsserviço que possa derrubar o microsserviço todo quando ele falhar. Tolerância a falhas
19. Microsserviços devem suportar falhas internas (do próprio microsserviço) e falhas externas (que acontecem em outras camadas e serviços externos). Tolerância a falhas
20. Ele é testado por meio de testes de carga e teste de caos. Um microsserviço pode ser considerado tolerante a falhas quando
21. Existe um procedimento padrão para tratar incidentes dentro das equipes. Um microsserviço pode ser considerado tolerante a falhas quando
23. É possível acompanhar o que está acontecendo e o que já aconteceu com os seus microsserviços Monitoramento
24. Seu logging reflete com precisão os estados passados do microsserviço Um microsserviço pode ser considerado com um bom monitoramento quando
25. Seus dashboards são fáceis de interpretar e possuem todas as métricas principais. Um microsserviço pode ser considerado com um bom monitoramento quando
26. Possui bons alertas Um microsserviço pode ser considerado com um bom monitoramento quando
27. Os logs não contêm informações sensíveis e só informações relevantes. Um microsserviço pode ser considerado com um bom monitoramento quando
28. As pessoas responsáveis pelo microsserviço estão bem definidas? Um microsserviço pode ser considerado com um bom monitoramento quando
29. As pessoas que entram na equipe desse serviço conseguem ter acesso a esse histórico de informações, sabe como preparar o ambiente, desenho da arquitetura, dentre outras informações essenciais para que possa iniciar o desenvolvimento? Uma equipe que quiser saber desse microsserviço vai conseguir entender o papel dele somente com a documentação? Documentação
30. Contém uma descrição da responsabilidade daquele microsserviço É atualizada frequentemente Um microsserviço pode ser considerado bem documentado quando a documentação
31. Contém um diagrama de arquitetura Contatos das pessoas responsáveis Guia de bordo de desenvolvimento Collections Faq Um microsserviço pode ser considerado bem documentado quando a documentação
32. Qual o papel dele/em que parte esse microsserviço entra dentro daquele ecossistema. Todas as pessoas da equipe devem saber do conteúdo e pessoas de fora devem compreender. Um microsserviço pode ser considerado bem documentado quando a documentação
33. Alguns dos principais padrões apresentados por Chris Richardson no site Microsservices.io Padrões de microsserviços
34. Monolítica - arquitetar um aplicativo como uma única unidade implantável Padrões de arquitetura
35. https://microservices.io/patterns/monolithic.html
36. Microsserviços - arquitetar um aplicativo como uma coleção de serviços fracamente acoplados Padrões de arquitetura
37. https://microservices.io/patterns/microservices.html
38. Strangler Patterns - cria uma nova aplicação em torno do monolito legado, fazendo as funções do antigo monolito e adicionando novas, agregando mais valor ao novo serviço Padrões de refatoração
39. https://microservices.io/patterns/refactoring/strangler-application.html
40. AntiCorruption Layers - cria uma camada de anticorrupção que se traduz entre os modelos de domínio (do monolito que foi herdado e do microsserviço novo que está sendo desenvolvido) Padrões de refatoração
41. https://docs.microsoft.com/pt-br/azure/architecture/patterns/anti-corruption-layer
42. Database per Service - cada serviço tem seu próprio banco de dados privado Padrões de gerenciamento de dados
43. https://microservices.io/patterns/data/database-per-service.html
44. Saga - trabalha com uma sequência de transações locais, para manter a consistência dos dados entre os serviços Padrões de gerenciamento de dados
45. https://microservices.io/patterns/data/database-per-service.html
46. Saga - Orquestração - um objeto orquestrador informa as aplicações participantes quais transações locais executar. Padrões de gerenciamento de dados
47. https://microservices.io/patterns/data/saga.html
48. Saga - Coreografia - decisões distribuídas , cada transação publica eventos que acionam transações locais em outros serviços. Padrões de gerenciamento de dados
49. https://microservices.io/patterns/data/saga.html
50. Api Composition - implementar consultas invocando os serviços que possuem os dados e realizando uma junção na memória Padrões de gerenciamento de dados
51. https://microservices.io/patterns/data/api-composition.html
52. CQRS - Define um banco de dados read-only, que é uma réplica somente leitura projetada para oferecer suporte a essa consulta. O aplicativo mantém a réplica atualizada por meio de eventos Padrões de gerenciamento de dados
53. https://microservices.io/patterns/data/cqrs.html
54. Domain Event - publica um evento sempre que os dados forem alterados Padrões de gerenciamento de dados
55. API Gateway - um serviço que fornece a cada cliente uma interface unificada para serviços, adicionando uma camada a mais de segurança, fazendo balanceamento de carga etc Padrões de APIs externas
56. https://microservices.io/patterns/apigateway.html
57. Backend-for-frontend - um gateway de API separado para cada tipo de cliente Padrões de APIs externas
58. https://microservices.io/patterns/apigateway.html
59. Spring possui uma grande variedade de projetos para os mais variados cenários e necessidades dentro de uma aplicação Spring Cloud
60. Facilita a criação de sistemas distribuídos que são cloud native https://spring.io/projects/spring-cloud Spring Cloud
61. Possibilita que microsserviços descubram facilmente a rota de outros serviços que precisem acessar, os mais conhecidos são Spring Cloud Consul e Spring Cloud Netflix Eureka Service Discovery
62. Tem o papel de ser um intermediário nas nossas requisições para outros serviços. Os mais conhecidos são o Zuul e o Spring Cloud Gateway Gateway
63. Permite armazenar configurações de modo centralizado, para isso temos o Spring Cloud Config Server Configuração centralizada - Config Server
64. Um modo simples de se comunicar com outras aplicações Open Feign
65. Controle sobre falhas e altas taxas de latência dentre os serviços, mais conhecido: Resilience4J Circuit Breaker
66. Inclui id único a cada requisição que entra na aplicação, o que facilita o rastreamento de requisições que passam por um grande fluxo dentro do serviço Sleuth
67. Vamos ao código!
68. Obrigada! https://www.linkedin.com/in/kamila-santos-oliv eira/ https://www.youtube.com/Kamilacode https://www.instagram.com/kamila_code/ https://beacons.page/kamila_code