Modernização de arquitectura monolítica numa arquitectura de micro-serviços

• Main Author: Barros, Nuno Amaro Beito
• Publication Date: 2020
• Format: Master thesis
• Language: por
• Source: Repositórios Científicos de Acesso Aberto de Portugal (RCAAP)
• Download full: http://hdl.handle.net/20.500.11960/2474
• topic: Pagamentos; Monólito; Microserviços; Spring; Hibernate; Java; Kafka; Arquitectura de sistemas; Payments; Monolith; Microservices; System architecture

O desenvolvimento de software em arquitectura monolítica é tipicamente o primeiro passo aquando do desenvolvimento de uma prova de conceito, devido à sua rapidez de implementação e consequente reduzido time-to-market. Actualmente, com a conjuntura de mercado existente e consequente mutação de mercados, tendências e ideias, opta-se frequentemente por uma solução inicial monolítica, efectuando compromissos técnicos com vista a uma rápida adopção de determinada plataforma, produto ou serviço de informática que esteja em desenvolvimento. No entanto, passada a prova inicial do conceito, é constatado frequentemente que o projecto desenvolvido numa arquitectura monolítica assume dimensões cuja natureza o tornam difícil de manter, escalar e estender. Este foi o caso do JumiaPay, que, após uma solução monolítica inicial, se depara agora com este problema e, com vista a maior escalabilidade e manutenibilidade, adoptou uma abordagem para dividir o seu monólito em micro-serviços e, de igual modo, na tentativa de corrigir algumas decisões tomadas que são menos eficientes, efectuadas ao longo do tempo, que foram fruto das várias influências, de natureza humana, técnica ou económica. Este Relatório de Mestrado trata dessa abordagem de reestruturação do JumiaPay numa arquitetura distribuída baseada em micro-serviços. Foi conseguida a migração da parte do sistema que está responsável pelas integrações com os parceiros, pois foi identificada como a parte que iria escalar mais rapidamente. Neste caso, foi imperativo identificar os pontos comuns entre todas as integrações para que fosse possível integrá-las com o restante do sistema. Esta tarefa revelou-se complexa devido às diferenças nos fluxos entre os parceiros. A separação deste código responsável pela integração com os parceiros permitiu-nos uma separação mais clara de responsabilidades, podendo facilmente aumentar escalabilidade quando necessário e consequentemente, a fiabilidade.