Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Centro de Informática
Recife,
2019
2
Recife,
2019
3
RESUMO
ABSTRACT
With the advancement of technology, the way to develop software has become complex and
multidisciplinary. A common approach inside enterprises is to use a monolithic architecture as
the way of development, however, this architecture may lead to some complications when
used for large applications presenting scale limitations, mainly, when frequent iterations and
deliveries are required. Furthermore, the micro-service architecture appears as an alternative
route for the construction of complex applications and demands that require flexibility and
speed. Despite the fact that the term micro-services is recent, the concept exists for more than
ten years. One way to do it is by migrating between architectures and guaranteeing that no
existing data is lost. This course completion work aims to analyze data from the
StackOverflow website in order to identify the main challenges related to micro-services that
were pointed out and discussed by the software developer community and identifying
potential solutions to these challenges. For this purpose a mapping methodology was used,
and the main challenges detected until now were security, architecture design, migration.
AGRADECIMENTOS
Agradeço a aquela que é a expressão de Deus em minha vida, minha mãe. Agradeço por todo
o apoio e suporte que recebi desde os meus primeiros passos até a conclusão da minha
graduação.
Agradeço ao professor Vinicius Cardoso Garcia pela orientação e pelo acompanhamento. Seu
suporte foi fundamental para a conclusão deste trabalho.
Agradeço aos meus colegas de turma, “2012.3”, que compartilharam as lutas e as vitórias
durante todos estes anos. Por todo apoio, todo incentivo e por sempre acreditar e me
incentivar a enfrentar todas as adversidades.
Agradeço aos meus amigos, colegas, por todo suporte que me foi dado. Não poderia esquecer
aqueles que me atrapalharam e aos que disseram que eu nunca iria conseguir. Muito obrigado
por essas palavras, pois elas só fortaleceram a minha força de vontade e minha determinação.
Por fim, agradeço à UFPE, ao CIn, e a todos aqueles que contribuíram direta ou indiretamente
para a minha formação.
7
LISTA DE SIGLAS
LISTA DE TABELAS
LISTA DE QUADROS
LISTA DE FIGURAS
SUMÁRIO
1 INTRODUÇÃO .............................................................................................................. 13
1 INTRODUÇÃO
1.1 OBJETIVOS
Objetivo Geral
Este trabalho tem como objetivo entender quais são os desafios e as potenciais
soluções sobre a arquitetura de microsserviços por meio de um estudo aplicado em uma base
de dados colaborativa e comunitária utilizada majoritariamente por desenvolvedores de
software e/ou stakeholders envolvidos no domínio do assunto em questão.
Objetivos Específicos
Identificar os principais desafios no uso de microsserviços
Descrever as potenciais soluções adotadas para os desafios encontrados
1
www,stackoverflow.com/
2
https://stackoverflow.com/company acessado dia 21/06/2019.
15
2 FUNDAMENTAÇÃO TEÓRICA
implantados e geridos com maior eficiência. A segunda onda foi composta de tecnologias de
serviços que permitia que se comunicassem uns com os outros sem interferências das suas
redes locais. Tecnologias de monitoramento fizeram parte da terceira onda permitindo o
monitoramento e a análise do comportamento dos recursos dos microsserviços em diferentes
níveis de detalhe.
conceito de microsserviços em sua arquitetura. A Amazon oferece serviços como S3 que pode
ser considerado como microsserviço (SAVCHENKO et al, 2015).
Arquiteturas diversas têm sido usadas ao longo das décadas para a solução de
problemas. Segundo Lucio (2017), o objetivo de otimizar a implantação de softwares
modulares, com ciclos de vida independentes, foi o que motivou o aparecimento da
arquitetura de microsserviços. Ao longo dos anos, características relativas à descentralização
de linguagens, automação do processo de implantação, alinhamento ao negócio e organização
de projetos e equipes foram constituindo os microsserviços.
Fowler (2014) relata que uma explicação para entender a arquitetura de microsserviços
pede uma comparação com o estilo monolítico, que é uma aplicação construída como uma
única unidade, isto é, uma única aplicação é responsável por todos os processos. Ela apresenta
a interface para interação com o usuário, acessa os dados persistidos no banco de dados,
processa pedidos de clientes e todas as outras ações que a aplicação necessitar. A aplicação
monolítica é autossuficiente e independente de outras aplicações de computação. A filosofia
do projeto é que o aplicativo é responsável não apenas por uma determinada tarefa, mas pode
também executar todos os passos necessários para completar uma macro função.
3
Ver Prana: A Sidecar for your Netflix PaaS based Applications and Services. Disponível em
<http://techblog.netflix.com/2014/11/prana-sidecar-for-yournetflix-paas.html> e Tonse S. Microservices at
Netflix. Disponível em http://www.slideshare.net/stonse/microservices-at-netflix>.
20
A composição do serviço, que é uma forte área de pesquisa, oferece a capacidade para
que os serviços interajam uns com os outros e gerem funcionalidades complexas. SOA pode
realizar composições de serviço como orquestração, coreografia e coordenação.
Microsserviços foca na coreografia e evita ser dependente de outros componentes, enquanto
que SOA depende fortemente da orquestração de serviços; em microsserviços, há pouca ou
nenhuma orquestração (LEON, 2017).
21
Segundo ainda Leon (2017), SOA é apropriada para grandes aplicações com dados
pesados, complexos e processamento de mensagens. Microsserviços é apropriado para
aplicações pequenas e sistemas pequenos. Um exemplo dado está na Internet das Coisas (IoT)
onde estão envolvidos muitos microsserviços na troca de informações dos dispositivos IoT.
Além disso, microsserviços é uma melhor escola para microempresas e startups porque a
implantação dos microsserviços é feito em contêineres especializados, o uso de tecnologias da
nuvem estão amplamente disponíveis. Outros dois benefícios são custo e esforço, que são
maiores no SOA.
A arquitetura de microsserviço tem como objetivo uma entrega rápida para colocação
em produção assim que possível, já que muitas empresas vêm a tecnologia da informação
como a principal facilitadora para maior agilidade em termos de, por exemplo, adaptação a
mudanças no mercado e por isso uma implantação rápida dos microsserviços em múltiplos
ambientes de execução, em programações arbitrárias e um mínimo de gestão centralizada.
O segundo item nesta lista de três benefícios se refere à escalabilidade, mas de acordo
com Jamshidi et al (2018), este termo é ambíguo porque pode se referir à sua capacidade de
mudança no número de usuários que acessam o serviço ou ainda a capacidade do processo de
desenvolvimento de acomodar desenvolvedores trabalhando em paralelo.
Nos últimos anos diversas empresas têm migrado seus sistemas monolíticos para a
arquitetura de microsserviços. Algumas delas como Wix.com adotou microsserviços devido a
problemas técnicos que resultaram em sérios problemas de estabilidade e em 2010 a empresa
começou o repartir em pequenos serviços a fim de melhor lidar com a escalabilidade e a
qualidade (DOERRFELD, 2018).
Mas, a migração não aconteceu sem problemas. Wix.com teve que lidar com vários
problemas começando com comunicação entre os microsserviços a falhas diversas e, portanto,
teve que inventar um novo padrão de integração e de testes, além de uma nova cultura interna.
A arquitetura interdependente da Best Buy também se tornou um problema com
gargalos nas implantações de modo que o tempo ocioso era longo demais para sustentar a
condução de negócios online. Mas o maior problema durante a migração do sistema foi a falta
de confiança entre o pessoal de TI devido a uma resistência cultural à maneira como o
software é desenvolvido e lançado (DOERRFELD, 2018).
23
Escalonabilidade 15 2 3 3 12 2
Delegação de 11 3 1 3 10 3
responsabilidades
da equipe
Suporte DevOps 8 3 2 1 6 3
Porque todos 6 4 2 3 4 4
estão fazendo
Tolerância a 2 4 2 4 / /
falhas
Experimentar 2 3 2 3 / /
tecnologia fácil
Delegação de 1 4 1 4 / /
responsabilidades
do software
Migração da 6 4 / / 6 4
base de dados e
separação de
dados
Comunicação 4 3.5 2 3 2 3
entre serviços
Estimativa do 2 4 2 1 2 3
esforço
Infraestrutura 2 4 / 4 / /
do DevOps
exigindo
esforço
Esforço da 2 4 / / 2 4
conversão da
biblioteca
Mente das 2 4 1 4 1 4
pessoas
Retorno 2 3 1 3 1 3
esperado no
investimento
Fonte: Taibi et al, 2017
2.8 RESUMO
3 METODOLOGIA
4
Disponível em: https://s3.amazonaws.com/academia.edu.documents/40605563/gqm.pdf?response-content-
disposition=inline%3B%20filename%3DThe_Goal_Question_Metric_Approach.pdf&X-Amz-
Algorithm=AWS4-HMAC-SHA256&X-Amz-
Credential=AKIAIWOWYYGZ2Y53UL3A%2F20190623%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-
Date=20190623T134515Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-
29
No que diz respeito ao objetivo, a pesquisa é classificada como descritiva, visto que os
fatos foram sistematicamente coletados, registrados, analisados e exibidos com o intuito de
apresentar os principais desafios no uso de microsserviços (BARREIROS, 2015).
Em relação à natureza dos dados e das análises adotadas, a pesquisa predomina o caráter
qualitativo, visto que apresenta análise e interpretação do contexto do objeto de pesquisa.
Os dados discutidos neste trabalho foram obtidos através de um repositório6, onde ficam
armazenados todos os dados do Stackoverflow. Após a obtenção e o tratamento dos dados, foi
percebido que o mesmo estava incompleto, pois estava apenas com as perguntas e sem as
respostas. Visto isso, foi feito uma nova coleta dos dados através do serviço online 7 onde
através da consulta, exibida na Figura 4, foram obtidos os mesmos dados referente à
microsserviços, só que dessa vez com as respostas.
3.4 RESUMO
4 RESULTADOS
Para a obtenção dos resultados, foi utilizada a abordagem GQM, o Quadro 1 apresenta
os objetivos definidos de acordo com o objetivos deste trabalho.
OBJETIVO
OBJETO Analisar Estudo sobre microsserviços
Melhorar a compreensão
FINALIDADE Com o propósito de
sobre microsserviços
FOCO Com relação aos Questionamentos
32
encontrados no
Stackoverflow
PONTO DE VISTA Sob o ponto de vista do Desenvolvedor de Software
AMBIENTE No seguinte contexto Stackoverflow
Após a definição dos objetivos, foram elaboradas as questões relacionadas a eles, sendo
elas exibidas no Quadro 2, onde foram definidos baseados nos objetivos específicos desde
trabalho.
Quadro 2 - Questões
QUESTÕES
Q1 - Quais os principais desafios referentes ao uso de microsserviços?
Q2 - Quais as potenciais soluções para os desafios detectados na questão anterior?
Em seguida, faz-se necessária a definição das métricas, pois elas devem conter
informações suficientes para responder as questões. O Quadro 3 apresenta as métricas
utilizadas para a obtenção das respostas das questões exibidas no Quadro 2.
Quadro 3 - Métricas
MÉTRICAS
M1 - Olhar no stackoverflow quais são esses desafios
M2 - Olhar no stackoverflow quais as soluções para esses desafios
4.2 DESAFIOS
Segurança
Na base de dados foram encontradas várias perguntas relacionadas ao mesmo
problema, e com isso podemos identificar várias maneiras de se resolver esse mesmo
problema. O processo de autenticação e controle de acesso garante que o usuário só consiga
ter acesso a aquilo que lhe é permitido.
Na autenticação faz-se a primeira verificação, onde se detecta quem e que tipo de
usuário está acessando ou se é alguém tentando invadir o sistema. Após esse processo de
verificação e acesso ao sistema, toda e qualquer atividade deve ser permitida pelo controle de
acesso, restringindo o acesso apenas ao que foi pré-estabelecido na hora da criação do
usuário. Dessa forma pode-se afirmar que para garantir a segurança de um microsserviço é
necessária a junção da autenticação e o controle de acesso.
O Quadro 4 apresenta as questões relacionadas a segurança e algumas possíveis
soluções para essas questões.
34
O processo de autenticação pode ser feito de várias maneiras como sugerida pela
comunidade. O spring security é utilizado apenas para aplicações java, o Oauth é bastante
utilizado quando se deseja o login único (single sign on), ou seja, permite acesso seguro a
vários sites sem compartilhar dados de senha, faz isso através do envio de tokens de
autorização. O XACML tem a mesma finalidade do Oauth, usado quando deseja o logon
único, mas faz uso de XML para garantir o acesso seguro a vários sites. O CORS é uma
política de segurança e não se aplica nesse nosso caso. Então, podemos afirmar que o Oauth e
o XACML são bastante abrangentes para a resolução do problema de autenticação, onde o
Oauth possui uma complexidade menor que o XACML. O spring security também resolve o
problema de autenticação, mas é limitado para a linguagem java.
O controle de acesso também pode ser feito por diversas formas como foi sugerida pela
comunidade. O DMZ é usado em redes, logo não atende o nosso problema. O JWT não é
propriamente um método de controle de acesso, mas é um token que pode ser usado
combinado com o Oauth para fazer o controle de acesso. Já o controle de acesso feito pela
API Gateway é específica para fazer o controle de acesso, é uma maneira tão simples quanto o
JWT. Logo, ambas resolvem o problema e a escolha de uso fica pela parte dos
desenvolvedores.
Aplicação
A aplicação é o software que é composto por vários microsserviços, e nessa base
foram detectadas algumas dificuldades em relação ao teste dos módulos e sobre a interface
vista pelo usuário, como pode ser visto no Quadro 5.
35
Os testes são a garantia que o sistema chegará ao cliente livre de falhas e a solução
dada foi que os testes fosse uma etapa do fluxo de entrega do produto final, dessa forma
tornando possível a correção do mesmo. Sendo construído dessa forma, com os testes fazendo
parte do fluxo, podemos dizer que é a forma correta de realização dos testes, caso a aplicação
não passe em algum dos testes, a mesma é automaticamente reprovada alertando ao
desenvolvedor onde foi reprovada, evitando que essa versão do software chegue ao seu
destino final com problemas.
Já a construção da interface gráfica, não precisa ser criada como um microsserviço,
pois isso poderia aumentar a complexidade de sua construção, então foi sugerido que ela fosse
criada como um monolítico e conectada a aplicação. Essa solução é bastante simples e a mais
prática, pois oferece ganho de tempo e baixa complexidade.
Arquitetura
Quando relacionado a banco de dados, foi detectado que as dificuldades eram muito
específicas de cada projeto, e dessa forma os usuários apenas recomendavam escolher melhor
a arquitetura do banco, pois não havia como corrigir. Sendo a melhor maneira, pois tentar
corrigir essa arquitetura pode gerar um grande esforço e tempo, onde reconstruir com uma
arquitetura bem desenhada gastaria um esforço bem menor.
Quando se referiu à transações, também foi recomendo que fosse revista a forma
como estava sendo construído, pois dessa forma havia situações que causaria inconsistência
dos dados. A inconsistência se dá através da existência de informações duplicadas em
diversos lugares. Faz-se necessário que a arquitetura seja muito bem desenhada para evitar
que durante o processo essas duplicatas sejam criadas.
Banco de Dados
Problema nos
Manda rever a arquitetura sobre
relacionamentos do
como o banco foi dividido e as
banco de dados
relações mantidas
para utilizar no MS
Garantir
Usar gerenciadores de
consistência dos
transações
dados
Onde armazenar
tabela comum para Replica a tabela
Consistência 7 todos os MS
Sincronizar o banco
de dados entre os Usando JWT
MS
Eliminar registro Criar um MS cuja função é
fantasma eliminar esses registros
Garantir múltiplo Diz que não é possível
Múltiplo
1 acesso ao Banco de Recomenda usar JDBC pois cada MS tem seu
Acesso
Dados próprio servidor
Migração
É o processo de mudança do software construído em uma arquitetura para outra, nesse
caso de monolítico para microsserviço. Essa migração deve ser feita em etapas e o erro ou má
formação em alguma dessas etapas impactará no resultado final. Nas pesquisas foi encontrado
um caso que é o inverso, migrando de microsserviço para monolítico. O Quadro 8 trás os
problemas relacionados a migração.
Problema
Desafio Quantidade Descrição Solução
Específico
Gerenciar os dados Usar cache distribuída
Fazer um MS reagir depois de receber Usar um framework para realizar
Arquitetura 14 uma mensagem essa orquestração
Migrar mas manter os mesmo Escrever o MS e redirecionar as
endpoints chamadas
Migração Banco de Como migrar todo o sistema, sem
6
Dados migrar o banco de dados?
Melhor forma para se monitorar um
Monitoramento 1
MS
Como unir os MS para gerar um
Reversa 1
Monolito?
Quando o problema da migração está relacionado a arquitetura, foi encontrado problemas com o
gerenciamento dos dados então foi sugerido que se use cache distribuída. Essa cache distribuída vai
permitir que vários microsserviços tenham acesso aos dados de maneira rápida, e evita que os
microsserviços tenham acesso direto ao banco de dados. Essa cache é sincronizada de maneira
assíncrona com o banco de dados na medida em que é utilizada.
Para fazer com que o serviço reaja após algum evento, é necessário usar um
framework/software para fazer esse tipo de orquestração. Ainda relacionada a arquitetura, para migrar
de arquitetura sem precisar mudar os endpoints, então cria-se os novos microsserviços e redireciona as
chamadas. Pois quem está chamando o recurso não sabe como está sendo executado por trás do
endpoint.
As células vazias na tabela, significam que nesses desafios em específicos não havia nenhuma
solução sugerida, dessa forma eu, como um estudante do assunto, sugeri algumas possíveis soluções
para esses problemas.
Para utilizar o mesmo banco de dados após a migração do sistema, não houve nenhuma
sugestão, mas cria-se uma interface entre o banco de dados e a aplicação e todas as requisições devem
40
ser feita através dessa interface. Com isso, independente de como a aplicação esteja construída, basta
que a requisição seja feita corretamente que os dados corretos serão retornados.
O monitoramento de microsserviços pode ser feito através de softwares, como por exemplo,
Splunk, Nagios, Loggly, entre outros. Já referente à migração reversa, não houve nenhuma possível
solução, mas acredito que o processo deve ser a reconstrução do sistema, visto que passar de uma
construção fracamente acoplada para uma fortemente acoplada não seja algo tão comum.
Spring
Apesar de ser utilizado por grandes empresas, Netflix, Nubank, In Loco Media, entre
outras, microsserviços ainda é um conceito novo, e por sua vez apresentam bastantes desafios.
Garantir a segurança dos dados é algo imprescindível para qualquer organização, no quadro 4
observa-se que existem várias maneiras conseguir segurança em microsserviços, de maneiras
a autenticação através do Oauth, XACML ou Spring security(para aplicações java) e o
controle de acesso pode ser feito através da combinação do Oauth com o JWT, pela ACL ou
apenas pela API Gateway.
A arquitetura do microsserviço é relativamente simples de entender, porém a sua
construção não é tão simples de ser entendido, visto que uma parte das empresas e dos
desenvolvedores estão familiarizados com outro tipo de arquitetura, que possui uma
construção simples. Dessa forma, os problemas relacionados à arquitetura, como pôde ser
observado no quadro 6, o maior gargalo é como conseguir a comunicação entre esses
serviços, e uma possível solução é usar algum tipo de serviço de mensageria, que faça essa
troca de informações entre os microsserviços.
Quando se refere ao o uso de banco de dados, o desafio mais impactante é a sua
arquitetura, ou seja, como é possível usar o banco de forma que seja possível suportar vários
microsserviços acessando o tempo todo e que mantenha os dados consistentes, a solução para
esse desafio vária de problema para problema, como visto no quadro 7, mas pode ser
resolvido de duas formas basicamente, usando um banco de dados comum e usar uma política
que controle o acesso ou usar um banco de dados individual para cada microsserviço e usar
uma política para fazer a sincronização dos dados. Dessa forma é possível garantir um banco
consistente e que pode ser usado por vários microsserviços.
Já a migração envolve várias etapas, e por isso como foi visto no quadro 8, o problema é
essa mudança, desconstruir algo que já está funcionando para mudar a forma como está
construída. Então, esse problema também pode ser abordado de maneiras diferentes, a
depender da necessidade e tempo que a empresa tem disponível para a realização dessa
migração. Para um curto prazo, o sugerido foi que os novos módulos sejam criados seguindo
a nova arquitetura e conectados ao sistema antigo, e em algum momento mais oportuno mudar
gradativamente o sistema antigo, já para um longo prazo, a sugestão é criar um software em
paralelo seguindo a arquitetura de microsserviço, para evitar problemas no sistema atual, e
quando o mesmo estiver completo, fazer a substituição de softwares.
42
A tendência é que cada vez mais empresas busquem uma forma de usar microsserviços,
seja através da migração do sistema antigo, ou através da construção de um sistema nova e
substituição do antigo, mas, apesar de ser um conceito que ainda não está maduro, vem para
mudar a forma de se desenvolver software.
Os resultados desse estudo apresentam informações sobre os desafios e algumas
potenciais soluções, entretanto algumas dessas potenciais soluções realmente solucionam o
problema, outras atendem parcialmente, como por exemplo, o uso do JWT para solucionar o
problema de controle de acesso, onde apenas o ele não resolve o problema, entretanto
utilizado junto com o Oauth resolveria. Há algumas que não atendem a necessidade, como o
próprio JWT quando foi citado para resolver o problema de consistência de banco de dados.
Visto isso, esperamos que através dos dados encontrados nesse estudo através da exibição
esses desafios e das suas possíveis soluções, auxiliem os desenvolvedores de software e/ou
stakeholders a superarem tais problemas.
4.4 RESUMO
Neste capítulo foi apresentada a definição do objetivo, das questões e das métricas
utilizadas, foi apresentado os principais desafios e algumas possíveis soluções, junto com eles
uma discussão sobre essas soluções sugeridas pela comunidade. Algumas delas totalmente
válidas, algumas parcialmente corretas e algumas que estavam fora do contexto, pois
resolviam esse tipo de problema, mas em outro contexto.
43
5 CONSIDERAÇÕES FINAIS
5.2 CONCLUSÃO
Este trabalho teve como objetivo principal um mapeamento de parte de uma base de
dados colaborativa e comunitária utilizada majoritariamente por desenvolvedores de software
e/ou stakeholders envolvidos no domínio do assunto em questão, para entender quais são os
desafios e as potenciais soluções no uso da arquitetura de microsserviços.
6 REFERENCIAS
DOERRFELD, B. From monolith to microservices: Horror stories and best practices. 2018.
Disponível em <https://techbeacon.com/app-dev-testing/monolith-microservices-horror-
stories-best-practices> Acesso em 9 jun 2019.
GALDINO, Fernando. SOA, API, Microsserviços: onde aplicar cada uma dessas
modalidades? 2017. Disponível em <https://www.linkedin.com/pulse/soa-api-microsserviços-
onde-aplicar-cada-uma-dessas-galdino-pmp/> Acesso em 29 mai 2019.
JAMSHIDI, Pooyan et al. Microservices: The road so far and challenges ahead. IEEE
Software, May-Jun 2018.
46
LEON, A. F. Don’t believe the hype! SOA AND MSA are not the same. 2017. Website.
Disponível em:
<https://www.academia.edu/34828240/Dont_believe_the_hype_SOA_AND_MSA_are_not_t
he_same> Acesso em 29 mai 2019.
LEWIS, J., FOWLER, M. Microservice Resource Guide. 2014. Disponível em: <
https://www.martinfowler.com/microservices/> Acesso em 3 mar 2019
MACHADO, G. M.: Micro Serviços: Qual a diferença para arquitetura monolítica? (2017).
Disponível em: < https://www.opus-software.com.br/micro-servicos-arquietura-monolitica/
SAVCHENKO, D.I. et al. Microservices validation: Mjolnirr platform case study. Mipro,
2015