CAMPUS DE ERECHIM
DEPARTAMENTO DE ENGENHARIAS E CIÊNCIA DA COMPUTAÇÃO
CURSO DE CIÊNCIA DA COMPUTAÇÃO
ERECHIM - RS
2017
ANDERSON EDUARDO BARBERINI
ERECHIM - RS
2017
AGRADECIMENTOS
Aos meus pais, Marcos e Isolete, que são meus maiores exemplos de superação e sempre
me incentivaram e me deram forças em toda essa jornada. Às minhas irmãs, Andressa e Adrielli
que sempre foram compreensíveis e pacientes durante todo o processo.
A minha namorada Marilei, por todo apoio e carinho prestado durante muitas horas de
estudo e dedicação necessários para chegar até aqui.
A Deus, por ter me dado saúde e força para superar as dificuldades.
A todos os professores que de alguma forma colaboraram, transmitindo conhecimento
e experiência ao longo de todo curso. Em especial, ao professor Marcos Lucas, pela orientação
deste trabalho.
A todos os meus amigos que estiveram ao meu lado e entenderam as minhas ausências
nos momentos necessários.
Aos colegas de trabalho, pelas dicas e sugestões que foram muito importantes para
diversas decisões das minhas atividades acadêmicas.
RESUMO
Key-words: Microservice architecture. Containers. Docker. REST API. Web platform for
product customization.
LISTA DE ILUSTRAÇÕES
1 INTRODUÇÃO................................................................................................................... 10
2 ARQUITETURA DA APLICAÇÃO ................................................................................ 12
2.1 Microserviços ................................................................................................................... 12
2.2 Containers ........................................................................................................................ 15
2.2.1 Docker ............................................................................................................................. 16
2.3 RESTful ............................................................................................................................ 17
2.4 API Gateway .................................................................................................................... 18
2.4.1 Kong API Gateway ......................................................................................................... 19
2.5 Autenticação e autorização ............................................................................................. 20
2.5.1 JWT ................................................................................................................................. 21
3 TECNOLOGIAS................................................................................................................. 22
3.1 HTML ............................................................................................................................... 22
3.2 CSS .................................................................................................................................... 23
3.3 JavaScript......................................................................................................................... 24
3.3.1 VueJS .............................................................................................................................. 25
3.4 PHP ................................................................................................................................... 25
3.4.1 Laravel............................................................................................................................. 26
3.4.2 Lumen ............................................................................................................................. 27
3.5 Banco de dados ................................................................................................................ 28
3.5.1 MySQL............................................................................................................................ 29
3.6 Servidor HTTP ................................................................................................................ 30
3.6.1 Nginx ............................................................................................................................... 31
4 IMPLEMENTAÇÃO DOS MICROSERVIÇOS............................................................. 32
4.1 Configuração dos containers .......................................................................................... 32
4.2 Serviço de Autenticação .................................................................................................. 35
4.2.1 Modelo Entidade - Relacionamento ................................................................................ 35
4.2.2 Serviços da API ............................................................................................................... 37
4.2.3 Diagrama de sequência ................................................................................................... 37
4.3 Serviço de Clientes ........................................................................................................... 38
4.3.1 Modelo Entidade – Relacionamento ............................................................................... 38
4.3.2 Serviços da API ............................................................................................................... 39
4.3.3 Diagrama de sequência ................................................................................................... 39
4.4 Serviço de Empresas ....................................................................................................... 40
4.4.1 Modelo Entidade - Relacionamento ................................................................................ 40
4.4.2 Serviços da API ............................................................................................................... 41
4.4.3 Diagrama de sequência ................................................................................................... 41
4.5 Serviço de Pedidos ........................................................................................................... 42
4.5.1 Modelo Entidade - Relacionamento ................................................................................ 42
4.5.2 Serviços da API ............................................................................................................... 43
4.5.3 Diagrama de sequência ................................................................................................... 44
4.6 Kong API Gateway .......................................................................................................... 44
5 DESENVOLVIMENTO DA APLICAÇÃO ..................................................................... 47
5.1 Descrição do sistema ....................................................................................................... 47
5.2 Configuração dos containers .......................................................................................... 48
5.3 Plataforma para customização ....................................................................................... 49
5.3.1 Página inicial ................................................................................................................... 50
5.3.2 Página da empresa ........................................................................................................... 50
5.3.3 Área restrita do cliente .................................................................................................... 51
5.3.4 Ferramenta de personalização ......................................................................................... 53
5.4 Painel administrativo ...................................................................................................... 54
5.4.1 Módulo de clientes .......................................................................................................... 55
5.4.2 Módulo de pedidos .......................................................................................................... 56
5.4.3 Módulo de configurações ................................................................................................ 57
6 CONCLUSÃO E TRABALHOS FUTUROS ................................................................... 58
REFERÊNCIAS ..................................................................................................................... 60
APÊNDICE A – DOCUMENTAÇÃO DA API ................................................................... 64
10
1 INTRODUÇÃO
“Os negócios em casa são uma tendência para 2017 e uma saída
para momentos difíceis, afirma o consultor Milton dos Santos. É uma
tendência por conta das oportunidades todas que a tecnologia tem
permitido em relação a novas máquinas, novas aplicações. É um
negócio que exige pouco investimento, então ele é aberto a uma
quantidade grande de pessoas, e a gente não pode esquecer do fator crise
também que tem impulsionado esse tipo de negócio. ”
2 ARQUITETURA DA APLICAÇÃO
2.1 Microserviços
comunicando através mecanismos leves, como uma API de recursos HTTP. Esses serviços são
desenvolvidos em torno de capacidades de negócios e implementados independentemente. São
de baixo acoplamento, podem ser escritos em diferentes linguagens de programação e utilizar
diferentes tecnologias para persistência de dados individualmente. (LEWIS; FOWLER, 2014)
A Figura 1 ilustra um comparativo entre uma arquitetura monolítica e uma arquitetura
de microserviços.
Para Newman (2015), os benefícios dos microserviços podem ser muitos e variados. Os
principais que ele destaca são:
Tecnologia heterogênea, pois nos permite escolher a ferramenta certa para cada
trabalho sem depender da abordagem mais padronizada, que muitas vezes, acaba
sendo de menor domínio comum.
Escalonamento, pois com serviços menores, pode-se escalar estes serviços que
precisam ser dimensionados permitido que outras partes do sistema executem em
hardware menos poderoso.
14
Facilidade de implantação, pois é possível fazer uma mudança para um único serviço
e implantá-lo independentemente. Este processo se torna muito mais rápido e muito
mais seguro do que implantar uma aplicação inteira. Esta é uma das principais razões
para organizações com Amazon e Netflix usarem arquitetura de microserviços.
2.2 Containers
Containers são leves e isso nos permite executar dezenas deles ao mesmo tempo,
tornando possível emular um sistema distribuído pronto para produção.
Permite que usuários executem aplicativos complexos sem precisar gastar horas em
problemas de configuração e instalação de ambientes.
Contudo Mouat (2015) ainda afirma: container é um conceito antigo. Por décadas os
sistemas UNIX já tinham um suporte ao chroot, que fornece uma forma de isolamento do
sistema de arquivos. Complementando, Clark (2014) relembra que o Google iniciou o
desenvolvimento do cgroups para o Linux. Esta tecnologia permite limitar o uso de recursos
para um conjunto de processo. Então, em meados dos anos 2000, eles começaram a mover toda
sua infraestrutura para containers. Tais tecnologias foram cruciais para o início do projeto Linux
Containers (LXC), que começou em 2008 e visava fornecer uma solução para conteinerização.
2.2.1 Docker
que estão disponíveis no Docker Hub ou criando novas imagens a partir de arquivos de
definição chamados Dockerfiles. (DIEDRICH, 2015)
O Docker Engine é quem fornece esta interface para execução dos containers. Além
disso, outras ferramentas foram desenvolvidas, o Docker Swarm, para gerenciamento de
cluster; Kitematic, uma GUI para trabalhar com containers e a Docker Machine, um utilitário
por linha de comando para provisionamento de hosts Docker. (MOUAT, 2015)
2.3 RESTful
dos servidores possam encaminhar, rotear e balancear sem que nenhum estado seja mantido
localmente entre as solicitações. Uma requisição stateless melhora o desempenho do serviço e
simplifica o design e a implementação de componentes do lado do servidor, visto que a ausência
do estado no servidor elimina a necessidade de sincronizar os dados da sessão com um
aplicativo externo.
O terceiro princípio definido por Rodriguez (2015), enfatiza que os URIs de serviços da
Web devem ser intuitivos a ponto de serem fáceis de adivinhar. Para isso, a estrutura de um
URI deve ser direta, previsível e facilmente compreensível. Uma maneira de atingir esse nível
de usabilidade é definir URIs de forma hierárquica, utilizando estrutura de diretórios. Para isso,
deve-se seguir algumas diretrizes como: ocultar a extensão do arquivo de script (.php, .jsp,
.asp), sempre manter tudo em minúsculo e usar hifens ao invés de espaços.
Por fim, o autor (RODRIGUEZ, 2015) define como quarto princípio a utilização de
XML, JSON ou ambos como formato de dados usado na troca de informações entre a aplicação
e os serviços. É importante que os serviços tenham a capacidade de suportar mais de um tipo
de MINE, como XML e JSON. Isso permite que a aplicação que for usar estes serviços utilize
o formato que seja mais adequado para o desenvolvimento.
Malavasi (2016) descreve que uma API Gateway é umas das ferramentas no mercado
mais efetivas para segurança, controle e desenvolvimento de APIs, principalmente por
contemplar os conceitos de CID, formado por três pilares: confidencialidade, integridade e
disponibilidade. Além disso, o Gateway vai atuar em uma camada separada da aplicação, onde
é possível separar claramente APIs e microserviços implementados. Outro benefício é a
possibilidade de antecipar e rastrear erros através de logs, já que todas as chamadas aos serviços
irão passar pelo Gateway.
O Kong é uma API layer escalável e de código aberto (também conhecida como gateway
API ou API Middleware). É executado na frente de qualquer API RESTful e é estendido através
de plugins, que fornecem funcionalidade extras, como autenticação, monitoramento, segurança,
20
controle de trafego, entre outros. Toda solicitação feita para a API atingirá primeiro o Kong e,
em seguida, será processada para a API final. Entre pedidos e respostas, o Kong irá executar
qualquer plugin que você tenha decidido instalar. Kong efetivamente se torna o ponto de entrada
para cada solicitação realizada. (KONG, 2017)
Neste projeto, a principal função da API Gateway vai ser oferecer uma camada para
autenticação, visto que determinados serviços só serão acessíveis por usuários autenticados.
Também simplificar o roteamento das chamadas RESTful, encapsulando a arquitetura interna
do sistema. A escolha desta ferramenta foi definida analisando três fatores: ser uma ferramenta
open source, possuir grande contribuição pela comunidade de desenvolvedores e a quantidade
de recursos / plugins que a ferramenta oferece.
2.5.1 JWT
JSON Web Token (JWT) é um padrão aberto especificado pela RFC 7519 que define
um modo compacto e autocontido para a transmissão segura de informações entre as partes
como um objeto JSON. Essas informações podem ser verificadas e confiáveis porque são
assinadas digitalmente. Os JWTs podem ser assinados usando um uma chave secreta (com o
algoritmo HMAC) ou um par de chaves público / privado usando o RSA. (JWT, 2017)
Os termos compacto e autocontido, segundo JWT (2017), são definidos por:
Compacto, devido ao seu tamanho menor, sendo possível ser enviado em uma URL
com parâmetros POST ou dentro de um cabeçalho HTTP. Com o tamanho menor, a
transmissão é mais rápida.
De acordo com o site oficial, JWT (2017), a estrutura do token é formada por 3 partes:
header, payload e signature. Todas elas são encodadas em Base64.
O header normalmente consiste em duas partes: o tipo de token, que no caso é o JWT,
e o algoritmo usado, como o HMAC SHA256, utilizado para este trabalho.
O payload contém os meta-dados, ou claims, que definem por exemplo, a entidade do
usuário. Nos claims é possível também definir o tempo de expiração do token.
Para criar o signature é preciso do header, payload, um secret e o algoritmo
especificado. No caso do HMAC SHA256, o signature é criado da seguinte maneira:
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIi
wiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
22
3 TECNOLOGIAS
3.1 HTML
HyperText Markup Language, ou HTML, uma linguagem para descrever a estrutura das
páginas da Web. Ela possibilita a criação de diversos elementos, como títulos, textos tabelas,
listas, formulários, figuras e principalmente links. (W3C, 2017)
De acordo com os autores Eis e Ferreira (2012), a primeira versão do HTML foi
desenvolvida por Tim Berners-Lee, em 1990. Entre 1993 e 1995, o HTML ganhou as versões
HTML+, HTML2.0 e HTML3.0. Cada uma delas possuíam diversas mudanças que
enriqueciam cada vez mais as possibilidades da linguagem. Até aqui o HTML ainda não era
tratado como um padrão. A partir de 1997, com o surgimento da W3C, grupo de trabalho
fundado por Berners-Lee, que tinha como objetivo manter o padrão do código, trabalhou nas
versões 3.2 do HTML fazendo com que ela fosse tratada como prática comum.
Em 2004, desenvolvedores de empresas como Apple, Mozilla e Opera, descontentes
com os rumos adotados pela W3C, fundaram a WHATWG (Web Hypertext Application
Technology Working Group), onde se propuseram a desenvolver as especificações para uma
nova linguagem, que seria chamado hoje de HTML 5. (SILVA, 2014)
O HTML4, não trazia grandes evoluções para a semântica de código e também não
facilitava a manipulação de elementos via CSS ou JavaScript. O HTML5 tinha como principal
objetivo facilitar a manipulação de elementos, possibilitando o desenvolvedor modificar as
características dos objetos de forma não intrusiva e de maneira transparente para o usuário final.
23
3.2 CSS
Cascading Style Sheet ou CSS, é uma linguagem para descrever a apresentação das
páginas web, incluindo cores, layout e fontes. Também permite adaptar o a tela para diferentes
dispositivos, como telas grandes, pequenas ou até para impressas. O CSS é independente do
HTML e pode ser usado com qualquer linguagem de marcação baseada em XML. (W3C, 2017)
Essa camada da web é muito importante. Ela quem define a aparência do documento,
através de características adicionadas aos elementos através de regras. Uma regra CSS é
composta de duas partes: o seletor e a declaração. O seletor é o alvo da regra e a declaração
determina os parâmetros para estilização. Os parâmetros são constituídos de uma propriedade,
que define qual a característica a ser estilizada e o valor, que quantifica ou qualifica a
propriedade. (SILVA, 2011)
Segundo Alvarez (2008), a primeira versão do CSS (CSS1) foi desenvolvida em 1995,
porém foi lançada em 1996 como recomendação oficial do W3C. Ela trouxe grandes avanços
24
para o visual das páginas, oferecendo controle aos elementos existentes no documento. Porém,
conforme a evolução do design, se existia a necessidade cada vez maior de customizações que
o CSS não suportava.
Surgiu então a segunda versão, o CSS2. Com sua chegada, muitas novidades foram
incorporadas, melhorando a qualidade das páginas desenvolvidas. E da mesma forma que a
versão anterior, com o passar do tempo, o CSS2 não estava mais suprindo as novas
necessidades, e era preciso fazer o uso de truques ou hacks e utilizar o apoio de outras
ferramentas para se chegar no resultado esperado. Atualmente a versão mais recente é a CSS3.
Nela, foram incorporadas novos seletores, recursos e diversas funcionalidades que
revolucionaram a forma com que se estiliza páginas. (ALVAREZ, 2008)
Rabelo (2017) destaca que, com a evolução do CSS, surgiu ferramentas para auxiliar no
desenvolvimento, como os pré-processadores. SASS é uma destas ferramentas. Ela permite
adicionar lógica, variáveis, aninhação de seletores, entre diversos outros recursos. Isso traz um
ganho enorme em produtividade e mantem uma boa organização nos códigos. No fim, os
arquivos SASS são processados, e produzem uma versão compilada contendo o CSS puro.
3.3 JavaScript
JavaScript é uma linguagem de programação web. Ela está presente na maioria dos sites
modernos todos os navegadores modernos, inclusive consoles, tablets e smartphones incluem
interpretadores JavaScript, o que torna a linguagem mais onipresente da história. Conforme
comentado nos capítulos anteriores, HTML é usado para especificar o conteúdo, CSS para
especificar a apresentação de páginas e o JavaScript para especificar o comportamento das
páginas. É uma linguagem de programação interpretada de alto nível, dinâmica e não tipada.
(FLANAGAN, 2011)
JavaScript tem uma biblioteca padrão de objetos e um conjunto de elementos que
formam o núcleo da linguagem. Pode-se estender o núcleo em dois lados, cliente-side e server-
side. (MOZILLA DEVELOPER NETWORK, 2017)
Client-side: Usado para aplicações do lado do cliente. Fornece objetos para controlar
um navegador web e seu Document Object Model (DOM).
3.3.1 VueJS
3.4 PHP
O PHP (PHP: Hypertext Preprocessor) é uma linguagem de script open source de uso
geral, utilizada especialmente para o desenvolvimento web e que pode ser embutida dentro do
HTML. (PHP, 2017)
A linguagem de programação PHP foi criada em 1994, por Rasmus Lerdorf, e
significava Personal Home Page Tools. Ela era formada por um conjunto de scripts escritos em
26
linguagem C, que eram voltados a criação de páginas dinâmicas. Com o tempo, mais pessoas
passaram a utilizar a linguagem, e Rasmus adicionou vários recursos, como a interação com
banco de dados. Em 1995 o código-fonte do PHP foi liberado e com isso mais desenvolvedores
colaboraram para o projeto.
Ao longo do tempo o PHP passou por várias reescritas de código e foi evoluindo cada
vez mais. Por volta de 1998, sua sigla mudou para PHP: Hypertext Preprocessor e já estava
presente em cerca de 10% dos domínios da internet. Apesar de toda evolução, o PHP ainda
necessitava de maior suporte à orientação a objetos. Esses recursos foram trazidos pelo PHP 5,
em julho de 2004. Ao longo de mais de uma década, o PHP continua adicionando novos
recursos e é considerada como uma das linguagens de programação orientadas a objetos que
mais crescem no mundo. Estima-se que o PHP seja utilizado em mais de 80% dos servidores
web existentes, tornando-a disparadamente a linguagem mais utilizada para desenvolvimento
web. (DALL’OGLIO, 2015)
Segundo Gilmore (2008), o PHP possui quatro características chaves que conduzem a
linguagem a uma posição de destaque no mercado de desenvolvimento:
3.4.1 Laravel
Templates: utiliza um templage engine conhecido por Blade, uma linguagem leve,
onde é possível criar layouts hierárquicos com blocos predefinidos nos quais o
conteúdo é injetado dinamicamente.
3.4.2 Lumen
Conforme Barnes (2016) descreve em sua publicação, Lumen é uma ótima escolha
quando se precisa de velocidade. E caso de necessidade de mais poder, migrar do Lumen para
o Laravel é um processo simples e facilitado.
O autor Redmond (2016) cita o micro-framework Lumen como uma oportunidade para
melhorar o fluxo de trabalho dos desenvolvedores PHP, possibilitando a padronização em torno
de um conjunto poderoso: Laravel e Lumen. O Lumen pode ser tão minimalista quanto precise.
Ele é rápido e, mas mais importante, ele ajuda a ser produtivo.
Cada tabela, é composta por colunas que possuem um nome exclusivo. Os dados são
armazenados na tabela em forma de registros, onde cada um possui seus atributos. Para se
referir a uma tabela, usa-se o termo relação ou entidade. O termo tupla é usado para se referir a
uma linha, e o termo atributo para se referir a coluna de uma tabela. (DATE, 2004)
Um sistema de banco de dados fornece uma linguagem de definição de dados (DDL)
para especificar seu esquema e uma linguagem de manipulação de dados (DML) para expressar
suas consultas e atualizações. Dentre as diversas linguagens em uso, a amplamente utilizada é
o SQL. O SQL (Structured Query Language). (SILBERSCHATZ; KORTH; SUDARSHAN,
2010)
3.5.1 MySQL
Didática: permite que seu funcionamento seja estudado através do seu código fonte.
Conforme definido pela RFC 2616 por Fielding et al. (1999), Hypertext Transfer
Protocol (HTTP) é um protocolo do nível de aplicação para sistemas de informação de
hipermídia, distribuídos e colaborativos. Permite um conjunto aberto de métodos e cabeçalhos
que indicam o propósito de uma requisição.
Um servidor web pode-se referir a hardware ou software, ambos trabalhando juntos. Do
lado do hardware, um servidor web é um computador que armazena os arquivos de uma
aplicação e os entrega ao usuário final. Do lado do software o servidor web é responsável por
controlar como os usuários acessam os arquivos, através de um servidor HTTP. A Figura 4
ilustra a comunicação entre o cliente e o servidor. (MOZILLA DEVELOPER NETWORK,
2017)
3.6.1 Nginx
Nginx é um servidor HTTP de código aberto. Ele é conhecido por seu alto desempenho,
estabilidade, conjunto de recursos ricos, configuração simples e baixo consumo de recursos.
Ao contrário dos servidores tradicionais, o Nginx não depende de threads para processar
pedidos. Em vez disso, ele usa uma arquitetura muito mais escalável orientada a eventos
(assíncrona). Mesmo se você não necessite lidar com milhares de solicitações simultâneas, você
pode se beneficiar por seu baixo consumo de memória. (NGINX, 2017)
De acordo com a W3Techs (2017), site especializado em dados estatísticos de
tecnologias da web, o servidor Nginx compões uma fatia de 35,7% do mercado. Contudo, é
possível restringir esses dados somente aos sites mais visitados, segundo o ranking da Alexa.
Considerando apenas os 1.000 sites mais visitados, o Nginx conta com uma fatia 56,4% do
mercado, passando a ser o mais popular.
A sua performance e a popularidade de uso nos principais sites foram os fatores
determinando para definir o Nginx como o servidor HTTP padrão para este trabalho.
32
foi incluído a instalação do servidor Nginx e também do supervidor, responsável por controlar
e monitorar os processos do sistema. É através deste controlador que os serviços do PHP e do
Nginx são iniciados e monitorados.
A Figura 5 representa o Dockerfile em uma versão simplificada, com os comandos
necessários para a construção da imagem para os microserviços, de acordo com as
características mencionadas anteriormente.
FROM alpine:3.5
EXPOSE 80 443
Fonte: Autor
O comando build é responsável por gerar uma imagem a partir do arquivo Dockerfile
que está dentro do diretório client. O comando run é responsável por executar esta imagem.
Porém, executar esse processo para todos os serviços do sistema se torna um processo oneroso
e diminui a produtividade. Como solução para isso, foi utilizado um recurso do Docker
chamado Docker Compose.
Conforme a Docker (2017) descreve, o Docker Compose é uma ferramenta para definir
e executar aplicativos do Docker com vários containers. Utilizando um arquivo YAML, todos
os serviços são configurados e com um único comando todos eles são criados e iniciados.
A Figura 6 representa a definição do Docker Compose utilizado para o serviço de
clientes, abordado nas próximas sessões. Nela é possível identificar a configuração de dois
containers, um para o serviço e outro para o banco de dados.
client:
build: ./client-service/docker/api
image: client.service.api
depends_on:
- client_db
volumes:
- ./client-service/src:/var/www/client
ports:
- 8082:80
client_db:
image: mysql
ports:
- 3307:3306
environment:
- MYSQL_ROOT_PASSWORD=12345
volumes:
- ./data/client:/var/lib/mysql
Fonte: Autor
35
O serviço tem sua imagem gerada a partir do arquivo de definição Dockerfile no local
especificado pela propriedade build, e o outro container que usa a imagem oficial do MySQL.
Com um único comando, a imagem é construída e os containers iniciados:
docker-compose up -d
Fonte: Autor
parceiros e demais acessos necessários, com por exemplo a aplicação. Na Figura 8 é possível
visualizar esta estrutura.
Fonte: Autor
Nota-se que as tabelas não possuem relação com entidades externas. É uma
característica dos microserviços, enfatizada por autores influentes na evolução desta
abordagem. Fowler (2017), cita em seu site, um comentário do Werner Vogels, CTO da
Amazon falando sobre esse aspecto. Ele define que o serviço deve encapsular os dados e ser
acessível somente através de uma interface publicada do serviço. Nenhum acesso direto ao
banco de dados é permitido fora do serviço e não há compartilhamento de dados entre os
serviços.
O próprio Fowler (2015), relatou essa abordagem, definindo que uma das principais
características dos microserviços é que cada serviço gerencia seu próprio banco de dados e
qualquer outro serviço deve passar pela API para chegar até ele. Esta característica é refletida
em todos os serviços implementados neste trabalho.
37
O serviço de autenticação provê três funções básicas: login, logout e cadastro das
credenciais dos usuários, contendo o usuário e senha.
No processo de login, as credenciais são validadas de acordo com o tipo de usuário, ou
seja, se é cliente, empresa ou parceiro. Porém, o fluxo depende do Kong API Gateway, abordada
no capítulo 4.6. Cada usuário do sistema deve estar cadastrado no gateway, através de um
consumer - e após, persistido no banco de dados, através da coluna consumer_id - e com base
nas informações retornadas, um token é criado através das credenciais JWT geradas pelo Kong.
Um consumer pode ter várias credenciais JWT, cada uma correspondente a um token
cadastrado, ou seja, um usuário pode ter vários logins em diferentes dispositivos.
No processo de logout, as credenciais JWT geradas para um usuário são excluídas. Com
isso, quando um request chegar ao gateway, não será mais aceito, pois o token será inválido.
Os endereços expostos pela API de autenticação estão descritos na Tabela 1
Conforme descrito na Tabela 1, existem dois fluxos que são responsáveis por persistir
as credenciais de um cliente ou empresa no banco de dados. Estes dois recursos são chamados
internamente por outros serviços, após o cadastro de um usuário, sem necessidade de passar
pelo Kong. Porém, os fluxos de login e logout dependem diretamente do gateway, visto que
todas as chamadas externas terão que passar por ele, conforme descrito na sessão 4.6. Na Figura
9 é representado através do diagrama de sequência o processo de login e logout.
38
Fonte: Autor
Fonte: Autor
Alguns serviços desta API são dependentes do token, que deve ser enviado junto com a
requisição. É em seu payload que é extraído a empresa que está requisitando o recurso. É o caso
do serviço para listar os clientes e também as estatísticas, pois para esses dois processos, é
necessário saber quem é a empresa para então saber quem são os clientes.
Os endereços expostos pela API de clientes estão listados na Tabela 2.
Os fluxos dos serviços expostos pela API de clientes, conforme já mencionado nos
capítulos anteriores, dependem do gateway, pois todas as requisições feitas por um usuário são
enviadas ao Kong. Apenas o fluxo de cadastro depende de outro serviço, que é o AuthService,
40
para o controle das credenciais. Essa comunicação ocorre internamente entre os microserviços,
conforme apresentado no diagrama de sequência apresentado na Figura 11. Para os demais
serviços da API, a comunicação é semelhante ao que ocorre com a busca de clientes: o usuário
solicita a requisição, o sistema envia para o gateway que chama o serviço e retorna as
informações.
Fonte: Autor
O banco de dados do serviço de empresas é composto de apenas uma tabela, onde são
armazenadas as informações sobre a empresa e também configurações para a página acessada
pelos clientes. A Figura 12 demonstra o modelo entidade relacionamento para esta estrutura.
41
Fonte: Autor
A API de empresas compões três funções básicas, que são: cadastro, listagem e
atualização. Os endereços expostos por ela estão definidos na Tabela 3.
Fonte: Autor
Fonte: Autor
Da mesma forma que a API de clientes, alguns serviços desta API também são
dependentes do token. Essa arquitetura é necessária pois é preciso saber quem está requisitando
o recurso. É o caso da listagem de pedidos. Se for uma empresa, lista todos os pedidos da
empresa, caso for um cliente, lista apenas os pedidos daquele cliente específico.
Os endereços expostos pela API de pedidos estão descritos na Tabela 4.
Fonte: Autor
kong:
image: kong:0.10
depends_on:
- kong_db
ports:
- 8000:8000
- 8443:8443
- 8001:8001
environment:
- KONG_DATABASE=postgres
- KONG_PG_HOST=kong_db
- SERVICE_NAME=kong
kong_db:
image: postgres:9.4
ports:
- 5432:5432
environment:
- POSTGRES_USER=kong
- POSTGRES_DB=kong
- SERVICE_NAME=kong_db
volumes:
- kong_db:/var/lib/postgresql/data
Fonte: Autor
curl -i -X POST \
--url http://localhost:8001/apis/ \
--data 'name=clients' \
--data 'uris=/v1/clients' \
--data 'upstream_url=http://client/api/v1/clients'
É também pela interface de administrador que os plugins são instalados. Sua instalação
pode ser feita em uma API específica ou de âmbito global. Para este trabalho foram utilizados
dois plugins, um para autenticação via JWT e outro para o módulo CORS, responsável por
permitir que as APIs recebam solicitações de um domínio diferente. No caso, o primeiro é
utilizado individualmente, para cada API, e o segundo é global.
46
curl -i -X POST \
--url http://localhost:8001/apis/clients/plugins \
--data 'name=jwt'
Após rodar o comando acima, a API de clientes estará com o plugin do JWT instalado
e a partir disso, toda requisição deverá conter um cabeçalho informando o token de acesso. O
exemplo abaixo demonstra esse cabeçalho com um token real.
Authorization: Bearer
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIi
wiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
A interface de aplicação é mapeada através da porta 8000, para tráfego HTTP e na porta
8443, para tráfego HTTPS. Ao enviar uma requisição, deve-se informar qual é o serviço que
está sendo solicitado, para então, o gateway encaminhar a chamada ao destino. Porém, antes de
fazer este roteamento, os plugins instalados são executados, podendo assim, negar a requisição
antes mesmo de encaminhá-la ao destino. Um exemplo deste caso é o uso da autenticação por
JWT, onde se o sistema não informar o token de acesso, o gateway nega a requisição antes
mesmo de chegar ao serviço. Abaixo segue um exemplo de requisição para a interface da
aplicação, solicitando o serviço de clientes através do URI informado no cadastro da API:
5 DESENVOLVIMENTO DA APLICAÇÃO
Fonte: Autor
48
Fonte: Autor
o PHP e outro para o Nginx. Essa abordagem foi arquitetada pois é a parte da aplicação onde
todas as requisições são resolvidas, então as possibilidades de escalabilidade ficam mais
amplas, dependendo da demanda.
Sendo assim, foi definido através do Docker Compose dois serviços que, na definição
do Dockerfile, utilizam as imagens oficiais do php:7-fpm e da última versão do Nginx. A Figura
19 representa o YAML desta estrutura.
web:
build: ./docker/nginx
ports:
- 80:80
- 443:443
volumes:
- ./app:/var/www/app
-./panel:/var/www/panel
- ./docker/nginx/conf:/etc/nginx/conf.d
depends_on:
- app
app:
build: ./docker/php
volumes:
- ./app:/var/www/app
Fonte: Autor
A plataforma para customização é composta de três módulos: uma página com conteúdo
sobre a empresa, uma área restrita do cliente, onde é possível visualizar os seus pedidos e a
ferramenta para personalizar produtos. Esta plataforma é oferecida pela empresa que se
cadastrou na Mogg através do endereço principal da aplicação, definido no endereço abaixo.
http://www.mogg.com.br
http://nivel1.mogg.com.br
Fonte: Autor
Ao aderir ao serviço, a empresa irá possuir uma página exclusiva, onde poderá incluir
um texto falando sobre ela. O nome que aparece no topo da página também é editável,
juntamente com o subdomínio usado na URL de acesso. A tela, conforme apresentado na
Figura 21, possui três menus: um para acesso a página inicial, outro para a plataforma de
customização e o último para a área restrita do cliente.
51
Fonte: Autor
Fonte: Autor
Um ponto importante é que todo cadastro fica vinculado a uma empresa específica.
Desse modo, o usuário pode ter cadastro em outras empresas, onde os dados não são
compartilhados. Este requisito é importante para manter de forma isolada os clientes que cada
empresa possui.
Após se autenticar ou se cadastrar, o usuário será enviado para a tela que ele solicitou
anteriormente. Um exemplo deste fluxo é o momento em que o cliente acessa a ferramenta da
empresa e é redirecionado para a autenticação. Após completar, volta para a página da
ferramenta já autenticado.
Acessando a área restrita, por meio do menu MINHA CONTA, é possível visualizar o
status de cada pedido e conferir qual o valor e data da compra. Esta tela está representada na
Figura 23.
53
Fonte: Autor
O acesso a esta página é feito através do menu CRIAR localizado no topo da aplicação.
Porém, para visualizar seu conteúdo, é necessário estar autenticado como cliente, que foi
descrito no capítulo 5.3.3. Então, após se identificar, a tela de personalização é exibida. Nela o
cliente pode customizar apenas canecas, requisito para que o trabalho não ficasse tão extenso.
Ainda na tela, são exibidas informações sobre o preço, informado pela empresa, e o botão para
fechar o pedido, após o cliente estar satisfeito com seu produto. Após finalizar o pedido, o
usuário é redirecionado para a área restrita, onde são exibidas as últimas ordens realizadas.
Conforme apresentado na Figura 24 a ferramenta possui dois recursos principais: textos
e imagens. O cliente pode inserir diversos textos, com opções de mudar a fonte da letra e
também as cores. Quanto as imagens, é possível enviar fotos e ajusta-las conforme necessário.
Os dois tipos de elementos podem ser excluídos, rotacionados ou redimensionados de acordo
com a preferência.
54
Fonte: Autor
http://panel.mogg.com.br
Fonte: Autor
Este módulo é responsável por manter os clientes da empresa. Nele, é possível visualizar
as informações de cada cliente e também alterar caso for necessário. A empresa tem a opção de
adicionar novos clientes, podendo assim, usar o sistema como um controle interno do negócio.
Na tela de clientes, apresentada na Figura 26, é exibido um datagrid listando os clientes
e as informações mais pertinentes, sendo o identificador, nome e-mail e telefone e os botões
para alterar ou incluir novos clientes.
Fonte: Autor
56
Fonte: Autor
Fonte: Autor
Fonte: Autor
58
além de um novo módulo no painel administrativo para a empresa gerenciar todos os produtos
disponíveis para personalização.
Entre os trabalhos futuros também está a criação de um serviço de e-mail para enviar
aos clientes e empresas mensagens de boas-vindas, pedidos realizados, status de pedidos, entre
outros. Em complemento, permitir a empresa mais opções de apresentar aos seus clientes seus
serviços, através de banners, novas páginas, galeria de trabalhos, entre outros.
60
REFERÊNCIAS
BEAN, MARTIN. Laravel 5 Essentials: Explore the fundamentals of Laravel, one of the
most expressive and robust PHP frameworks available. Birmingham: Packt Publishing Ltd.,
2015.
EIS, Diego; FERREIRA, Elcio. HTML5 e CSS 3 - Com Farinha e Pimenta. São Paulo:
Tableless, 2012.
FIELDING Roy Thomas et al. Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616, 1999.
Disponível em: <https://www.ietf.org/rfc/rfc2616.txt>. Acesso em: 04 nov. 2017.
FILIPOVA, Olga. Learning Vue.js 2. Packt Publishing Ltd, 2016.
FLANAGAN, David. JavaScript: The Definitive Guide, Sixth Edition. O'Reilly Media,
2011.
FONSECA, Marina. 10 máquinas para abrir um negócio em casa a partir de 630 reais,
2017. Acesso em: 11 abr. 2017. Disponível em: <https://exame.abril.com.br/pme/10-maquinas-
para-abrir-um-negocio-em-casa-a-partir-de-630-reais>.
MOUAT, Adrian. Using Docker: Developing and Deploying Software with Containers. First
Edition. O'Reilly Media, 2015.
PEGN TV. Máquina que customiza tecidos é opção para quem trabalha em casa, 2016.
Disponível em <http://g1.globo.com/economia/pme/pequenas-empresas-grandes-
negocios/noticia/2016/12/maquina-que-customiza-tecidos-e-opcao-para-quem-trabalha-em-
casa.html>. Acesso em: 11 abr. 2017.
RABELO, Eduardo. A evolução do CSS: De arquivos CSS, SASS, BEM para CSS
Modules até Styled Components, 2017. Disponível em: <https://medium.com/tableless/a-
evolu%C3%A7%C3%A3o-do-css-de-arquivos-css-sass-bem-para-css-modules-at%C3%A9-
styled-components-b7ad4d16ffc2>. Acesso em: 18 mai. 2017.
REDMOND, Paul. Lumen Programming Guide: Writing PHP Microservices, REST and
Web Service APIs. Apress, 2016.
RODRIGUEZ, Alex. RESTful Web services: The basics, 2015. Disponível em:
<https://www.ibm.com/developerworks/library/ws-restful/>. Acesso em: 15 mai. 2017.
SILVA, Maurício Samy. Desenvolva aplicações web profissionais com uso dos poderosos
recursos de estilização das CSS3. 1. ed. São Paulo: Novatec. 2011.
63