logistics as microservices from monolithic to
TRANSCRIPT
Logistics as microservices From monolithicto microservices A case study Logistics
NELSON DANIEL MENDES FERREIRAOutubro de 2020
Logistics as microservices
āFrom monolithic to microservices
A case study ā Logisticsā
Nelson Daniel Mendes Ferreira
DissertaĆ§Ć£o para obtenĆ§Ć£o do Grau de Mestre em
Engenharia InformĆ”tica, Ćrea de EspecializaĆ§Ć£o em
Engenharia de Software
Orientador: Ana Maria Neves Almeida Baptista Figueiredo
Supervisor: Paulo Jorge Lopes de AraĆŗjo
Porto, Outubro 2020
iii
Resumo
O desenvolvimento de software aos longos dos Ćŗltimos anos tem evoluĆdo dada a
exigĆŖncia do mercado e a sua necessidade de obter soluƧƵes com elevado desempenho
e eficƔcia. As empresas visam atender os requisitos dos seus clientes, pretendendo
assegurar soluƧƵes com elevado nĆvel de desempenho, usabilidade, disponibilidade e
escalabilidade enquanto reduzem os seus custos de desenvolvimento e implantaĆ§Ć£o.
Assim, ao longo dos anos as empresas tendem a decompor os seus serviƧos em
pequenos segmentos de cĆ³digo-fonte, denominados de microsserviƧos. Estes,
permitem obter o mƔximo partido dos serviƧos disponibilizados pelos provedores de
cloud e proporcionar soluƧƵes satisfatĆ³rias quer para as empresas quer para os clientes.
Neste trabalho procede-se Ć realizaĆ§Ć£o de uma migraĆ§Ć£o arquitetural, decompondo
uma aplicaĆ§Ć£o monolĆtica da empresa Flowinn, Logistics, em utilizaĆ§Ć£o no quotidiano
dos seus clientes, em diversos microsserviƧos e utilizar padrƵes comuns em
arquiteturas baseadas em microsserviƧos. ApĆ³s a migraĆ§Ć£o sĆ£o avaliados os impactos e
observadas, ou nĆ£o melhorias associadas Ć migraĆ§Ć£o nas vertentes acima descritas.
Como resultado pretende-se reduzir os custos da empresa e tornar o produto mais
competitivo no mercado em que se encontra.
Palavras-chave: MonolĆtica, MicrosserviƧos, EvoluĆ§Ć£o arquitetural, Continuous
Integration, Continuous Delivery.
v
Abstract
Over the past few years, software development has evolved given the market's demand
for solutions with high performance and efficiency. The companies aim to meet the
requirements of their customers, aiming to ensure solutions with a high level of
performance, usability, availability and scalability while reducing their development
and deployment costs.
Over the years, companies have tended to break their services into small segments of
source code, denominated microservices. These get the most out of the services
provided by cloud providers and allow satisfactory solutions for companies and
customers.
With this work, it is intended to do an architectural migration, decomposing a
monolithic application of the company Flowinn, in use in the daily of its customers, in
several microservices and to use common standards in microservices based
architectures. Subsequently, it is intended to assess the impacts and improvements
associated with migration in the areas described above.
All this work aims to reduce the company's costs and make the product more
competitive in the market in which it is.
Keywords: Monolithic, Microservices, Architectural evolution, Continuous Integration,
Continuous Delivery.
vii
Agradecimentos
Aos meus pais, pelo carinho e motivaĆ§Ć£o que me deram ao longo de todos os meus
anos de estudo.
Ć minha famĆlia, por me ajudarem sempre que preciso.
Ć minha namorada, Ana Rita, por todo o apoio e dedicaĆ§Ć£o demonstrado, estando ao
meu lado em todas as minhas conquistas.
Ć minha orientadora, Ana Almeida, pela orientaĆ§Ć£o prestada, disponibilidade e apoio
que sempre demonstrou.
Ć empresa Flowinn, pela experiĆŖncia, conhecimento e confianƧa transmitida desde o
primeiro dia.
A todos muito obrigado!
ix
Ćndice
1 IntroduĆ§Ć£o ................................................................................. 1
1.1 Contexto .........................................................................................1
1.2 Problema ........................................................................................2
1.3 Objetivos ........................................................................................2
1.4 Resultados esperados ..........................................................................3
1.5 HipĆ³tese de investigaĆ§Ć£o ......................................................................4
2 Contexto teĆ³rico ......................................................................... 5
2.1 Arquiteturas monolĆticas ......................................................................5
2.2 Arquiteturas baseadas em microsserviƧos ..................................................7
2.3 Domain-driven design ..........................................................................8
2.4 Base de dados em microsserviƧos ............................................................8 2.4.1 Base de dados partilhada ...............................................................9 2.4.2 Base de dados para cada microsserviƧo ...............................................9
2.5 PadrĆ£o Saga .....................................................................................9
2.6 PadrĆ£o CQRS .................................................................................. 10
2.7 Event sourcing ................................................................................ 10
2.8 API Management .............................................................................. 11
2.9 API Gateway .................................................................................. 12
2.10 Descoberta de serviƧos (Service discovery) .............................................. 12
2.11 ComunicaĆ§Ć£o sĆncrona entre microsserviƧos ............................................. 13
2.12 ComunicaĆ§Ć£o assĆncrona entre microsserviƧos ........................................... 13 2.12.1 RabbitMQ ................................................................................ 14 2.12.2 Apache Kafka ........................................................................... 15 2.12.3 ComparaĆ§Ć£o entre RabbitMQ e Apache Kafka ..................................... 16
2.13 Continuous integration (CI) e continuous deployment (CD) ............................ 18 2.13.1 Jenkins ................................................................................... 19 2.13.2 Bitbucket Pipelines .................................................................... 19 2.13.3 ComparaĆ§Ć£o entre Jenkins e Bitbucket Pipelines ................................. 19 2.13.4 Docker ................................................................................... 20 2.13.5 Kubernetes .............................................................................. 21 2.13.6 Helm ..................................................................................... 22
2.14 Cloud computing ............................................................................. 22 2.14.1 Google Cloud Platform ................................................................ 23 2.14.2 Amazon Web Services .................................................................. 23 2.14.3 Microsoft Azure ........................................................................ 24 2.14.4 DigitalOcean ............................................................................ 24
x
2.15 JMeter ......................................................................................... 24
2.16 Servidor de autenticaĆ§Ć£o Ćŗnico ............................................................ 24
3 MigraĆ§Ć£o entre arquiteturas .......................................................... 27
3.1 EstratĆ©gias de migraĆ§Ć£o ..................................................................... 27
3.2 Exemplos de MigraƧƵes ...................................................................... 29 3.2.1 Wix ....................................................................................... 29 3.2.2 Netflix ................................................................................... 30
4 AnƔlise de valor ......................................................................... 31
4.1 Novo Modelo de Desenvolvimento de Conceitos ......................................... 31 4.1.1 IdentificaĆ§Ć£o da Oportunidade ....................................................... 32 4.1.2 AnĆ”lise da Oportunidade .............................................................. 33 4.1.3 GeraĆ§Ć£o e Enriquecimento de Ideias ................................................ 34 4.1.4 SeleĆ§Ć£o da Ideia ........................................................................ 34 4.1.5 DefiniĆ§Ć£o de conceito ................................................................. 34
4.2 Valor para o cliente e valor percebido pelo cliente .................................... 35
4.3 Business Model Canvas ...................................................................... 35
4.4 Analytic Hierarchy Process.................................................................. 38
5 Abordagens tecnolĆ³gicas .............................................................. 41
5.1 Gateway e JHipster Registry ............................................................... 41
5.2 Gateway e Consul ............................................................................ 42
5.3 WSO2 API Manager ........................................................................... 44
5.4 AvaliaĆ§Ć£o de abordagens .................................................................... 45
6 Estudo de caso ā Logistics ............................................................. 51
6.1 AplicaĆ§Ć£o monolĆtica ā āAs isā .............................................................. 51 6.1.1 Arquitetura .............................................................................. 51 6.1.2 Componentes ........................................................................... 53 6.1.3 ImplantaĆ§Ć£o ............................................................................. 55
6.2 Arquitetura baseada em microsserviƧos ā āTo beā ...................................... 56 6.2.1 Gateway e JHipster Registry ......................................................... 57 6.2.2 Base de dados para cada microsserviƧo ............................................. 57 6.2.3 Apache Kafka ........................................................................... 58 6.2.4 Bitbucket Pipelines .................................................................... 58 6.2.5 Docker ................................................................................... 59 6.2.6 Google Cloud Platform ................................................................ 59
7 AnĆ”lise e conceĆ§Ć£o ..................................................................... 61
7.1 Requisitos ..................................................................................... 61
7.2 RepresentaĆ§Ć£o do domĆnio .................................................................. 63 7.2.1 Gateway ................................................................................. 63
xi
7.2.2 MS1 ā Zones.............................................................................. 64 7.2.3 MS2 ā Product ........................................................................... 64 7.2.4 MS5 ā Numbering Series ............................................................... 65 7.2.5 MS6 ā Stock .............................................................................. 66 7.2.6 MS8 ā Reception ........................................................................ 66 7.2.7 MS10 ā Integrator ....................................................................... 67 7.2.8 MS14 ā Optimization ................................................................... 68 7.2.9 MS15 ā Intelligence ..................................................................... 68
7.3 Processos do armazĆ©m ...................................................................... 69 7.3.1 ReceĆ§Ć£o .................................................................................. 69 7.3.2 ArrumaĆ§Ć£o ............................................................................... 72 7.3.3 ExpediĆ§Ć£o ............................................................................... 74
7.4 Processos de sincronizaĆ§Ć£o ................................................................. 78
7.5 PadrƵes utilizados ............................................................................ 79
8 ImplantaĆ§Ć£o da nova soluĆ§Ć£o ........................................................ 81
8.1 Bitbucket Pipelines .......................................................................... 81
8.2 Kubernetes .................................................................................... 84 8.2.1 ImplantaĆ§Ć£o na Google ................................................................ 85 8.2.2 DigitalOcean ............................................................................ 88
9 AvaliaĆ§Ć£o ................................................................................. 91
9.1 MĆ©tricas ....................................................................................... 91 9.1.1 Desempenho e escalabilidade ........................................................ 91 9.1.2 Manutenibilidade, automatizaĆ§Ć£o e satisfaĆ§Ć£o .................................... 98
10 ConclusĆ£o ............................................................................... 105
10.1 Trabalho futuro .............................................................................. 106
A Anexos ................................................................................... 111
A.1 MicrosserviƧos ............................................................................... 111
A.2 Bitbucket Pipelines e Jira .................................................................. 114 A.2.1 Pipeline definido ...................................................................... 114 A.2.2 IntegraĆ§Ć£o Jira ........................................................................ 120
A.3 Ficheiro de configuraĆ§Ć£o do Kubernetes ................................................. 123
A.4 AvaliaĆ§Ć£o ..................................................................................... 126 A.4.1 Desempenho e escalabilidade ....................................................... 127 A.4.2 Manutenibilidade, automatizaĆ§Ć£o e satisfaĆ§Ć£o ................................... 129
Lista de Figuras
Figura 1 ā Service Registry Pattern, baseado em (Chris Richardson, 2018c) ............................. 13
Figura 2 ā āArquitetura geral do RabbitMQ simplificadaā (Pieter Humphrey, 2017) ................ 15
Figura 3 ā āArquitetura global Apache Kafkaā (Kafka Architecture, 2017) ................................ 16
Figura 4 ā Etapas do padrĆ£o Strangler Fig Application (Samir Behara, 2018) ........................... 28
Figura 5 ā RepresentaĆ§Ć£o do Novo Modelo de Desenvolvimento de Conceitos (Koen et al.,
2002) .......................................................................................................................................... 31
Figura 6 ā Diagrama de componentes utilizando JHipster Registry, baseado em (JHipster,
2017a) ........................................................................................................................................ 41
Figura 7 ā Diagrama de componentes utilizando Consul, baseado em (JHipster, 2017b) ......... 43
Figura 8 ā Diagrama de componentes utilizando WSO API Manager, baseado em (Skalena,
2018) .......................................................................................................................................... 44
Figura 9 ā Diagrama de componentes das aplicaƧƵes monolĆticas............................................ 52
Figura 10 ā Diagrama de componentes da aplicaĆ§Ć£o Logistics .................................................. 54
Figura 11 ā Diagrama de componentes da aplicaĆ§Ć£o Logistics Intelligence .............................. 55
Figura 12 ā Diagrama de implantaĆ§Ć£o da aplicaĆ§Ć£o monolĆtica ................................................ 56
Figura 13 ā Diagrama de componentes da soluĆ§Ć£o a implementar .......................................... 57
Figura 14 ā Ferramentas a utilizar na automatizaĆ§Ć£o do processo de implantaĆ§Ć£o ................. 58
Figura 15 ā Diagrama de casos de uso ....................................................................................... 62
Figura 16 ā MicrosserviƧos Logistics .......................................................................................... 63
Figura 17 ā RepresentaĆ§Ć£o do microsserviƧo Zones .................................................................. 64
Figura 18 ā RepresentaĆ§Ć£o do microsserviƧo Product ............................................................... 65
Figura 19 ā RepresentaĆ§Ć£o do microsserviƧo Numbering Series ............................................... 66
Figura 20 ā RepresentaĆ§Ć£o do microsserviƧo Stock ................................................................... 66
Figura 21 ā RepresentaĆ§Ć£o do microsserviƧo Reception ........................................................... 67
Figura 22 ā RepresentaĆ§Ć£o do microsserviƧo Integrator ........................................................... 67
Figura 23 ā RepresentaĆ§Ć£o do microsserviƧo Optimization....................................................... 68
Figura 24 ā RepresentaĆ§Ć£o do microsserviƧo Intelligence ......................................................... 68
Figura 25 ā Diagrama de sequĆŖncia de rececionamento de produtos ...................................... 70
Figura 26 ā Diagrama de sequĆŖncia de finalizaĆ§Ć£o da receĆ§Ć£o.................................................. 72
Figura 27 ā Diagrama de sequĆŖncia da arrumaĆ§Ć£o de um produto .......................................... 73
Figura 28 ā Diagrama de sequĆŖncia da aprovaĆ§Ć£o da encomenda ........................................... 75
Figura 29 ā Diagrama de sequĆŖncia da estimativa das encomendas ........................................ 77
Figura 30 ā Diagrama de sequĆŖncia da importaĆ§Ć£o de produtos .............................................. 78
Figura 31 ā Pipeline desenvolvido no Bitbucket Pipelines ......................................................... 82
Figura 32 ā Step de implantaĆ§Ć£o na DigitalOcean ..................................................................... 84
Figura 33 ā Diagrama de implantaĆ§Ć£o de alta granularidade .................................................... 85
Figura 34 ā Diagrama de implantaĆ§Ć£o na Google Cloud Platform ............................................. 87
Figura 35 ā Diagrama de implantaĆ§Ć£o na DigitalOcean ............................................................. 89
Figura 36 ā Tempo mĆ©dio de resposta na criaĆ§Ć£o de linhas de receĆ§Ć£o ................................... 93
Figura 37 ā Tempo de resposta mĆ©dio na finalizaĆ§Ć£o das receƧƵes .......................................... 93
xiv
Figura 38 ā DuraĆ§Ć£o do processo de finalizaĆ§Ć£o das receƧƵes .................................................. 94
Figura 39 ā Tempo de resposta mĆ©dio do processo de arrumaĆ§Ć£o ........................................... 95
Figura 40 ā DuraĆ§Ć£o mĆ©dia do processo de arrumaĆ§Ć£o ............................................................. 95
Figura 41 ā DuraĆ§Ć£o mĆ©dia do processo de expediĆ§Ć£o .............................................................. 96
Figura 42 ā RepresentaĆ§Ć£o do microsserviƧo Entities .............................................................. 111
Figura 43 ā RepresentaĆ§Ć£o do microsserviƧo Settings ............................................................. 112
Figura 44 ā RepresentaĆ§Ć£o do microsserviƧo Operation ......................................................... 112
Figura 45 ā RepresentaĆ§Ć£o do microsserviƧo NMVS ................................................................ 113
Figura 46 ā RepresentaĆ§Ć£o do microsserviƧo Stowage ............................................................ 113
Figura 47 ā RepresentaĆ§Ć£o do microsserviƧo Container .......................................................... 113
Figura 48 ā RepresentaĆ§Ć£o do microsserviƧo Shipping Order .................................................. 114
Figura 49 ā Steps executados conforme o branch ................................................................... 115
Figura 50 ā DefiniĆ§Ć£o dos steps de configuraĆ§Ć£o do ambiente ............................................... 115
Figura 51 ā DefiniĆ§Ć£o do step build .......................................................................................... 116
Figura 52 ā DefiniĆ§Ć£o do step Docker Hub ............................................................................... 117
Figura 53 ā Step de implantaĆ§Ć£o da imagem no Kubernetes ................................................... 118
Figura 54 ā Script de implantaĆ§Ć£o ............................................................................................ 119
Figura 55 ā Fluxo do ciclo de vida de um issue existente na empresa (imagem cedida pela
Flowinn) .................................................................................................................................... 120
Figura 56 ā Ambientes de implantaĆ§Ć£o definidos no Bitbucket ............................................... 121
Figura 57 ā InformaĆ§Ć£o detalhada do ambiente de testes DigitalOcean ................................ 122
Figura 58 ā Issue LWMS-15 representado Jira ......................................................................... 123
Figura 59 ā Detalhe das implantaƧƵes do issue LWMS-15 ....................................................... 123
Figura 60 ā ConfiguraĆ§Ć£o do deployment do microsserviƧo Zones .......................................... 124
Figura 61 ā ConfiguraĆ§Ć£o do container presente no pod ......................................................... 124
Figura 62 ā Ficheiro da implantaĆ§Ć£o da base de dados do microsserviƧo zones ..................... 126
Figura 63 ā QEF utilizado para avaliar a soluĆ§Ć£o desenvolvido ................................................ 130
Figura 64 ā QuestionĆ”rio apresentado e 1ĀŖ pergunta .............................................................. 131
Figura 65 ā 2ĀŖ pergunta do questionĆ”rio ................................................................................. 131
Figura 66 ā 3ĀŖ pergunta do questionĆ”rio ................................................................................. 131
Figura 67 ā 4ĀŖ pergunta do questionĆ”rio ................................................................................. 131
Figura 68 ā 5ĀŖ pergunta do questionĆ”rio ................................................................................. 131
Figura 69 ā 6ĀŖ pergunta do questionĆ”rio ................................................................................. 132
Figura 70 ā Respostas obtidas na 1Āŗ pergunta ......................................................................... 132
Figura 71 ā Respostas obtidas na 2Āŗ pergunta ......................................................................... 132
Figura 72 ā Respostas obtidas na 3Āŗ pergunta ......................................................................... 133
Figura 73 ā Respostas obtidas na 4Āŗ pergunta ......................................................................... 133
Figura 74 ā Respostas obtidas na 5Āŗ pergunta ......................................................................... 133
Figura 75 ā Respostas obtidas na 6Āŗ pergunta ......................................................................... 133
Lista de Tabelas
Tabela 1 ā ComparaĆ§Ć£o entre RabbitMQ e Apache Kafka ......................................................... 16
Tabela 2 ā ComparaĆ§Ć£o entre Jenkins e Bitbucket Pipelines ...................................................... 20
Tabela 3 ā Business Model Canvas ............................................................................................. 36
Tabela 4 ā ComparaĆ§Ć£o dos critĆ©rios elegidos ........................................................................... 46
Tabela 5 ā Soma das colunas da comparaĆ§Ć£o dos critĆ©rios ....................................................... 46
Tabela 6 ā Matriz normalizada ................................................................................................... 46
Tabela 7 ā Resultados do processo de sincronizaĆ§Ć£o das entidades ......................................... 97
Tabela 8 ā Resultados do processo de sincronizaĆ§Ć£o dos produtos .......................................... 97
Tabela 9 ā AvaliaĆ§Ć£o do fator documentaĆ§Ć£o ............................................................................ 98
Tabela 10 ā AvaliaĆ§Ć£o do fator monitorizaĆ§Ć£o ........................................................................... 99
Tabela 11 ā AvaliaĆ§Ć£o do fator processo de implantaĆ§Ć£o ........................................................ 100
Tabela 12 ā Objetivos e questƵes ............................................................................................ 101
Tabela 13 ā ClassificaĆ§Ć£o das respostas ................................................................................... 102
Tabela 14 ā AvaliaĆ§Ć£o do fator satisfaĆ§Ć£o da empresa ............................................................ 103
Tabela 15 ā VariĆ”veis utilizadas no step build .......................................................................... 116
Tabela 16 ā VariĆ”veis utilizadas no step Docker Hub ............................................................... 117
Tabela 17 ā VariĆ”veis utilizadas no step de implantaĆ§Ć£o ......................................................... 119
Tabela 18 ā DNS utilizado para cada comunicaĆ§Ć£o .................................................................. 125
Tabela 19 ā CriaĆ§Ć£o das linhas de receĆ§Ć£o na aplicaĆ§Ć£o monolĆtica ........................................ 127
Tabela 20 ā CriaĆ§Ć£o das linhas de receĆ§Ć£o na aplicaĆ§Ć£o baseada em microsserviƧos ............. 127
Tabela 21 ā Processo de expediĆ§Ć£o na aplicaĆ§Ć£o monolĆtica ................................................... 128
Tabela 22 ā Processo de expediĆ§Ć£o na aplicaĆ§Ć£o baseada em microsserviƧos ....................... 129
AcrĆ³nimos e SĆmbolos
Lista de AcrĆ³nimos
CD Continuous Deployment
SPR Single Principle Responsibility
CQRS Command Query Responsibility Segregation
MB Message Broker
AMQP Advanced Message Queuing Protocol
CI Continuous Integration
UI User Interface
IaaS Infrastructure as a Service
PaaS Platform as a Service
SaaS Software as a Service
AHP Analytic Hierarchy Process
CTO Chief Technology Officer
DNS Domain Name System
HTTP Hypertext Transfer Protocol
API Application Programming Interface
ERP Enterprise Resource Planning
HTML HyperText Markup Language
REST Representational State Transfer
SSH Secure Shell
TCP Transmission Control Protocol
JDBC Java Database Connectivity
GB Gigabyte
QEF Quality evaluation framework
1
1 IntroduĆ§Ć£o
1.1 Contexto
Este trabalho, resulta da necessidade de melhorar o desempenho de uma aplicaĆ§Ć£o
denominada de Logistics, desenvolvida e comercializada pela empresa Flowinn que
atua no mercado de Tecnologias de InformaĆ§Ć£o para a GestĆ£o. Esta empresa dedica-se
ao desenvolvimento de aplicaƧƵes de gestĆ£o com o intuito de otimizar os processos
diĆ”rios, de alguns tipos de indĆŗstrias, maioritariamente do ramo farmacĆŖutico, mas
tambĆ©m na indĆŗstria alimentar, metalomecĆ¢nica pesada e de madeiras.
A referida aplicaĆ§Ć£o, surgiu com o intuito de promover uma melhoria no funcionamento
interno dos armazĆ©ns de distribuiĆ§Ć£o da indĆŗstria farmacĆŖutica, aumentando assim a
sua eficiĆŖncia. Os armazĆ©ns sĆ£o espaƧos idealizados para armazenar produtos em
grande quantidade, sendo necessƔrio utilizar uma estrutura coerente e organizada
permitindo, rececionar, manobrar e expedir os mais diversos tipos de produtos com um
controlo moderado das condiƧƵes ambientais e de seguranƧa.
A gestĆ£o de armazĆ©ns inclui um conjunto de atividades a jusante e a montante,
nomeadamente a receĆ§Ć£o e o armazenamento de produtos de acordo com as
necessidades, a recolha de produtos de acordo com as encomendas dos clientes e a
preparaĆ§Ć£o dos mesmos para expediĆ§Ć£o. Para qualquer tipo de indĆŗstria, o processo de
gestĆ£o de armazĆ©ns tem como principais objetivos, a reduĆ§Ć£o de espaƧo ocupado e de
tempo despendido, uma vez que agrega um conjunto de operaƧƵes que, na cadeia de
fornecimento (Supply Chain) do produto, nĆ£o acrescentam valor. AlĆ©m disso, em
particular na indĆŗstria farmacĆŖutica, Ć© necessĆ”rio dar uma rĆ”pida resposta aos pedidos
efetuados, pelo que o fator tempo adquire uma elevada importĆ¢ncia.
2
1.2 Problema
Atualmente, a aplicaĆ§Ć£o Logistics apresenta uma arquitetura monolĆtica, implementada
atravƩs da framework JHipster, utilizando Spring como back-end e Angular 8 como
front-end.
Com o objetivo de otimizar as tarefas essenciais no armazƩm dos clientes, Ʃ fulcral obter
uma rĆ”pida resposta aos pedidos efetuados, permitindo a sua satisfaĆ§Ć£o atempada, por
isso os clientes desta aplicaĆ§Ć£o (maioritariamente da indĆŗstria farmacĆŖutica), tĆŖm
solicitado algumas funcionalidades, pelo que a aplicaĆ§Ć£o tem sofrido algumas
atualizaƧƵes ao longo do tempo. As referidas atualizaƧƵes foram sendo sucessivamente
realizadas na aplicaĆ§Ć£o existente, provocando, atualmente, inĆŗmeros problemas tais
como, manutenibilidade do cĆ³digo fonte, difĆcil implementaĆ§Ć£o de novas
funcionalidades, quebra de funcionalidades jĆ” implementadas aquando nova
implementaĆ§Ć£o e grande dimensĆ£o da aplicaĆ§Ć£o tornando as builds extensas, sendo
estas, por vezes, simples correƧƵes de uma Ćŗnica tarefa.
AlĆ©m das questƵes referidas, a aplicaĆ§Ć£o Logistics nĆ£o implementa testes, sendo
obrigatĆ³ria a execuĆ§Ć£o de testes manuais, por isso mais falĆveis, podendo nĆ£o detetar
falhas tanto nas novas funcionalidades como nas previamente implementadas.
Ć de salientar que o processo de disponibilizaĆ§Ć£o das novas funcionalidades para cada
um dos clientes Ć© executado manualmente. Este, Ć© suscetĆvel a falhas de configuraĆ§Ć£o
ou erros humanos, que por sua vez podem paralisar o ambiente de produĆ§Ć£o,
resultando em prejuĆzo para os clientes.
Assim pode considerar-se que existem basicamente quatro grandes problemas a
resolver:
ā¢ Elevado tempo de resposta;
ā¢ Algum descontrolo nas atualizaƧƵes;
ā¢ RealizaĆ§Ć£o de testes manualmente;
ā¢ Processo de implantaĆ§Ć£o de forma manual.
1.3 Objetivos
3
Com base no problema descrito anteriormente, observa-se de forma imediata quatro
objetivos:
ā¢ ReduĆ§Ć£o do tempo de resposta;
ā¢ Controlo de atualizaƧƵes;
ā¢ RealizaĆ§Ć£o de testes de forma automĆ”tica;
ā¢ DisponibilizaĆ§Ć£o automĆ”tica das novas funcionalidades desenvolvidas.
Com vista Ć concretizaĆ§Ć£o dos objetivos acima descritos, o trabalho a desenvolver nesta
dissertaĆ§Ć£o deverĆ” implementar uma arquitetura que permita responder aos
problemas referidos, melhorando o desempenho e escalabilidade da aplicaĆ§Ć£o,
relativamente Ć arquitetura monolĆtica atual. Assim, torna-se necessĆ”rio efetuar uma
anƔlise dos requisitos pretendidos para se prosseguir com a escolha cuidada das
tecnologias a utilizar.
Ao contrĆ”rio do produto existente na empresa, pretende-se que, esta nova versĆ£o,
implemente testes automatizados para as diversas funcionalidades, de modo a facilitar
implementaƧƵes futuras e aumentar a fiabilidade do cĆ³digo fonte.
Posteriormente Ć s implementaƧƵes efetuadas, Ć© expectĆ”vel a automatizaĆ§Ć£o do
processo de implantaĆ§Ć£o dos serviƧos nos respetivos clientes, aplicando o conceito de
CD (Continuous Deployment), eliminando-se, assim, os possĆveis erros causados pelos
processos manuais, tornando o processo de implantaĆ§Ć£o repetĆvel e confiĆ”vel (Jez
Humble & David Farley, 2010).
Atualmente, a empresa Flowinn, disponibiliza um serviƧo de autenticaĆ§Ć£o, que visa
eliminar a necessidade dos clientes que possuem vƔrios produtos fazerem login em
cada um dos mesmos. Este serviƧo permite usufruir de uma sessĆ£o transversal aos
produtos, uma vez que esta Ć© armazenada no servidor de autenticaĆ§Ć£o.
Assim, pretende-se que a aplicaĆ§Ć£o a desenvolver, comunique com o serviƧo de
autenticaĆ§Ć£o referido.
1.4 Resultados esperados
Ć expectĆ”vel implementar uma soluĆ§Ć£o arquiteturalmente mais moderna, baseada em
microsserviƧos, que cumpra os objetivos acima descritos e que visa solucionar os
problemas atuais da empresa Flowinn. A soluĆ§Ć£o desenvolvida, deverĆ” prosseguir na
4
empresa e a sua implantaĆ§Ć£o nos clientes deverĆ” ser automĆ”tica e independente para
cada microsserviƧo. Com isto, Ć© de esperar que os problemas como, difĆcil manutenĆ§Ć£o
e implementaĆ§Ć£o de novas funcionalidades, erros manuais e falhas na detenĆ§Ć£o de
funcionalidades incorretamente implementadas, sejam reduzidos ou se possĆvel
eliminados.
1.5 HipĆ³tese de investigaĆ§Ć£o
No caso em apreƧo, serĆ” que a transformaĆ§Ć£o da aplicaĆ§Ć£o, que atualmente assenta
numa arquitetura monolĆtica, para uma arquitetura baseada em microsserviƧos, trarĆ”
vantagens no que respeita aos problemas identificados e objetivos a atingir acima
descritos?? SerĆ” que se obterĆ£o os resultados esperados referidos na seĆ§Ć£o anterior?
A resposta poderĆ” surgir a partir da transformaĆ§Ć£o da aplicaĆ§Ć£o de uma arquitetura
monolĆtica, para uma arquitetura baseada em microsserviƧos, e posterior avaliaĆ§Ć£o.
AvaliaĆ§Ć£o esta relativa os benefĆcios da soluĆ§Ć£o para a empresa Flowinn,
nomeadamente ao nĆvel do desempenho e manutenĆ§Ć£o da soluĆ§Ć£o. Esta avaliaĆ§Ć£o serĆ”
efetuada atravĆ©s da comparaĆ§Ć£o da soluĆ§Ć£o atual e da soluĆ§Ć£o desenvolvida apĆ³s a
conclusĆ£o deste trabalho.
Por fim, pode tambĆ©m avaliar-se os benefĆcios de implantaĆ§Ć£o contĆnua no quotidiano
da soluĆ§Ć£o e o seu impacto no desenvolvimento.
5
2 Contexto teĆ³rico
Neste capĆtulo encontram-se descritas de forma sucinta as definiƧƵes das arquiteturas
monolĆtica e de microsserviƧos, indicando vantagens e desvantagens de cada uma delas,
e ainda padrƵes a utilizar para se prosseguir com a transformaĆ§Ć£o da primeira na
segunda.
2.1 Arquiteturas monolĆticas
Nesta secĆ§Ć£o, apresenta-se o conceito de arquitetura monolĆtica, descrevendo as suas
vantagens e desvantagens. Uma grande parte dos sistemas utilizados por muitas
organizaƧƵes, tĆŖm por base uma arquitetura monolĆtica, formadas por vĆ”rios mĆ³dulos que sĆ£o
compilados separadamente e depois ligados, formando assim um grande sistema onde os
mĆ³dulos podem interagir. Por vezes estes sistemas sĆ£o bastante complexos. Hipoteticamente
numa situaĆ§Ć£o estĆ”tica, tal configuraĆ§Ć£o nĆ£o acarreta problemas, no entanto, pensando um
modo evolutivo, a complexidade atinge um nĆvel significativo, tornando-se uma tarefa muito
difĆcil para os diferentes programadores destas aplicaƧƵes, devido Ć complexidade e tamanho
de cĆ³digo existente em cada um destes sistemas.
As arquiteturas monolĆticas sĆ£o compostas apenas por um segmento, onde se
encontram presente todos os mĆ³dulos necessĆ”rios para o funcionamento da aplicaĆ§Ć£o
de software. Estes mĆ³dulos sĆ£o executados todos na mesma mĆ”quina, partilhando
recursos de processamento e memĆ³ria (Chris Richardson, 2018c).
Este segmento, geralmente apresenta uma grande dimensĆ£o, visto que
tradicionalmente sĆ£o constituĆdas pelas seguintes camadas (Daniel Viana, 2017):
ā¢ Client side ou front-end: primeira camada visĆvel para o utilizador quando acede
Ć aplicaĆ§Ć£o. Esta contĆ©m componentes relacionados com a interface do
utilizador, design, usabilidade e interaĆ§Ć£o com o mesmo;
6
ā¢ Server side ou back-end: conjunto de camadas responsĆ”veis por implementar as
funcionalidades da aplicaĆ§Ć£o, aceder a camadas de persistĆŖncia de dados, entre
outros.
Este tipo de arquitetura Ʃ das mais antigas e projeta aplicaƧƵes sem modularidade
externa, ou seja, nĆ£o visam ser mĆ³dulos de outras aplicaƧƵes.
As vantagens e desvantagens (Chris Richardson, 2018c) desta arquitetura sĆ£o as a seguir
apresentadas.
Vantagens:
ā¢ FĆ”cil desenvolvimento;
ā¢ Pode sofrer, facilmente, alteraƧƵes radicais tanto a nĆvel de cĆ³digo, como a nĆvel
de base de dados;
ā¢ FĆ”cil de implantar;
ā¢ FĆ”cil implementaĆ§Ć£o de testes de ponta-a-ponta (end-to-end);
ā¢ FĆ”cil de escalar horizontalmente o monĆ³lito.
Desvantagens:
ā¢ Manutenibilidade do cĆ³digo-fonte;
ā¢ Alta dependĆŖncia dos componentes do cĆ³digo;
ā¢ Elevado tamanho da aplicaĆ§Ć£o, em casos mais complexos, prejudica o processo
de CD;
ā¢ Necessidade de implantar toda a aplicaĆ§Ć£o quando existem novas alteraƧƵes;
ā¢ Escalabilidade limitada, pois exige que todo o sistema seja replicado;
ā¢ Confiabilidade reduzida, dado que uma falha em um dos mĆ³dulos, poderĆ” levar
Ć falha de todo o sistema;
ā¢ AusĆŖncia de flexibilidade, visto que exige o compromisso com a tecnologia
escolhida inicialmente para a aplicaĆ§Ć£o.
Nos Ćŗltimos anos tem-se vindo a adotar uma abordagem de implementaĆ§Ć£o de
arquiteturas baseada em microsserviƧos, que surgiu como um padrĆ£o comum de
7
desenvolvimento de software a partir das melhores prƔticas de uma sƩrie de
organizaƧƵes lĆderes e o seu esforƧo na construĆ§Ć£o de aplicaƧƵes de grandes dimensƵes
e continuamente evolutivas, capazes de reagir rapidamente aos requisitos de software
sempre em mudanƧa (Cesar de la Torre et al., 2017).
2.2 Arquiteturas baseadas em microsserviƧos
As arquiteturas baseadas em microsserviƧos, contrariamente Ć s arquiteturas
monolĆticas, utilizam uma abordagem Ć modularizaĆ§Ć£o de software, consistem num
conjunto de aplicaƧƵes constituĆdas por uma coleĆ§Ć£o de serviƧos, designados de
microsserviƧos. Estes representam unidades que adotam o padrĆ£o SPR (Single Principle
Responsibility), serviƧos que devem ter responsabilidade de apenas uma parte da
aplicaĆ§Ć£o, tornando assim cada unidade menos acoplada (Fanis Despoudis, 2017). Este
desacoplamento permite que cada serviƧo possa ser desenvolvido por equipas
diferentes, implementado e mantido de forma independente. A comunicaĆ§Ć£o destes
serviƧos Ćnfimos, permite resolver problemas de negĆ³cios complexos, no entanto
apresentam algumas vantagens e desvantagens que devem ser consideradas antes da
sua implantaĆ§Ć£o (Chris Richardson, 2018c).
Algumas vantagens:
ā¢ Maior desacoplamento;
ā¢ Em caso de falha de um microsserviƧo, nĆ£o hĆ” comprometimento da integridade
total da aplicaĆ§Ć£o;
ā¢ Permite experimentaĆ§Ć£o e a utilizaĆ§Ć£o de diferentes tecnologias;
ā¢ Facilita o processo de CD de aplicaƧƵes grandes e complexas, atravĆ©s da
implantaĆ§Ć£o dos diversos serviƧos;
ā¢ ConstituĆdo por pequenas porƧƵes de cĆ³digo em cada serviƧo, facilitando a sua
manutenĆ§Ć£o ao longo do ciclo de vida;
ā¢ ExistĆŖncia de unidades independentes, permitindo assim, desenvolvimento,
implantaĆ§Ć£o e escalabilidade diferente entre si, inclusive estes processos podem
ser efetuados por equipas distintas e independentes.
Desvantagens:
ā¢ A definiĆ§Ć£o correta dos serviƧos Ć© um processo complexo;
8
ā¢ ImplementaĆ§Ć£o de funcionalidades que necessitam de vĆ”rios microsserviƧos,
podem exigir coordenaĆ§Ć£o entre equipas;
ā¢ Maior dificuldade de implementaĆ§Ć£o de testes de integraĆ§Ć£o;
ā¢ Processo de implantaĆ§Ć£o exige a coordenaĆ§Ć£o de um elevado nĆŗmero de
serviƧos a implantar;
ā¢ Ć necessĆ”rio um tratamento especial por parte dos programadores nos
processos de falhas.
Atualmente, existem diversos padrƵes que visam solucionar problemas comuns em
arquiteturas distribuĆdas baseadas em microsserviƧos, tais como, distribuiĆ§Ć£o da base
de dados e consistĆŖncia da informaĆ§Ć£o, descoberta e comunicaĆ§Ć£o dos microsserviƧos,
entre outros. Ao longo deste capĆtulo serĆ£o apresentados padrƵes e algumas boas
prĆ”ticas a ter em conta para a implementaĆ§Ć£o deste tipo de arquiteturas.
2.3 Domain-driven design
O padrĆ£o DDD (Domain-driven design), segundo (Evans, 2003) consiste no alinhamento
entre a implementaĆ§Ć£o da soluĆ§Ć£o tecnolĆ³gica e os conceitos de negĆ³cio o que facilita
a implementaĆ§Ć£o de soluƧƵes presentes em domĆnios complexos.
A utilizaĆ§Ć£o deste padrĆ£o exige a perceĆ§Ć£o do domĆnio de negĆ³cio, de modo a que este
seja refletido na implementaĆ§Ć£o e estruturaĆ§Ć£o do cĆ³digo implementado.
Este padrĆ£o apresenta vantagens que poderĆ£o beneficiar o desenvolvimento deste
projeto, nomeadamente, facilita a comunicaĆ§Ć£o entre os programadores e os analistas
e permite definir os contextos do domĆnio e as suas caracterĆsticas. Esta definiĆ§Ć£o por
sua vez, auxilia a implementaĆ§Ć£o de serviƧos desacoplados o que permite a sua
reutilizaĆ§Ć£o ao longo da soluĆ§Ć£o.
2.4 Base de dados em microsserviƧos
A migraĆ§Ć£o de uma arquitetura monolĆtica para uma arquitetura baseada em
microsserviƧos, exige a seleĆ§Ć£o do padrĆ£o a utilizar relativamente Ć base de dados da
nova soluĆ§Ć£o.
Nas secƧƵes seguintes apresentam-se dois padrƵes distintos, base de dados partilhada
e base de dados por microsserviƧo.
9
2.4.1 Base de dados partilhada
Este conceito consiste na utilizaĆ§Ć£o de uma base de dados partilhada entre vĆ”rios
microsserviƧos (Chris Richardson, 2018b). Assim, quando um microsserviƧo necessita
de informaĆ§Ć£o acede Ć base de dados, evitando comunicaƧƵes com outros
microsserviƧos. A implementaĆ§Ć£o deste padrĆ£o Ć© simples e as transaƧƵes locais sĆ£o
efetuadas de forma atĆ³mica e consistente. No entanto, a utilizaĆ§Ć£o deste padrĆ£o
apresenta inĆŗmeras desvantagens (Chris Richardson, 2018b), tais como:
ā¢ Alto acoplamento no desenvolvimento e execuĆ§Ć£o: Necessidade de
coordenaĆ§Ć£o das alteraƧƵes, caso existam programadores a trabalhar em
diferentes serviƧos que tenham acesso Ć mesma tabela;
ā¢ Quantidade de pedidos por parte de todos os microsserviƧos pode causar
sobrecarga e falhas na base de dados Ćŗnica.
2.4.2 Base de dados para cada microsserviƧo
De modo a colmatar as desvantagens do padrĆ£o descrito na secĆ§Ć£o anterior, surge o
padrĆ£o database per service (Chris Richardson, 2018a), este consiste na utilizaĆ§Ć£o de
uma base de dados distinta para cada microsserviƧo.
Com a utilizaĆ§Ć£o deste padrĆ£o, cada microsserviƧo Ć© responsĆ”vel pelos seus dados,
impossibilitando a alteraĆ§Ć£o externa dos mesmos. Os microsserviƧos tornam-se menos
acoplados garantindo-se que alteraƧƵes Ć base de dados de um microsserviƧo, nĆ£o
afetem as restantes. Dado que cada base de dados Ć© independe, a seleĆ§Ć£o da tecnologia
a utilizar torna-se independente tambƩm, possibilitando o uso de diferentes
tecnologias no armazenamento de dados conforme a necessidade do microsserviƧo.
Contudo, este padrĆ£o apresenta algumas desvantagens (Chris Richardson, 2018a), que
devem ser consideradas:
ā¢ Quando Ć© pedida informaĆ§Ć£o que necessita dos dados presentes em
microsserviƧos distintos, Ʃ necessƔria a consulta de ambos;
ā¢ TransaƧƵes que interajam com diversos microsserviƧos necessitam de ser
controladas, com o intuito de manter coerente a informaĆ§Ć£o de todas as bases
de dados.
2.5 PadrĆ£o Saga
10
No cenĆ”rio da existĆŖncia de uma base de dados distinta para cada microsserviƧo, Ć©
necessĆ”rio manter a sua coerĆŖncia e assegurar as validaƧƵes do pedido efetuado. Para
controlar estas situaƧƵes deve ser utilizado o padrĆ£o Saga (Umesh Ram Sharma, 2017).
Este padrĆ£o, consiste āna sequĆŖncia de transaƧƵes locais. Cada microsserviƧo atualiza a
sua base de dados e publica um evento para ativar a prĆ³xima transaĆ§Ć£oā. No caso de a
transaĆ§Ć£o falhar, a Saga executa transaƧƵes de modo a reverter as alteraƧƵes
anteriormente efetuadas. Este processo aumenta a complexidade do cĆ³digo
implementado (Umesh Ram Sharma, 2017).
2.6 PadrĆ£o CQRS
O padrĆ£o CQRS (Command Query Responsibility Segregation), consiste na separaĆ§Ć£o
dos conceitos de leitura e escrita da base de dados. Estes conceitos apresentam
diferentes responsabilidades, sendo o primeiro responsƔvel por consultar e apresentar
os dados pedidos, acedendo Ć base de dados em modo leitura e o segundo Ć©
responsƔvel pela escrita dos dados (Dominic Betts et al., 2013; Edson Yanaga, 2017).
Este padrĆ£o permite a utilizaĆ§Ć£o da mesma ou diferentes bases de dados, podendo
estas armazenar diferentes esquemas de dados. Assim, Ć© possĆvel tirar partido das
seguintes vantagens (Dominic Betts et al., 2013):
ā¢ SeparaĆ§Ć£o dos conceitos aperfeiƧoada;
ā¢ Escalabilidade independente: Permite escalar de forma independente os
componentes de leitura e escrita;
ā¢ Permite a consulta de dados em implementaƧƵes de event sourcing.
No entanto, este padrĆ£o apresenta tambĆ©m algumas desvantagens (Dominic Betts et
al., 2013):
ā¢ Aumento da complexidade do sistema: Necessidade de desenvolver um
mecanismo de sincronizaĆ§Ć£o quando existem vĆ”rias bases de dados;
ā¢ PossĆveis inconsistĆŖncias dos dados: Os utilizadores podem aceder a dados que
ainda nĆ£o foram atualizados.
2.7 Event sourcing
11
Segundo Chris Richardson (Dominic Betts et al., 2013), o padrĆ£o Event sourcing, consiste
no armazenamento de uma sequĆŖncia de eventos, sendo que, cada evento representa
uma alteraĆ§Ć£o do estado da entidade. AtravĆ©s do histĆ³rico de eventos, Ć© possĆvel obter
os diversos estados e reconstituir o percurso atƩ ao estado atual da entidade.
Algumas vantagens deste padrĆ£o sĆ£o:
ā¢ PreservaĆ§Ć£o do histĆ³rico de eventos, facilitando a identificaĆ§Ć£o em caso de
falhas ou comportamentos indesejados do sistema;
ā¢ Possibilidade de verificar o estado de uma entidade em qualquer momento
(Dominic Betts et al., 2013; Martin Fowler, 2005).
Tal como os anteriores tambĆ©m este padrĆ£o apresenta algumas desvantagens (Dominic
Betts et al., 2013; Martin Fowler, 2005) como:
ā¢ Necessidade de aprendizagem de implementaĆ§Ć£o do padrĆ£o;
ā¢ Aumento a complexidade do sistema.
2.8 API Management
O API Management, Ć© uma plataforma centralizada de gestĆ£o das API constituintes de
um produto. O objetivo desta plataforma Ć© ācriar, analisar e gerir os API num ambiente
seguro e escalĆ”velā (Brajesh De, 2017).
Esta plataforma deve integrar as seguintes funcionalidades (Brajesh De, 2017):
ā¢ API Gateway: Ponto de entrada do produto, que serĆ” explicado no subcapĆtulo
seguinte;
ā¢ MonitorizaĆ§Ć£o das API: Apresenta a informaĆ§Ć£o do fluxo de acesso, as datas, os
consumidores, o sucesso ou insucesso das respostas e o desempenho de cada
API;
ā¢ RestriĆ§Ć£o das API: A utilizaĆ§Ć£o de uma API pode ser configurada, permitindo
aplicar a determinados consumidores, limites ou polĆticas de uso;
ā¢ Portal dos desenvolvedores: Este portal permite a gestĆ£o das API existentes. A
documentaĆ§Ć£o de cada API deverĆ” ser desenvolvida e guardada neste portal,
juntamente com a prĆ³pria;
12
ā¢ AutenticaĆ§Ć£o e seguranƧa das API;
ā¢ GestĆ£o do ciclo de vida da API.
2.9 API Gateway
O padrĆ£o API Gateway Ć© considerado o ponto de entrada para os clientes. Estes
efetuam os seus pedidos para o Gateway que, por sua vez, reencaminha os pedidos
para o(s) respetivo(s) microsserviƧo(s) reforƧando aspetos de seguranƧa, taxas de uso,
validaĆ§Ć£o e transformaĆ§Ć£o da informaĆ§Ć£o (Brajesh De, 2017).
A utilizaĆ§Ć£o deste padrĆ£o permite isolar os microsserviƧos implementados dos clientes,
assim estes nĆ£o necessitam de saber a localizaĆ§Ć£o de cada microsserviƧo, apenas a
localizaĆ§Ć£o do API Gateway, o que contribui para a simplificaĆ§Ć£o do cĆ³digo
desenvolvido em cada cliente.
As desvantagens deste padrĆ£o, passam pelo aumento da complexidade e necessidade
de adicionar o componente Ć soluĆ§Ć£o. Este componente exige desenvolvimento,
implantaĆ§Ć£o e alta disponibilidade, para que possa receber sempre os pedidos dos
clientes. Por fim, o tempo de resposta pode aumentar, uma vez que Ć© adicionado um
componente extra (Umesh Ram Sharma, 2017).
2.10 Descoberta de serviƧos (Service discovery)
āEm aplicaƧƵes monolĆticas implantadas em mĆ”quinas fĆsicas, para efetuar o pedido de
uma funcionalidade, nĆ£o existe necessidade de descobrir a localizaĆ§Ć£o do serviƧo, uma
vez que a sua localizaĆ§Ć£o maioritariamente Ć© estĆ”ticaā (Chris Richardson, 2018c). Este
cenƔrio difere em arquiteturas implantadas na nuvem.
āAs instĆ¢ncias dos microsserviƧos sĆ£o atribuĆdas dinamicamente em localizaƧƵes da
nuvemā. Assim, surge a ānecessidade de descobrir a localizaĆ§Ć£o dos serviƧosā (Chris
Richardson, 2018c). Com esta necessidade, surgiu o padrĆ£o Service registry (Chris
Richardson, 2016b), que consiste na implementaĆ§Ć£o de um componente, Service
registry, responsĆ”vel por armazenar a instĆ¢ncia do serviƧo e a sua localizaĆ§Ć£o. Este
padrĆ£o relaciona-se com o padrĆ£o Self Registration, uma vez que, segundo (Chris
Richardson, 2016a), as instĆ¢ncias de microsserviƧos devem ser registadas ou removidas
do componente nas seguintes circunstĆ¢ncias:
ā¢ Quando inicializa deve registar-se;
13
ā¢ Quando termina, devido a um erro ou voluntariamente, deve ser eliminada;
ā¢ Deve renovar o seu registo periodicamente.
AtravƩs dos dois padrƵes acima descritos, quando Ʃ efetuado o pedido de uma
funcionalidade, ādeverĆ” ser consultado o componente, Service Registry, com o intuito
de obter a lista de instĆ¢ncias e as respetivas localizaƧƵes das mesmasā, como ilustrado
na Figura 1.
Figura 1 ā Service Registry Pattern, baseado em (Chris Richardson, 2018c)
2.11 ComunicaĆ§Ć£o sĆncrona entre microsserviƧos
A comunicaĆ§Ć£o nos microsserviƧos pode ser efetuada de forma sĆncrona, constituĆda
por um remetente e um destinatĆ”rio. O remetente efetua o pedido e fica bloqueado Ć
espera do momento em que o destinatƔrio lhe responde.
A comunicaĆ§Ć£o sĆncrona, pode ser facilmente implementada permitindo respostas em
tempo real, em contrapartida esta exige conhecer a localizaĆ§Ć£o do microsserviƧo
destinatĆ”rio, sendo que, este tem obrigatoriamente, de estar disponĆvel no momento
da comunicaĆ§Ć£o, caso contrĆ”rio esta nĆ£o resultarĆ”. Este tipo de comunicaĆ§Ć£o oferece
uma baixa disponibilidade, sendo difĆcil garantir que a funcionalidade pretendida Ć©
executada pelo sistema. Em comparaĆ§Ć£o com a comunicaĆ§Ć£o assĆncrona, esta
apresenta maior acoplamento ao longo do tempo. Considerando a necessidade de
conhecimento do contrato do microsserviƧo destinatƔrio, uma mudanƧa deste contrato
obriga o remetente a adaptar-se.
2.12 ComunicaĆ§Ć£o assĆncrona entre microsserviƧos
14
A comunicaĆ§Ć£o assĆncrona surgiu com o intuito de solucionar problemas existentes da
comunicaĆ§Ć£o sĆncrona, estes eram encontrados com elevada frequĆŖncia em
arquiteturas baseadas em microsserviƧos.
A utilizaĆ§Ć£o de um MB (Message Broker), permite solucionar os problemas acima
descritos atravĆ©s da utilizaĆ§Ć£o de mensagens, proporcionando comunicaĆ§Ć£o assĆncrona
entre microsserviƧos. AtravĆ©s do MB, o microsserviƧo remetente nĆ£o necessita de saber
a localizaĆ§Ć£o do destinatĆ”rio e, de modo a realizar a comunicaĆ§Ć£o, escreve a mensagem
no MB e este entrega a mensagem ao(s) destinatƔrio(s), eliminado o acoplamento entre
microsserviƧos (Chris Richardson, 2018c).
A comunicaĆ§Ć£o assĆncrona entre microsserviƧos apresenta algumas vantagens e
desvantagens (Chris Richardson, 2018c).
Vantagens:
ā¢ Nenhum acoplamento entre microsserviƧos (acima descrito);
ā¢ Maior confiabilidade: contrariamente Ć comunicaĆ§Ć£o sĆncrona, o destinatĆ”rio
pode estar indisponĆvel quando o recetor escreve a mensagem, esta serĆ”
armazenada numa fila de mensagens atƩ que o destinatƔrio a possa processar;
ā¢ Aumento do desempenho dos microsserviƧos: apĆ³s o envio da mensagem para
a fila do MB, o microsserviƧo continuarĆ” disponĆvel para responder aos pedidos
efetuados, contrariamente ao que acontece quando comunica sincronamente,
uma vez que fica temporariamente indisponĆvel, Ć espera da resposta.
Desvantagens:
ā¢ PossĆvel problema de desempenho: O MB deve apresentar um bom
desempenho para possibilitar e acompanhar o crescimento do sistema;
ā¢ PossĆvel ponto Ćŗnico de falha: em caso de falha do MB, a confiabilidade do
sistema Ć© afetada;
ā¢ Complexidade adicionada: āO MB Ć© um componente que deve ser instalado e
configuradoā.
2.12.1 RabbitMQ
15
O RabbitMQ āĆ© uma ferramenta leve e poderosaā, que permite a comunicaĆ§Ć£o atravĆ©s
de mensagens. Este Ć© um MB open-source, desenvolvido em 2007, que por defeito usa
o AMQP (Advanced Message Queuing Protocol) (Roy, 2017), porƩm suporta outros.
Este MB ādestaca-se devido a sua facilidade de implementaĆ§Ć£o, flexibilidade,
disponibilidade de ferramentas complementares e API simples e intuitivaā (Vinicius
Feitosa Pacheco, 2018).
Figura 2 ā āArquitetura geral do RabbitMQ simplificadaā (Pieter Humphrey, 2017)
AtravƩs da anƔlise do diagrama da Figura 2, podem identificar-se os seguintes
componentes:
ā¢ Producers (Produtores): componente que publica mensagens no RabbitMQ;
ā¢ Exchanges (Trocas): componente responsĆ”vel por āreceber as mensagens dos
produtores e atribuĆ-las Ć s respetivas filas, dependendo das regras definidasā;
ā¢ Queues (Filas): componente que armazena as mensagens atĆ© que os
consumidores as recebam;
ā¢ Consumers (Consumidores): componente que recebe mensagens.
2.12.2 Apache Kafka
O Apache Kafka surgiu em 2011, ācom o intuito de escapar Ć s limitaƧƵes dos MB
tradicionaisā (Jakub Korab, 2017). Foi desenhado para suportar um elevado fluxo de
mensagens, sendo considerado por (Vinicius Feitosa Pacheco, 2018), o MB ācom melhor
desempenho e o mais escalĆ”vel para a entrega de mensagensā.
16
Figura 3 ā āArquitetura global Apache Kafkaā (Kafka Architecture, 2017)
Contrariamente ao RabbitMQ, nĆ£o funciona sem o servidor ZooKeeper, representado
na Figura 3.
O ZooKeeper Ʃ um serviƧo open-source, desenvolvido pela Apache Software Foundation,
que disponibiliza funcionalidades importantes para aplicaƧƵes distribuĆdas, tais como,
eleiĆ§Ć£o de um lĆder, armazenamento de objetos atravĆ©s de uma chave Ćŗnica e
coordenaĆ§Ć£o de processos (Stephane Maarek, 2019).
Neste contexto, o ZooKeeper tem a responsabilidade de administrar o MB Apache Kafka,
guardar os produtores e consumidores.
2.12.3 ComparaĆ§Ć£o entre RabbitMQ e Apache Kafka
Na Tabela 1 pode observar-se uma comparaĆ§Ć£o entre o MB RabbitMQ e o MB Apache
Kafka relativamente a algumas caracterĆsticas (Jakub Korab, 2017; Vinicius Feitosa
Pacheco, 2018; What Is Apache Kafka?, 2019).
Tabela 1 ā ComparaĆ§Ć£o entre RabbitMQ e Apache Kafka
CaracterĆsticas
RabbitMQ Apache Kafka
Open-Source Sim Sim
17
Escalabilidade Elevada, contudo, inferior ao Apache Kafka, āVinte mil mensagens por segundoā
Elevada, ādevido Ć partiĆ§Ć£o de tĆ³picos, permitindo assim, leitura paralela do tĆ³picoā. Pode facilmente ser distribuĆdo devido Ć s suas partiƧƵes. āCem mil mensagens por segundoā
Disponibilidade Alta Alta
Desempenho Elevada, contudo, necessita de mais recursos
Elevada
Modelo de OperaĆ§Ć£o āProdutor envia a mensagem e o consumidor recebe as mensagens das respetivas filas que subscreveuā. āNeste processo, o roteamento da mensagem Ć© efetuado pelo MBā
Produtor envia mensagem que fica armazenada no respetivo tĆ³pico. āOs consumidores sĆ£o responsĆ”veis por rastrear e ler as mensagensā
HistĆ³rico de mensagens A mensagem Ć© removida apĆ³s ser entregue ao consumidor
A mensagem Ć© persistida, por um determinado perĆodo configurĆ”vel
Envio da mensagem para vƔrios consumidores
NĆ£o permite, Ć© necessĆ”rio replicar a fila e enviar a mensagem para as duas filas
Permite
DependĆŖncias Erlang Zookeeper
MonitorizaĆ§Ć£o Interface grĆ”fica incluĆda NecessĆ”rio software externo Protocolo AMQP, por defeito, com
suporte via plugins para outros
BinƔrio
Tecnologias suportadas Muitas, Python, Java, JavaScript, Spring, entre outras
Muitas, Erlang, .NET, Java, Python, entre outras
Ideal nos seguintes cenĆ”rios āNecessidade de suportar mĆŗltiplos protocolosā āIntegrar consumidores com roteamento complexoā
āNecessidade de replicaĆ§Ć£oā, histĆ³rico de mensagens, event-sourcing
AtravĆ©s da anĆ”lise da Tabela 1, Ć© possĆvel concluir que as alternativas apresentam uma
excelente qualidade nos serviƧos que proporcionam. A escolha da tecnologia deverƔ ter
em conta o cenĆ”rio onde se pretende integrar, o modelo de operaĆ§Ć£o e o protocolo
18
pretendido para a comunicaĆ§Ć£o. Por fim, Ć© de realƧar que o MB Apache Kafka,
apresenta um melhor desempenho e escalabilidade do que o RabbitMQ, podendo este
ser um fator decisivo para a escolha da alternativa a implementar.
2.13 Continuous integration (CI) e continuous deployment (CD)
O objetivo de uma arquitetura baseada em microsserviƧos Ʃ acelerar o
desenvolvimento de software. Para que seja realizado com sucesso os diferentes
objetivos, devem definidos a nĆvel organizacional, a definiĆ§Ć£o de pequenas equipas,
autĆ³nomas, bem como a nĆvel de processo, com a utilizaĆ§Ć£o de continuous delivery e
continuous deployment.
Assim, com o intuito de responder rapidamente e com qualidade Ć demanda dos
clientes, Ć© necessĆ”rio automatizar os processos de implantaĆ§Ć£o, minimizando os erros
manuais e os entregues ao cliente. Assim, Ʃ aconselhƔvel a prƔtica de CI (Continuous
Integration). Esta preconiza que os programadores devem integrar com frequĆŖncia
cĆ³digo fonte por eles desenvolvido no repositĆ³rio partilhado, permitindo que, no caso
de existĆŖncia de erros, estes sejam descobertos e corrigidos rapidamente (Jez Humble
& David Farley, 2010).
A frequĆŖncia de integraĆ§Ć£o das alteraƧƵes permite evitar conflitos no momento da
integraĆ§Ć£o, jĆ” que o restante cĆ³digo fonte da equipa nĆ£o serĆ” muito divergente do atual
na nova funcionalidade.
A prĆ”tica de CI torna mais rĆ”pido o processo de integraĆ§Ć£o e entrega das novas
funcionalidades. A qualidade do software, deve ser assegurada atravƩs de processos
automĆ”ticos de compilaĆ§Ć£o e testes ao cĆ³digo desenvolvido (Martin Fowler, 2006).
CD consiste na implantaĆ§Ć£o autĆ³noma das alteraƧƵes efetuadas ao cĆ³digo-fonte,
realizando testes automĆ”ticos Ć aplicaĆ§Ć£o, de modo a validar se as alteraƧƵes sĆ£o
corretas e garantir que a implantaĆ§Ć£o efetuada fica estĆ”vel e disponĆvel. Este, tem como
objetivo diminuir o tempo entre o momento de desenvolvimento do cĆ³digo e o de
entrega ao cliente, atravĆ©s do processo automĆ”tico de implantaĆ§Ć£o no ambiente de
produĆ§Ć£o (Jez Humble & David Farley, 2010).
BenefĆcios da prĆ”tica de CD (Jez Humble & David Farley, 2010):
ā¢ RĆ”pida resposta Ć demanda do cliente;
19
ā¢ Facilidade na entrega de software em novos ambientes: este processo, consiste
na configuraĆ§Ć£o do ambiente, indicando o mesmo nos pipelines automĆ”ticos de
implantaĆ§Ć£o;
ā¢ ReduĆ§Ć£o de erros: o processo de implantaĆ§Ć£o automĆ”tico, torna a implantaĆ§Ć£o
repetĆvel e reduz possĆveis erros provocados por processos manuais;
ā¢ Feedback do cliente: a empresa receberĆ” a opiniĆ£o do cliente muito mais rĆ”pido,
jĆ” que o tempo de desenvolvimento e entrega ao cliente Ć© reduzido.
As abordagens de CI/CD, relacionam a prƔtica de ambas, combinado os dois processos
de modo a tirar partido das vantagens de ambos. Esta prƔtica visa automatizar os
processos de entrega e implantaĆ§Ć£o, com o intuito de proporcionar rapidamente um
produto de qualidade aos clientes.
2.13.1 Jenkins
O Jenkins, Ć© um servidor de automatizaĆ§Ć£o open-source escrito em Java. Esta
ferramenta, que surgiu em 2011, desenvolvida por Kohsuke Kawaguchi, permite
automatizar o processo de desenvolvimento de software, atravƩs de CI e facilita o
processo de CD (John Ferguson Smart, 2011).
2.13.2 Bitbucket Pipelines
O Bitbucket Pipelines Ʃ um serviƧo da Atlassian para projetos na cloud, disponibilizado
por volta do ano 2017. EstĆ” integrado na UI (User Interface) do bitbucket. O intuito deste
serviƧo, Ʃ facilitar os processos de CI e CD e integrar automaticamente o mesmo com o
produto Jira, mostrando quais os problemas incluĆdos em cada implantaĆ§Ć£o (Atlassian,
2019).
2.13.3 ComparaĆ§Ć£o entre Jenkins e Bitbucket Pipelines
Na Tabela 2 pode observar-se uma comparaĆ§Ć£o entre Jenkins e o Bitbucket Pipelines
relativamente a algumas caracterĆsticas (Atlassian, 2019; John Ferguson Smart, 2011).
20
Tabela 2 ā ComparaĆ§Ć£o entre Jenkins e Bitbucket Pipelines
CaracterĆsticas Jenkins Bitbucket Pipelines
Open-Source Sim NĆ£o. PreƧo variado consoante o tempo mensal gasto em builds
IntegraĆ§Ć£o do cĆ³digo fonte Necessita de configurar o repositĆ³rio para efetuar a build
Executado no prĆ³prio repositĆ³rio do projeto
InstalaĆ§Ć£o ConfiguraĆ§Ć£o do servidor
NĆ£o necessita
Suporte de repositĆ³rios Git, Mercurial, Github Git e Mercurial
Escrita do pipeline Jenkinsfile ou definiĆ§Ć£o dos steps atravĆ©s da UI
Ficheiro yml
Suporte para implantaĆ§Ć£o em Dockers Sim Sim
IntegraĆ§Ć£o com o Jira Sim, configurĆ”vel atravĆ©s de plugin
Sim, automƔtica
Linguagens suportadas Python, Ruby, Java, Android, C/C++
Java, Javascript, PHP, Python, Ruby
Comunidade Extensa Sem dados obtidos
Facilidade de uso FƔcil FƔcil
MonitorizaĆ§Ć£o UI do servidor UI do Bitbucket
2.13.4 Docker
O Docker Ć© uma ferramenta open-source que surgiu em 2013, desenvolvida pela
empresa Docker, Inc. Tem como objetivo auxiliar a implantaĆ§Ć£o das aplicaƧƵes atravĆ©s
da utilizaĆ§Ć£o de containers (contentores). Estes sĆ£o um ambiente isolado de software
executĆ”vel que agrupam o cĆ³digo e as suas dependĆŖncias (O que Ć© Docker?, 2018).
21
A utilizaĆ§Ć£o destes containers permite isolar a execuĆ§Ć£o da aplicaĆ§Ć£o, o que torna
possĆvel executar diversas aplicaƧƵes de forma isolada num mesmo servidor,
apresentando inĆŗmeras vantagens (O que Ć© Docker?, 2018), tais como:
ā¢ DependĆŖncias: a execuĆ§Ć£o da aplicaĆ§Ć£o Ć© efetuada no container, a sua imagem
inclui as dependĆŖncias necessĆ”rias para uma execuĆ§Ć£o bem-sucedida, sem a
necessidade de configuraƧƵes ou instalaƧƵes na mƔquina ou no servidor onde
se encontra;
ā¢ ReduĆ§Ć£o de custos: a utilizaĆ§Ć£o dos Docker, permite a reduĆ§Ć£o de custos de
servidores, uma vez que nĆ£o Ć© necessĆ”ria uma quantidade tĆ£o grande de espaƧo
disponĆvel para a execuĆ§Ć£o da aplicaĆ§Ć£o;
ā¢ CĆ³pia de seguranƧa e reversĆ£o da versĆ£o implantada: atravĆ©s das imagens, Ć©
possĆvel reverter a aplicaĆ§Ć£o para versƵes anteriores caso a imagem implantada
nĆ£o seja desejada;
ā¢ SistematizaĆ§Ć£o: a imagem Ć© construĆda atravĆ©s de ficheiros de configuraĆ§Ć£o,
permitindo replicarem-se sem qualquer diferenƧa no ambiente;
ā¢ IntegraĆ§Ć£o com serviƧos cloud.
2.13.5 Kubernetes
Kubernetes Ć© um projeto open-source desenvolvido pela Cloud Native Computing
Foundation e disponibilizado em 2014. Este sistema permite a orquestraĆ§Ć£o de
containers e a automatizaĆ§Ć£o do processo de implantaĆ§Ć£o dos mesmos.
A utilizaĆ§Ć£o de Kubernetes segundo (Sayfan, 2017), permite a implantaĆ§Ć£o distribuĆda
de software visando obter escalabilidade e implantaƧƵes sem causar indisponibilidade
do sistema. AtravƩs das suas funcionalidades, este permite, escalabilidade horizontal,
escalabilidade automĆ”tica conforme a utilizaĆ§Ć£o dos recursos onde se encontra a
executar o microsserviƧo, controlo de disponibilidade do mesmo e reinĆcio automĆ”tico
em caso de falha, implantaĆ§Ć£o automĆ”tica e reversĆ£o da mesma em caso de falha.
De acordo com (Sayfan, 2017), a implantaĆ§Ć£o do Kubernetes resulta num cluster
constituĆdo por pelo menos um node. Este, consiste numa mĆ”quina fĆsica ou virtual
responsƔvel por hospedar os pods. Estes nodes permitem replicar rapidamente os pods
neles hospedados, permitindo implantaƧƵes sem inatividade da aplicaĆ§Ć£o, tolerĆ¢ncia Ć
falha da mesma, disponibilidade, escalabilidade e elasticidade. Por fim, um pod Ć©
constituĆdo por um ou mais containers. No caso de utilizaĆ§Ć£o de mais de um container
22
por pod, estes irĆ£o partilhar os recursos de armazenamento e rede, nomeadamente o
endereƧo de rede serƔ o mesmo para os containers.
2.13.6 Helm
Helm Ć© uma ferramenta open-source desenvolvida por Deis. Esta visa auxiliar a
instalaĆ§Ć£o e configuraĆ§Ć£o de aplicaƧƵes no cluster Kubernetes. AtravĆ©s desta
ferramenta Ć© possĆvel instalar aplicaƧƵes previamente configuradas e prontas a utilizar
(Sayfan, 2017).
A utilizaĆ§Ć£o desta ferramenta apresenta as seguintes vantagens:
ā¢ GestĆ£o da complexidade ao implantar aplicaƧƵes;
ā¢ Facilita a partilha de aplicaƧƵes;
ā¢ Facilita quer a atualizaĆ§Ć£o quer o retorno Ć versĆ£o anterior da aplicaĆ§Ć£o.
2.14 Cloud computing
Cloud computing, consiste no fornecimento de recursos informƔticos atravƩs da
internet, contrariamente ao armazenamento dos serviƧos em hardware fĆsico (Thomas
Erl et al., 2013).
Os provedores de cloud disponibilizam diversos serviƧos que apresentam ādiferentes
nĆveis de abstraĆ§Ć£o e esforƧo a implantaĆ§Ć£o dos serviƧosā (Michael J. Kavis, 2014), entre
eles podem distingir-se:
ā¢ IaaS (Infrastructure as a Service): permite adquirir recursos computacionais
escalƔveis e automatizados. Este modelo visa evitar despesas em hardware e
tambĆ©m a complexidade de gestĆ£o dos servidores fĆsicos e infraestruturas como
datacenters;
ā¢ PaaS (Platform as a Service): permite o desenvolvimento da aplicaĆ§Ć£o e a sua
implantaĆ§Ć£o atravĆ©s da internet. Este serviƧo disponibiliza a plataforma na qual
a aplicaĆ§Ć£o serĆ” executada. Assim, reduz Ć s equipas a necessidade de criaĆ§Ć£o e
manutenĆ§Ć£o das plataformas de cada aplicaĆ§Ć£o implantada;
ā¢ SaaS (Software as a Service): permite disponibilizar e aceder ao software atravĆ©s
da internet. O provedor do serviƧo Ʃ responsƔvel pelo hardware, disponibilidade,
seguranƧa e os dados da aplicaĆ§Ć£o.
23
De modo geral algumas das vĆ”rias vantagens que a utilizaĆ§Ć£o da cloud apresenta para
os utilizadores sĆ£o:
ā¢ ReduĆ§Ć£o de custos, tendo apenas custos proporcionais: atravĆ©s da cloud Ć©
possĆvel pagar apenas pela quantidade de recursos tecnolĆ³gicos consumidos
(pay-per-use). Evitando gastos monetĆ”rios com equipamentos fĆsicos que
porventura poderiam nĆ£o ser utilizados;
ā¢ Aumento da escalabilidade, tornando possĆvel obter elasticidade: possibilidade
de aumento ou diminuiĆ§Ć£o instantĆ¢nea dos recursos de modo a ajustar aos
elevados ou baixos fluxos de utilizadores;
ā¢ Aumento da disponibilidade e confiabilidade: āfoco na minimizaĆ§Ć£o e
eliminaĆ§Ć£o das interrupƧƵes do tempo de execuĆ§Ć£oā.
2.14.1 Google Cloud Platform
Esta plataforma cloud, Ć© disponibilizada pela Google tendo surgido em 2011, sendo a
mais recente neste domĆnio. Contudo, ao longo dos Ćŗltimos anos tem demostrado um
elevado crescimento relativamente ao nĆŗmero de clientes no domĆnio.
Esta plataforma oferece āconexƵes rĆ”pidas e confiĆ”veis aos seus utilizadoresā
(Intellipaat, 2019). As suas vantagens (Intellipaat, 2019) sĆ£o:
ā¢ āExperiĆŖncia em DevOpsā;
ā¢ āProjetada especificamente para negĆ³cios baseados na nuvemā;
ā¢ āDescontos flexĆveis e contratosā.
2.14.2 Amazon Web Services
Esta plataforma surgiu em 2006, disponibilizada pela Amazon, sendo a primeira, a mais
experiente e a que domina o mercado cloud (Intellipaat, 2019).
Oferece diversos serviƧos configurƔveis de forma independente, com o intuito de gerir
as aplicaƧƵes, base de dados, seguranƧa, entre outros.
As principais vantagens (Intellipaat, 2019), desta cloud sĆ£o apresentadas abaixo:
ā¢ DomĆnio do mercado cloud;
24
ā¢ IntegraĆ§Ć£o com ferramentas open-source;
ā¢ Qualidade dos serviƧos dado a experiĆŖncia adquirida.
2.14.3 Microsoft Azure
Microsoft Azure Ć© uma plataforma cloud disponibilizada pela Microsoft em 2010. EstĆ”
em segundo lugar em termos de domĆnio no mercado.
O uso desta plataforma Ć© recomendado quando existe integraĆ§Ć£o com ferramentas da
Microsoft.
2.14.4 DigitalOcean
A DigitalOcean Ć© uma plataforma cloud que surgiu em 2011 fundada por Ben Uretsky e
Moisey Uretsky.
De acordo com (Saleem, 2019), esta cloud visa responder Ć s necessidades dos
ādesenvolvedores de software individuais e empresas startupā, com menor dimensĆ£o
menos necessidades, portanto. Esta em 2018, foi premiada com o tĆtulo de terceira
maior empresa de hospedagem na cloud.
2.15 JMeter
JMeter Ć© uma ferramenta open-source desenvolvida pela Apache e permite a definiĆ§Ć£o
e execuĆ§Ć£o de testes atravĆ©s de uma interface grĆ”fica ou atravĆ©s da escrita de scripts.
Esta ferramenta permite tambƩm testar o comportamento e o desempenho de
aplicaƧƵes, atravĆ©s da execuĆ§Ć£o de testes de carga, automatizando os pedidos
efetuados Ć mesma (JMeter, 2020).
Ć uma ferramenta que exporta os dados dos testes efetuados e auxilia no seu processo
de anƔlise atravƩs de tabelas e grƔficos.
2.16 Servidor de autenticaĆ§Ć£o Ćŗnico
Este servidor de autenticaĆ§Ć£o, permite que o cliente do produto, caso possua mais
produtos, possa aceder aos mesmos, efetuando apenas login uma Ćŗnica vez. Esta
funcionalidade beneficia a experiĆŖncia de utilizaĆ§Ć£o dos produtos e simplifica a
25
integraĆ§Ć£o entre os mesmos, uma vez que estes nĆ£o necessitam de implementar os
seus prĆ³prios processos de autenticaĆ§Ć£o (CoMakeIT, 2018).
Atualmente, na empresa Flowinn, a autenticaĆ§Ć£o, Ć© efetuada atravĆ©s de um servidor
Ćŗnico, Keycloak. AtravĆ©s deste sistema, Ć© possĆvel partilhar o utilizador com login
efetuado e todos os utilizadores das aplicaƧƵes num local Ćŗnico.
27
3 MigraĆ§Ć£o entre arquiteturas
Neste capĆtulo apresentam-se e analisam-se, com base em experiĆŖncias idĆŖnticas,
algumas soluƧƵes da migraĆ§Ć£o de arquiteturas monolĆticas para arquiteturas baseadas
em microsserviƧos.
A migraĆ§Ć£o de arquiteturas monolĆticas para arquiteturas baseadas em microsserviƧos,
surge como possĆvel soluĆ§Ć£o para a complexidade existente num Ćŗnico sistema. A atual
demanda dos clientes por rƔpidas entregas e novas funcionalidades nos seus produtos,
terƔ de passar, necessariamente, pelo desenvolvimento de soluƧƵes baseadas em
microsserviƧos, jĆ” que estas apresentam inĆŗmeras vantagens neste aspeto, tais como,
facilitaĆ§Ć£o do processo de manutenĆ§Ć£o do cĆ³digo, permitem o desenvolvimento e
implantaĆ§Ć£o independente levando a que a quebra de uma funcionalidade nĆ£o
comprometa a totalidade da soluĆ§Ć£o, por fim, facilitam o processo de CD.
3.1 EstratĆ©gias de migraĆ§Ć£o
Segundo (Newman, 2019), estas migraƧƵes devem ser decisƵes conscientes, que visam
resolver questƵes ou problemas que por meio de soluƧƵes monolĆticas nĆ£o Ć© possĆvel.
Para o processo de definiĆ§Ć£o da estratĆ©gia para efetuar a migraĆ§Ć£o, existem diversas
opƧƵes. Uma delas, a transformaĆ§Ć£o de toda a aplicaĆ§Ć£o monolĆtica em vĆ”rias soluƧƵes
baseadas em microsserviƧos, simultaneamente e de uma sĆ³ vez, apesar de parecer a
soluĆ§Ć£o mais fĆ”cil, Ć© impraticĆ”vel, uma vez que, existem problemas consequentes desta
mudanƧa. A entrega da totalidade do software Ć© mais suscetĆvel a falhas que poderiam
ser identificadas e corrigidas ao longo da migraĆ§Ć£o, e nĆ£o permite obter resultados do
processo.
28
āIf you do a big-bang rewrite, the only thing youāre guaranteed of is a big bangā. - Martin
Fowler (Newman, 2019)
Como se referiu, a realizaĆ§Ć£o da alteraĆ§Ć£o for efetuada de uma vez, implica um longo
investimento temporal e impossibilita a utilizaĆ§Ć£o da soluĆ§Ć£o atĆ© que todo o processo
de migraĆ§Ć£o seja concluĆdo. Assim, nĆ£o Ć© possĆvel obter rapidamente feedback
relativamente ao valor acrescentado com a alteraĆ§Ć£o, bem como, verificar o sucesso da
alteraĆ§Ć£o no decorrer do seu processo. Este mĆ©todo apresenta ainda a desvantagem de
nĆ£o permitir desenvolver novas funcionalidades enquanto a migraĆ§Ć£o nĆ£o estiver
totalmente concluĆda, uma vez que estas necessitam que a lĆ³gica aplicacional seja
completamente migrada para a nova soluĆ§Ć£o.
De modo a facilitar a migraĆ§Ć£o de aplicaƧƵes com arquiteturas monolĆticas para
arquiteturas baseadas em microsserviƧos existem diversos padrƵes, um deles Ʃ o
Strangler Fig Application. Foi definido em 2004 por Martin Fowler e consiste em
transformar de forma incremental o monĆ³lito em diversos microsserviƧos (Newman,
2019). Segundo (Kyle Brown, 2017), esta transformaĆ§Ć£o consiste em trĆŖs etapas:
ā¢ Transform (TransformaĆ§Ć£o): Desenvolvimento de uma determinada
funcionalidade jĆ” existente no monĆ³lito num microsserviƧo externo ao monĆ³lito.
Este microsserviƧo faz parte da nova soluĆ§Ć£o;
ā¢ Co-exist (Coexistir): De modo a testar a funcionalidade desenvolvida em paralelo
com a mesma funcionalidade existente, Ʃ necessƔrio que ambas executem em
paralelo nos dois sistemas;
ā¢ Eliminate (Eliminar): Elimina o componente da aplicaĆ§Ć£o monolĆtica, retornando
todo o trƔfego para o novo serviƧo desenvolvido.
Figura 4 ā Etapas do padrĆ£o Strangler Fig Application (Samir Behara, 2018)
29
Como apresentado na Figura 4, a aplicaĆ§Ć£o deste padrĆ£o requer a utilizaĆ§Ć£o de um
mecanismo de encaminhamento de trƔfego, que permita distribuir os pedidos
efetuados Ć funcionalidade sobre a aplicaĆ§Ć£o monolĆtica para a nova soluĆ§Ć£o
desenvolvida no microsserviƧo. ApĆ³s anĆ”lise pode concluir-se que, a segunda etapa
(coexistir) requer um esforƧo maior por ser necessĆ”ria a manutenĆ§Ć£o de duas soluƧƵes
e respetivas base de dados.
3.2 Exemplos de MigraƧƵes
3.2.1 Wix
Neste primeiro caso, a migraĆ§Ć£o foi efetuada pela Wix. Esta āĆ© uma plataforma de
desenvolvimento web, que permite aos seus utilizadores criar websites sem qualquer
conhecimento em programaĆ§Ć£oā (Yoav Abrahami, 2015).
Numa conferĆŖncia (Aviran Mordo, 2006), realizada no evento GOTO Conferences, em
novembro de 2016, Aviran Mordo, vice-presidente de engenharia na Wix, apresentou a
estrutura arquitetural das suas soluƧƵes e a mudanƧa que necessitaram de efetuar para
ultrapassar e escapar aos problemas do seu monĆ³lito, nomeadamente:
ā¢ āUma falha em Ć”reas nĆ£o relacionadas causarĆ” falhas em todo o sistemaā.
ā¢ āAlteraƧƵes em Ć”reas nĆ£o relacionadas implicam a implantaĆ§Ć£o de todo o
sistemaā.
ā¢ āServidor monĆ³lito Ć© responsĆ”vel por todos os processosā.
A estratĆ©gia adotada para a migraĆ§Ć£o foi a realizaĆ§Ć£o de um processo incremental que
passou por separar as funƧƵes do monĆ³lito com base nos dois segmentos de clientes,
nomeadamente, ediĆ§Ć£o e visualizaĆ§Ć£o de websites. O processo iniciou-se pela
separaĆ§Ć£o da parte pĆŗblica, de visualizaĆ§Ć£o dos websites, do monĆ³lito.
Com base na publicaĆ§Ć£o efetuada, por Yoav Abrahami, arquiteto na Wix, este processo
de divisĆ£o durou cerca de quatro a cinco anos. Este foi descrito por ele como ādifĆcil e
longo, uma vez que a plataforma continuou ativa e sobre desenvolvimento de novas
funcionalidades, aquando a extraĆ§Ć£o de funcionalidades existentes no monĆ³lito para os
novos microsserviƧosā (Yoav Abrahami, 2015).
Com esta migraĆ§Ć£o e de acordo com Aviran Mordo (Aviran Mordo, 2006), a Wix obteve
resultados que com ao sistema anterior, nĆ£o seriam possĆveis nomeadamente,
30
escalabilidade, manutenibilidade e autonomia de desenvolvimento por equipas.
Contudo, a nova arquitetura implementada apresenta algumas desvantagens
relativamente ao monĆ³lito, nomeadamente complexidade do sistema e uma maior
dificuldade de testar as funcionalidades.
3.2.2 Netflix
Segundo Yury Izrailevsky, a ideia de migrar a aplicaĆ§Ć£o monolĆtica surgiu em meados de
2008, quando este apresentou uma falha nos datacenters que obrigou a
indisponibilidade do sistema da Netflix durante trĆŖs dias, impossibilitando, na altura, o
envio de DVD para os seus membros (Yury Izrailevsky, 2016).
O objetivo desta mudanƧa, foi obter uma reduĆ§Ć£o de custos relativamente aos
datacenters e tirar vantagem da elasticidade e escalabilidade da nuvem, o que permite
escalar mais rapidamente que os datacenters fĆsicos.
Esta migraĆ§Ć£o, consistiu na transformaĆ§Ć£o de um monĆ³lito e datacenters, em vĆ”rios
microsserviƧos implantados na nuvem. A migraĆ§Ć£o efetuada, pretendia melhorar a
disponibilidade, escalabilidade e performance da soluĆ§Ć£o. Com o intuito de evitar a
migraĆ§Ć£o de problemas presentes no monĆ³lito, a nova soluĆ§Ć£o consiste em centenas
de microsserviƧos e base de dados NoSQL resultantes da desnormalizaĆ§Ć£o do modelo
de dados anterior (Netflix Technology Blog, 2012; Yury Izrailevsky, 2016).
A migraĆ§Ć£o foi um processo incremental, que teve a duraĆ§Ć£o de sete anos, contudo, a
nova infraestrutura na nuvem, aumentou drasticamente a disponibilidade e
escalabilidade do sistema, permitindo Ć Netflix expandir-se ao longo de 130 novos
paĆses, āsem terem de se preocupar com a falta de espaƧo ou poder computacionalā,
afirmou John Piela, com base nas declaraƧƵes de Adrian Cockcroft, āarquiteto da cloud
da Netflixā (John Piela, 2016).
31
4 AnƔlise de valor
4.1 Novo Modelo de Desenvolvimento de Conceitos
O novo modelo de desenvolvimento de conceitos, defendido por Peter Koen et al.,
providencia uma linguagem comum e a definiĆ§Ć£o dos componentes chave do Fuzzy
Front-End (FEE). Este modelo, acrescenta clareza e racionalidade ao front end, para
atingir o objetivo de identificar claramente os requisitos, planos de negĆ³cios e definiĆ§Ć£o
de mercado para o novo projeto (Koen et al., 2002).
Figura 5 ā RepresentaĆ§Ć£o do Novo Modelo de Desenvolvimento de Conceitos (Koen et al.,
2002)
Este modelo, divide o front end em trĆŖs Ć”reas distintas, sendo elas o motor, a parte
interna e os fatores de influĆŖncia. A primeira impulsiona o processo de inovaĆ§Ć£o e
consiste nos valores da empresa, lideranƧa e cultura. A parte interna inclui os cinco
elementos do Front End Inovation (FEI), sendo eles (GeraĆ§Ć£o de Ideias, SeleĆ§Ć£o de Ideias,
DefiniĆ§Ć£o do Conceito e Tecnologia, IdentificaĆ§Ć£o de Oportunidades e AnĆ”lise de
Oportunidades). Esta parte apresenta dois pontos de entrada; a IdentificaĆ§Ć£o da
32
oportunidade e a geraĆ§Ć£o da ideia. Por fim, os fatores de influĆŖncia sĆ£o fatores externos,
que influenciam a organizaĆ§Ć£o como por exemplo, fatores econĆ³micos, culturais ou
legais, clientes e influĆŖncia proporcionada pelos concorrentes (Koen et al., 2002).
4.1.1 IdentificaĆ§Ć£o da Oportunidade
Neste elemento, sĆ£o identificadas as oportunidades que vĆ£o de encontro Ć estratĆ©gia
da empresa. Estas, geralmente, sĆ£o orientadas pelos objetivos do negĆ³cio e podem ser
respostas a ameaƧas competitivas, produtos inovadores com o intuito de ganhar
vantagens ou um meio de reduzir os custos atuais das operaƧƵes. Existem diversos
mƩtodos para avaliar as oportunidades (Koen et al., 2002), nomeadamente:
ā¢ Roadmapping, Ć© uma forma grĆ”fica que permite planear recursos tecnolĆ³gicos.
Este mƩtodo permite expor facilmente a complexidade do produto para as
pessoas que nĆ£o fazem parte da equipa do projeto;
ā¢ AnĆ”lise das tendĆŖncias tecnolĆ³gicas e dos clientes, visa identificar as
caracterĆsticas dominantes do mercado e os consumidores a ele associados, com
o intuito de obter oportunidades competitivas para o projeto;
ā¢ AnĆ”lise da inteligĆŖncia competitiva, refere-se Ć prĆ”tica de recolha, anĆ”lise e
comunicaĆ§Ć£o das informaƧƵes disponĆveis sobre as tendĆŖncias competitivas;
ā¢ Pesquisa do mercado, consiste na anĆ”lise do mercado envolvente do projeto a
desenvolver;
ā¢ Planeamento de cenĆ”rios, Ć© uma abordagem disciplinada para imaginar e
planear o futuro de modo a encontrar decisƵes que, de outra forma, poderiam
ser ignoradas.
A anĆ”lise das tendĆŖncias tecnolĆ³gicas e dos clientes Ć© o mĆ©todo mais adequado para
identificar a oportunidade corretamente. Posteriormente serĆ£o analisadas as duas
arquiteturas, a atual e a que serĆ” desenvolvida.
As aplicaƧƵes monolĆticas, como se descreveu anteriormente, sĆ£o mais simples no que
respeita Ć sua implementaĆ§Ć£o, porĆ©m ao longo do seu ciclo de vida e das constantes
mudanƧas ao nĆvel funcional, podem dar origem aos problemas identificados na secĆ§Ć£o
1.2 deste documento. A aplicaĆ§Ć£o Logistics, sobre a qual este trabalho incide, nĆ£o Ć©
exceĆ§Ć£o, atravĆ©s do uso contĆnuo do cliente surgiu a ideia de melhorar o produto
arquiteturalmente, visando tornar este sistema mais manutenĆvel, escalĆ”vel e legĆvel
para novos membros da equipa. Com estas melhorias, pretende-se obter reduĆ§Ć£o de
33
custos e esforƧos em implementaƧƵes futuras sobre o produto. AtravƩs desta ideia, a
Flowinn poderĆ” ver o seu produto modernizado e atual, podendo levar a vantagens
sobre os seus concorrentes diretos no mercado.
4.1.2 AnƔlise da Oportunidade
Posteriormente Ć identificaĆ§Ć£o das oportunidades, Ć© necessĆ”rio proceder Ć sua
avaliaĆ§Ć£o para verificar se estas valem o investimento. Esta avaliaĆ§Ć£o pode ser efetuada
formalmente ou iterativamente. Neste elemento, Ʃ pressuposto uma anƔlise superficial
sobre a oportunidade, podendo resultar em incertezas nas tecnologias e no mercado.
As tĆ©cnicas usadas para a identificaĆ§Ć£o de oportunidades, descritas no ponto 4.1.1,
podem ser utilizadas para este elemento, contudo, deverĆ” ser mais descritivo e
apresentar mais detalhes. Podem ainda ser utilizadas quatro tƩcnicas, enquadramento
estratĆ©gico, avaliaĆ§Ć£o do mercado, anĆ”lise dos concorrentes e avaliaĆ§Ć£o dos clientes
(Koen et al., 2002).
Para a anƔlise da ideia descrita neste documento, o enquadramento estratƩgico Ʃ a
tĆ©cnica mais adequada uma vez que, se pretende acrescentar valor interno Ć empresa
Flowinn, este por sua vez trarĆ” valor aos diversos clientes do produto Logistics.
Atualmente, o processo de implementaĆ§Ć£o de uma nova funcionalidade consiste em
quatro principais fases, especificaĆ§Ć£o e detalhe da funcionalidade, desenvolvimento,
testes manuais no ambiente de testes e implantaĆ§Ć£o em produĆ§Ć£o. Este processo,
devido Ć complexidade atual da soluĆ§Ć£o, Ć© moroso, arriscado e por vezes leva a falhas,
visto que, dada a inexistĆŖncia de testes, quando se realizam novas implementaƧƵes, sĆ£o,
por vezes, quebradas funcionalidades previamente desenvolvidas. Portanto, na fase de
testes manuais, esta anomalia pode nĆ£o ser detetada, uma vez que Ć© testada apenas a
nova funcionalidade e nĆ£o a totalidade da versĆ£o do produto a ser colocado no cliente.
A ideia em anƔlise, tenciona melhorar as fases de desenvolvimento, testes manuais no
ambiente de testes e implantaĆ§Ć£o em produĆ§Ć£o, dado que com soluĆ§Ć£o em vista Ć©
expectĆ”vel acelerar o processo diretamente e indiretamente. A soluĆ§Ć£o em vista, visa
reduzir a complexidade aglomerada em um monĆ³lito, facilitando a perceĆ§Ć£o das
funcionalidades existentes e consequente reduĆ§Ć£o do tempo despendido nas novas
implementaƧƵes. AtravĆ©s de uma correta automatizaĆ§Ć£o de testes, serĆ” possĆvel
detetar a quebra indesejada de funcionalidades. Por fim, relativamente Ć fase de
implantaĆ§Ć£o no cliente, Ć© pretendido acelerar e automatizar o processo de entrega,
com isto os clientes terĆ£o acesso Ć s novas funcionalidades num espaƧo de tempo menor,
podendo dar a sua opiniĆ£o e melhorar continuamente o seu produto, ao invĆ©s de
procurar soluƧƵes alternativas no mercado.
34
4.1.3 GeraĆ§Ć£o e Enriquecimento de Ideias
Este elemento tem o propĆ³sito de criar, desenvolver e amadurecer as ideias, este Ć© um
processo evolutivo, podendo estas sofrer diversas mudanƧas Ć medida que sĆ£o
estudadas e examinadas. Contactos com o cliente ou utilizadores finais do produto e
comunicaĆ§Ć£o com outras empresas, Ć© comum para enriquecer as ideias.
O processo de geraĆ§Ć£o de ideias pode ser formal, atravĆ©s de sessƵes de brainstorming
e ideias que vĆ£o sendo armazenadas, ou informais tais como, experiĆŖncias falhadas ou
pedidos incomuns dos clientes (Koen et al., 2002).
Atualmente, a empresa Flowinn apresenta todos os seus produtos desenvolvidos sobre
arquiteturas monolĆticas, sendo a ideia apresentada neste trabalho o primeiro projeto
com base em microsserviƧos. Assim, Ć© expectĆ”vel nesta fase, a elaboraĆ§Ć£o de uma
pesquisa aprofundada das possĆveis alternativas dos componentes a utilizar na
concretizaĆ§Ć£o desta ideia. Estas pesquisas visam ser iterativas, uma vez que devem ser
apresentadas em reuniƵes, as possĆveis soluƧƵes de modo a que os elementos possam
contribuir com as suas opiniƵes e experiĆŖncias, com o intuito de expor situaƧƵes que
nĆ£o tenham sido pensadas inicialmente e acrescentem valor Ć ideia.
4.1.4 SeleĆ§Ć£o da Ideia
Neste ponto, deve ser selecionada a ideia que permite alcanƧar o maior valor comercial,
assim sendo, este processo Ć© fulcral para o sucesso e futuro do projeto a desenvolver.
No entanto de acordo com (Koen et al., 2002), nĆ£o existe um Ćŗnico que garanta a
escolha da melhor soluĆ§Ć£o.
No Ć¢mbito deste projeto, de modo a proporcionar as maiores vantagens
organizacionais, tendo em conta gastos financeiros e temporais necessƔrios, serƔ
utilizado o mƩtodo AHP (Analytic Hierarchy Process), posteriormente analisado com
detalhe no capĆtulo 5.
4.1.5 DefiniĆ§Ć£o de conceito
A definiĆ§Ć£o de conceito Ć© o elemento final do novo modelo de desenvolvimento de
conceito e fornece a Ćŗnica saĆda deste modelo. Aqui a oportunidade escolhida deve ser
defendida, justificando o investimento necessƔrio para o seu desenvolvimento.
35
Atualmente, o produto utilizado neste trabalho jĆ” se encontra comercializado. A
migraĆ§Ć£o apresentada pretende melhorar a soluĆ§Ć£o existente, beneficiando a empresa
e os seus clientes.
4.2 Valor para o cliente e valor percebido pelo cliente
O valor para o cliente, consiste na diferenƧa entre os benefĆcios que o produto lhe
oferece e os custos que o cliente teve para o obter. Este valor pode ser diferente do
valor definido pela empresa.
Valor percebido Ć© o valor interpretado pelo cliente, com base na satisfaĆ§Ć£o das suas
necessidades, e nĆ£o o valor monetĆ”rio do produto (Woodall, 2003).
Neste projeto, o cliente valoriza o desempenho, a usabilidade e correta funcionalidade
do sistema, sendo fulcral minimizar os erros presentes no ambiente de produĆ§Ć£o.
Este projeto visa responder Ć s necessidades do cliente e facilitar a continuidade da
entrega de valor em futuras funcionalidades pedidas pelo mesmo. Estes benefĆcios,
devem ser corretamente transmitidos para os clientes, de modo a manter as suas
perceƧƵes alinhadas em relaĆ§Ć£o aos benefĆcios do produto.
Por outro lado, este projeto apresenta custos, tais como, custo monetƔrio para o cliente,
custo temporal de implementaĆ§Ć£o da arquitetura e esforƧo necessĆ”rio da respetiva
implementaĆ§Ć£o.
4.3 Business Model Canvas
O modelo de negĆ³cio Canvas, foi proposto por Alexander Osterwalder e visa descrever
de uma forma grĆ”fica, clara e lĆ³gica, como uma organizaĆ§Ć£o cria e proporciona valor
atravĆ©s do seu negĆ³cio. Este modelo, Ć© segmentado por nove blocos sendo eles,
parceiros chave, atividades chave, recursos chave, estrutura de custos, proposta de
valor, relaĆ§Ć£o com o cliente, canais de comunicaĆ§Ć£o, segmento de clientes e fontes de
receita, abrangendo as quatro Ć”reas principiais do negĆ³cio que sĆ£o, clientes, oferta,
infraestrutura e viabilidade financeira (Osterwalder et al., 2010).
36
Tabela 3 ā Business Model Canvas
Parceiros chave
ā¢ Flowinn
Atividades chave
ā¢ Design da soluĆ§Ć£o
ā¢ Desenvolvimento da soluĆ§Ć£o
ā¢ Testes automĆ”ticos
ā¢ ConfiguraĆ§Ć£o dos ambientes de desenvolvimento e produĆ§Ć£o
ā¢ ConfiguraĆ§Ć£o do processo de implantaĆ§Ć£o
Proposta de valor
ā¢ Escalabilidade
ā¢ Manutenibilidade
ā¢ Flexibilidade
ā¢ Sustentabilidade
ā¢ Disponibilidade
RelaĆ§Ć£o com o cliente
ā¢ Portal Service Desk
Segmento de clientes
ā¢ Clientes da aplicaĆ§Ć£o Logistics
ā¢ Flowinn
Recursos chave
ā¢ Programadores
ā¢ ServiƧos cloud
ā¢ Git
ā¢ Servidor de mensagens assĆncronas
Canais de ComunicaĆ§Ć£o
ā¢ Contato presencial
ā¢ Email
Estrutura de custos
ā¢ Desenvolvimento da soluĆ§Ć£o
ā¢ ManutenĆ§Ć£o da soluĆ§Ć£o
ā¢ Infraestrutura
Fontes de receita
ā¢ DiminuiĆ§Ć£o de tempo gasto em manutenĆ§Ć£o de software (manutenibilidade)
ā¢ DiminuiĆ§Ć£o do tempo de desenvolvimento
ā¢ Entrega mais rĆ”pida do produto aos clientes
ā¢ Entrega de software menos propĆcio a falhas devido aos testes implementados
ā¢ Venda do projeto aos clientes
37
Com base na Tabela 3, pode observar-se que o modelo canvas Ć© constituĆdo pelos
seguintes segmentos:
ā¢ Parceiros chave
āIdentificam os fornecedores e os parceiros essenciais para o bom funcionamento do
negĆ³cioā. (Osterwalder et al., 2010).
O parceiro chave deste projeto Ć© a empresa Flowinn.
ā¢ Atividades chave
āRepresentam as aƧƵes mais importantes que a empresa deve realizar para que o
negĆ³cio seja bem-sucedidoā (Osterwalder et al., 2010).
As atividades chave deste projeto sĆ£o, design e desenvolvimento da soluĆ§Ć£o,
implementaĆ§Ć£o de testes automĆ”ticos e configuraĆ§Ć£o do processo automĆ”tico de
implantaĆ§Ć£o para os ambientes de desenvolvimento e produĆ§Ć£o de cada cliente.
ā¢ Recursos chave
āDescrevem os bens necessĆ”rios para a empresa, atravĆ©s do seu modelo de negĆ³cio,
entregar valor aos seus clientesā (Osterwalder et al., 2010).
Os recursos chave passam por programadores, serviƧos cloud, git e servidor de
mensagens assĆncronas.
ā¢ Estrutura de custos
āDescreve todos os custos envolvidos no modelo de negĆ³cioā (Osterwalder et al., 2010).
Os custos sĆ£o desenvolvimento da soluĆ§Ć£o, manutenĆ§Ć£o da soluĆ§Ć£o e infraestrutura.
ā¢ Proposta de valor
āRepresenta o conjunto de produtos e serviƧos que acrescentam valor para um
segmento de cliente especĆficoā (Osterwalder et al., 2010).
As propostas de valor sĆ£o escalabilidade, manutenibilidade, flexibilidade,
sustentabilidade e disponibilidade.
ā¢ RelaĆ§Ć£o com o cliente
38
āDescreve o tipo de relaĆ§Ć£o entre a organizaĆ§Ć£o e os seus clientesā (Osterwalder et al.,
2010).
A relaĆ§Ć£o com o cliente Ć© efetuada atravĆ©s do Portal Service Desk, que consiste numa
aplicaĆ§Ć£o web, integrada no sistema interno da empresa Flowinn, com o intuito de
fornecer um suporte eficiente ao cliente.
ā¢ Canais de comunicaĆ§Ć£o
āDescreve os meios que a companhia utiliza para comunicar e transmitir a sua proposta
de valor aos segmentos de clienteā (Osterwalder et al., 2010).
A comunicaĆ§Ć£o com os clientes Ć© efetuada atravĆ©s de emails e contatos presenciais.
ā¢ Segmentos de clientes
āRepresenta os diferentes grupos de pessoas ou organizaƧƵes que a empresa procura
alcanƧar e servirā (Osterwalder et al., 2010).
Neste ponto a aplicaĆ§Ć£o destina-se aos clientes do produto Logistics e Ć empresa
Flowinn, jĆ” que esta, a longo prazo, beneficiarĆ” do produto, nomeadamente na
manutenĆ§Ć£o e sustentabilidade.
ā¢ Fontes de receitas
āFontes de receita descrevem as metodologias que a organizaĆ§Ć£o segue para gerar
dinheiro atravĆ©s segmento de clienteā (Osterwalder et al., 2010).
Concluindo, as fontes de receita sĆ£o, diminuiĆ§Ć£o de tempo gasto em manutenĆ§Ć£o de
software e de desenvolvimento, entrega mais rƔpida do produto aos clientes, entrega
de software menos propĆcio a falhas devido aos testes implementados e valor gerado
da venda do projeto aos clientes.
4.4 Analytic Hierarchy Process
O mƩtodo de anƔlise hierƔrquica AHP, foi desenvolvido em 1980 por Thomas L. Saaty.
Este mĆ©todo, auxilia a escolha e respetiva justificaĆ§Ć£o dadas as alternativas possĆveis. A
ideia principal deste mĆ©todo Ć© decompor o problema de decisĆ£o em nĆveis hierĆ”rquicos,
de modo a facilitar a sua compreensĆ£o.
39
A primeira etapa do mesmo, consiste na construĆ§Ć£o da Ć”rvore hierĆ”rquica de decisĆ£o,
esta Ć© constituĆda pelo objetivo da decisĆ£o no topo, seguido pelos critĆ©rios de avaliaĆ§Ć£o
associados ao problema e por fim as alternativas disponĆveis para solucionar o
problema (Saaty, 2008).
Posteriormente, segue-se a segunda etapa, que consiste na atribuiĆ§Ć£o de prioridades
aos diferentes pares de critĆ©rios escolhidos. De modo a efetuar esta atribuiĆ§Ć£o, Ć©
necessĆ”ria a utilizaĆ§Ć£o da escala de Saaty, que Ć© definida por valores entre 1 e 9, sendo
que 1 representa igualdade de importĆ¢ncia dos critĆ©rios e 9 representa uma diferenƧa
de importĆ¢ncia absoluta entre os mesmos (Saaty, 2008).
Por fim, Ć© necessĆ”rio garantir a consistĆŖncia das prioridades relativas, atravĆ©s dos
cĆ”lculos matemĆ”ticos que serĆ£o apresentados no decorrer da execuĆ§Ć£o do mĆ©todo,
posteriormente indicada na secĆ§Ć£o 5.4.
41
5 Abordagens tecnolĆ³gicas
Este capĆtulo tem como objetivo apresentar algumas das abordagens possĆveis para a
implementaĆ§Ć£o da soluĆ§Ć£o baseada em microsserviƧos, bem como, o processo de
seleĆ§Ć£o da abordagem a implementar. Esta seleĆ§Ć£o serĆ” efetuada com base no mĆ©todo
de anƔlise hierƔrquica, AHP.
5.1 Gateway e JHipster Registry
JHipster Registry Ć© uma aplicaĆ§Ć£o open-source, ābaseado em Spring Cloud Netflix,
Eureka e Spring Cloud Configā, disponibilizada pela equipa do JHipster (JHipster, 2017a).
A utilizaĆ§Ć£o desta abordagem resulta numa soluĆ§Ć£o que apresenta a arquitetura que se
pode observar na Figura 6.
Figura 6 ā Diagrama de componentes utilizando JHipster Registry, baseado em (JHipster,
2017a)
42
Os utilizadores, como ilustrado na figura acima, interagem com o microsserviƧo de
Gateway, atravƩs dos pedidos efetuados no seu browser. De modo a concluir os
diversos pedidos dos utilizadores, o componente Gateway, comunica com o
componente JHipster Registry. Este indicarƔ qual o microsserviƧo com que deve
comunicar posteriormente e a sua localizaĆ§Ć£o, assim o componente Gateway efetua o
pedido ao respetivo microsserviƧo, que lhe darƔ a resposta ao pedido pretendido.
O Gateway, Ć© um componente constituĆdo pelo front-end, visĆvel pelos utilizadores e
pelo encaminhamento dos pedidos para o devido microsserviƧo. Este encaminhamento
Ć© efetuado de forma dinĆ¢mica, aplicando o algoritmo round robin no caso de existirem
vĆ”rias instĆ¢ncias de um microsserviƧo. (JHipster, 2017a; Sendil Kumar N & Deepu K
Sasidharan, 2018).
O JHipster Registry, Ć© um service registry, responsĆ”vel por armazenar a localizaĆ§Ć£o dos
microsserviƧos constituintes da soluĆ§Ć£o, permitindo a comunicaĆ§Ć£o com eles. Este
componente disponibilizado pelo JHipster, Ć© um servidor constituĆdo por Eureka e
Spring Cloud Config, o comportamento deste componente pode ser alterado, uma vez
que, o seu cĆ³digo fonte Ć© disponibilizado para desenvolvimento.
O componente permite as seguintes funcionalidades (Sendil Kumar N & Deepu K
Sasidharan, 2018):
ā¢ Descoberta de serviƧos, atravĆ©s do Eureka;
ā¢ Registo e configuraĆ§Ć£o dos microsserviƧos em tempo de execuĆ§Ć£o, atravĆ©s do
Spring Cloud Config;
ā¢ Dashboard administrativa configurĆ”vel, que contĆ©m informaĆ§Ć£o bastante
detalhada de todos os microsserviƧos, como, instĆ¢ncias e o seu estado, consumo
de recursos por microsserviƧo, histĆ³rico e documentaĆ§Ć£o de cada microsserviƧo,
nĆŗmero de pedidos efetuados ao microsserviƧo, entre outros.
Pela observaĆ§Ć£o da Figura 6, pode concluir-se que esta abordagem utiliza os seguintes
padrƵes, descoberta de serviƧos (service discovery), self registration e service registry,
descritos anteriormente no capĆtulo 2.
5.2 Gateway e Consul
O Consul Ć© um produto open-source da Hashicorp, desenvolvido com recurso Ć
linguagem Go.
43
Este, segundo Armon Dadgar (Armon Dadgar, 2018), diretor de tecnologia CTO (Chief
Technology Officer) e cofundador da HashiCorp e (Sendil Kumar N & Deepu K
Sasidharan, 2018), apresenta as seguintes funcionalidades:
ā¢ Descoberta de serviƧos: regista os serviƧos e o seu estado, permitindo a
comunicaĆ§Ć£o com os mesmos. A descoberta de um serviƧo pode ser efetuada
por DNS (Domain Name System) ou HTTP (Hypertext Transfer Protocol);
ā¢ DeteĆ§Ć£o de falhas: informaĆ§Ć£o sobre os serviƧos registados, indicando se estĆ”
disponĆvel ou em falha;
ā¢ Armazenamento chave valor: permite armazenar objetos, atravĆ©s de uma chave
Ćŗnica. Esta poderĆ” ser utilizada pelos serviƧos registados para obter o objeto
armazenado;
ā¢ Permite vĆ”rios datacenters: cada datacenter contĆ©m o seu armazenamento
chave valor, permitindo configuraƧƵes diferentes ao utilizador;
ā¢ MonotorizaĆ§Ć£o: apresenta a informaĆ§Ć£o do estado de cada microsserviƧo
atravƩs de uma dashboard;
ā¢ SeguranƧa na comunicaĆ§Ć£o: permite definir regras de comunicaĆ§Ć£o entre os
microsserviƧos;
ā¢ DocumentaĆ§Ć£o: permite visualizar a documentaĆ§Ć£o de cada microsserviƧo,
atravƩs de swagger.
A utilizaĆ§Ć£o desta abordagem resulta numa soluĆ§Ć£o que apresenta a seguinte
arquitetura demonstrada.
Figura 7 ā Diagrama de componentes utilizando Consul, baseado em (JHipster, 2017b)
44
O Consul, similarmente ao JHipster Registry, disponibiliza uma API (Application
Programming Interface), que permite o registo dos microsserviƧos. Estes, quando
iniciam podem registar-se atravĆ©s de um pedido HTTP Ć API, ou atravĆ©s de um ficheiro
de configuraĆ§Ć£o.
Como observado na Figura 7, o processo de comunicaĆ§Ć£o entre os microsserviƧos Ć©
similar ao JHipster Registry, contudo a utilizaĆ§Ć£o do Consul apresenta āa vantagem de
se focar na consistĆŖncia em vez de disponibilidadeā (Sendil Kumar N & Deepu K
Sasidharan, 2018).
5.3 WSO2 API Manager
O WSO2 API Manager, Ć© uma ferramenta open-source, que permite implantar e gerir o
ciclo de vida das API. Esta soluĆ§Ć£o visa facilitar a ācriaĆ§Ć£o, publicaĆ§Ć£o, seguranƧa e
versionamento das APIā atravĆ©s da disponibilizaĆ§Ć£o de componentes especĆficos, tais
como, Developer Portal, API Gateway, Key Manager, Traffic Manager e Analytics (WSO2,
consultado em 2019).
A utilizaĆ§Ć£o desta abordagem resulta numa soluĆ§Ć£o com a seguinte arquitetura.
Figura 8 ā Diagrama de componentes utilizando WSO API Manager, baseado em (Skalena,
2018)
Como Ć© possĆvel observar na Figura 8, a utilizaĆ§Ć£o do WSO2 acrescenta os seguintes
componentes Ć soluĆ§Ć£o (WSO2, consultado em 2019):
ā¢ Analytics ā Apresenta, atravĆ©s da recolha de dados efetuada pela Gateway,
dados estatĆsticos dos acessos a cada microsserviƧo existente na soluĆ§Ć£o.
ā¢ Developer ā Permite testar as API e registar os seus clientes.
45
ā¢ Publisher ā Interface que permite a publicaĆ§Ć£o dos microsserviƧos, respetivas
documentaƧƵes e controlar o ciclo de vida das API. Contrariamente Ć s soluƧƵes
anteriores, apresenta a funcionalidade de colocar ficheiros externos e
documentaĆ§Ć£o atravĆ©s de swagger.
ā¢ Key Manager ā Componente responsĆ”vel pela gestĆ£o dos tokens de acesso e
seguranƧa. O API Gateway efetua comunicaĆ§Ć£o com este componente para
obter e validar o token de acesso.
ā¢ Traffic Manager ā Permite restringir o acesso Ć s API, atravĆ©s do controlo dos
acessos Ć s mesmas.
ā¢ Gateway ā Como apresentado na subsecĆ§Ć£o 2.8, a API Gateway consiste no
ponto de entrada para os clientes que pretendem consumir os serviƧos. Este
componente Ʃ responsƔvel por direcionar os pedidos recebidos para os
respetivos microsserviƧos, de acordo com as polĆticas de uso e verificaƧƵes de
seguranƧa. Este Gateway deverƔ utilizar o API Microgateway do WSO2. AtravƩs
deste componente, serĆ” possĆvel a utilizaĆ§Ć£o do padrĆ£o service discovery,
disponibilizado pelo WSO2, que consiste no armazenamento dos endereƧos
pĆŗblicos atravĆ©s de um servidor etcd. Neste sĆ£o armazenados em formato chave
valor, os endereƧos e uma chave identificadora, que posteriormente, poderƔ ser
utilizada para modificar o endereƧo (Viraj Salaka, 2019).
5.4 AvaliaĆ§Ć£o de abordagens
No contexto deste projeto, o mƩtodo hierƔrquico AHP (Analytical Hierarchy Process)
descrito na secĆ§Ć£o 4.4, serĆ” utilizado com o objetivo de avaliar qual a melhor tecnologia
a utilizar no desenvolvimento da nova soluĆ§Ć£o para a resoluĆ§Ć£o do problema descrito
no capĆtulo 1.
Para a utilizaĆ§Ć£o do mĆ©todo AHP, Ć© necessĆ”rio definir os critĆ©rios a utilizar assim como
as respetivas prioridades. Neste projeto, os critƩrios associados ao problema descrito
sĆ£o:
ā¢ PersonalizaĆ§Ć£o: pretende avaliar as alternativas consoante a possibilidade de
criar ou alterar o componente. Estas alteraƧƵes podem ser visuais ou
comportamentais, caso seja necessĆ”rio para a implementaĆ§Ć£o da soluĆ§Ć£o;
46
ā¢ MonitorizaĆ§Ć£o: pretende avaliar a monitorizaĆ§Ć£o oferecida pelos componentes
das alternativas, focando aspetos como, indicaĆ§Ć£o de trĆ”fego, estado de cada
microsserviƧo, entre outros;
ā¢ Complexidade: pretende avaliar a complexidade exigida para a integraĆ§Ć£o do
componente na soluĆ§Ć£o a ser desenvolvida.
ApĆ³s a definiĆ§Ć£o dos critĆ©rios, iniciou-se a comparaĆ§Ć£o entre os mesmos, definindo os
respetivos pesos indicados na Tabela 4.
Tabela 4 ā ComparaĆ§Ć£o dos critĆ©rios elegidos
CritĆ©rios PersonalizaĆ§Ć£o MonitorizaĆ§Ć£o Complexidade
PersonalizaĆ§Ć£o 1 1/4 1/3
MonitorizaĆ§Ć£o 4 1 2
Complexidade 3 1/2 1
A seguinte fase, inicia-se pela realizaĆ§Ć£o de soma de cada coluna da tabela acima
representada (Saaty, 2008), resultando os valores presentes na Tabela 5.
Tabela 5 ā Soma das colunas da comparaĆ§Ć£o dos critĆ©rios
Soma 8 7/4 10/3
AtravĆ©s da soma dos valores de cada coluna, Ć© possĆvel realizar-se a normalizaĆ§Ć£o da
matriz inicial, dividindo cada elemento pela soma total da coluna (Saaty, 2008),
ilustrado na Tabela 6.
Tabela 6 ā Matriz normalizada
CritĆ©rios PersonalizaĆ§Ć£o MonitorizaĆ§Ć£o Complexidade
PersonalizaĆ§Ć£o 0.125 0.1429 0.1
47
MonitorizaĆ§Ć£o 0.5 0.5714 0.6
Complexidade 0.375 0.2857 0.3
Os valores presentes na Tabela 6, podem ser apresentados em forma de tabela ou
atravƩs de matriz.
De modo a terminar esta fase, Ʃ necessƔrio obter o vetor de prioridades relativas. Este
resulta da mƩdia dos valores de cada linha da matriz normalizada ilustrada na Tabela 6.
Vetor de prioridades = [0.12260.55710.3202
]
AtravĆ©s deste valor, Ć© possĆvel concluir que o critĆ©rio monotorizaĆ§Ć£o Ć© considerado o
mais importante, seguido da complexidade e personalizaĆ§Ć£o.
Uma vez terminada esta fase, segue-se a avaliaĆ§Ć£o da consistĆŖncia das prioridades
relativas. Deste modo, Ć© necessĆ”rio o cĆ”lculo da razĆ£o de consistĆŖncia (RC), que Ć© obtida
atravĆ©s da divisĆ£o do Ćndice de consistĆŖncia (IC) pelo Ćndice aleatĆ³rio (IR), āreferente a
um grande nĆŗmero de comparaƧƵes par a par efetuadasā (Saaty, 2008). Para calcular o
IC Ć© necessĆ”rio efetuar a multiplicaĆ§Ć£o da matriz representada na Tabela 4 pelo vetor
de prioridades.
Efetuados os primeiros cƔlculos obteve-se o seguinte vetor:
[0.36861.68790.9666
]
Posteriormente, para obter o valor prĆ³prio para calcular o IC, Ć© necessĆ”rio dividir o
vetor resultante pelo vetor de prioridades e efetuar a mƩdia dos resultados obtidos.
Valor prĆ³prio = 3.0183
Com este valor Ć© possĆvel obter o IC e posteriormente o RC:
IC = 0.0091 RC = 0.0158
Uma vez que o valor obtido Ć© menor que 0.1, pode se afirmar que os valores das
prioridades relativas estĆ£o consistentes (Saaty, 2008).
48
De seguida, Ʃ necessƔrio construir uma matriz que compare as alternativas
relativamente ao critƩrio a analisar e repetir o processo de determinar a prioridade
relativa, como demostrado acima.
CritĆ©rio personalizaĆ§Ć£o:
Alternativas Gateway e JHipster Registry
Gateway e Consul
WSO2 API Manager
Gateway e JHipster Registry
1 5 3
Gateway e Consul 1/5 1 1/3
WSO2 API Manager 1/3 3 1
Soma 23/15 9 13/3
Matriz normalizada = [0.6522 0.5556 0.69230.1304 0.1111 0.07690.2174 0.3333 0.2308
]
Vetor de prioridades = [0.63330.10620.2605
]
CritĆ©rio monitorizaĆ§Ć£o:
Alternativas Gateway e JHipster Registry
Gateway e Consul
WSO2 API Manager
Gateway e JHipster Registry
1 3 7
Gateway e Consul 1/3 1 5
49
WSO2 API Manager 1/7 1/5 1
Soma 31/21 21/5 13
Matriz normalizada = [0.6774 0.7143 0.53850.2258 0.2381 0.38460.0968 0.0476 0.0769
]
Vetor de Prioridades = [0.64340.28280.0738
]
CritƩrio complexidade:
Alternativas Gateway e JHipster Registry
Gateway e Consul
WSO2 API Manager
Gateway e JHipster Registry
1 1 5
Gateway e Consul 1 1 5
WSO2 API Manager 1/5 1/5 1
Soma 11/5 11/5 11
Matriz normalizada = [0.4545 0.4545 0.45450.4545 0.4545 0.45450.0909 0.0909 0.0909
]
Vetor de Prioridades = [0.45450.45450.0909
]
50
De acordo com (Saaty, 2008), apĆ³s o cĆ”lculo do vetor de prioridade de cada critĆ©rio Ć©
necessĆ”rio obter a prioridade composta para as alternativas em avaliaĆ§Ć£o. Esta, Ć© obtida
atravĆ©s da multiplicaĆ§Ć£o dos vetores anteriores agregados numa Ćŗnica matriz, pelos
valores dos pesos dos critĆ©rios, obtidas no inĆcio deste mĆ©todo.
[0.6333 0.6434 0.45450.1062 0.2828 0.45450.2605 0.0738 0.0909
] x [0.12260.55710.3202
] = [0.58160.31610.1021
]
Pode concluir-se que a soluĆ§Ć£o mais indicada para resolver o problema proposto Ć© a
utilizaĆ§Ć£o da alternativa Gateway e JHipster Registry, sendo esta a opĆ§Ć£o selecionada
para este trabalho.
Em segundo lugar ficou a alternativa Gateway e Consul e por Ćŗltimo, a alternativa do
WSO2 API Manager.
51
6 Estudo de caso ā Logistics
Como se referiu no capĆtulo 1 a aplicaĆ§Ć£o Logistics desenvolvida pela empresa Flowinn,
maioritariamente dedicada Ć gestĆ£o de armazĆ©ns da indĆŗstria farmacĆŖutica encontra-
se desenvolvida assente numa arquitetura monolĆtica. No entanto a empresa percebeu
que deve melhorar o seu produto para se manter competitiva no mercado. O principal
objetivo desta aplicaĆ§Ć£o Ć© auxiliar a gestĆ£o dos processos presentes no quotidiano dos
armazĆ©ns dos seus clientes. ApĆ³s um processo de anĆ”lise Ć ferramenta e aos pedidos
dos clientes, a empresa optou por tentar a abordagem de transformar a sua aplicaĆ§Ć£o
monolĆtica numa baseada em microsserviƧos, partindo das premissas do capĆtulo 1.
As seƧƵes seguintes apresentam a atual arquitetura (AS IS), e aquela que neste trabalho
se propƵe para dar resposta aos problemas identificados no capĆtulo 1 (TO BE).
6.1 AplicaĆ§Ć£o monolĆtica ā āAs isā
A aplicaĆ§Ć£o monolĆtica abordada nesta dissertaĆ§Ć£o, como descrito no capĆtulo 1, surgiu
com o intuito de auxiliar a gestĆ£o dos processos presentes no quotidiano dos armazĆ©ns
dos seus clientes.
Neste capĆtulo, serĆ” analisada de forma detalhada esta aplicaĆ§Ć£o, de modo a
contextualizar os seus componentes e respetiva lĆ³gica.
6.1.1 Arquitetura
A aplicaĆ§Ć£o monolĆtica atual, Logistics, desenvolvida pela empresa Flowinn, com
recurso Ć framework JHipster, utiliza Spring no back-end e Angular 8 no front-end. O
52
intuito desta aplicaĆ§Ć£o Ć© auxiliar e otimizar os principais processos dos armazĆ©ns dos
clientes, sendo eles: receĆ§Ć£o, arrumaĆ§Ć£o e a expediĆ§Ć£o.
Para a otimizaĆ§Ć£o supracitada, a aplicaĆ§Ć£o Logistics partilha a sua base de dados com a
aplicaĆ§Ć£o Logistics Intelligence. Esta Ć© responsĆ”vel pela anĆ”lise das aƧƵes no quotidiano
do armazĆ©m do cliente e pela aplicaĆ§Ć£o de modelos matemĆ”ticos, visando otimizar a
eficƔcia das mesmas.
Os utilizadores da soluĆ§Ć£o Logistics nĆ£o interagem diretamente com a aplicaĆ§Ć£o
Logistics Intelligence, uma vez que esta nĆ£o apresenta front-end, apresenta apenas
back-end desenvolvido em Spring, responsƔvel por consumir diretamente os dados da
aplicaĆ§Ć£o Logistics, atravĆ©s do acesso direto Ć sua base de dados.
A aplicaĆ§Ć£o Logistics comunica tambĆ©m com o ERP (Enterprise Resource Planning) de
cada cliente. O ERP Ć© um sistema de informaĆ§Ć£o utilizado pelos clientes para gerir todos
os processos do armazĆ©m. Contudo, este Ć© um sistema legado, de difĆcil consulta da
informaĆ§Ć£o diretamente no mesmo.
A arquitetura das soluƧƵes acima referidas Ʃ apresentada na Figura 9.
Figura 9 ā Diagrama de componentes das aplicaƧƵes monolĆticas
Neste diagrama pode verificar-se que o front-end Ć© constituĆdo por trĆŖs componentes,
sendo eles:
ā¢ View: Template HTML (HyperText Markup Language) responsĆ”vel por
apresentar os dados aos utilizadores da aplicaĆ§Ć£o;
ā¢ Component: Permite criar e apresentar as views e sĆ£o responsĆ”veis por gerir a
interaĆ§Ć£o do utilizador com a aplicaĆ§Ć£o;
53
ā¢ Services: ResponsĆ”vel por comunicar com o back-end da aplicaĆ§Ć£o atravĆ©s de
pedidos REST (Representational State Transfer).
O back-end da mesma, por sua vez, Ć© constituĆdo por quatro componentes:
ā¢ Resources: Declara os mĆ©todos HTTP da aplicaĆ§Ć£o e encaminha os pedidos do
front-end para o respetivo service;
ā¢ Services: ResponsĆ”vel por aplicar as regras e lĆ³gica de negĆ³cio da aplicaĆ§Ć£o;
ā¢ Repository: Camada responsĆ”vel por gerir a comunicaĆ§Ć£o com a base de dados
e garantir a persistĆŖncia da informaĆ§Ć£o;
ā¢ Entities: RepresentaĆ§Ć£o dos objetos presentes no domĆnio.
O back-end da aplicaĆ§Ć£o Logistics Intelligence Ć© constituĆdo pelos resources, entities e
services que apresentam a mesma responsabilidade dos anteriores referidos, no
entanto estes Ćŗltimos sĆ£o tambĆ©m responsĆ”veis por abrir uma conexĆ£o Ć base de dados
e guardar as alteraƧƵes.
No diagrama estĆ” representada a base de dados MySQL, na qual Ć© armazenada a
informaĆ§Ć£o consumida pelas aplicaƧƵes Logistics e Logistics Intelligence e o ERP, que
representa o sistema de informaĆ§Ć£o dos clientes.
6.1.2 Componentes
Neste subcapĆtulo serĆ£o abordados os componentes do domĆnio das aplicaƧƵes
monolĆticas, bem como as suas dependĆŖncias, sendo que apenas terĆ£o anĆ”lise os
componentes mais relevantes da aplicaĆ§Ć£o Logistics, uma vez que por serem
numerosos torna o diagrama de difĆcil leitura.
54
Figura 10 ā Diagrama de componentes da aplicaĆ§Ć£o Logistics
Observando a Figura 10, pode concluir-se que existe uma elevada dependĆŖncia em
quatros componentes, o general node, product, lot e serial number.
O general node, como o prĆ³prio nome indica, consiste na generalizaĆ§Ć£o das localizaƧƵes
existentes no armazĆ©m e tem o intuito de dividir o mesmo em locais adequados Ć
prƔtica dos diversos processos. Este componente permite que os utilizadores
identifiquem as diversas localizaƧƵes do armazĆ©m e o local de execuĆ§Ć£o de cada
processo.
Por sua vez, os componentes product, lot e serial number, representam respetivamente,
os produtos presentes no armazĆ©m, os diversos lotes e o nĆŗmero de sĆ©rie de cada
produto ou de cada lote.
Um lote, representa um conjunto de produtos com uma determinada caracterĆstica que
lhes Ć© idĆŖntica, enquanto que o nĆŗmero de sĆ©rie identifica a unidade de um produto.
Assim, atravĆ©s destes componentes Ć© possĆvel aos utilizadores conseguirem rastrear
cada produto desde o momento da sua entrada no armazĆ©m atĆ© Ć saĆda do mesmo, o
que facilita a organizaĆ§Ć£o e a economia de tempo ao longo dos processos.
Como analisado na Figura 9, a aplicaĆ§Ć£o Logistics partilha a sua base de dados com a
aplicaĆ§Ć£o Logistics Intelligence. Esta partilha poderĆ”, posteriormente, condicionar a
55
migraĆ§Ć£o arquitetural deste projeto, assim sendo, Ć© necessĆ”rio entender os
componentes desta Ćŗltima aplicaĆ§Ć£o que sĆ£o essenciais e poderĆ£o influenciar a
migraĆ§Ć£o.
Figura 11 ā Diagrama de componentes da aplicaĆ§Ć£o Logistics Intelligence
A aplicaĆ§Ć£o Logistics Intelligence verifica, periodicamente a existĆŖncia de processos que
necessitam de otimizaĆ§Ć£o atravĆ©s do componente Scheduler. Se for verificada a
existĆŖncia desses processos, esta aplicaĆ§Ć£o necessitarĆ” de recorrer Ć base de dados para
obter toda informaĆ§Ć£o necessĆ”ria a fim de aplicar os modelos matemĆ”ticos de
otimizaĆ§Ć£o desenvolvidos no componente Simplex Model. A pesquisa pela informaĆ§Ć£o
necessƔria estƔ dividida em componentes com base nas tabelas existentes na base de
dados partilhada, e Ć© efetuada separadamente em cada componente, nomeadamente
o Wms General, Wms Stock, Wms Shipping e Wms Optimization. Por fim, o Wms
Transactional Ʃ um componente responsƔvel pelo retrocesso das transaƧƵes efetuadas
na base de dados caso ocorra algum erro ao longo dos processos.
6.1.3 ImplantaĆ§Ć£o
Este subcapĆtulo descreve o processo de implantaĆ§Ć£o da aplicaĆ§Ć£o monolĆtica em
utilizaĆ§Ć£o pela empresa Flowinn e a que serĆ” utilizada posteriormente no processo de
avaliaĆ§Ć£o de resultados para a comparaĆ§Ć£o entre esta aplicaĆ§Ć£o e aquela que Ć©
desenvolvida no Ć¢mbito deste trabalho baseada em microsserviƧos.
Atualmente, a empresa Flowinn, usufrui do serviƧo Bitbucket Pipelines, contudo devido
Ć extensa duraĆ§Ć£o das builds da aplicaĆ§Ć£o, este serviƧo nĆ£o se encontra em utilizaĆ§Ć£o.
Assim, quando Ć© necessĆ”ria a atualizaĆ§Ć£o da aplicaĆ§Ć£o nos diversos ambientes,
nomeadamente em testes ou produĆ§Ć£o, Ć© necessĆ”ria a execuĆ§Ć£o de diversos processos
de forma manual por parte dos programadores da empresa.
56
Inicialmente, o programador executa a build no seu computador atravƩs do Maven, e
transfere o ficheiro resultante da mesma para o ambiente que pretende efetuar a
implantaĆ§Ć£o, atravĆ©s de uma ligaĆ§Ć£o SSH (Secure Shell).
Posteriormente, efetua uma sequĆŖncia de comandos, responsĆ”veis pela criaĆ§Ć£o do
backup da implantaĆ§Ć£o anterior e a execuĆ§Ć£o da nova versĆ£o a implantar.
A figura seguinte ilustra o ambiente de produĆ§Ć£o desta aplicaĆ§Ć£o.
Figura 12 ā Diagrama de implantaĆ§Ć£o da aplicaĆ§Ć£o monolĆtica
Como Ć© possĆvel observar no diagrama, a implantaĆ§Ć£o Ć© constituĆda pelos monĆ³litos,
Logistics e Logistics Intelligence, que se conectam Ć base de dados Ćŗnica.
O servidor representa uma mĆ”quina Linux com 8 RAM (memĆ³ria que permite leitura e
escrita de informaĆ§Ć£o) e 2 CPU.
6.2 Arquitetura baseada em microsserviƧos ā āTo beā
Nesta secĆ§Ć£o, Ć© apresentada a arquitetura que se propƵe implementar, com o intuito
de responder ao problema descrito no capĆtulo 1, no entanto, deve ressalvar-se que
este trabalho Ć© desenvolvido num ambiente dinĆ¢mico, no que respeita Ć estratĆ©gia e
opƧƵes tomadas pela empresa Flowinn, a arquitetura proposta encontra-se
representada na Figura 13.
57
Figura 13 ā Diagrama de componentes da soluĆ§Ć£o a implementar
6.2.1 Gateway e JHipster Registry
Como se concluiu no capĆtulo anterior, a alternativa mais adequada para a
implementaĆ§Ć£o desta soluĆ§Ć£o Ć© o Gateway e JHipster Registry. Esta escolha deve-se Ć
detalhada monitorizaĆ§Ć£o de toda a soluĆ§Ć£o e Ć reduzida complexidade acrescentada.
A utilizaĆ§Ć£o desta alternativa permite resolver problemas comuns em arquiteturas
baseadas em microsserviƧos, tais como, descoberta de serviƧos, monitorizaĆ§Ć£o da
disponibilidade e gestĆ£o dos mesmos.
6.2.2 Base de dados para cada microsserviƧo
Com o intuito de efetuar a migraĆ§Ć£o da aplicaĆ§Ć£o monolĆtica para microsserviƧos,
deverĆ” ter-se em conta a divisĆ£o da base de dados Ćŗnica, para uma base de dados por
microsserviƧo. Esta abordagem, como apresentado na secĆ§Ć£o 2.4, permite manter o
baixo acoplamento e isolar a informaĆ§Ć£o presente em cada microsserviƧo,
contrariamente Ć abordagem de uma base de dados Ćŗnica para todos os microsserviƧos.
Esta Ćŗltima, aumenta as dependĆŖncias no caso dos microsserviƧos serem desenvolvidos
58
por diversas equipas, dificulta e atrasa o processo de implantaĆ§Ć£o automĆ”tico, uma vez
que, pode necessitar de coordenaĆ§Ć£o das alteraƧƵes efetuadas Ć base de dados.
6.2.3 Apache Kafka
Apache Kafka Ć© a abordagem pretendida para a soluĆ§Ć£o, uma vez que, um dos objetivos
Ć© a escalabilidade. Como se referiu na secĆ§Ć£o 2.12, esta abordagem apresenta melhores
resultados em relaĆ§Ć£o ao RabbitMQ, prevenindo assim, possĆveis problemas neste
Ć¢mbito, bem como, melhor desempenho atravĆ©s de menos recursos, perante situaƧƵes
de elevado fluxo de dados.
Relativamente ao processo de implantaĆ§Ć£o, este serĆ” automatizado com recurso Ć s
ferramentas apresentadas na Figura 14.
Figura 14 ā Ferramentas a utilizar na automatizaĆ§Ć£o do processo de implantaĆ§Ć£o
6.2.4 Bitbucket Pipelines
O Bitbucket Pipelines Ć© a abordagem escolhida para esta soluĆ§Ć£o.
Apesar do Jenkins ser uma abordagem gratuita, necessita mais esforƧo para colocar em
prĆ”tica. A sua utilizaĆ§Ć£o necessita a configuraĆ§Ć£o do servidor e dos plugins necessĆ”rios.
Por sua vez, este servidor necessita de ser implantado para que seja acedido,
apresentando custos adicionais Ć empresa.
A abordagem escolhida, Bitbucket Pipelines Ʃ um serviƧo incorporado no Bitbucket, o
que evita a utilizaĆ§Ć£o recursos para a sua instalaĆ§Ć£o. Os serviƧos disponibilizados por
esta abordagem, apresentam vantagens para o quotidiano dos programadores da
59
mesma, uma vez que, serĆ” possĆvel visualizar as funcionalidades implantadas em cada
build atravƩs do produto Jira.
Por fim, apesar desta abordagem ser um produto pago, atualmente, a empresa Flowinn,
usufrui de um plano constituĆdo pelos produtos Bitbucket e Jira. Este oferece um
plafond de minutos mensais para builds atravƩs do serviƧo Bitbucket Pipelines, apesar
de atualmente, esta funcionalidade nĆ£o estar a ser utilizado pela empresa.
6.2.5 Docker
Docker, como descrito na subsecĆ§Ć£o 2.13.4, Ć© uma ferramenta que permite a
implantaĆ§Ć£o em ambientes controlados e configurĆ”veis.
Esta ferramenta serĆ” utilizada com o intuito de controlar as dependĆŖncias e o ambiente
onde a aplicaĆ§Ć£o serĆ” implantada. Assim, em caso de necessidade de anĆ”lise de erros,
o ambiente onde estes ocorrem Ć© facilmente replicado e analisado.
6.2.6 Google Cloud Platform
O provedor de serviƧos na cloud escolhido para este projeto Ʃ a Google, optando pelo
serviƧo Google Cloud Platform. Os fatores que levam Ć escolha desta alternativa sĆ£o o
preƧo dos serviƧos disponibilizados e a satisfaĆ§Ć£o das necessidades da soluĆ§Ć£o,
nomeadamente escalabilidade, disponibilidade e processos de CI e CD.
Atualmente, a empresa Flowinn definiu o objetivo de mover os seus produtos para
serviƧos na cloud, usufruindo de um contrato com este provedor. Este por sua vez,
oferece os serviƧos pretendidos por um valor mais rentĆ”vel Ć empresa.
Relativamente Ć s outras abordagens estudadas, estas nĆ£o justificariam uma mudanƧa,
considerando os critƩrios de preƧo e os serviƧos necessitados.
61
7 AnĆ”lise e conceĆ§Ć£o
O processo de anĆ”lise e conceĆ§Ć£o visa descrever as tarefas de decomposiĆ§Ć£o, anĆ”lise e
implementaĆ§Ć£o da nova soluĆ§Ć£o. Ao longo deste capĆtulo serĆ” descrito o processo de
anĆ”lise do domĆnio e de levantamento de requisitos, bem como as fraƧƵes a conceber
para a nova soluĆ§Ć£o.
7.1 Requisitos
O processo de desenvolvimento de software deve iniciar-se pela anƔlise de requisitos.
Este permite, iterativamente, identificar as funcionalidades pretendidas pelas partes
interessadas para o sistema, os requisitos funcionais, requisitos nĆ£o funcionais e ainda
as caracterĆsticas do mesmo.
O levantamento de requisitos exaustivo, foi efetuado anteriormente pela empresa
Flowinn aquando do processo de desenvolvimento da aplicaĆ§Ć£o monolĆtica descrita na
secĆ§Ć£o 6.1. Dado o elevado nĆŗmero de requisitos envolvidos serĆ£o apenas analisados,
atravƩs do diagrama ilustrado na Figura 15, os mais importantes e que de alguma forma
condicionam a migraĆ§Ć£o arquitetural proposta neste projeto.
62
Figura 15 ā Diagrama de casos de uso
Como Ć© possĆvel observar no diagrama da Figura 15, a aplicaĆ§Ć£o Logistics apresenta dois
tipos de utilizador, o administrador e os utilizadores regulares. O primeiro Ć©
exclusivamente utilizado pela Flowinn para gerir a aplicaĆ§Ć£o, o segundo engloba os
funcionƔrios do armazƩm do cliente.
Por fim, foram identificados os requisitos nĆ£o funcionais da nova soluĆ§Ć£o:
ā¢ RNF1: O sistema deverĆ” ser facilmente escalĆ”vel, suportando o fluxo de pedidos
efetuados pelo cliente;
ā¢ RNF2: O sistema deve efetuar a importaĆ§Ć£o de dados proveniente do armazĆ©m
de forma assĆncrona, possibilitando que os utilizadores continuem a utilizar a
aplicaĆ§Ć£o;
ā¢ RNF3: A informaĆ§Ć£o presente em todas as bases de dados da aplicaĆ§Ć£o deverĆ”
ser coerente;
ā¢ RNF4: A aplicaĆ§Ć£o deverĆ” suportar os erros que poderĆ£o ocorrer nos processos
quotidianos de gestĆ£o do armazĆ©m.
63
7.2 RepresentaĆ§Ć£o do domĆnio
A decomposiĆ§Ć£o da aplicaĆ§Ć£o monolĆtica serĆ” iniciada atravĆ©s da aplicaĆ§Ć£o do padrĆ£o
DDD (Domain-driven design), descrito no subcapĆtulo 2.3. AtravĆ©s deste padrĆ£o
pretende-se dividir o monĆ³lito e tornĆ”-lo em pequenas partes isoladas, os
microsserviƧos, que representam um determinado contexto do domĆnio da aplicaĆ§Ć£o e
cumprem os seus requisitos.
Finalizada a anĆ”lise do domĆnio completo da aplicaĆ§Ć£o e da aplicaĆ§Ć£o do padrĆ£o descrito,
podem observar-se os microsserviƧos projetados para a nova soluĆ§Ć£o, na Figura 16.
Figura 16 ā MicrosserviƧos Logistics
A Figura 16 ilustra os microsserviƧos constituintes da nova arquitetura da aplicaĆ§Ć£o
Logistics. A seguir descrevem-se os microsserviƧos mais relevantes da soluĆ§Ć£o. A
descriĆ§Ć£o dos restantes pode ser encontrada nos anexos, uma vez que a sua inclusĆ£o
neste ponto do documento tornƔ-lo-ia demasiado maƧador.
7.2.1 Gateway
O Gateway Ć© o ponto de entrada da nova soluĆ§Ć£o, este Ć© responsĆ”vel por omitir a
implementaĆ§Ć£o dos microsserviƧos representados, assim o cliente nĆ£o necessitarĆ” de
comunicar individualmente com os mesmos, uma vez que comunicarĆ” sempre com o
Gateway.
Este componente Ć© constituĆdo pelo front-end, que Ć© composto por toda a informaĆ§Ć£o
visĆvel para os utilizadores, e pelo back-end, responsĆ”vel pelo encaminhamento dos
pedidos para os respetivos microsserviƧos com base na descoberta de serviƧos,
proveniente do JHipster Registry e pela gestĆ£o dos utilizadores da aplicaĆ§Ć£o. Esta gestĆ£o
64
permite detetar transversalmente o utilizador ativo na aplicaĆ§Ć£o e partilhar o seu
identificador para que seja possĆvel perceber as suas aƧƵes.
7.2.2 MS1 ā Zones
Figura 17 ā RepresentaĆ§Ć£o do microsserviƧo Zones
Este microsserviƧo representa o domĆnio das zonas nos armazĆ©ns, Ć© responsĆ”vel pela
gestĆ£o das mesmas e por aplicar a respetiva lĆ³gica de negĆ³cio, ilustrada no RF1. NĆ£o
apresenta qualquer dependĆŖncia de outros microsserviƧos, contudo, Ć© um dos mais
importantes, uma vez que como descrito no RF3, sempre que exista a necessidade de
situar algum processo no armazƩm, serƔ necessƔrio identificar a respetiva zona. Nos
microsserviƧos que envolvam estes processos serĆ” guardada uma identidade Ćŗnica da
mesma, denominada de id. Assim, Ć© possĆvel associar a zona ao processo, mantendo o
isolamento e baixo acoplamento de cada microsserviƧo.
7.2.3 MS2 ā Product
65
Figura 18 ā RepresentaĆ§Ć£o do microsserviƧo Product
O Product representa o domĆnio dos produtos existentes nos armazĆ©ns, identifica todos
os produtos presentes no mesmo, RF2, e as suas respetivas caracterĆsticas,
nomeadamente o lote, cĆ³digo de barras e nĆŗmero de sĆ©rie. Este microsserviƧo engloba
tambĆ©m a qualidade em que os produtos se encontram quando sĆ£o recebidos no
processo da receĆ§Ć£o. Similar ao MS 1 - Zones, este microsserviƧo Ć© dos mais importantes
na soluĆ§Ć£o, uma vez que outros necessitam do domĆnio de produtos para realizar os
seus processos, como enunciado no RF5. De modo a resolver esta dependĆŖncia de
domĆnio e melhorar a performance da soluĆ§Ć£o na apresentaĆ§Ć£o de dados para os
utilizadores, serĆ” duplicada a informaĆ§Ć£o do produto nos microsserviƧos,
nomeadamente a descriĆ§Ć£o e o seu identificador. Assim, serĆ” possĆvel apresentar a
informaĆ§Ć£o atravĆ©s de um pedido ao respetivo microsserviƧo do processo, sem ser
necessƔrio consultar o produto em todos os pedidos efetuados. Apesar desta vantagem,
esta duplicaĆ§Ć£o de informaĆ§Ć£o Ć© suscetĆvel Ć incoerĆŖncia de dados ao longo dos
microsserviƧos, obrigando Ć implementaĆ§Ć£o de um controlo da informaĆ§Ć£o, com o
intuito de a manter sempre coerente ao longo dos microsserviƧos. Este controlo Ʃ
efetuado com recurso Ć s mensagens publicadas no MB, Apache Kafka. Sempre que
estes atributos sejam modificados, Ć© publicada uma mensagem no respetivo tĆ³pico do
MB, os microsserviƧos que guardam esta informaĆ§Ć£o duplicada subscrevem o tĆ³pico e
atualizam a sua base de dados local, mantendo assim a informaĆ§Ć£o coerente em toda a
aplicaĆ§Ć£o.
7.2.4 MS5 ā Numbering Series
66
Figura 19 ā RepresentaĆ§Ć£o do microsserviƧo Numbering Series
A necessidade de o cliente identificar cada processo efetuado no armazƩm, implica uma
lĆ³gica especifica no momento de criaĆ§Ć£o do mesmo e uma vez que Ć© transversal aos
diversos processos, optou-se por isolar a mesma neste microsserviƧo, Numbering Series.
Aquando a criaĆ§Ć£o de um processo que necessite seguir a respetiva ordem aplicada pela
lĆ³gica acima referida, serĆ” necessĆ”rio comunicar com este microsserviƧo e obter o
respetivo nĆŗmero de sĆ©rie do processo.
7.2.5 MS6 ā Stock
Figura 20 ā RepresentaĆ§Ć£o do microsserviƧo Stock
Este microsserviƧo tem o intuito de armazenar as entradas e saĆdas dos produtos nos
armazƩns, permitindo o controlo do stock atual nos mesmos, este processo Ʃ referido
no RF4. Para tal, subscreverĆ” eventos, relativos aos processos que envolvam a
movimentaĆ§Ć£o de produtos no armazĆ©m, publicados no MB, Apache Kafka, e registarĆ”
as respetivas movimentaƧƵes na sua base de dados. De modo a garantir a coerĆŖncia
entre a informaĆ§Ć£o presente nos diversos microsserviƧos Ć© necessĆ”rio recorrer ao
padrĆ£o SAGA, descrito na subsecĆ§Ć£o 2.5, uma vez que caso ocorram falhas,
nomeadamente rutura de stock, Ʃ necessƔrio garantir que as operaƧƵes resultantes do
processo denotem as mesmas para que o utilizador as consulte posteriormente.
7.2.6 MS8 ā Reception
67
Figura 21 ā RepresentaĆ§Ć£o do microsserviƧo Reception
O Reception pretende agrupar o domĆnio relacionado com o processo de receĆ§Ć£o no
armazĆ©m, nomeadamente, o produto rececionado e a sua qualidade. Esta informaĆ§Ć£o
serĆ” armazenada e associada Ć respetiva receĆ§Ć£o. Por sua vez, o reception document
permite ao cliente identificar os documentos que dĆ£o origem Ć s receƧƵes.
Por fim, existindo a necessidade de identificar os utilizadores que executam as receƧƵes,
este microsserviƧo engloba os reception users que duplicam a identificaĆ§Ć£o Ćŗnica do
utilizador, associando-o Ć s respetivas receƧƵes.
Este microsserviƧo Ć© um dos mais importantes da soluĆ§Ć£o, visto que engloba o processo
de receĆ§Ć£o, sendo que este Ć© o mais praticado no armazĆ©m do cliente.
7.2.7 MS10 ā Integrator
Figura 22 ā RepresentaĆ§Ć£o do microsserviƧo Integrator
Este microsserviƧo tem o intuito de centralizar as configuraƧƵes de comunicaĆ§Ć£o com o
ERP utilizado por cada cliente e efetuar as integraƧƵes necessƔrias no mesmo,
nomeadamente a importaĆ§Ć£o e exportaĆ§Ć£o da informaĆ§Ć£o. Assim, as comunicaƧƵes
com sistemas ERP serĆ£o efetuadas exclusivamente atravĆ©s deste microsserviƧo,
68
reduzindo a possĆvel duplicaĆ§Ć£o das configuraƧƵes de cada sistema nos restantes
microsserviƧos.
Posteriormente Ć comunicaĆ§Ć£o com os sistemas referidos, serĆ” publicado um evento
no respetivo tĆ³pico do MB, permitindo ao microsserviƧo referente ao domĆnio da
integraĆ§Ć£o subscrever o mesmo, interpretar e transformar a informaĆ§Ć£o recolhida na
representaĆ§Ć£o do domĆnio e armazenar na sua base de dados.
7.2.8 MS14 ā Optimization
Figura 23 ā RepresentaĆ§Ć£o do microsserviƧo Optimization
O Optimization Ć© responsĆ”vel por gerir a otimizaĆ§Ć£o dos processos de expediĆ§Ć£o no
armazĆ©m. Este irĆ” armazenar a informaĆ§Ć£o que serĆ” utilizada, posteriormente, para
auxiliar os modelos matemƔticos aplicados pelo M15 - Intelligence. Sendo esta
informaĆ§Ć£o referente Ć aplicaĆ§Ć£o Logistics, optou-se pela criaĆ§Ć£o deste microsserviƧo,
invĆ©s de armazenar a informaĆ§Ć£o no M15 - Intelligence. Assim, os modelos matemĆ”ticos
desenvolvidos no mesmo poderĆ£o ser utilizados em diferentes contextos.
7.2.9 MS15 ā Intelligence
Figura 24 ā RepresentaĆ§Ć£o do microsserviƧo Intelligence
A aplicaĆ§Ć£o monolĆtica Logistics Intelligence, descrita na subsecĆ§Ć£o 6.1.2, obtĆ©m a
informaĆ§Ć£o presente na aplicaĆ§Ć£o Logistics atravĆ©s do acesso direto Ć base de dados.
69
Assim, com a migraĆ§Ć£o proposta neste trabalho, o acesso direto obriga tambĆ©m a
migraĆ§Ć£o da primeira aplicaĆ§Ć£o. Pois, anteriormente a informaĆ§Ć£o encontrava-se
presente na Ćŗnica base dados da aplicaĆ§Ć£o Logistics, porĆ©m agora estĆ” dispersa ao longo
dos microsserviƧos conforme o seu domĆnio.
Este acesso direto opƵe-se aos princĆpios e vantagens dos microsserviƧos apresentados
na subsecĆ§Ć£o 2.2, nomeadamente o desacoplamento e isolamento dos microsserviƧos.
7.3 Processos do armazƩm
Neste subcapĆtulo serĆ£o descritos os processos dos armazĆ©ns e algumas das etapas
frequentemente efetuadas no quotidiano. Como consequente resultado da mudanƧa
arquitetural e da utilizaĆ§Ć£o do padrĆ£o base de dados para cada microsserviƧo, a
informaĆ§Ć£o Ć© armazenada ao longo dos diversos microsserviƧos, contrariamente Ć
soluĆ§Ć£o monolĆtica, que se encontra numa base de dados Ćŗnica.
De forma a manter a informaĆ§Ć£o coerente e comunicar as alteraƧƵes ao longo de todos
os microsserviƧos envolvidos no processo, Ć© necessĆ”ria a utilizaĆ§Ć£o dos padrƵes SAGA
e MB, descritos na secĆ§Ć£o 2.
Assim sendo, existiu a necessidade de adaptar a implementaĆ§Ć£o dos diversos processos
dos armazĆ©ns, uma vez que exigem o processamento de informaĆ§Ć£o proveniente de
vƔrios microsserviƧos.
7.3.1 ReceĆ§Ć£o
A receĆ§Ć£o Ć© um dos processos mais importantes no quotidiano do armazĆ©m, inicia-se
com a chegada dos produtos adquiridos nos fornecedores, ao armazƩm do cliente. Este
processo Ć© constituĆdo por vĆ”rias etapas, nomeadamente, receĆ§Ć£o dos produtos
recebidos, verificaĆ§Ć£o da autenticidade e qualidade dos mesmos, separaĆ§Ć£o e
reorganizaĆ§Ć£o dos produtos nos locais destinados Ć prĆ”tica deste processo e por fim o
acrƩscimo dos produtos rececionados ao stock presente no armazƩm.
Estas etapas exigem rigor, pois uma simples falha pode causar elevados prejuĆzos e
influenciar a produtividade nos seguintes processos do armazƩm.
O diagrama ilustrado na Figura 25 descreve o processo de receĆ§Ć£o de um produto.
70
Figura 25 ā Diagrama de sequĆŖncia de rececionamento de produtos
Como se pode observar, o utilizador apenas comunica com o Gateway ao longo de
todos os pedidos efetuados. Este Ʃ responsƔvel por comunicar com os restantes
microsserviƧos dependendo da aĆ§Ć£o que pretende efetuar. O processo inicia-se apĆ³s o
71
utilizador da aplicaĆ§Ć£o indicar o cĆ³digo do produto que pretende rececionar e este ser
validado pelo MS Product. Neste caso o utilizador preenche tambĆ©m o lote e o nĆŗmero
de sĆ©rie do produto em questĆ£o e estas informaƧƵes sĆ£o validadas no MS Product.
ApĆ³s o utilizador inserir a quantidade que pretende rececionar, o Gateway comunica
com o MS Reception. Este Ć© responsĆ”vel pela validaĆ§Ć£o e armazenamento da linha de
receĆ§Ć£o efetuada pelo utilizador. Com o intuito de manter a coerĆŖncia da informaĆ§Ć£o,
estes dois microsserviƧos necessitam de aplicar a lĆ³gica de negĆ³cio ilustrada no
diagrama Figura 25. No caso em que o utilizador comunica uma nova data de validade
de um lote para um produto em questĆ£o, o MS Reception publica o evento no MB
utilizado nesta arquitetura, Apache Kafka, que serĆ” subscrito pelo MS Product. Este,
posteriormente, atualizarĆ” a respetiva data de validade para o lote em questĆ£o. No caso
em que se verifique a necessidade de atualizar a quantidade de um produto com
nĆŗmero de sĆ©rie, serĆ” publicada um outro evento no MB, que permitirĆ” ao MS Product
subscrever e efetuar a lĆ³gica de negĆ³cio especifica. Contudo, no caso de ser necessĆ”rio
criar um lote ou nĆŗmero de serie, serĆ” efetuado um pedido sĆncrono ao MS Product,
uma vez que o MS Reception necessita do identificador Ćŗnico do lote ou do nĆŗmero de
sĆ©rie para continuar a aplicar a sua lĆ³gica de negĆ³cio e posteriormente armazenar a
informaĆ§Ć£o relativa ao produto rececionado. AtravĆ©s deste pedido sĆncrono Ć© possĆvel
assegurar a coerĆŖncia da informaĆ§Ć£o entre ambos os microsserviƧos.
ApĆ³s o armazenamento da informaĆ§Ć£o sobre o produto rececionado, o MS Reception,
comunica o sucesso do procedimento ao Gateway, que por sua vez informa o utilizador.
Posteriormente Ć conclusĆ£o do processo de rececionamento dos produtos
anteriormente detalhado, o utilizador irĆ” finalizar a receĆ§Ć£o, iniciando o processo
descrito na Figura 26.
72
Figura 26 ā Diagrama de sequĆŖncia de finalizaĆ§Ć£o da receĆ§Ć£o
Inicialmente, este processo irĆ” validar a informaĆ§Ć£o submetida pelo utilizador e guardar
na base de dados do microsserviƧo Reception, seguidamente comunicarƔ o sucesso com
o Gateway que por sua vez informarĆ” o utilizador. Aquando a finalizaĆ§Ć£o da receĆ§Ć£o, Ć©
publicado um evento no MB, este serĆ” subscrito pelo MS Operation que darĆ” inĆcio Ć
criaĆ§Ć£o das operaƧƵes resultantes da receĆ§Ć£o em questĆ£o.
De forma similar ao rececionamento de produtos, este processo exige a coerĆŖncia entre
a informaĆ§Ć£o presente na base de dados de dois microsserviƧos, o MS Stock e o MS
Operation, sendo necessĆ”rio recorrer Ć utilizaĆ§Ć£o do padrĆ£o SAGA descrito no
subcapĆtulo 2.5. Este terĆ” inĆcio atravĆ©s da publicaĆ§Ć£o do evento acima descrito. Este
evento serƔ subscrito pelo MS Stock, responsƔvel por validar e atualizar o stock com
base nas operaƧƵes criadas. Dependendo do resultado da movimentaĆ§Ć£o do stock, este
microsserviƧo publica um evento que serƔ subscrito pelo MS Operation, este, por sua
vez, irĆ” atualizar as respetivas operaƧƵes concluindo o processo de finalizaĆ§Ć£o da
receĆ§Ć£o e garantindo a coerĆŖncia entre a informaĆ§Ć£o presente na base de dados de
cada microsserviƧo.
7.3.2 ArrumaĆ§Ć£o
73
Seguidamente, serĆ” analisado o processo de arrumaĆ§Ć£o, este consiste na
movimentaĆ§Ć£o dos produtos de uma zona do armazĆ©m para outra. Este processo Ć©
geralmente efetuado para mover os produtos das zonas de receĆ§Ć£o para as respetivas
zonas do armazƩm, mantendo assim o stock de produtos no armazƩm organizado, o
que facilita os processos posteriores de expediĆ§Ć£o no armazĆ©m.
Seguidamente, na Figura 27, serĆ” analisado detalhadamente a arrumaĆ§Ć£o de um
produto no armazƩm.
Figura 27 ā Diagrama de sequĆŖncia da arrumaĆ§Ć£o de um produto
Como Ć© possĆvel observar na Figura 27, este processo Ć© iniciado pelo utilizador
indicando a zona onde os produtos estĆ£o inicialmente localizados. Esta aĆ§Ć£o Ć©
comunicada com o Gateway, que por sua vez recorre ao microsserviƧo Zones para
validar a zona introduzida. Posteriormente, o utilizador deverĆ” indicar o produto que
pretende mover, este serƔ validado atravƩs do microsserviƧo Stock, que verificarƔ a
74
existĆŖncia do produto em questĆ£o e retornarĆ” a quantidade existente no local.
Posteriormente, o utilizador indicarĆ” a quantidade do produto que pretende
movimentar e a zona destino que serĆ” validada novamente pelo MS Zones.
Seguidamente, serĆ” comunicado ao MS Stowage, o processo de arrumaĆ§Ć£o pretendido.
Este microsserviƧo valida e conclui o processo desencadeando duas aƧƵes simultĆ¢neas,
nomeadamente a comunicaĆ§Ć£o da conclusĆ£o do processo ao Gateway, que informarĆ”
o utilizador, e a publicaĆ§Ć£o de um evento no MB. Este evento serĆ” subscrito pelo MS
Operation, que criarĆ” a operaĆ§Ć£o resultante do processo e seguidamente publicarĆ” um
novo evento no MB.
Similarmente ao processo de finalizaĆ§Ć£o da receĆ§Ć£o, este tambĆ©m exige a coerĆŖncia
entre a informaĆ§Ć£o presente na base de dados do MS Operation e do MS Stock, pelo
que serĆ” aplicado o mesmo padrĆ£o SAGA, ou seja, o MS Stock irĆ” subscrever o evento
publicado pelo MS Operation e realizar a movimentaĆ§Ć£o do stock do produto para a
zona destino. Conforme o sucesso desta movimentaĆ§Ć£o, serĆ” publicado um evento que
serĆ” subscrito pelo MS Operation, que irĆ” atualizar a respetiva operaĆ§Ć£o do processo
de arrumaĆ§Ć£o em questĆ£o.
7.3.3 ExpediĆ§Ć£o
O processo de expediĆ§Ć£o engloba a gestĆ£o das encomendas que os clientes efetuam ao
armazƩm. Este processo deve ser rigoroso e bem executado de modo a obter o maior
lucro possĆvel para o armazĆ©m, sendo o seu foco entregar os produtos aos clientes nas
melhores condiƧƵes e dentro dos prazos estabelecidos. Atualmente a aplicaĆ§Ć£o permite
efetuar esta gestĆ£o atravĆ©s de trĆŖs processos distintos, a criaĆ§Ć£o de encomendas e das
linhas de encomenda e otimizaĆ§Ć£o das mesmas.
De modo a iniciar um processo de expediĆ§Ć£o, o utilizador deverĆ” registar a informaĆ§Ć£o
importante relativa Ć encomenda recebida, nomeadamente, o tipo de processo, o local
e data da entrega da encomenda. Posteriormente o utilizador poderĆ” iniciar o segundo
processo, criaĆ§Ć£o de linhas da encomenda, que pretende registar os produtos e as
respetivas quantidades encomendadas pelo cliente.
Por fim, devido Ć mudanƧa arquitetural, o processo de otimizaĆ§Ć£o foi divido em
subprocessos sendo estes, a aprovaĆ§Ć£o da encomenda e estimativa da mesma.
Esta divisĆ£o visa diminuir a complexidade do processo em si e obter o mĆ”ximo proveito
da assincronia oferecida pelo MB implementado na nova soluĆ§Ć£o. Os subprocessos
executam sem a necessidade de o utilizador intervir e os seus procedimentos serĆ£o
analisados nos seguintes diagramas.
75
Figura 28 ā Diagrama de sequĆŖncia da aprovaĆ§Ć£o da encomenda
Contrariamente aos processos anteriormente analisados, este inicia-se de forma
automĆ”tica. O MS Shipping Order verifica, periodicamente, a existĆŖncia de novas
encomendas e inicia o processo de aprovaĆ§Ć£o, atualizando o estado da encomenda.
Aquando esta atualizaĆ§Ć£o, Ć© publicado um evento no MB, que serĆ” subscrito pelo MS
Stock. Este irĆ” verificar se os produtos pretendidos existem em stock, de modo a
satisfazer a encomenda em questĆ£o.
76
No caso de ausĆŖncia de stock, o processo de aprovaĆ§Ć£o irĆ” terminar atravĆ©s da
publicaĆ§Ć£o de um evento no MB. O MS Shipping Order irĆ” interpretar o evento de nĆ£o
aprovaĆ§Ć£o e atualizarĆ” a encomenda com o respetivo estado. Pelo contrĆ”rio, na
existĆŖncia de stock para a encomenda, o MS Stock, reserva as quantidades necessĆ”rias
publicando o sucesso no MB. Este serĆ” escutado pelo MS Shipping Order, que por sua
vez irĆ” atualizar a encomenda para o estado de aprovada. Esta atualizaĆ§Ć£o, permitirĆ” o
MS Container escutar a aprovaĆ§Ć£o e atribuir a embalagem necessĆ”ria para enviar os
produtos pretendidos ao cliente. Aquando esta atribuiĆ§Ć£o publicarĆ” um evento
conforme o sucesso da operaĆ§Ć£o, permitindo assim ao MS Shipping Order, escutar o
mesmo e atualizar a encomenda na sua base de dados, mantendo a informaĆ§Ć£o
coerente ao longo dos microsserviƧos.
A implementaĆ§Ć£o do MB, permitiu reduzir o tempo total deste processo, dado que
anteriormente, na soluĆ§Ć£o monolĆtica, primeiramente era efetuado a reserva de stock
sem despoletar o inĆcio da criaĆ§Ć£o da embalagem, sendo obrigatĆ³rio a espera pela nova
iteraĆ§Ć£o da tarefa que ocorre a um dado intervalo de tempo.
ApĆ³s a conclusĆ£o da aprovaĆ§Ć£o das encomendas, estas necessitam de ser estimadas e
otimizadas de modo a reduzir o tempo de entrega ao cliente. Este processo serĆ”
analisado detalhadamente no diagrama ilustrado na Figura 29.
77
Figura 29 ā Diagrama de sequĆŖncia da estimativa das encomendas
O MS Shipping Order inicia, periodicamente, este processo, verificando a existĆŖncia de
encomendas disponĆveis para estimar, atualizando o seu estado e publicando um
evento no MB. O MS Optimization irĆ” interpretar o evento anteriormente subscrito e
criar um processo a ser otimizado pelo MS Intelligence. Para tal, o primeiro realiza uma
tarefa periĆ³dica responsĆ”vel por verificar a existĆŖncia de novos processos a ser
otimizados, posteriormente publicados no MB, em forma de evento. Com isto, o MS
Intelligence, subscreverƔ estes eventos e iniciarƔ a estimativa da encomenda atravƩs
dos modelos matemƔticos desenvolvidos. Estes visam otimizar as viagens dos
utilizadores no armazƩm para recolha de produtos. Em caso de insucesso este processo
de estimativa termina com a publicaĆ§Ć£o de um evento no MB, que permite ao MS
Optimization atualizar o seu processo. Contrariamente, em caso de sucesso serĆ£o
publicados dois eventos, um que permite ao MS Shipping Order atualizar a encomenda
em questĆ£o com a respetiva estimativa calculada, e um segundo que permite sinalizar
o processo como executado corretamente no MS Optimization.
78
7.4 Processos de sincronizaĆ§Ć£o
Neste subcapĆtulo serĆ£o descritos os processos de importaĆ§Ć£o de dados provenientes
do ERP do cliente para a aplicaĆ§Ć£o baseada em microsserviƧos.
Anteriormente, como descrito na subsecĆ§Ć£o 6.1.1 e com o intuito de manter a
informaĆ§Ć£o coerente na aplicaĆ§Ć£o relativa aos produtos, clientes, armazĆ©ns e
documentos, a aplicaĆ§Ć£o monolĆtica comunicava com o ERP do cliente. Atualmente, Ć©
necessĆ”rio manter a importaĆ§Ć£o de dados funcional e para tal foi necessĆ”rio criar o MS
Integrator, descrito na subsecĆ§Ć£o 7.2.7.
Ć possĆvel efetuar a importaĆ§Ć£o dos dados atravĆ©s da sequĆŖncia descrita no diagrama
Figura 30.
Figura 30 ā Diagrama de sequĆŖncia da importaĆ§Ć£o de produtos
O diagrama acima ilustra o processo manual de importaĆ§Ć£o de dados dos produtos do
ERP.
Este processo inicia-se pela aĆ§Ć£o do utilizador no Gateway, que comunica a aĆ§Ć£o
pretendida ao MS Integrator. Este microsserviƧo aquando a receĆ§Ć£o do pedido, inicia a
integraĆ§Ć£o dos dados de forma assĆncrona e comunica ao Gateway que o pedido foi
aceite, este Ćŗltimo por sua vez, indica ao utilizador a importaĆ§Ć£o dos produtos. O MS
Integrator Ć© responsĆ”vel pela comunicaĆ§Ć£o e receĆ§Ć£o dos dados proveniente do ERP,
publicando os mesmos no MB atravƩs de um evento. Posteriormente, o MS Product
escuta o evento e transforma os dados provenientes do ERP na representaĆ§Ć£o de
79
domĆnio dos produtos, armazenando os mesmo na base de dados local. Termina assim
o processo de importaĆ§Ć£o dos dados.
Este processo que representa a importaĆ§Ć£o de dados dos produtos Ć© similar Ć s restantes
integraƧƵes, nomeadamente importaĆ§Ć£o de clientes, armazĆ©ns e documentos. Se o
domĆnio a importar difere, o evento publicado e o microsserviƧo que subscreve o
mesmo, tambƩm diferem.
7.5 PadrƵes utilizados
Com o intuito de facilitar e melhorar a qualidade da nova soluĆ§Ć£o, baseada em
microsserviƧos, foram utilizados padrƵes que visam enfrentar algumas das
desvantagens comuns nestas arquiteturas.
Inicialmente no processo de decomposiĆ§Ć£o da aplicaĆ§Ć£o monolĆtica foi utilizado o
padrĆ£o Domain-driven design. Este auxiliou a definiĆ§Ć£o dos microsserviƧos
implementados atravĆ©s da divisĆ£o dos mesmos pelo domĆnio a representar, isolando
assim as regras e lĆ³gica de negĆ³cio do mesmo.
Relativamente ao Gateway, aplica o padrĆ£o API Gateway, descrito na subsecĆ§Ć£o 2.9,
este serĆ” o Ćŗnico ponto da aplicaĆ§Ć£o acessĆvel diretamente pelos utilizadores, ocultando
a implementaĆ§Ć£o de microsserviƧos efetuada. Esta dissimulaĆ§Ć£o permite facilmente
efetuar alteraƧƵes Ć arquitetura de microsserviƧos, sem adicionar complexidade no
front-end visĆvel pelo cliente.
De modo a solucionar a identificaĆ§Ć£o dos microsserviƧos e possibilitar a comunicaĆ§Ć£o
com os mesmos, foi necessĆ”rio a utilizaĆ§Ć£o do padrĆ£o Service Discovery, atravĆ©s do
componente JHipster Registry, detalhado na subsecĆ§Ć£o 5.1. Este Ć© responsĆ”vel por
armazenar a localizaĆ§Ć£o dos microsserviƧos e verificar a sua disponibilidade
periodicamente.
Na decomposiĆ§Ć£o da base de dados foi aplicado o padrĆ£o Database per service, que
consiste na utilizaĆ§Ć£o de uma base de dados por microsserviƧo, permitindo isolar a
informaĆ§Ć£o armazenada do domĆnio, diminuir o acoplamento dos microsserviƧos e
possĆveis quebras de performance no acesso e persistĆŖncia da informaĆ§Ć£o. Um dos
aspetos mais importantes deste padrĆ£o Ć© garantir que as bases de dados sĆ£o acedidas
apenas pelo microsserviƧo a que pertencem, para tal como descrito na anƔlise do MS
Intelligence, foi necessĆ”rio alterar o anterior comportamento da aplicaĆ§Ć£o Logistics
Intelligence, migrando a mesma para o microsserviƧo descrito.
80
Derivado Ć divisĆ£o efetuada na base de dados, foi necessĆ”rio implementar mecanismos
que garantam a coerĆŖncia entre a informaĆ§Ć£o presente nos microsserviƧos,
nomeadamente nos casos em que exista a necessidade de modificar a informaĆ§Ć£o
presente em diversos microsserviƧos, foi aplicado o padrĆ£o SAGA, descrito na
subsecĆ§Ć£o 2.5. Este padrĆ£o foi aplicado baseado em coreografia, ou seja, cada
microsserviƧo apĆ³s realizar a transaĆ§Ć£o local, publica um evento no MB, que serĆ”
subscrito por outros microsserviƧos, acionando assim as suas transaƧƵes locais.
Contudo, se uma transaĆ§Ć£o local falhar, serĆ” publicado o evento de erro, permitindo
aos microsserviƧos reverterem as alteraƧƵes anteriormente efetuadas, garantido assim
a coerĆŖncia da informaĆ§Ć£o nos casos de sucesso e insucesso dos processos.
De modo a efetuar a comunicaĆ§Ć£o entre os microsserviƧos, foram utilizados os dois
padrƵes de comunicaĆ§Ć£o descritos nas subsecƧƵes 2.11 e 2.12, nomeadamente
comunicaĆ§Ć£o sĆncrona e assĆncrona. No decorrer da implementaĆ§Ć£o foi priorizada a
utilizaĆ§Ć£o da comunicaĆ§Ć£o assĆncrona, uma vez que esta apresenta vantagens sobre a
sĆncrona, nomeadamente o microsserviƧo que pretende comunicar nĆ£o necessita de
saber a localizaĆ§Ć£o do destinatĆ”rio, apenas precisa de publicar uma mensagem no MB.
Estas permitem que os destinatĆ”rios possam estar indisponĆveis no momento da
comunicaĆ§Ć£o, jĆ” que permanecerĆ” no MB atĆ© ser processada, isto poderĆ” ocorrer
quando o microsserviƧo destino estiver disponĆvel.
Como descrito na subsecĆ§Ć£o 6.2.3, o MB implementado nesta soluĆ§Ć£o foi o Apache
Kafka, visto que apresenta desempenho superior Ć alternativa RabbitMQ analisada.
Este componente atravĆ©s da publicaĆ§Ć£o e subscriĆ§Ć£o de eventos pelos microsserviƧos,
permite a comunicaĆ§Ć£o entre estes sem saberem da sua existĆŖncia, proporcionando a
reduĆ§Ć£o do acoplamento entre os microsserviƧos.
Por fim, a comunicaĆ§Ć£o sĆncrona foi utilizada apenas em Ćŗltimo recurso, nos casos em
que a assĆncrona nĆ£o poderia ser aplicada, nomeadamente nos processos que
necessitam de informaĆ§Ć£o imediata de outro microsserviƧo para avanƧar com sua lĆ³gica
de negĆ³cio.
81
8 ImplantaĆ§Ć£o da nova soluĆ§Ć£o
Para os processos de desenvolvimento e implantaĆ§Ć£o da nova soluĆ§Ć£o foram aplicados
os conceitos de CI e CD, atravĆ©s da utilizaĆ§Ć£o das ferramentas abordadas na subsecĆ§Ć£o
6.2, o que facilita o processo.
Como jĆ” referido na subsecĆ§Ć£o 6.2, o sistema de controlo de versƵes utilizado pela
empresa Flowinn Ć© o Bitbucket. Este foi utilizado de modo a hospedar os diversos
repositĆ³rios Git e criar versƵes do respetivo cĆ³digo-fonte desenvolvido neste projeto.
Neste projeto foi utilizado um repositĆ³rio Git para cada microsserviƧo e Gateway,
resultando no total de 16 repositĆ³rios, assim serĆ” possĆvel disponibilizar os mesmo de
forma independente.
Ao longo das prĆ³ximas subsecƧƵes serĆ£o descritos o processo de CD e o ambiente de
implantaĆ§Ć£o da nova soluĆ§Ć£o.
8.1 Bitbucket Pipelines
Foi utilizado o Bitbucket Pipelines, serviƧo descrito na subseĆ§Ć£o 6.2.4, para promover a
automatizaĆ§Ć£o das implantaƧƵes e evitar os processos manuais com maior
suscetibilidade a erros. Este, permite aplicar o padrĆ£o de CD atravĆ©s do pipeline
desenvolvido neste projeto e integrar as implantaƧƵes com o produto Jira. Esta
integraĆ§Ć£o serĆ” analisada com mais detalhe no anexo A.2.
82
Cada microsserviƧo terƔ um ciclo de vida independente do desenvolvimento e
implantaĆ§Ć£o. Desta forma, cada um terĆ” um pipeline prĆ³prio, o que se pode observar
com mais detalhe no anexo A.2. Este contƩm as tarefas ilustradas na Figura 31.
Figura 31 ā Pipeline desenvolvido no Bitbucket Pipelines
O pipeline desenvolvido, pretende automatizar o processo de criaĆ§Ć£o da build e
disponibilizaĆ§Ć£o da mesma no ambiente de testes e de produĆ§Ć£o. Como Ć© possĆvel
observar na imagem, este Ć© constituĆdo por quatro steps, sendo eles, configuraĆ§Ć£o do
ambiente de build, Docker Hub, build, Google Platform.
O primeiro step, consiste na definiĆ§Ć£o do ambiente em que o pipeline irĆ” correr, esta
configuraĆ§Ć£o poderĆ” assumir dois valores, dev, representante do ambiente de testes e
prod, que representa o ambiente de produĆ§Ć£o.
O segundo Ć© o step buildĀø que Ć© constituĆdo por quatro subprocessos, nomeadamente
a execuĆ§Ć£o da build atravĆ©s do Maven, execuĆ§Ć£o dos testes unitĆ”rios seguidos de testes
de integraĆ§Ć£o e por fim Ć© criada a imagem Docker. Esta, no step seguinte, Docker Hub,
serĆ” publicada no repositĆ³rio de imagens atravĆ©s de trĆŖs subprocessos. O primeiro
Image Tag, atribui uma Docker Tag Ć imagem anteriormente gerada, fornecendo assim
mais informaĆ§Ć£o sobre a mesma e facilitando a sua identificaĆ§Ć£o e gestĆ£o no futuro. O
subprocesso seguinte consiste no login no repositĆ³rio de imagens, Docker Hub, sendo
que por fim, o Ćŗltimo subprocesso publica a imagem no mesmo.
Com o intuito de facilitar a gestĆ£o dos repositĆ³rios de cada microsserviƧo foi definido a
seguinte nomenclatura.
<<nome da conta>>/<<microsserviƧo>>-<<ambiente de execuĆ§Ć£o>>
83
Com esta nomenclatura Ć© possĆvel identificar o microsserviƧo e o ambiente do
repositĆ³rio. O controlo da versĆ£o das imagens Ć© efetuado atravĆ©s do nĆŗmero da build
no Bitbucket Pipeline, resultando na seguinte nomenclatura para cada imagem:
<<nome da conta>>/<<microsserviƧo>>-<<ambiente de execuĆ§Ć£o>>:<<nĀŗ da build>>
Por fim, o Ćŗltimo step Ć© efetuado de forma distinta conforme o ambiente definido no
pipeline, atravĆ©s do Bitbucket Deployments. Este serviƧo permite a gestĆ£o dos vĆ”rios
ambientes de implantaĆ§Ć£o atravĆ©s da atribuiĆ§Ć£o de nomes diferentes aos mesmos.
Permite tambĆ©m a utilizaĆ§Ć£o de variĆ”veis diferentes conforme a implantaĆ§Ć£o, deste
modo, como descrito detalhadamente no anexo A.2, foi possĆvel a reutilizaĆ§Ć£o de um
step genĆ©rico de implantaĆ§Ć£o, responsĆ”vel por implantar conforme o Deployment
pretendido e previamente configurado.
Este step, Ć© constituĆdo por cinco subprocessos. Os primeiros trĆŖs, sĆ£o responsĆ”veis por
efetuar o login na Google, a ligaĆ§Ć£o ao projeto e ao cluster onde se pretende implantar.
O quarto step atualiza a versĆ£o da imagem Docker executada no cluster Kubernetes e o
Ćŗltimo executa um smoke test, com o intuĆdo de confirmar a disponibilidade da
implantaĆ§Ć£o da soluĆ§Ć£o.
No dia 14 de Agosto, por questƵes internas, a empresa Flowinn, abdicou da ideia de
implantar a soluĆ§Ć£o na Google, optando pela DigitalOcean. Assim, de modo a cumprir
os requisitos da empresa e promover a continuidade do projeto, foi necessƔrio a
adaptaĆ§Ć£o do pipeline jĆ” desenvolvido para a Google.
Tendo estudado e conseguido seguir todos os passos da implantaĆ§Ć£o na plataforma
Google, para a implantaĆ§Ć£o na plataforma DigitalOcean apenas foi necessĆ”rio a criaĆ§Ć£o
do script de implantaĆ§Ć£o no novo provedor de serviƧos cloud, a configuraĆ§Ć£o do
ambiente da nova implantaĆ§Ć£o e a substituiĆ§Ć£o do ambiente a implantar no Ćŗltimo step
do pipeline. Assim, o pipeline resultante, apenas difere no quarto step anteriormente
descrito na Figura 31. Este foi substituĆdo pelo seguinte step.
84
Figura 32 ā Step de implantaĆ§Ć£o na DigitalOcean
Como Ć© possĆvel observar na Figura 32, o step responsĆ”vel por implantar a soluĆ§Ć£o na
DigitalOcean Ć© constituĆdo por cinco subprocessos. O primeiro consiste no download da
interface de linha de comandos da DigitalOcean.
Contrariamente Ć implantaĆ§Ć£o na Google, Ć data da realizaĆ§Ć£o deste projeto, a Atlassian
nĆ£o disponibiliza uma imagem da DigitalOcean (Properdesign, 2019), impossibilitando
a utilizaĆ§Ć£o dos comandos necessĆ”rios para a configuraĆ§Ć£o sem efetuar o download da
interface descrita. Posteriormente sĆ£o efetuados o login e a configuraĆ§Ć£o do cluster
onde se pretende implantar. Finalizando com a implantaĆ§Ć£o da nova imagem criada no
ambiente pretendido e com a execuĆ§Ć£o do smoke test. Este visa confirmar se a
implantaĆ§Ć£o Ć© executada com sucesso e se encontra disponĆvel para os utilizadores.
8.2 Kubernetes
Neste subcapĆtulo serĆ” descrito detalhadamente o processo de configuraĆ§Ć£o efetuado
no Kubernetes e na Google Cloud que possibilitou a implantaĆ§Ć£o da soluĆ§Ć£o
desenvolvida em ambientes cloud.
Com o intuito de proporcionar um ambiente de testes para a soluĆ§Ć£o, foi necessĆ”ria a
criaĆ§Ć£o do cluster Kubernetes e efetuar a gestĆ£o dos recursos alocados a cada
microsserviƧo no mesmo. Ao longo do estudo e preparaĆ§Ć£o desta implantaĆ§Ć£o foram
seguidas boas prƔticas apresentadas pela Google (Qwiklabs, 2020) e Kubernetes
(Configuration Best Practices, 2020), e apresentadas implantaƧƵes diferentes Ć empresa
Flowinn, uma vez que esta irĆ” suportar os custos de manutenĆ§Ć£o da soluĆ§Ć£o
desenvolvida. Para atingir um valor econĆ³mico suportĆ”vel pela empresa, foi necessĆ”ria
85
a reduĆ§Ć£o de nodes a utilizar no cluster e a reduĆ§Ć£o e condicionamento de recursos
disponĆveis para cada microsserviƧo. Como consequĆŖncia desta restriĆ§Ć£o,
posteriormente, quer a escalabilidade quer o desempenho da soluĆ§Ć£o serĆ£o
condicionados.
8.2.1 ImplantaĆ§Ć£o na Google
De modo a facilitar a leitura do diagrama, a implantaĆ§Ć£o serĆ” divida em dois. O primeiro
Ć© de alta granularidade, com o intuito de representar o fluxo de comunicaĆ§Ć£o entre os
microsserviƧos implantados e o segundo pretende complementar a informaĆ§Ć£o com um
maior nĆvel de detalhe.
Figura 33 ā Diagrama de implantaĆ§Ć£o de alta granularidade
Como se pode observar, cada componente Ć© executado com recurso Ć sua imagem
Docker armazenada em repositĆ³rios distintos do Docker Hub. Nesta soluĆ§Ć£o as
comunicaƧƵes serĆ£o efetuadas atravĆ©s dos padrƵes REST, para comunicaƧƵes sĆncronas,
e TCP (Transmission Control Protocol) para as assĆncronas. Por sua vez, as comunicaƧƵes
86
entre os microsserviƧos e as suas respetivas bases de dados sĆ£o efetuadas atravĆ©s de
JDBC (Java Database Connectivity).
Por fim, a implantaĆ§Ć£o da soluĆ§Ć£o desenvolvida serĆ” ilustrada no Figura 34.
87
Figura 34 ā Diagrama de implantaĆ§Ć£o na Google Cloud Platform
Como Ć© possĆvel observar, a implantaĆ§Ć£o resulta no cluster Kubernetes, Logistics,
implantado na Google Cloud Platform. Este cluster foi segmentado em diferentes
88
namespaces, permitindo a implantaĆ§Ć£o de diferentes ambientes, nomeadamente
desenvolvimento e produĆ§Ć£o.
Este cluster Ć© constituĆdo por 4 nodes. Cada node representa uma mĆ”quina virtual do
tipo N1, constituĆda por 2 vCPUās (unidade de processamento em mĆ”quinas virtuais) e
7.5 GB (Gigabyte) de RAM.
Estes sĆ£o responsĆ”veis por assegurar o funcionamento dos pods ilustrados no digrama,
desde a disponibilizaĆ§Ć£o, acessibilidade, escalabilidade e tolerĆ¢ncia Ć s falhas. ApĆ³s a
configuraĆ§Ć£o dos nodes, iniciou-se a configuraĆ§Ć£o e implantaĆ§Ć£o dos respetivos pods,
importante referir que cada pod Ć© constituĆdo por um container Docker. Esta
configuraĆ§Ć£o foi efetuada atravĆ©s de ficheiros na linguagem yaml, como Ć© possĆvel
observar no exemplo descrito no anexo A.3, com exceĆ§Ć£o do pod Apache Kafka. Este
Ćŗltimo, foi implantado com o auxĆlio da ferramenta Helm, descrita no subcapĆtulo 2.13.6.
Na implantaĆ§Ć£o efetuada foram apenas expostos dois componentes, o Gateway e o
JHipster Registry. O primeiro como descrito anteriormente, serĆ” o ponto de entrada dos
utilizadores na aplicaĆ§Ć£o, o segundo apenas serĆ” utilizado pela empresa Flowinn uma
vez que apresenta informaĆ§Ć£o detalhada sobre os microsserviƧos e os seus consumos.
Apesar da implantaĆ§Ć£o estar em completo funcionamento na Google Cloud Platform, a
avaliaĆ§Ć£o da soluĆ§Ć£o terĆ” de ser efetuada na DigitalOcean, pelo motivo descrito no
subcapĆtulo 8.1.
8.2.2 DigitalOcean
A implantaĆ§Ć£o foi realizada atravĆ©s dos mesmos ficheiros Kubernetes, ilustrados no
anexo A.3, uma vez que este Ʃ independente do provedor de serviƧos cloud.
A DigitalOcean apresenta mƔquinas virtuais de diferentes especificaƧƵes, tornando
inevitĆ”vel a mudanƧa dos nodes a utilizar. AtravĆ©s da observaĆ§Ć£o do diagrama de baixa
granularidade representado na Figura 35 Ć© possĆvel observar a nova implantaĆ§Ć£o
efetuada. O diagrama de alta granularidade, mantĆ©m-se igual, com exceĆ§Ć£o de agora
se encontrar implantado na DigitalOcean.
89
Figura 35 ā Diagrama de implantaĆ§Ć£o na DigitalOcean
Similarmente Ć implantaĆ§Ć£o na Google, esta resulta no cluster Kubernetes, Logistics,
segmentado por namespaces.
90
Atualmente, este cluster Ć© constituĆdo por trĆŖs nodes de diferentes especificaƧƵes. Os
nodes 1 e 2 ilustrados na Figura 35, representam uma mĆ”quina virtual constituĆda por
4 vCPUās e 8 GB de RAM cada. O node 3 representa uma mĆ”quina virtual diferente,
constituĆda por 1 vCPUās e 2 GB de RAM.
A escolha de diferentes mƔquinas surge porque na DigitalOcean, quanto maior for a
capacidade do node, mais recursos ficam disponĆveis para a implantaĆ§Ć£o, ou seja, a
utilizaĆ§Ć£o de dois nodes idĆŖnticos ao node 3, ofereceria menos recursos que a utilizaĆ§Ć£o
do node 1 ou 2.
Os componentes expostos desta implantaĆ§Ć£o sĆ£o o Gateway e o JHipster Registry, pelos
motivos previamente descritos na implantaĆ§Ć£o anterior.
Por fim, Ć© de realƧar que esta implantaĆ§Ć£o na plataforma DigitalOcean foi relativamente
simples, uma vez que foram adquiridos os conhecimentos necessƔrios com trabalho
efetuado com a Google Cloud Platform.
91
9 AvaliaĆ§Ć£o
A avaliaĆ§Ć£o da soluĆ§Ć£o desenvolvida Ć© imprescindĆvel, pois permite avaliar se os
objetivos inicialmente propostos sĆ£o atingidos e os problemas ultrapassados. De modo
a efetuar um correto processo de avaliaĆ§Ć£o, primeiramente, deve-se efetuar o seu
plano. Este consiste na definiĆ§Ć£o das mĆ©tricas e metodologias que permitem a avaliaĆ§Ć£o
das mesmas. Assim, este capĆtulo destina-se Ć definiĆ§Ć£o e execuĆ§Ć£o do plano de
avaliaĆ§Ć£o da soluĆ§Ć£o.
9.1 MĆ©tricas
AtravĆ©s da anĆ”lise do problema e objetivos definidos no capĆtulo 1, foram identificadas
mĆ©tricas que devem ser utilizadas, de modo a que seja possĆvel aferir as vantagens e
desvantagens da implementaĆ§Ć£o da nova soluĆ§Ć£o comparativamente ao produto atual,
Logistics.
9.1.1 Desempenho e escalabilidade
O desempenho Ć© um dos fatores que deve estar melhorado na nova soluĆ§Ć£o, resultante
da migraĆ§Ć£o descrita neste trabalho. Esta mĆ©trica Ć© mensurĆ”vel, uma vez que Ć data,
existem ferramentas gratuitas que permitem avaliar aplicaƧƵes, nomeadamente o
JMeter descrito no subcapĆtulo 2.15. Esta ferramenta permite automatizar o processo
de solicitaĆ§Ć£o de funcionalidades das aplicaƧƵes, permitindo assim, verificar o
comportamento das mesmas em diversos cenƔrios, tais como, grande quantidade de
pedidos recebidos.
92
Para avaliar esta mĆ©trica foi necessĆ”rio efetuar os mesmos testes Ć s duas soluƧƵes em
circunstĆ¢ncias idĆŖnticas, de modo a obter resultados vĆ”lidos e fidedignos.
Antes de iniciar a avaliaĆ§Ć£o, foi necessĆ”rio replicar o ambiente de produĆ§Ć£o da aplicaĆ§Ć£o
monolĆtica, descrito no subcapĆtulo 6.1.3, numa mĆ”quina idĆŖntica de testes da empresa
Flowinn. Relativamente a soluĆ§Ć£o baseada em microsserviƧos foi avaliada a
implantaĆ§Ć£o na DigitalOcean descrita no subcapĆtulo 8.2.2.
As mĆ©tricas definidas para avaliar o desempenho e escalabilidade das soluƧƵes tĆŖm por
base o tempo de resposta ao utilizador e a duraĆ§Ć£o da execuĆ§Ć£o do caso de teste.
AtravƩs da interface grƔfica do JMeter foram configurados os pedidos correspondentes
aos casos de teste e as variĆ”veis de execuĆ§Ć£o, tais como, o intervalo de tempo para a
realizaĆ§Ć£o dos pedidos e a quantidade dos mesmos. Para o primeiro foi definido o valor
fixo de dez segundos enquanto que o segundo varia conforme o caso de teste
pretendido.
De modo comparar as duas soluƧƵes foram testados os diversos processos do armazƩm
e sincronizaĆ§Ć£o.
Nos casos de teste onde possa existir impacto de latĆŖncia da rede, foi repetido o
processo cinco vezes e posteriormente calculou-se a mƩdia dos resultados.
ā¢ ReceĆ§Ć£o
Como descrito no subcapĆtulo 7.3, o processo de receĆ§Ć£o Ć© dos mais importantes do
armazĆ©m. No ambiente de produĆ§Ć£o, este processo Ć© o mais utilizado e apresenta
receƧƵes de grande volume de dados. De modo simular o comportamento das
aplicaƧƵes perante um cenĆ”rio idĆŖntico ao descrito foram realizados vĆ”rios testes Ć s
mesmas, variando o nĆŗmero de linhas constituintes da receĆ§Ć£o entre 50 e 5000.
Inicialmente, testou-se o processo de criaĆ§Ć£o das linhas de receĆ§Ć£o obtendo os
resultados detalhados no anexo A.4.1. para posteriormente se realizar a mƩdia dos
mesmos. Os valores obtidos estĆ£o apresentados no seguinte grĆ”fico.
93
Figura 36 ā Tempo mĆ©dio de resposta na criaĆ§Ć£o de linhas de receĆ§Ć£o
AtravĆ©s da anĆ”lise dos resultados pode concluir-se que a aplicaĆ§Ć£o monolĆtica
demonstrou melhor desempenho perante um reduzido nĆŗmero de linhas,
nomeadamente 50, 100 e 500 pedidos. PorĆ©m para nĆŗmeros mais elevados, 1000, 2000
e 5000 pedidos, a aplicaĆ§Ć£o baseada em microsserviƧos, apresentou melhores tempos
de resposta, estes devem-se ao comportamento de escalabilidade automƔtica do
Kubernetes. ApĆ³s o aumento significativo do nĆŗmero de pedidos, o Kubernetes atribui
mais recursos de processamento e memĆ³ria ao microsserviƧo responsĆ”vel pelas
receƧƵes, MS8 ā Receptions, resultando na diminuiĆ§Ć£o do tempo de resposta ao
utilizador.
Assim conclui-se que, para receƧƵes com elevado nĆŗmero de linhas a aplicaĆ§Ć£o baseada
em microsserviƧos Ʃ significativamente mais rƔpida.
Posteriormente Ć receĆ§Ć£o de todos os produtos Ć© necessĆ”rio finalizar as respetivas
receƧƵes, despoletando o processo ilustrado na Figura 25 do subcapĆtulo 7.3.
Figura 37 ā Tempo de resposta mĆ©dio na finalizaĆ§Ć£o das receƧƵes
62.532 63.904 71.7392
141.076 140.6877
793.97372
68.28 69.916 88.9012
90.2936 74.8 105.7974
0
200
400
600
800
1000
50 100 500 1000 2000 5000Te
mp
o d
e re
spo
sta
(ms)
NĀŗ de pedidos
MonĆ³litica MicrosserviƧos
51.55295.4
542.19
9491348
2822
75.55298 602.25
840
895
941
0
1000
2000
3000
50 100 500 1000 2000 5000
Tem
po
de
resp
ost
a m
Ć©dio
(m
s)
NĀŗ de pedidos
MonĆ³litica MicrosserviƧos
94
Figura 38 ā DuraĆ§Ć£o do processo de finalizaĆ§Ć£o das receƧƵes
Como Ć© possĆvel observar no grĆ”fico Figura 37, similarmente Ć criaĆ§Ć£o das linhas de
receĆ§Ć£o, para o nĆŗmero de 50, 100 e 500, a aplicaĆ§Ć£o monolĆtica respondeu em menor
espaƧo de tempo comparativamente a aplicaĆ§Ć£o baseada em microsserviƧos, contudo
para os testes com maior nĆŗmero de pedidos, a aplicaĆ§Ć£o monolĆtica demora
significativamente mais tempo a responder ao utilizador.
ApĆ³s receber os pedidos, as aplicaƧƵes executam o processo de finalizaĆ§Ć£o da receĆ§Ć£o,
este processo deve ser realizado no menor tempo possĆvel pois a sua conclusĆ£o Ć© fulcral
para manter a coerĆŖncia entre o stock de produtos no armazĆ©m e para a continuaĆ§Ć£o
dos restantes processos do mesmo. Assim, optou-se pela recolha da duraĆ§Ć£o dos
processos em ambas as soluƧƵes, representada no grĆ”fico Figura 38. A soluĆ§Ć£o baseada
em microsserviƧos apresenta uma melhoria significativa no tempo de duraĆ§Ć£o do
processo, demostrando que a utilizaĆ§Ć£o da comunicaĆ§Ć£o assĆncrona implementada ao
longo dos microsserviƧos atravĆ©s da utilizaĆ§Ć£o de eventos com recurso ao MB Apache
Kafka, beneficia o processo, apresentando uma reduĆ§Ć£o da duraĆ§Ć£o relativamente Ć
comunicaĆ§Ć£o sĆncrona atualmente em uso na aplicaĆ§Ć£o monolĆtica.
ā¢ ArrumaĆ§Ć£o
Este processo foi avaliado com base no mesmo mĆ©todo utilizado na finalizaĆ§Ć£o da
receĆ§Ć£o, uma vez que para a realizaĆ§Ć£o deste processo Ć© importante saber o tempo de
resposta da aplicaĆ§Ć£o ao utilizador e o intervalo de tempo para o processo ser concluĆdo.
Este processo, similarmente Ć s receƧƵes, reflete a movimentaĆ§Ć£o do stock de produtos
no armazĆ©m, exigindo assim a coerĆŖncia da informaĆ§Ć£o presente na aplicaĆ§Ć£o e no
armazĆ©m do cliente, possibilitando o processo posterior, a expediĆ§Ć£o dos produtos.
Assim, foram efetuados os testes ao processo, simulando a arrumaĆ§Ć£o de 50, 100, 500
produtos, atravĆ©s da realizaĆ§Ć£o dos pedidos Ć s aplicaƧƵes. Contrariamente ao processo
de receĆ§Ć£o, a arrumaĆ§Ć£o nĆ£o Ć© solicitada com tanta regularidade pelos funcionĆ”rios do
0:24 0:25 0:28 0:360:56
6:13
0:10 0:10 0:11 0:130:21 0:54
0:00
2:24
4:48
7:12
50 100 500 1000 2000 5000
Du
raĆ§Ć£
o (
Min
uto
s:Se
gun
do
s)
NĀŗ de pedidos
MonĆ³litica MicrosserviƧos
95
armazĆ©m, sendo assim aceitĆ”vel a reduĆ§Ć£o do nĆŗmero mĆ”ximo de pedidos para 500
invƩs de 5000.
Os resultados obtidos apĆ³s a realizaĆ§Ć£o dos testes descritos sĆ£o ilustrados nos seguintes
grƔficos.
Figura 39 ā Tempo de resposta mĆ©dio do processo de arrumaĆ§Ć£o
Figura 40 ā DuraĆ§Ć£o mĆ©dia do processo de arrumaĆ§Ć£o
AtravƩs dos grƔficos apresentados pode concluir-se que o tempo de resposta da
aplicaĆ§Ć£o monolĆtica Ć© inferior Ć aplicaĆ§Ć£o baseada em microsserviƧos em todos os
casos de testes, contudo o mesmo nĆ£o acontece com a mĆ©dia da duraĆ§Ć£o do processo
em cada caso de testes. Esta, na aplicaĆ§Ć£o baseada em microsserviƧos Ć©
significativamente mais reduzida que na aplicaĆ§Ć£o monolĆtica. Esta reduĆ§Ć£o, deve-se Ć
alteraĆ§Ć£o efetuada ao processo, uma vez que na nova soluĆ§Ć£o sĆ£o utilizados eventos
para dar seguimento ao processo, contrariamente ao processo na aplicaĆ§Ć£o monolĆtica
que recorre ao agendamento da tarefa que verifica se existem novos processos para
iniciar.
Por fim, serĆ£o descritos os testes realizados ao Ćŗltimo processo do armazĆ©m, a
expediĆ§Ć£o.
34.56 32.454 30.948
60.896 55.906 59.5868
0
20
40
60
80
50 100 500
Tem
po
de
resp
ost
a m
Ć©dio
(m
s)
NĀŗ de pedidos
MonĆ³litica MicrosserviƧos
0:19 0:20
0:31
0:02 0:02
0:10
0:00
0:07
0:14
0:21
0:28
0:36
50 100 500
Du
raĆ§Ć£
o m
Ć©dia
(M
inu
tos:
Segu
nd
os)
NĀŗ de pedidos
MonĆ³litica MicrosserviƧos
96
ā¢ ExpediĆ§Ć£o
Atualmente, o processo de expediĆ§Ć£o, similarmente Ć arrumaĆ§Ć£o, nĆ£o Ć©
frequentemente utilizado pelos funcionƔrios do armazƩm, sendo assim necessƔrio
realizar casos de testes para um processo de expediĆ§Ć£o com 50, 100 e 500 linhas. Estes
valores visam simular o comportamento das aplicaƧƵes no ambiente de produĆ§Ć£o,
permitindo identificar se a nova soluĆ§Ć£o trarĆ” melhorias imediatas Ć empresa Flowinn.
Como Ć© possĆvel verificar na Figura 28 do subcapĆtulo 7.3, o processo de expediĆ§Ć£o
inicia-se sem a aĆ§Ć£o do utilizador, assim foi recolhida a duraĆ§Ć£o do processo para cada
caso de teste. Este procedimento foi repetido 5 vezes, tendo-se calculado por fim a
mĆ©dia da duraĆ§Ć£o como observar nos seguintes parĆ”grafos e no anexo A.4.1.
Figura 41 ā DuraĆ§Ć£o mĆ©dia do processo de expediĆ§Ć£o
Similarmente aos resultados obtidos nos processos anteriores, a aplicaĆ§Ć£o baseada em
microsserviƧos demostrou melhor desempenho, reduzindo significativamente o tempo
de duraĆ§Ć£o de cada processo de expediĆ§Ć£o comparativamente aos demostrados pela
aplicaĆ§Ć£o monolĆtica.
ConcluĆdos os testes aos processos do armazĆ©m, seguiu-se com os dos processos de
sincronizaĆ§Ć£o, nomeadamente a integraĆ§Ć£o dos produtos e das entidades.
De modo a aproximar os testes realizados com o cenĆ”rio presente em produĆ§Ć£o, foi
utilizado o ERP do cliente para sincronizar a informaĆ§Ć£o nas aplicaƧƵes.
ā¢ Entidades
Neste processo de sincronizaĆ§Ć£o sĆ£o realizados quatro pedidos ao ERP da empresa onde
a aplicaĆ§Ć£o estĆ” instalada, solicitando a informaĆ§Ć£o sobre os clientes, fornecedores e os
pontos de entrega de cada um dos anteriores. No total foram retornados 2169
entidades e 17 pontos de entrega.
0:230:28
0:35
0:040:09
0:17
0:00
0:14
0:28
0:43
50 100 500
Du
raĆ§Ć£
o M
Ć©dia
(M
inu
tos:
Segu
nd
os)
NĀŗ de pedidos
MonĆ³litica MicrosserviƧos
97
Os testes efetuados visam obter informaĆ§Ć£o sobre as duas mĆ©tricas analisadas
anteriormente, tempo de resposta ao utilizador e duraĆ§Ć£o do processo de
sincronizaĆ§Ć£o. Assim, este processo foi executado dez vezes em cada aplicaĆ§Ć£o. Os
resultados obtidos sĆ£o apresentados na Tabela 7.
Tabela 7 ā Resultados do processo de sincronizaĆ§Ć£o das entidades
MonolĆtica Tempo de resposta mĆ©dio 02:47 Minutos
DuraĆ§Ć£o mĆ©dia 02:47 Minutos
MicrosserviƧos Tempo de resposta mƩdio 72.744 ms
DuraĆ§Ć£o mĆ©dia 01:49 Minutos
Como Ć© possĆvel observar, a implantaĆ§Ć£o da nova soluĆ§Ć£o nos clientes da empresa trarĆ”
uma melhoria significativa nas mƩtricas definidas. O tempo de resposta Ʃ
significativamente reduzido, pois a nova soluĆ§Ć£o responde ao utilizador de imediato,
informando-o que os dados pedidos serĆ£o sincronizados, ao invĆ©s de esperar o tĆ©rmino
do processo para informar o utilizador. Esta alteraĆ§Ć£o, permite ao utilizador continuar
a usufruir das restantes funcionalidades da aplicaĆ§Ć£o contrariamente ao que acontece
atualmente na aplicaĆ§Ć£o monolĆtica. Relativamente Ć duraĆ§Ć£o do processo, na aplicaĆ§Ć£o
baseada em microsserviƧos, Ʃ menor, uma vez que, como descrito na Figura 30 do
subcapĆtulo 7.4, apĆ³s a conclusĆ£o de cada pedido Ć© publicado um evento no MB,
permitindo ao MS3 ā Entities armazenar a informaĆ§Ć£o recebida enquanto os restantes
pedidos sĆ£o executados pelo MS10 ā Integrator, contrariamente ao processo
sequencial executado na aplicaĆ§Ć£o monolĆtica.
ā¢ Produtos
Contrariamente ao processo de entidades, este Ć© constituĆdo apenas por um pedido ao
ERP, responsĆ”vel por devolver a informaĆ§Ć£o dos produtos e cĆ³digo de barras. No total
este pedido devolve 2054 produtos e 1372 cĆ³digos de barras.
Para efetuar os testes ao processo foram utilizadas as mesmas mƩtricas e forma de
execuĆ§Ć£o do processo anterior, repetindo o processo dez vezes e calculando a mĆ©dia
dos valores obtidos.
Os resultados obtidos sĆ£o apresentados na seguinte tabela.
Tabela 8 ā Resultados do processo de sincronizaĆ§Ć£o dos produtos
MonolĆtica Tempo de resposta mĆ©dio 02:27 Minutos
DuraĆ§Ć£o mĆ©dia 02:27 Minutos
MicrosserviƧos Tempo de resposta mƩdio 75.044 ms
98
DuraĆ§Ć£o mĆ©dia 02:21 Minutos
Como Ć© possĆvel observar o tempo de resposta mĆ©dio Ć© significativamente mais baixo,
pelo mesmo motivo descrito no processo de sincronizaĆ§Ć£o das entidades.
Relativamente Ć duraĆ§Ć£o mĆ©dia, a aplicaĆ§Ć£o baseada em microsserviƧos apresenta
tambĆ©m melhores resultados, porĆ©m nĆ£o tĆ£o expressivos uma vez que este processo Ć©
constituĆdo apenas por um pedido ao ERP.
Por fim, Ć© possĆvel concluir que a aplicaĆ§Ć£o baseada em microsserviƧos apresenta
melhor desempenho e escalabilidade em relaĆ§Ć£o Ć aplicaĆ§Ć£o monolĆtica, uma vez que
apresenta resultados mais favorƔveis na maioria dos processos testados. Assim, quando
a aplicaĆ§Ć£o for disponibilizada para o cliente, estas melhorias serĆ£o imediatamente
alcanƧadas.
Contudo, para atingir os valores apresentados pela aplicaĆ§Ć£o monolĆtica, nos casos de
menor carga de pedidos, poderĆ” ser configurada de forma diferente. Por exemplo, uma
das soluƧƵes possĆveis seria atribuir uma quantidade de recursos maior aquando a sua
implantaĆ§Ć£o.
9.1.2 Manutenibilidade, automatizaĆ§Ć£o e satisfaĆ§Ć£o
Na avaliaĆ§Ć£o das mĆ©tricas, manutenibilidade, automatizaĆ§Ć£o e satisfaĆ§Ć£o foi utilizado o
modelo de avaliaĆ§Ć£o QEF (Quality evaluation framework), ilustrado no anexo A.4.2. Este
Ć© constituĆdo por trĆŖs dimensƵes, que agrupam os diversos fatores a avaliar. De modo
a proceder Ć avaliaĆ§Ć£o de cada fator, foi necessĆ”rio definir os requisitos, o seu peso e a
forma de avaliaĆ§Ć£o.
ā¢ Manutenibilidade
Esta mĆ©trica agrupa dois fatores, a documentaĆ§Ć£o e a monitorizaĆ§Ć£o. Os requisitos de
cada fator e os resultados obtidos na sua avaliaĆ§Ć£o, serĆ£o apresentados nos seguintes
parƔgrafos.
Tabela 9 ā AvaliaĆ§Ć£o do fator documentaĆ§Ć£o
Objetivo AvaliaĆ§Ć£o da mĆ©trica
Forma de AvaliaĆ§Ć£o Escala
Resultados Obtidos
AnĆ”lise e criaĆ§Ć£o de requisitos
VisualizaĆ§Ć£o dos requisitos
Deve ser possĆvel verificar os requisitos da soluĆ§Ć£o
0 ou 100 %
100%
Documentar os componentes
DocumentaĆ§Ć£o dos componentes
Deve existir documentaĆ§Ć£o desenvolvida atravĆ©s do Swagger, para cada componente
0 a 100 %
100%
99
desenvolvidos
šĀŗ šš ššššššššš”šš šššš¢šššš”šššš
šĀŗ š”šš”šš šš ššššššššš”šš š„100
Documentar a implantaĆ§Ć£o efetuada
Documento detalhado da implantaĆ§Ć£o
Deve existir um documento explicativo da implantaĆ§Ć£o efetuada
0 ou 100 %
100%
Documentar a nova arquitetura
Documento detalho da nova soluĆ§Ć£o
Deve existir um documento detalhado da soluĆ§Ć£o desenvolvida
0 ou 100 %
100%
Este fator visa avaliar a documentaĆ§Ć£o da soluĆ§Ć£o. Permite obter informaĆ§Ć£o sobre as
decisƵes tomadas ao longo do desenvolvimento da soluĆ§Ć£o e perceber o seu
funcionamento. Uma boa documentaĆ§Ć£o permite reduzir a curva de aprendizagem do
projeto para novos membros e facilitar o desenvolvimento de implementaƧƵes futuras.
Como Ć© possĆvel observar na tabela acima, todos os objetivos foram concluĆdos com
sucesso.
A avaliaĆ§Ć£o desta mĆ©trica poderia incluir um inquĆ©rito, com o intuito de comparar a
facilidade de aprendizagem e implementaĆ§Ć£o de novas funcionalidades nas aplicaƧƵes,
monolĆtica e baseada em microsserviƧos. Seria expectĆ”vel obter maior facilidade na
nova soluĆ§Ć£o, uma vez que apresenta documentaĆ§Ć£o dos componentes desenvolvidos.
Contudo, este nĆ£o pode ser efetuado, uma vez que nĆ£o existe um pĆŗblico alvo de
programadores para inquerir.
Tabela 10 ā AvaliaĆ§Ć£o do fator monitorizaĆ§Ć£o
Objetivo AvaliaĆ§Ć£o da mĆ©trica
Forma de AvaliaĆ§Ć£o Escala
Resultados Obtidos
Visualizar os logs dos componentes
Cada componente deve conter um ficheiro de logs
šĀŗ šš ššššššššš”šš šš¢š ššššš ššš”š šššš
šĀŗ š”šš”šš šš ššššššššš”šš š„100 0 a
100 % 100%
Visualizar o CPU utilizado
VisualizaĆ§Ć£o do CPU utilizado
šĀŗ šš ššššššššš”šš šš¢š ššššš ššš”š š š¶šš
šĀŗ š”šš”šš šš ššššššššš”šš š„100 0 a
100 % 100%
Visualizar a MemĆ³ria utilizada
VisualizaĆ§Ć£o da memĆ³ria utilizada
šĀŗ šš ššššššššš”šš šš¢š ššššš ššš”š š šššĆ³ššš
šĀŗ š”šš”šš šš ššššššššš”šš š„ 100 0 a
100 % 100%
Visualizar a disponibilidade da soluĆ§Ć£o
VisualizaĆ§Ć£o do estado e disponibilidade da aplicaĆ§Ć£o
šĀŗ šš ššššššššš”šš šššš š š š£ššššššš š šš š”ššš
šĀŗ š”šš”šš šš ššššššššš”šš š„ 100 0 a
100 % 100%
Controlar o trĆ”fego da soluĆ§Ć£o
VisualizaĆ§Ć£o da quantidade de pedidos e
šĀŗ šš ššššššššš”šš šš¢š ššššš ššš”š š š”šĆ”šššš
šĀŗ š”šš”šš šš ššššššššš”šš š„ 100 0 a
100 % 100%
100
trƔfego que o componente recebe
O fator monitorizaĆ§Ć£o objetiva avaliar o controlo sobre a aplicaĆ§Ć£o desenvolvida e o
acesso ao histĆ³rico de execuĆ§Ć£o da mesma, permitindo a identificaĆ§Ć£o e resoluĆ§Ć£o de
erros em ambientes de desenvolvimento e produĆ§Ć£o. Estes, podem ser derivados de
quebras de funcionalidade, falta de memĆ³ria ou processamento, indisponibilidade da
soluĆ§Ć£o ou excesso de trĆ”fego na aplicaĆ§Ć£o. Como Ć© possĆvel observar na tabela acima,
foi avaliada a existĆŖncia de mecanismos de controlo dos possĆveis erros descritos,
tendo-se alcanƧado todos os objetivos propostos.
ā¢ AutomatizaĆ§Ć£o
Esta mĆ©trica pretende avaliar o grau de automatizaĆ§Ć£o do processo de implantaĆ§Ć£o
desenvolvido ao longo deste trabalho. Visa agilizar as implantaƧƵes eliminando os erros
resultantes do processo manual de implantaĆ§Ć£o atualmente praticado pela empresa
Flowinn. AtravĆ©s desta, os programadores da empresa nĆ£o necessitam de dispensar o
seu tempo para realizar as implantaƧƵes da aplicaĆ§Ć£o.
A dimensĆ£o automatizaĆ§Ć£o Ć© constituĆda apenas pelo fator processo de implantaĆ§Ć£o,
descrito posteriormente.
Tabela 11 ā AvaliaĆ§Ć£o do fator processo de implantaĆ§Ć£o
Objetivo AvaliaĆ§Ć£o da mĆ©trica
Forma de AvaliaĆ§Ć£o Escala Resultados Obtidos
Automatizar a implantaĆ§Ć£o da soluĆ§Ć£o
Componentes devem ser implantados atravƩs do pipeline
šĀŗ šš šššššš ššš£šĆ§šš ššššššš”šššš
šĀŗ š”šš”šš šš ššššššššš”šš š„100 0 a
100 % 100%
Automatizar o processo de execuĆ§Ć£o de build
ExecuĆ§Ć£o da build do cĆ³digo-fonte da aplicaĆ§Ć£o
Verificar a execuĆ§Ć£o da build do repositĆ³rio
0 ou 100 %
100%
Testar as funcionalidades desenvolvidas
ExecuĆ§Ć£o dos testes unitĆ”rios
Verificar a execuĆ§Ć£o dos testes unitĆ”rios
0 ou 100 %
100 %
Testar a integraĆ§Ć£o das funcionalidades desenvolvidas
ExecuĆ§Ć£o dos testes de integraĆ§Ć£o
Verificar a execuĆ§Ć£o dos executa testes integraĆ§Ć£o
0 ou 100 %
100%
Assegurar a qualidade do
AnĆ”lise da qualidade do cĆ³digo
Verificar se existe uma anĆ”lise do cĆ³digo
0 ou 100 %
0%
101
cĆ³digo desenvolvido
Publicar a imagem Docker
PublicaĆ§Ć£o na imagem no respetivo repositĆ³rio
Verificar a publicaĆ§Ć£o da imagem no respetivo repositĆ³rio do Docker Hub
0 ou 100 %
100%
Implantar a soluĆ§Ć£o no ambiente
ImplantaĆ§Ć£o da soluĆ§Ć£o efetuada atravĆ©s do pipeline
Verificar a implantaĆ§Ć£o da soluĆ§Ć£o
0 ou 100 %
100%
A implantaĆ§Ć£o efetuada deverĆ” ficar disponĆvel para o utilizador
AplicaĆ§Ć£o disponĆvel apĆ³s a implantaĆ§Ć£o
Verificar a execuĆ§Ć£o do smoke test Ć implantaĆ§Ć£o efetuada
0 ou 100 %
100%
Suportar os diversos ambientes
ImplantaĆ§Ć£o nos diversos ambientes
Verificar a implantaĆ§Ć£o no ambiente de desenvolvimento e produĆ§Ć£o
0, 50 ou 100 %
100%
Como Ć© possĆvel observar na tabela, os objetivos foram atingidos todos na sua
totalidade com exceĆ§Ć£o do objetivo āAssegurar a qualidade do cĆ³digo desenvolvidoā.
Este, deverĆ” ser considerado no futuro da aplicaĆ§Ć£o, uma vez que permite garantir a
qualidade do produto entregue ao cliente. Assim, a avaliaĆ§Ć£o deste fator, atravĆ©s da
aplicaĆ§Ć£o do mĆ©todo QEF, resulta numa taxa de qualidade de 96.55%.
ā¢ SatisfaĆ§Ć£o
Esta mĆ©trica visa avaliar a satisfaĆ§Ć£o da empresa com a soluĆ§Ć£o desenvolvida.
Contrariamente Ć s mĆ©tricas anteriores, esta nĆ£o Ć© mensurĆ”vel. Assim para efetuar a
avaliaĆ§Ć£o dos objetivos ilustrados no QEF, foi efetuado o questionĆ”rio ilustrado no
anexo A.4.2 e entregue o mesmo aos programadores da empresa integrantes do
projeto relativo Ć aplicaĆ§Ć£o monolĆtica, no entanto o seu nĆŗmero Ć© irrisĆ³rio para que
possam ser obtidas conclusƵes, pois sĆ³ existem dois. De qualquer forma o questionĆ”rio
foi realizado. Para uma dimensĆ£o de programadores mais elevada o questionĆ”rio seria
o mesmo, no entanto provavelmente os resultados obtidos teriam um maior nĆvel de
credibilidade.
O questionĆ”rio foi desenvolvido atravĆ©s do Google Forms e Ć© constituĆdo por seis
questƵes de escolha mĆŗltipla e resposta Ćŗnica.
Tabela 12 ā Objetivos e questƵes
Objetivo QuestĆ£o
102
Melhor desempenho e escalabilidade āA aplicaĆ§Ć£o baseada em microsserviƧos apresenta um melhor desempenho e escalabilidade do que a aplicaĆ§Ć£o monolĆtica.ā
Simplificar a implementaĆ§Ć£o de novas funcionalidades
A implementaĆ§Ć£o de novas funcionalidades Ć© simplificada na aplicaĆ§Ć£o baseada em microsserviƧos.
OtimizaĆ§Ć£o dos processos do armazĆ©m āA utilizaĆ§Ć£o do message broker, Apache Kafka, permite simplificar e otimizar os processos anteriormente implementados atravĆ©s de aƧƵes periĆ³dicas, nomeadamente a movimentaĆ§Ć£o de stock.ā
Agilizar a entrega das funcionalidades desenvolvidas
āA automatizaĆ§Ć£o do processo de implantaĆ§Ć£o permite agilizar a entrega das funcionalidades desenvolvidas.ā
ReduĆ§Ć£o de erros na implantaĆ§Ć£o da soluĆ§Ć£o āA automatizaĆ§Ć£o do processo de implantaĆ§Ć£o permite reduzir possĆveis erros dos processos manuais, aumentado a fiabilidade do mesmo.ā
EvoluĆ§Ć£o arquitetural apresenta benefĆcios para a empresa
āA evoluĆ§Ć£o para uma arquitetura baseada em microsserviƧos tornou-se um benefĆcio para os desenvolvedores bem como para a empresa Flowinn.ā
Posteriormente Ć entrega do questionĆ”rio, nĆ£o foi possĆvel obter um pĆŗblico alvo
extenso, pois o projeto na empresa Flowinn Ć© desenvolvido pelo CTO da mesma e pelo
autor deste trabalho (os dois programadores anteriormente referidos). Assim, apenas
a resposta do CTO ao questionƔrio foi considerada vƔlida.
As questƵes ilustradas na Tabela 12 sĆ£o constituĆdas por cinco possĆveis respostas. Estas
foram classificadas com percentagem de cumprimento do objetivo, como ilustrado na
seguinte tabela, permitindo efetuar a avaliaĆ§Ć£o dos objetivos no QEF.
Tabela 13 ā ClassificaĆ§Ć£o das respostas
PossĆvel resposta Percentagem de cumprimento do objetivo
Discordo totalmente 0%
Discordo parcialmente 25%
Indiferente 50%
Concordo parcialmente 75%
Concordo totalmente 100%
Seguidamente Ć classificaĆ§Ć£o das perguntas foi possĆvel avaliar os objetivos propostos,
atravƩs do cƔlculo da mƩdia das respostas obtidas no questionƔrio, ilustradas em forma
de grƔfico no anexo A.4.2, obtendo-se os seguintes resultados.
103
Tabela 14 ā AvaliaĆ§Ć£o do fator satisfaĆ§Ć£o da empresa
Objetivo Resultados Obtidos Melhor desempenho e escalabilidade 100%
Simplificar a implementaĆ§Ć£o de novas funcionalidades
75%
OtimizaĆ§Ć£o dos processos do armazĆ©m 100%
Agilizar a entrega das funcionalidades desenvolvidas
100%
ReduĆ§Ć£o de erros na implantaĆ§Ć£o da soluĆ§Ć£o 100%
EvoluĆ§Ć£o arquitetural apresenta benefĆcios para a empresa
100%
Como Ć© possĆvel verificar, os objetivos foram totalmente atingidos com exceĆ§Ć£o da
simplificaĆ§Ć£o da implementaĆ§Ć£o de novas funcionalidades, obtendo-se uma taxa de
qualidade de 96.30% no fator de satisfaĆ§Ć£o da empresa.
105
10 ConclusĆ£o
O avanƧo tecnolĆ³gico e a elevada exigĆŖncia do mercado, provocam uma forte
necessidade de obtenĆ§Ć£o de soluƧƵes com elevado desempenho e eficĆ”cia, o que
tornou as aplicaƧƵes baseadas em microsserviƧos cada vez mais comuns no quotidiano
das empresas.
Com este trabalho pretendeu efetuar-se uma migraĆ§Ć£o arquitetural na aplicaĆ§Ć£o
Logistics da empresa Flowinn, decompondo o monĆ³lito em diversos microsserviƧos e
utilizando padrƵes comuns em arquiteturas baseadas em microsserviƧos.
Como descrito na secĆ§Ć£o 1.3, o objetivo principal deste projeto passava por
implementar uma arquitetura baseada em microsserviƧos que permitisse obter
melhorias no desempenho dos processos do quotidiano dos armazƩns do cliente. Como
demostrado na avaliaĆ§Ć£o das soluƧƵes, a nova arquitetura, atravĆ©s da utilizaĆ§Ć£o dos
microsserviƧos e o MB, permitiu atingiu este objetivo, uma vez que apresentou
melhores resultados nos testes efetuados.
Os objetivos, implementaĆ§Ć£o de testes automatizados e automatizaĆ§Ć£o do processo de
implementaĆ§Ć£o, foram tambĆ©m atingidos. Os primeiros permitem assegurar que a
aplicaĆ§Ć£o e as suas funcionalidades se encontram operacionais e o segundo permitiu
agilizar a implantaĆ§Ć£o da soluĆ§Ć£o, tornado o processo repetĆvel e confiĆ”vel. Assim, foi
possĆvel eliminar os possĆveis erros manuais do processo anteriormente praticado na
empresa.
PorĆ©m, o Ćŗltimo objetivo proposto, comunicaĆ§Ć£o com o sistema de autenticaĆ§Ć£o da
empresa, nĆ£o foi atingido. Este facto, deveu-se Ć alteraĆ§Ć£o de requisitos por parte da
empresa, apĆ³s o inĆcio do projeto. A aplicaĆ§Ć£o monolĆtica, Logistics, Ć© um produto
isolado comercializado aos clientes, contudo pretendia iniciar-se a integraĆ§Ć£o da
106
mesma com os diversos produtos da empresa. ApĆ³s idealizar a nova soluĆ§Ć£o, aplicaĆ§Ć£o
baseada em microsserviƧos, a empresa optou por manter o produto isolado, excluindo
a comunicaĆ§Ć£o com o serviƧo de autenticaĆ§Ć£o. Assim, esta apresenta uma autenticaĆ§Ć£o
JWT (Json Web Token) que consiste na validaĆ§Ć£o do token de autenticaĆ§Ć£o do utilizador.
Posteriormente, a Ćŗnica limitaĆ§Ć£o apresentada pela empresa foi a reduĆ§Ć£o dos custos
da implantaĆ§Ć£o na Google Cloud Platform. ApĆ³s a reduĆ§Ć£o dos recursos de cada
microsserviƧo, foi possĆvel reduzir os mesmos, ainda assim, a empresa optou por trocar
de provedor de serviƧos. Portanto, a aplicaĆ§Ć£o baseada em microsserviƧos foi
implantada na DigitalOcean, com uma reduĆ§Ć£o de recursos.
Finalizando, pode concluir-se, observando o capĆtulo 9, que apesar da complexidade
inerente Ć migraĆ§Ć£o de aplicaƧƵes monolĆticas, o projeto desenvolvido atingiu os
principais objetivos pretendidos e a satisfaĆ§Ć£o da empresa.
Regressando Ć hipĆ³tese de investigaĆ§Ć£o, pode observar-se que, de facto hĆ” vantagens
na transformaĆ§Ć£o da aplicaĆ§Ć£o Logistics de uma arquitetura monolĆtica, para uma
arquitetura baseada em microsserviƧos, sendo que os objetivos da secĆ§Ć£o 1.3 foram
atingidos e os resultados esperados da secĆ§Ć£o 1.4 obtidos.
10.1 Trabalho futuro
Com o possĆvel crescimento da soluĆ§Ć£o devido Ć constante demanda por novas
funcionalidades, futuramente seria benƩfico mensurar a qualidade e seguranƧa do
cĆ³digo entregue em cada implementaĆ§Ć£o da soluĆ§Ć£o. Esta mediĆ§Ć£o pode ser efetuada
de forma automĆ”tica, atravĆ©s da utilizaĆ§Ć£o de ferramentas como o SonarQube e
FindBugs.
Em conjunto, futuramente deverĆ” ser aprimorado o desenvolvimento de testes
automĆ”ticos nomeadamente os testes unitĆ”rios, testes de integraĆ§Ć£o e testes de
usabilidade. Estes, poderĆ£o ser desenvolvidos com recurso a ferramentas distintas. O
front-end poderƔ ser testado atravƩs de frameworks como Protractor, Jasmine e Karma
enquanto que o back-end poderƔ ser testado atravƩs do JUnit.
A utilizaĆ§Ć£o destas ferramentas deverĆ” ter como objetivo atingir um valor prĆ³ximo da
cobertura total do cĆ³digo desenvolvido.
107
ReferĆŖncias
Armon Dadgar. (2018, Junho 26). Introduction to HashiCorp Consul. https://www.youtube.com/watch?v=mxeMdl0KvBI&feature=emb_title Atlassian. (2019, Julho 22). Build, test, and deploy with PipelinesāAtlassian Documentation. https://confluence.atlassian.com/bitbucket/build-test-and-deploy-with-pipelines-792496469.html Aviran Mordo. (2006). Journey from Monolith to Microservices and DevOps. https://gotocon.com/amsterdam-2016/presentation/Journey%20from%20Monolith%20to%20Microservices%20and%20DevOps Brajesh De. (2017). API Management: An Architectās Guide to Developing and Managing. Apress. Cesar de la Torre, Bill Wagner, & Mike Rousos. (2017). .NET Microservices: Architecture for Containerized .NET Applications. Chris Richardson. (2016a). Microservices Pattern: Self Registration pattern. microservices.io. http://microservices.io/patterns/self-registration.html Chris Richardson. (2016b). Microservices Pattern: Service registry pattern. microservices.io. http://microservices.io/patterns/service-registry.html Chris Richardson. (2018a). Microservices Pattern: Database per service. microservices.io. http://microservices.io/patterns/data/database-per-service.html Chris Richardson. (2018b). Microservices Pattern: Shared database. microservices.io. http://microservices.io/patterns/data/shared-database.html Chris Richardson. (2018c). Microservices Patterns: With examples in Java. Manning Publications. CoMakeIT. (2018, Agosto). A Quick Guide To Using Keycloak For Identity And Access Management. https://www.comakeit.com/blog/quick-guide-using-keycloak-identity-access-management/ Configuration Best Practices. (2020, Julho 17). Kubernetes. https://kubernetes.io/docs/concepts/configuration/overview/ Daniel Viana. (2017, Janeiro 30). O que Ć© front-end e back-end? Blog da TreinaWeb. https://www.treinaweb.com.br/blog/o-que-e-front-end-e-back-end/ Dominic Betts, Julian Dominguez, Grigori Melnik, Mani Subramanian, Fernando Simonazzi, & Greg Young. (2013). Exploring CQRS and Event Sourcing. Microsoft patterns & practices. Edson Yanaga. (2017). Migrating to Microservice Databases. OāReilly Media, Inc. https://www.oreilly.com/library/view/migrating-to-microservice/9781492048824/ch04.html Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. 359. Fanis Despoudis. (2017, Agosto). Understanding SOLID Principles: Single Responsibility. Medium. https://codeburst.io/understanding-solid-principles-single-responsibility-b7c7ec0bf80 Intellipaat. (2019, Junho 25). AWS vs Azure vs GoogleāDetailed Cloud Comparison. Intellipaat Blog. https://intellipaat.com/blog/aws-vs-azure-vs-google-cloud/ Jakub Korab. (2017). Understanding Message Brokers [Book]. OāReilly Media, Inc. https://www.oreilly.com/library/view/understanding-message-brokers/9781492049296/ Jez Humble, & David Farley. (2010). Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation. Addison Wesley. JHipster. (2017a). API Gateway. https://www.jhipster.tech/api-gateway/ JHipster. (2017b). Consul. https://www.jhipster.tech/consul/ JMeter. (2020). Apache JMeterāApache JMeterTM. https://jmeter.apache.org/ John Ferguson Smart. (2011). Jenkins: The Definitive Guide: Continuous Integration for the Masses. OāReilly Media. John Piela. (2016, Abril 2). Why Netflix Moved to a Microservices Architecture. ProgrammableWeb. https://www.programmableweb.com/news/why-netflix-moved-to-microservices-architecture/elsewhere-web/2016/04/02
108
Kafka Architecture. (2017, Maio). http://cloudurable.com/blog/kafka-architecture/index.html Koen, P. A., Ajamian, G. M., Boyce, S., Clamen, A., Fisher, E., Fountoulakis, S., Johnson, A., Puri, P., & Seibert, R. (2002). Effective Methods, Tools, and Techniques. The PDMA ToolBook for New Product Development, 32. Kyle Brown. (2017, Fevereiro 13). Apply the Strangler Application pattern to microservices applications. IBM Developer. https://developer.ibm.com/technologies/microservices/articles/cl-strangler-application-pattern-microservices-apps-trs/ Martin Fowler. (2005, Dezembro). Event Sourcing. martinfowler.com. https://martinfowler.com/eaaDev/EventSourcing.html Martin Fowler. (2006, Maio). Continuous Integration. martinfowler.com. https://martinfowler.com/articles/continuousIntegration.html Michael J. Kavis. (2014). Architecting the Cloud. John Wiley & Sons Inc. Netflix Technology Blog. (2012, Julho 9). Embracing the Differences: Inside the Netflix API Redesign. https://netflixtechblog.com/embracing-the-differences-inside-the-netflix-api-redesign-15fd8b3dc49d Newman, S. (2019). Monolith to Microservices. OāReilly Media. O que Ć© Docker? | Red Hat. (2018). https://www.redhat.com/pt-br/topics/containers/what-is-docker Osterwalder, A., Pigneur, Y., & Clark, T. (2010). Business model generation: A handbook for visionaries, game changers, and challengers. Wiley. Pieter Humphrey. (2017, Abril). Understanding When to use RabbitMQ or Apache Kafka. https://content.pivotal.io/blog/understanding-when-to-use-rabbitmq-or-apache-kafka Properdesign. (2019, Agosto 27). Redeploying a Kubernetes service on DigitalOcean managed cluster in response to a build on Bitbucket Pipelines. Proper Design. https://properdesign.co.uk/redeploying-a-kubernetes-service-on-digitalocean-managed-cluster-in-response-to-a-build-on-bitbucket-pipelines/ Qwiklabs. (2020). QwiklabsāHands-On Cloud Training. Qwiklabs. https://run.qwiklabs.com/ Roy, G. M. (2017). RabbitMQ in depth. Manning Publications Co. Saaty, T. L. (2008). Decision making with the analytic hierarchy process. International Journal of Services Sciences, 1(1), 83. https://doi.org/10.1504/IJSSCI.2008.017590 Saleem, S. (2019, MarƧo 27). What Is DigitalOcean and Why Should You Select It for Your Web Hosting? The Official Cloudways Blog. https://www.cloudways.com/blog/what-is-digital-ocean/ Samir Behara. (2018, Dezembro). Monolith to Microservices With the Strangler PatternāDZone Microservices. Dzone.Com. https://dzone.com/articles/monolith-to-microservices-with-the-strangler-patte Sayfan, G. (2017). Mastering Kubernetes: Large scale container deployment and management. Packt Publishing. Sendil Kumar N, & Deepu K Sasidharan. (2018). Full Stack Development with JHipster [Book]. https://www.oreilly.com/library/view/full-stack-development/9781788476317/ Skalena. (2018). WSO2 API Manager. Skalena. https://www.skalena.com/wso2-apimanager?lang=en Stephane Maarek. (2019, MarƧo 26). What is Zookeeper? https://www.youtube.com/watch?v=AS5a91DOmks Thomas Erl, Richardo Puttini, & Zaigham Mahmood. (2013). Cloud Computing: Concepts, Technology & Architecture. Prentice Hall. Umesh Ram Sharma. (2017). Practical Microservices. Packt Publishing. Vinicius Feitosa Pacheco. (2018). Microservice Patterns and Best Practices. Packt Publishing. https://www.oreilly.com/library/view/microservice-patterns-and/9781788474030/ Viraj Salaka. (2019, Agosto). Service Discovery with WSO2 API Microgateway. https://wso2.com/blogs/thesource/2019/08/service-discovery-with-wso2-api-microgateway/ What is Apache Kafka? | AWS. (2019). Amazon Web Services, Inc. https://aws.amazon.com/msk/what-is-kafka/ Woodall, T. (2003). Conceptualising Ā«Value for the CustomerĀ»: An Attributional, Structural and Dispositional Analysis. 44. WSO2. (2019). Key ConceptsāAPI Manager 2.6.0āWSO2 Documentation. https://docs.wso2.com/display/AM260/Key+Concepts Yoav Abrahami. (2015). Scaling Wix to 60M UsersāFrom Monolith to MicroservicesāWix Tech Stack. https://stackshare.io/wix/scaling-wix-to-60m-users-from-monolith-to-microservices
109
Yury Izrailevsky. (2016, Fevereiro 11). Completing the Netflix Cloud Migration. Netflix Media Center. https://media.netflix.com/en/company-blog/completing-the-netflix-cloud-migration
111
A Anexos
A.1 MicrosserviƧos
Os restantes microsserviƧos presentes na arquitetura baseada em microsserviƧos, serĆ£o
descritos ao longo dos prĆ³ximos parĆ”grafos. Englobam o restante domĆnio da aplicaĆ§Ć£o
Logistics e possibilitam a realizaĆ§Ć£o dos processos presentes nos armazĆ©ns,
nomeadamente receĆ§Ć£o, arrumaĆ§Ć£o e expediĆ§Ć£o.
ā¢ MS3 ā Entities
Figura 42 ā RepresentaĆ§Ć£o do microsserviƧo Entities
Este microsserviƧo representa o domĆnio dos clientes, os fornecedores do armazĆ©m e
os respetivos pontos de entrega.
ā¢ MS4 ā Settings
112
Figura 43 ā RepresentaĆ§Ć£o do microsserviƧo Settings
Settings, microsserviƧo que engloba as configuraƧƵes transversais Ć aplicaĆ§Ć£o,
necessĆ”rias para definir a forma de execuĆ§Ć£o e as vĆ”rias validaƧƵes a ter em conta ao
longo da aplicaĆ§Ć£o. Este microsserviƧo serĆ” tambĆ©m utilizado nos diversos processos de
armazƩm, uma vez que cada um destes poderƔ ser efetuado de forma distinta com base
em alguma configuraĆ§Ć£o.
ā¢ MS7 ā Operation
Figura 44 ā RepresentaĆ§Ć£o do microsserviƧo Operation
O microsserviƧo Operation, engloba o domĆnio das operaƧƵes resultantes dos seguintes
processos presentes no armazĆ©m, receĆ§Ć£o e arrumaĆ§Ć£o. Cada um destes processos
origina vƔrias operaƧƵes. Assim sendo, o microsserviƧo responsƔvel pelo processo
publicarĆ” um evento no MB, e este subscreverĆ” o mesmo, criando as respetivas
operaƧƵes. Posteriormente, no processo de expediĆ§Ć£o, serĆ£o criadas e utilizadas as
instruƧƵes responsƔveis por auxiliar os funcionƔrios dos armazƩns.
ā¢ MS9 ā NMVS
113
Figura 45 ā RepresentaĆ§Ć£o do microsserviƧo NMVS
Os clientes desta aplicaĆ§Ć£o sĆ£o do ramo farmacĆŖutico e como tal, necessitam de
verificar a autenticidade de certos produtos, que contĆŖm dispositivos de seguranƧa com
o intuito de evitar a comercializaĆ§Ć£o de produtos falsificados. Este microsserviƧo, NMVS,
Ć© responsĆ”vel por comunicar os produtos descritos Ć s entidades certificadoras e pela
gestĆ£o da resposta das mesmas.
ā¢ MS11 ā Stowage
Figura 46 ā RepresentaĆ§Ć£o do microsserviƧo Stowage
Este microsserviƧo Ć© responsĆ”vel pela gestĆ£o e armazenamento dos processos de
arrumaĆ§Ć£o.
ā¢ MS12 ā Container
Figura 47 ā RepresentaĆ§Ć£o do microsserviƧo Container
114
O Container engloba os volumes e contentores utilizados no processo de expediĆ§Ć£o com
o objetivo de gerir os produtos e embalagens a ser entregues nas encomendas
efetuadas ao armazƩm.
ā¢ MS13 ā Shipping Order
Figura 48 ā RepresentaĆ§Ć£o do microsserviƧo Shipping Order
Este microsserviƧo, Shipping Order, engloba o domĆnio das encomendas efetuadas ao
armazĆ©m. ContĆ©m a gestĆ£o das ordens de expediĆ§Ć£o, que consistem nas encomendas
efetuadas pelos clientes e os artigos com as respetivas quantidades requeridas.
Posteriormente Ć criaĆ§Ć£o da encomenda e Ć estimativa de tempo atĆ© estar concluĆda,
este darĆ” origem aos processos de picking e posteriormente de packing.
Estes processos consistem na recolha do produto das diversas zonas no armazƩm e
embalamento do mesmo para posteriormente ser entregue ao respetivo cliente. Estes
processos num trabalho futuro poderĆ£o ser novos microsserviƧos que subscreverĆ£o o
evento publicado aquando a conclusĆ£o da estimativa da encomenda, iniciando assim o
seu processo e a respetiva logica de negĆ³cio do mesmo.
A.2 Bitbucket Pipelines e Jira
Aqui ilustra-se o cĆ³digo do pipeline descrito no subcapĆtulo 8.1 e detalha-se a integraĆ§Ć£o
efetuada com o produto Jira.
A.2.1 Pipeline definido
115
Figura 49 ā Steps executados conforme o branch
AtravĆ©s da Figura 49, Ć© possĆvel observar que o pipeline executa de forma diferenciada
conforme o branch em que Ć© efetuado um commit. A implementaĆ§Ć£o de novas
funcionalidades deve ser efetuada em novos branchs, do tipo feature e aquando o seu
termino, deverĆ” ser criada uma pull-request para o branch development, desta forma,
o pipeline apenas executarĆ” a build do repositĆ³rio e executar os respetivos testes.
Seguidamente, a build do pipeline, nos branches development e master, diferem apenas
na configuraĆ§Ć£o do ambiente e na execuĆ§Ć£o da implantaĆ§Ć£o, deste modo os steps foram
criados de forma genĆ©rica permitindo a reutilizaĆ§Ć£o dos mesmos.
ā¢ ConfiguraĆ§Ć£o do ambiente da build
Figura 50 ā DefiniĆ§Ć£o dos steps de configuraĆ§Ć£o do ambiente
116
Como Ć© possĆvel observar, nos steps referidos Ć© configurada a variĆ”vel
DEPLOYMENT_ENVIROMENT conforme o ambiente de execuĆ§Ć£o. De modo a possibilitar
a sua utilizaĆ§Ć£o nos steps futuros, esta Ć© exportada para o artefacto build.env.
ā¢ Build
Figura 51 ā DefiniĆ§Ć£o do step build
Como ilustrado na Figura 51, este step executa a build atravƩs do Maven e cria a imagem
Docker com recurso ao plugin jib. Posteriormente, esta imagem Ć© colocada como
artefacto, possibilitando a sua reutilizaĆ§Ć£o nos steps seguintes. Cada microsserviƧo cria
uma imagem de nome diferente, sendo este o nome do microsserviƧo em questĆ£o.
Deste modo foi configurada uma variĆ”vel em cada repositĆ³rio que permite identificar o
nome da imagem criada como Ć© apresentado na seguinte tabela.
Tabela 15 ā VariĆ”veis utilizadas no step build
VariĆ”vel UtilizaĆ§Ć£o Tipo de VariĆ”vel
$DEFAULT_IMAGE_TAG_NAME Nome da imagem criada Configurada em cada repositĆ³rio
ā¢ Docker Hub
117
Figura 52 ā DefiniĆ§Ć£o do step Docker Hub
Este step, como se pode observar na figura, inicia-se pela importaĆ§Ć£o da variĆ”vel do
ambiente da build e pela imagem criada pela mesma. Posteriormente, Ć© atribuĆdo uma
tag Ć imagem, seguindo a nomenclatura descrita no subcapĆtulo 8.1. Finalmente sĆ£o
efetuados o login e a publicaĆ§Ć£o da imagem. Este step apresenta as seguintes variĆ”veis,
ilustradas na tabela seguinte, com intuito de reutilizar o mesmo ao longo de cada
microsserviƧo.
Tabela 16 ā VariĆ”veis utilizadas no step Docker Hub
VariĆ”vel UtilizaĆ§Ć£o Tipo de VariĆ”vel
$DOCKER_HUB_USER Nome de utilizador da conta do Docker Hub
Configurada em cada repositĆ³rio
$DOCKER_HUB_PASSWORD Token de acesso Ć conta do Docker Hub Configurada em cada repositĆ³rio
$BITBUCKET_REPO_SLUG Nome do repositĆ³rio no Bitbucket Existente no Bitbucket Pipelines
$DEPLOYMENT_ENVIRONMENT Ambiente onde executa a build Configurada no step configuraĆ§Ć£o do ambiente da build
$BITBUCKET_BUILD_NUMBER Identificador Ćŗnico com o nĆŗmero da build do Bitbucket Pipelines
Existente no Bitbucket Pipelines
ā¢ Google Cloud Platform e DigitalOcean
118
Como descrito no subcapĆtulo 8.2 a soluĆ§Ć£o foi implantada na Google Cloud Platform e
posteriormente na DigitalOcean, substituindo assim a utilizaĆ§Ć£o do step
deployTestesGoogle pelo deployTestesDigitalOcean ilustrados na figura seguinte.
Figura 53 ā Step de implantaĆ§Ć£o da imagem no Kubernetes
A implantaĆ§Ć£o da soluĆ§Ć£o foi realizada com recurso ao Bitbucket Deployments. Este
atravƩs da palavra-chave deployment, identifica o ambiente onde serƔ efetuada a
implantaĆ§Ć£o. Assim permite configurar as variĆ”veis conforme o ambiente, reutilizando
o script de implantaĆ§Ć£o, nomeadamente o script deployKubernetesDigitalOcean. Deste
modo Ć© tambĆ©m possĆvel configurar o modo de desencadear o deployment, sendo
automĆ”tico para o ambiente de testes e manual para o ambiente de produĆ§Ć£o.
A implantaĆ§Ć£o ocorre atravĆ©s do seguinte script.
119
Figura 54 ā Script de implantaĆ§Ć£o
Na figura Ć© apresentado o script de implantaĆ§Ć£o na Google e na DigitalOcean. SerĆ”
apenas analisado o segundo, sendo este o script em utilizaĆ§Ć£o na empresa. Inicialmente
Ʃ importada a variƔvel do ambiente, seguida do download da interface de linha de
comandos da DigitalOcean. Posteriormente Ć© efetuado a configuraĆ§Ć£o de acesso ao
cluster e Ć© implantada a imagem atravĆ©s da atualizaĆ§Ć£o da mesma no cluster Kubernetes.
Por fim Ć© executado o smoke test Ć aplicaĆ§Ć£o, confirmando se a mesma se encontra
disponĆvel apĆ³s a instalaĆ§Ć£o. De modo efetuar o script ilustrado foram utilizadas as
seguintes variƔveis.
Tabela 17 ā VariĆ”veis utilizadas no step de implantaĆ§Ć£o
VariĆ”vel UtilizaĆ§Ć£o Tipo de VariĆ”vel
$BITBUCKET_DEPLOYMENT_ENVIRONMENT Nome do ambiente configurado no Bitbucket Deployments
Existente no Bitbucket Pipelines
$DOCTL_VERSION VersĆ£o da interface de linha de comandos
Configurada em cada ambiente de implantaĆ§Ć£o
$K8s_CLUSTER_NAME Nome do cluster onde serĆ” efetuada a implantaĆ§Ć£o
Configurada em cada ambiente de implantaĆ§Ć£o
120
$K8S_SERVICE_URL URL de acesso Ć aplicaĆ§Ć£o implantada
Configurada em cada ambiente de implantaĆ§Ć£o
A.2.2 IntegraĆ§Ć£o Jira
Com o intuito de facilitar o trabalho diƔrio e permitir visualizar quais os problemas
reportados no produto Jira que se encontram resolvidos e instalados nos diversos
ambientes, foi integrado o Bitbucket Pipelines com o Jira.
Esta integraĆ§Ć£o foi efetuada com recursos a dois serviƧos disponibilizados pela
Atlassian, nomeadamente workflow triggers e Bitbucket Deployments.
Anteriormente na empresa Flowinn, jĆ” existia um fluxo no ciclo de vida dos issues,
apresentado na seguinte figura.
Figura 55 ā Fluxo do ciclo de vida de um issue existente na empresa (imagem cedida pela
Flowinn)
De modo a complementar a ciclo existente, foi sugerido a adiĆ§Ć£o de dois triggers
automƔticos nas seguintes transiƧƵes:
121
ā¢ Para fazer -> Em Progresso: Esta transiĆ§Ć£o do issue acontecerĆ” de forma
automĆ”tica, despoletada pela criaĆ§Ć£o de um branch relativo ao issue em
questĆ£o.
ā¢ Em progresso -> Em Testes: Com a introduĆ§Ć£o das pull-requests serĆ” possĆvel
automatizar esta transiĆ§Ć£o, aquando uma pull-request relativa ao issue em
questĆ£o for aceite e incluĆda no branch development.
ApĆ³s validaĆ§Ć£o com a empresa apenas o primeiro foi adicionado, uma vez que o
segundo nĆ£o foi possĆvel aplicar, isto porque esta transiĆ§Ć£o exige o preenchimento
obrigatĆ³rio do tempo despendido no issue. De modo a contornar este processo manual
seria necessĆ”rio a criaĆ§Ć£o de um novo estado, contudo nĆ£o seria obtida nenhuma
vantagem em relaĆ§Ć£o ao processo atual.
Relativamente Ć utilizaĆ§Ć£o do Bitbucket Deployments, este integra a build efetuada e os
respetivos issues implantados na mesma. Ć possĆvel visualizar esta integraĆ§Ć£o no menu
do Bitbucket e nos issues do Jira, facilitando assim o controlo das versƵes instaladas nos
ambientes.
De modo a configurar esta integraĆ§Ć£o, Ć© necessĆ”ria a configuraĆ§Ć£o de cada ambiente
de execuĆ§Ć£o do pipeline, descrito no subcapĆtulo anterior, configurar o acesso do
Bitbucket ao produto Jira e por fim relacionar os repositĆ³rios pretendidos com o projeto
presente no Jira.
Figura 56 ā Ambientes de implantaĆ§Ć£o definidos no Bitbucket
122
A figura anterior, representa os ambientes configurados no Bitbucket Deployments,
nomeadamente dois ambientes de testes, Testes e DigitalOcean e o de produĆ§Ć£o,
Production. Como Ć© possĆvel observar, cada ambiente identifica claramente qual a build
instalada e os respetivos commits e issues incluĆdos na mesma. Ć possĆvel verificar com
mais detalhe a informaĆ§Ć£o da build e do ambiente, acedendo ao mesmo, como
apresentado na imagem seguinte.
Figura 57 ā InformaĆ§Ć£o detalhada do ambiente de testes DigitalOcean
Como Ć© possĆvel observar na Figura 57, foi efetuado um commit associado ao issue
LWMS-15, sendo que este jĆ” se encontra instalado no ambiente DigitalOcean, assim o
issue presente no projeto do Jira contĆ©m tambĆ©m a informaĆ§Ć£o relativa Ć implantaĆ§Ć£o.
SerĆ” assim possĆvel a identificaĆ§Ć£o dos issues prontos para testes.
123
Figura 58 ā Issue LWMS-15 representado Jira
Como Ć© possĆvel observar, no menu lateral direito Ć© apresentada a informaĆ§Ć£o do
Bitbucket, nomeadamente o desenvolvimento efetuado e a implantaĆ§Ć£o, denominada
de lanƧamentos. Neste caso em concreto, o desenvolvimento apresenta o commit
ilustrado na Figura 57 e o lanƧamento representa a implantaĆ§Ć£o no ambiente
DigitalOcean, como Ć© possĆvel visualizar com mais detalhe na figura seguinte.
Figura 59 ā Detalhe das implantaƧƵes do issue LWMS-15
A.3 Ficheiro de configuraĆ§Ć£o do Kubernetes
Aqui Ć© detalhada a configuraĆ§Ć£o efetuada nos ficheiros Kubernetes do microsserviƧo
zones que permitiram a implantaĆ§Ć£o do componente no cluster, descrito no capĆtulo 8.
Cada microsserviƧo contĆ©m ficheiros similares diferenciando apenas o repositĆ³rio da
imagem Docker e configuraƧƵes da base de dados.
124
Figura 60 ā ConfiguraĆ§Ć£o do deployment do microsserviƧo Zones
Como Ć© possĆvel observar na Figura 60 para efetuar a implantaĆ§Ć£o de cada
microsserviƧo e Gateway foi utilizado o controlador Deployment do Kubernetes. Este,
neste caso concreto, permite identificar os pods do microsserviƧo Zones de modo a
escalar e assegurar a disponibilidade do mesmo. Quando um pod falha, o Kubernetes
irĆ” tentar substituĆ-lo imediatamente, visando reduzir o tempo de indisponibilidade do
microsserviƧo em questĆ£o. Atualmente, a soluĆ§Ć£o apresenta apenas uma rĆ©plica de
cada componente, contudo o cluster implantado foi configurado de modo a suportar
escalonamento vertical e horizontal de forma automƔtica, baseando-se no trƔfego do
microsserviƧo.
Figura 61 ā ConfiguraĆ§Ć£o do container presente no pod
125
Na Figura 61 sĆ£o ilustradas as configuraƧƵes que permitem ao Kubernetes identificar a
respetiva imagem Docker e as configuraƧƵes que o microsserviƧo necessita para
executar, nomeadamente a configuraĆ§Ć£o das comunicaƧƵes do microsserviƧo com o MB
Apache Kafka, o JHipster Registry e respetiva base de dados.
Como Ć© possĆvel verificar Ć© identificado neste ficheiro, o repositĆ³rio da imagem Docker,
flowinnlogistics/logistics_zones-dev, e a sua respetiva versĆ£o, 1, esta Ć© atualizada
atravĆ©s das builds do Bitbucket pipelines. Relativamente Ć comunicaĆ§Ć£o com os diversos
componentes, esta Ʃ efetuada atravƩs do serviƧo DNS do Kubernetes. Assim de modo a
efetuar a comunicaĆ§Ć£o sĆ£o utilizadas as seguintes variĆ”veis, neste caso em concreto:
Tabela 18 ā DNS utilizado para cada comunicaĆ§Ć£o
ComunicaĆ§Ć£o DNS utilizado
Base de dados zones-mysql.development.svc.cluster.local
JHipster Registry jhipster-registry.development.svc.cluster.local
Apache Kafka kafka.development.svc.cluster.local
Por fim, o ficheiro apresenta a configuraĆ§Ć£o dos recursos que o microsserviƧo irĆ”
consumir e da porta onde estarĆ” acessĆvel. Como foi descrito no subcapĆtulo 8.2, estes
recursos foram reduzidos por causa do orƧamento disponĆvel para a implantaĆ§Ć£o, assim
para os microsserviƧos mais importantes e mais utilizados nesta soluĆ§Ć£o,
nomeadamente zones, product, stock e receptions, foi atribuĆdo o inicial de 0.25 vCPU
do node em que o mesmo serĆ” implantado, aos restantes foi atribuĆdo o valor de 0.1
vCPU, pois Ć© expectĆ”vel que a sua utilizaĆ§Ć£o seja menor.
O ficheiro de configuraĆ§Ć£o da implantaĆ§Ć£o da base de dados Ć© apresentado na seguinte
figura.
126
Figura 62 ā Ficheiro da implantaĆ§Ć£o da base de dados do microsserviƧo zones
Similarmente ao ficheiro de configuraĆ§Ć£o de cada microsserviƧo, este utiliza o
controlador Deployment do Kubernetes. Neste ficheiro sĆ£o tambĆ©m configurados as
credenciais de acesso Ć base de dados e a imagem MySQL utilizada. Estas sĆ£o coerentes
ao longos dos microsserviƧos. Por fim, Ʃ tambƩm configurada a porta onde a base de
dados estarĆ” acessĆvel, 3306, e os recursos disponibilizados para a base de dados em
questĆ£o. Similarmente aos recursos dos microsserviƧos, optou-se por atribuir mais
recursos Ć base de dados dos microsserviƧos mais importantes, nomeadamente 0.1
vCPU e 0.05 vCPU para os restantes.
A.4 AvaliaĆ§Ć£o
Nesta secĆ§Ć£o serĆ£o detalhados os resultados obtidos na avaliaĆ§Ć£o das aplicaƧƵes e o
mĆ©todo de avaliaĆ§Ć£o utilizado no subcapĆtulo 9.1.2, QEF.
127
A.4.1 Desempenho e escalabilidade
Apresentando-se os resultados obtidos na execuĆ§Ć£o dos testes do processo de receĆ§Ć£o
e expediĆ§Ć£o. AtravĆ©s destes valores foi executada a mĆ©dia dos mesmos com o intuĆdo
de avaliar as soluƧƵes.
ā¢ ReceĆ§Ć£o
Tabela 19 ā CriaĆ§Ć£o das linhas de receĆ§Ć£o na aplicaĆ§Ć£o monolĆtica
NĆŗmero de pedidos Tempo de resposta (ms) Tempo mĆ©dio de resposta (ms)
50 60.68 66.2 57.7 62.28 65.8
62.532
100 66.48 65.5 56.38 65.33 65.83
63.904
500 70.41 73.09 71.398 70.202 73.596
71.7392
1000 139.892 161.795 105.995 142.018 155.68
141.076
2000 140.6755 140.5805 136.4925 130.69 155
140.6877
5000 731.3068 724.9088 747.301 766.064 1000.288
793.97372
Tabela 20 ā CriaĆ§Ć£o das linhas de receĆ§Ć£o na aplicaĆ§Ć£o baseada em microsserviƧos
NĆŗmero de pedidos Tempo de resposta (ms) Tempo mĆ©dio de resposta (ms)
50 67.54 69.6 66.66 66.1 71.5
68.28
128
100 69.76 69.59 69.56 70.59 70.08
69.916
500 85.164 80.86 91.122 96 91.36
88.9012
1000 94.918 99.245 106.482 100.464 50.359
90.2936
2000 68.148 98.559 49.976 50.512 106.805
74.8
5000 167.1412 116.9846 97.8608 80.0808 66.9196
105.7974
ā¢ ExpediĆ§Ć£o
Tabela 21 ā Processo de expediĆ§Ć£o na aplicaĆ§Ć£o monolĆtica
NĆŗmero de linhas na expediĆ§Ć£o
DuraĆ§Ć£o (Minutos: Segundos)
DuraĆ§Ć£o MĆ©dia (Minutos: Segundos)
50 00:22 00:25 00:25 00:19 00:22
00:23
100 00:28 00:27 00:29 00:28 00:28
00:28
500 00:34 00:34 00:34 00:35 00:36
00:35
129
Tabela 22 ā Processo de expediĆ§Ć£o na aplicaĆ§Ć£o baseada em microsserviƧos
NĆŗmero de linhas na expediĆ§Ć£o
DuraĆ§Ć£o (Minutos: Segundos)
DuraĆ§Ć£o MĆ©dia (Minutos: Segundos)
50 00:06 00:04 00:04 00:03 00:03
00:04
100 00:07 00:09 00:12 00:09 00:08
00:09
500 00:15 00:21 00:16 00:16 00:15
00:17
A.4.2 Manutenibilidade, automatizaĆ§Ć£o e satisfaĆ§Ć£o
Neste subseĆ§Ć£o apresenta-se o QEF efetuado e o questionĆ”rio apresentado Ć empresa.
ā¢ QEF
131
ā¢ QuestionĆ”rio apresentado Ć empresa Flowinn
Figura 64 ā QuestionĆ”rio apresentado e 1ĀŖ pergunta
Figura 65 ā 2ĀŖ pergunta do questionĆ”rio
Figura 66 ā 3ĀŖ pergunta do questionĆ”rio
Figura 67 ā 4ĀŖ pergunta do questionĆ”rio
Figura 68 ā 5ĀŖ pergunta do questionĆ”rio
132
Figura 69 ā 6ĀŖ pergunta do questionĆ”rio
ā¢ Respostas obtidas no questionĆ”rio
Figura 70 ā Respostas obtidas na 1Āŗ pergunta
Figura 71 ā Respostas obtidas na 2Āŗ pergunta