Como criar uma arquitetura escalável para processamento de arquivos utilizando conceitos de micro serviços e implementações Spring Boot. Apresentação na trilha de micro serviços no The Developers Conference 2017 - Florianópolis
1. Globalcode – Open4education
Criando uma arquitetura escalável
para processamento de arquivos
com micro serviços e Spring Boot
Emmanuel Neri
@emmanuelnerii
6. Globalcode – Open4education
Algumas possíveis soluções
Limitar o pool de threads?
Aumentar o hardware ou
replicar a instância?
Controlar o agendamento?
Separar em estruturas!
8. Globalcode – Open4education
Leitura do arquivo
busca os xmls a
cada x minutos
Insere xml na fila
Insere xml na
base NoSQL
MongoDB
Pasta de arquivos ActiveMQ
Leitor
11. Globalcode – Open4education
Solução de micro serviços
busca os xmls a
cada x minutos
Insere xml na fila
Insere xml na
base NoSQL
Fila envia xml para
processamento
Insere dados
processados no
banco relacional
Consulta dadosConsulta arquivos
-Esse tema é resultado de um estudo
- otimizar os processamento de arquivos em uma visão mais de estrutural da solução de software e não apenas de infraestrutura
- estudo comparativo de softwares monolíticos e software de micro serviços
short talk é divida em 3 partes
Apresentação de um cenário, mas pode ser aplicado para qualquer de processamento de arquivo
Uma das formas de decompor o cenário em pedaços menores
A implementação dos MS que utilizei Spring boot, mas pode ser outras tecnologias de preferência com características simulares de modularização
Problemática: processamento sem impacto no sistema
Decompor
+ impactante
Benefício
Tratar os gargalos de forma isolada
Flexibilidade
N existe maneira correta, adequado para seu cenário
decomposição por responsabilidades em nível macro
visando flexibilidade para escalar e deploys
se baseando no princípio de responsabilidade única, flexibilidade na escalabilidade e atualizações e reduzindo impacto total na solução
Como refletir essa solução na aplicação
2 responsabilidades ao pé da letra do SRP
Depende do cenário pode estar junto
se torna muito granular
Bom exemplo de MS
Assíncrono
Desacoplado
() Autores dizem MS devem ser assíncronos
Isolamento, bases únicas, flexibilidade para alterações
3ª onda de de bigdata “data in motion” – ReactiveMS Arquiteture
Deveria ser uma única aplicação?
Um dos desafio no acesso aos dados
Replicação do modelo
Acesso ao mesmo banco de dados
Arquitetura final: 3 estruturas independentes
Talvez o disponibilizador não tivesse acesso ao banco de dados
Via Rest
Tradeoff
Maior complexidade x Maior flexibilidade
Escalabilidade essência MS
Flexibilidade excelente para escalabilidade
Também é um fator decisivo no momento da decomposição dos MS
@EnableJpaRepositories / EnableJMS
Tomcat
Conjuntos de dependências
Compatibilidade das versões
Artefatos menores
Scheduling está no core do spring
@EnableScheduling
Activemq auto config e libs de JMS
config URL no application.properties
jmsMessagingTemplate.convertAndSend (Sender)
Mongodb libs do Spring data e client Mongo
inserir dados sem estrutura flexivel
Activemq
@JmsListener (Consumer)
Spring data/JPA já traz libs jpa/hibernate
@Entity
Application URLs/driver
Validation carregar libs de beanvalidation
Spring web = MVC
JDBC consultas sem JPA para não replicar modelo e + performance nas consultas
JDBC template
Mongo driver para não mapear no Spring Data e + performance nas consultas