| 🪧 Vitrine.Dev | |
|---|---|
| ✨ Nome | Tiu Lanches |
| 🏷️ Tecnologias | Java, Maven, Spring, MySQL, Docker, Kubernetes, Kafka |
| 🚀 URL | |
| 🔥 Desafio | Tech Challenge FIAP |
Projeto criado para conclusão da Pós Gradução em Software Architecture pela FIAP
Há uma lanchonete em expansão devido ao seu sucesso. Mas sem um sistema estruturado para atender as necessidades da lanchonete os atendimentos podem ser caóticos pela devido a alta demanda.
Quando o cliente chega ao estabelecimento ele precisa utilizar um sistema de autoatendimento na recepção, onde poderá criar seu pedido escolhendo o lanche, acompanhamento, bebida e sobremesa. Precisa possibilitar que o cliente possa realizar o pagamando com cartão de crédito, qrcode, pix ou conta do mercado pago.
Com o pedido criado é necessário exibir em um painel todo o processo que o pedido está passando em real time para que o solicitante acompanhe para poder retirar no balcão. Com o pedido pronto será exibido no painel a informação de sua conclusão.
O sistema precisa ser capaz de escalar de acordo com a demanda.
Para acessar a documentação com informações como o DDD deste projeto clicar no link para o Notion
O modelo de negócio foi pensado como ponto de partida o pedido, onde o cliente pode se identificar ou não, caso se identifique será exigido que informe CPF, email e nome.
Com o pedido criado será enviado uma criação de preferência para o mercado pago onde permitirá ao cliente escolher a forma de pagamento.
Quando o pagamento é efetivado o pedido é encaminhado para a produção(cozinha) e quando concluído o prepado é finalmente disponibilizado para entrega ao balcão que se encarrega de garantir que o pedido será entregue o cliente correto e finalizar o pedido.
Segue uma ilustração deste processo:
Para atender os requisitos da aplicação ser capaz de escalar foi implementado o Kubernetes onde são criados dois deployments um para a base de dados e outro para a aplicação.
A base de dados terá acesso a um volume no servidor de forma que os dados fiquem protegidos e não sejam perdidos no caso de seu POD precisar ser recriado.
Para a aplicação o seu deployment inicia criando 2 PODs iniciais este inclusive é a quantidade mínima que precisa estar disponível, podendo chegar a 4 PODs. Para isso foram implementadas a liberação de alguns acessos para que o HPA possa monitorar e realizar a escalabilidade quando o uso de processamento ultrapasse 50%.
Cada um dos deployments serão criados com seus devidos services e confimaps, mas existe um secret para ser usado por ambos devido senhas e token de acesso ao mercado pago.
O ponto de acesso com a web fica a cargo do service da aplicação.
Segue uma ilustração da arquitetura criada no kubernetes localmente:
- Clean Architecture
- Java - JDK 21
- MySql - 8.0
- Spring Framework
- Lombok
- Flyway
- Maven
- Jackson Databind
- Log4j
- Spring Doc
- Kafka
- Jacoco
- JUnit
- Mockito
Existem variáveis de ambiente na aplicação que estão cadastradas no docker compose e para kubernetes para serem apenas executadas.
Para poder funcionar em IDE é necessário cadastrar as seguintes variáveis de ambiente:
- MYSQL_ROOT_PASSWORD=<SENHA_ROOT>
- DATASOURCE_URL=<URL_CONEXAO_BD>
- DATASOURCE_USERNAME=<USER_NAME_DB>
- DATASOURCE_PASSWORD=<SENHA_DB>
- ACCESS_TOKEN_MP=<TOKEN_MERCADO_PAGO>
- Baixe o docker compose do projeto em https://github.com/luisferrarezi/tiulanches/blob/main/compose/docker-compose.yml
docker compose -f docker-compose.yml up --build -d
- Aplicação: http://localhost:8080
- Swagger: http://localhost:8080/swagger-ui/index.html
- Baixe baixe todos os arquivos localizados em https://github.com/luisferrarezi/tiulanches/tree/main/kubernetes/local
sh startapp.sh
Neste comando serão executados os arquivos yaml automaticamente, na sequência correta, entre subir a base de dados e subir a aplicação existe uma espera de 60 segundos para garantir que a base já estará funcional quando a aplicação subir. Somente após apresentar a mensagem de Projeto pronto que ele estará efetivamente ok para enviar requisições. Para isso é necessário ter o curl instalado no ambiente de execução do comando.
Caso não tenha ambiente para executar o bash por ser executado os comandos de acordo com a ordem disponibilizada abaixo
kubectl apply -f secrets.yaml
kubectl apply -f metrics.yaml
kubectl apply -f db-deployment.yaml
kubectl apply -f app-deployment.yaml
OBS: É INDISPENSÁVEL QUE TODO O AMBIENTE ESTEJA FUNCIONAL ANTES DE REALIZAR QUALQUER TESTE
- Aplicação: http://localhost:31200
- Swagger: http://localhost:31200/swagger-ui/index.html
Segue o link direto para o local onde a collection do postman está disponível: https://github.com/luisferrarezi/tiulanches/tree/main/Postman
Segue link do vídeo que explica como a arquitetura e aplicação estão estruturadas e como funciona o aplicativo desde a criação do pedido até a sua entrega.
Para a conclusão da 3ª Fase do projeto foi necessário criar novos recursos:
- Azure Function -> Mais detalhes acessar o Readme do projeto.
- Terraform App -> Mais detalhes acessar o Readme do projeto.
- Terraform Database -> Mais detalhes acessar o Readme do projeto.
Atualmente para esta branch existem 2 níveis de automação, explicado abaixo:
- Pull Request: este é executado no momento que é criado o PR, e nele é realizado um build para garantir que a aplicação não foi quebrada após alteração.
- Push: este é executado somente após o PR ter sido aprovado e executado o merge para a main, primeiro é realizado o build da aplicação, estando tudo ok é então logado no Container Registry da Azure, criado a imagem como latest e faz o upload dela para o ACR. Finalmente cria-se o ConfigMap com variáveis de ambiente necessárias para serem utilizadas pela aplicação no AKS, feito isso são utilizados os yamls configmap.yaml e app-deployment.yaml, para subir a aplicação no AKS.
Existe a variável de ambiente que é indispensável para que a function funcione corretamente:
- AZURE_CREDENTIALS=<AZURE_CREDENTIALS> - Credenciais necessárias do usuário github para que possa realizar o deploy
- CLUSTER_NAME=<CLUSTER_NAME> - O nome do cluster que foi criado para o AKS
- CONFIG_MAP_YAML=<CONFIG_MAP_YAML> - ConfigMap necessário com as variáveis de ambiente para o funcionamento da aplicação
- RESOURSE_GROUP=<RESOURSE_GROUP> - Resouce Group destinado na Azure para a aplicação
- SUBSCRIPTION= - Subscription ao qual o AKS criado pertence
- PASSWORD_ACR=<PASSWORD_ACR> - Senha para enviar imagem no ACR
- SERVER_ACR=<SERVER_ACR> - Server criado para enviar imagem no ACR
- USERNAME_ACR=<USERNAME_ACR> - Usuário para enviar imagem no ACR
Para a hospedagem de todo o projeto foi escolhida a Azure como Cloud pelos seguintes motivos:
- Extremamente robusta, segura e confiável
- Centraliza todos os recursos em Resouce Group, facilitando assim localizar tudo o que foi criado e ter melhor visualização dos custos da estrutura
- Transparente com os custos onde exibe de forma eficaz e clara onde está sendo usasdo o seu dinheiro e permite com muita agilidade interromper todos os recursos desnecessários e assim ajudando a economizar, diferente a AWS que faz questão de esconder muitos recursos criados que estão te cobrando.
- Tenho a conta de estudante que me permite utilizar R$ 500 para criar apresentar o projeto.
Segue link do vídeo que explica os seguintes pontos:
- Terraform criados para a estrutura que é montada
- Processo em cada um dos repositório com github actions
- Estrutura de login
- Estrutura Functions
- Estrutura Database
- Estrutura aplicação
- Demonstração do funcionamento da aplicação e do processo do login, realizando pedido tanto quando o CPF é informado e não informado
Link: https://youtu.be/v9yVQ3_HeSU
Segue link do vídeo que explica os seguintes pontos:
- Terraform readequado
- Estrutura Microsservices
- Nginx
- Estrutura testes
- Deploys AKS
- Sonar
- Estrutura bases
- Demonstração do funcionamento da aplicação em microsservices
Vídeo: https://youtu.be/4WYPlbg_rkY
Para a conclusão da 4ª Fase do projeto foi necessário criar novos repositórios:
- Pagamento -> Mais detalhes acessar o Readme do projeto.
- Pedidos -> Mais detalhes acessar o Readme do projeto.
- Produção -> Mais detalhes acessar o Readme do projeto.
Atualmente para esta branch existem 2 níveis de automação, explicado abaixo:
- Pull Request: este é executado no momento que é criado o PR, e nele é realizado um build para garantir que a aplicação não foi quebrada após alteração.
- Push: este é executado somente após o PR ter sido aprovado e executado o merge para a main, primeiro é realizado o build da aplicação, estando tudo ok é então logado no Container Registry da Azure, criado a imagem como latest e faz o upload dela para o ACR. Finalmente cria-se o ConfigMap com variáveis de ambiente necessárias para serem utilizadas pela aplicação no AKS, feito isso são utilizados os yamls configmap.yaml e app-deployment.yaml, para subir a aplicação no AKS.
Novas variáveis de ambiente que são indispensáveis para que funcione corretamente:
- CONEXAO_KAFKA=<CONEXAO_KAFKA> - Configuração do service do kafka
- SONAR_TOKEN=<SONAR_TOKEN> - Token criado no sonar para que a aplicação seja validada por ele
Foi implementado no através do git actions execução de testes e validação via sonar de todos os PRs e Main.
Segue imagem que ilustra o coverage e validação do sonar para este projeto:
Abaixo a imagem que ilustra a arquitetura atual do projeto usando microsserviços:
