microservices: mais que uma arquitetura de software, uma filosofia de desenvolvimento de software
TRANSCRIPT
Microservices
Emmanuel Neri
Mais que uma arquitetura de software, uma filosofia de
desenvolvimento de software
Agenda
● O que é microservices
● Comunicação entre serviços
● Um exemplo de aplicação
● Boas práticas
● Mudanças
● Conclusões
Microservices
“Microservices are small, autonomous services that work together”
Sam Newman
“A small application that can be deployed independently, scaled independently, and
tested independently and that has a single responsibility.”
Johannes Thones
Linha do tempo
Lei de Conway
“Any organization that designs a system (defined more broadly here than just information
systems) will inevitably produce a design whose structure is a copy of the organization’s
communication structure. “
Melvin Conway’s
Características
FOWLER; LEWIS (2014)
● Composto por um conjunto de serviços “pequenos”● Serviços autônomos● Permite ser escalado horizontal e vertical● Possui liberdade de tecnologia● Flexibilidade de deploy● Facilidade para integrações● Maior tolerância a falhas
Escalabilidade
● Eixo X - Duplicação horizontal
● Eixo Y - Decomposição vertical
● Eixo Z - Separação dos dados
Microservices é igual SOA?
“SOA é algo maior, utilizando para
integração de monolitos”
FOLWER; LEWIS (2014)
● Serviços reutilizáveis
● Serviços compartilham um contrato formal
● Serviços possuem baixo acoplamento
● Serviços autônomos
● Etc...
Princípios de SOA:
Como organizar os serviços?
Comunicação entre os serviços
● “HTTP é o padrão de comunicação no microservices”
○ Martin Fowler
● “O serviços devem ser assíncronos”
○ Jonar Bonér (Reactive Microservices Architecture)
■ Terceira onda de bigdata: “data in motion”
Características das comunicações ● Síncrona
○ Espera resposta
○ Comunicação em “tempo real”
○ Balanceador de carga a nível de infraestrutura
○ Tratamento de erros pode ser pelo status do http
● Assíncrona
○ Não espera resposta
○ Comunicação entre os dados pode ser “delay” entre as estruturas
○ Balanceador de carga pode ser uma fila
○ Possibilidade de Service Discovery / Message broker
○ Tratamento de erros pode ficar no gerenciador da fila
○ Em caso de erros o gerenciador de mensagens pode tratar o reenvio
Implementações de comunicação ● Síncrona
○ Rest, SOAP, CDI
● Assíncrona
○ Mensagens, Eventos, Replicação de base
Exemplo
Síncrona Assíncrona
Síncrona Assíncrona
Síncrona Assíncrona
Síncrona Assíncrona
Síncrona Assíncrona
Comparativo de tempo execução do relatório que utiliza dados das aplicações de pedidos e cadastros.
Testes Tempo
Execução 1 175
Execução 2 31
Execução 3 31
Execução 4 30
Execução 5 29
Média: 59,2 milissegundos
Testes Tempo
Execução 1 15
Execução 2 9
Execução 3 10
Execução 4 10
Execução 5 9
Média: 10,6 milissegundos
Conclusões do exemplo
Síncrona AssíncronaVantagens Desvantagens
Dados em tempo real Maior tempo entre as comunicações (maior
preocupação com performance)
Dados Centralizados Baixa integridade entre os relacionamentos
Maior reaproveitamento dos serviços
Serviços impactante em outras funcionalidades
Vantagens Desvantagens
Sincronizações transparentes para o usuário
Possibilidade de indisponibilidade dos dados
Serviços totalmente independentes
Replicação dos dados / Replicação de código
Maior complexidade com sincronizações
Frameworks● Dropwizard
● KumuluzEE
○ Duke's Choice Award Winner 2015
● Micro Profile
○ Wildfly Swarm
● Spring Boot
Boas práticas● Baixo acoplamento ● Bounded Context (DDD)
Boas práticas● Single Responsibility Principle ● Single Point of Failure
Mudanças no desenvolvimento● Desenvolvimentos voltados a APIs
● Desafios de Sistemas distribuídos
○ Base de dados distribuídas, Transações distribuídas, Latência de rede
● Complexidade nos testes automatizados
○ Testes distribuídos
● Segurança
Mudanças na cultura● DevOps
● Maior número de aplicações / instâncias
● Integrações constantes
● Governança dos serviços (APIs)
● Desenvolvimento multiprojetos
Por onde começar?
● Migração por camadas
○ Aplicação? Banco de dados?
● Começar de uma aplicação existente
Padrões de migração de monolitos
● Strangler Application ● Depedency Inversion Principles
Conclusão
● Vários trade-offs
○ Como fazer comunicação entre os serviço?
○ Como separar os serviços?
● Mudanças de cultura
● Mudança na forma de desenvolvimento
Referências● Building Microservices: Designing Fine-Grained Systems - Sam Newman
● The Art of Scalability - Martin L, Abbott, Michael T. Fisher ● Domain-Driven Design - Eric Evans● DevOps: A Software Architect's Perspective - Len Bass, Ingo Weber, Liming Zhu● Reactive Microservices Architecture - Jonas Bonér● http://martinfowler.com/articles/microservices.html● http://pt.slideshare.net/adriancockcroft/dockercon-state-of-the-art-in-microservices● http://pt.slideshare.net/gutomcosta/como-ddd-e-strategic-design-esto-nos-ajudando-a-m
odernizar-um-legado● http://pt.slideshare.net/ewolff/rest-vs-messaging-for-microservices● https://www.infoq.com/br/presentations/microservicos-uma-jornada-inesperada● http://pt.slideshare.net/tdc-globalcode/tdc2016sp-trilha-microservices-64181673