GITBOOK-39: No subject

docs/pocs/poc-1.md

@@ -2,11 +2,11 @@
 
 ## PoC 1 - Microsserviço Baseado em Domínios de Negócio
 
-#### Definição da PoC
+### Definição da PoC
 
 **Objetivo:** Demonstrar a criação eficaz de um microsserviço do zero, focando em um domínio de negócio específico para ilustrar como a modularização pode ser realizada de acordo com as necessidades de negócios.
 
-#### Requisitos da PoC
+### Requisitos da PoC
 
 1. **Identificação do Domínio de Negócio:** Agendamento de Consultas.
 2.  **Definição dos Requisitos:** Para a definição dos requisitos, foi utilizado um product backlog, que é uma lista dinâmica e ordenada das funcionalidades desejadas para o produto. Essa lista foi organizada e priorizada utilizando a técnica MoSCoW (Must have, Should have, Could have, Won't have this time). Essa técnica permite a priorização eficaz dos requisitos, classificando-os em quatro categorias principais:
@@ -64,39 +64,39 @@ A análise de resultados envolveu a avaliação desta PoC em diversos termos de
 
 <figure><img src="../.gitbook/assets/Desempenho Operacional.png" alt=""><figcaption><p>Fonte : Autor</p></figcaption></figure>
 
-**Latência Média**:
+1. **Latência Média**:
 
 * A latência média foi calculada como 48.45 ms.
 
-**Throughput**:
+2. **Throughput**:
 
 * O throughput foi calculado como 20.64 operações por segundo.
 
-#### **Distribuição da Latência**:
+3. **Distribuição da Latência**:
 
 <figure><img src="../.gitbook/assets/latency_distribution_chart.png" alt=""><figcaption><p>fonte : Autor</p></figcaption></figure>
 
 Este histograma mostra a frequência das latências observadas nas requisições. A latência é o tempo que leva para uma requisição ser processada e receber uma resposta. No gráfico abaixo, cada barra representa o número de requisições que tiveram uma latência dentro de um intervalo específico. Por exemplo, se uma barra está alta na posição "50 ms", isso significa que muitas requisições foram processadas em cerca de 50 milissegundos. Este gráfico ajuda a identificar se a maioria das requisições está sendo processada rapidamente ou se há um número significativo de requisições com latências mais altas.
 
-#### **Throughput ao Longo do Tempo**
+4. **Throughput ao Longo do Tempo**
 
 <figure><img src="../.gitbook/assets/throughput_time_chart.png" alt=""><figcaption><p>Fonte : Autor</p></figcaption></figure>
 
-Este gráfico de linha mostra o número de requisições bem-sucedidas ao longo do tempo. Ele ajuda a entender como o throughput do microsserviço varia durante o período de teste.]
+Este gráfico de linha mostra o número de requisições bem-sucedidas ao longo do tempo. Ele ajuda a entender como o throughput do microsserviço varia durante o período de teste.
 
-#### Ocorrências de Falhas
+5. **Ocorrências de Falhas**
 
 <figure><img src="../.gitbook/assets/failure_occurrences_chart_fixed.png" alt=""><figcaption></figcaption></figure>
 
 Este histograma mostra a distribuição das falhas ao longo do tempo. Ele indica em quais momentos ocorreram falhas nas requisições. Cada barra representa o número de falhas que ocorreram em um intervalo de tempo específico.
 
-#### **Uso de CPU e Memória**:
+6. **Uso de CPU e Memória**:
 
 * Os dados de uso de CPU e memória foram coletados utilizando o Grafana com o Prometheus. A métrica `process_cpu_usage{}` foi utilizada para medir a porcentagem de uso de CPU, e a métrica `jvm_memory_used_bytes{area="heap", id="G1 Old Gen"}` foi utilizada para medir a quantidade de memória usada pela geração "Old" do Garbage Collector G1. A "Old Generation" (ou "Geração Antiga") no contexto do Garbage Collector (GC) é onde os objetos de longa duração são armazenados. Monitorar essa área específica é crucial porque ela pode impactar significativamente o desempenho da aplicação, especialmente durante a execução do GC, quando a "Old Generation" é coletada. Se essa área estiver frequentemente cheia ou se estiver crescendo rapidamente, pode indicar problemas de retenção de memória ou a necessidade de tuning do GC.
 * **Uso de CPU**: O gráfico mostra que o uso de CPU varia, com um valor máximo de aproximadamente 0.06%.
 * **Uso de Memória**: O gráfico indica que o uso de memória na geração "Old" do Garbage Collector G1 varia entre 39 MB e 43 MB.
 
-#### Conclusão
+### Conclusão
 
 A partir dos dados analisados, observa-se que a latência média do microsserviço está razoavelmente baixa, indicando um bom tempo de resposta. O throughput é bom, mas pode ser melhorado. A presença de 304 falhas pode ser atribuída a fatores como as limitações do ambiente local com container, o que sugere que esses números podem ser mais favoráveis em um ambiente de produção otimizado. Como os dados foram coletados em um ambiente local rodando em um container, é provável que o desempenho em um ambiente de produção real seja diferente. Fatores como a configuração da infraestrutura, o balanceamento de carga e o tráfego de rede podem impactar significativamente os resultados. As limitações do ambiente local com container podem ter impactado tanto o throughput quanto o número de falhas observadas, sugerindo que esses números podem ser mais favoráveis em um ambiente de produção otimizado.
 

docs/pocs/poc-3.md

@@ -2,11 +2,11 @@
 
 ## **PoC 3 - Circuit Breaker**
 
-#### **Definição da PoC**
+### **Definição da PoC**
 
 **Objetivo**: Essa prova de conceito tem o intuito de validar a implementação do padrão Circuit Breaker para aumentar a resiliência do sistema, prevenindo falhas em cascata entre microsserviços.
 
-#### **Requisitos da PoC**
+### **Requisitos da PoC**
 
 Os seguintes requisitos devem ser atendidos para que essa prova de conceito seja considerada concluída:
 
@@ -18,13 +18,13 @@ Os seguintes requisitos devem ser atendidos para que essa prova de conceito seja
 
 #### **Passos para Implementação**
 
-**1.Escolher o Microsserviço:**
+1. **Escolher o Microsserviço:**
 
 Foi selecionado o microsserviço "registry" devido à sua extrema importância, pois ele comporta as principais funcionalidades do serviço de agendamento de consultas. Este microsserviço é crítico para o funcionamento da aplicação, uma vez que gerencia o registro e a manutenção das instituições e profissionais, além de seus horários de disponibilidade. Por sua relevância, garantir a resiliência e disponibilidade deste serviço é fundamental para o sucesso da plataforma.
 
 O código fonte com a implementação pode ser encontrado no seguinte repositório: [https://github.com/mateusbrandaot/TCC2\_Microservices/tree/main/agenday/registry](https://github.com/mateusbrandaot/TCC2\_Microservices/tree/main/agenday/registry)
 
-**2.Configurar o Circuit Breaker:**
+2. **Configurar o Circuit Breaker:**
 
 * Utilizamos a biblioteca Resilience4j para implementar o Circuit Breaker.
 *   Adicionamos dependências no `pom.xml`:
@@ -37,7 +37,7 @@ O código fonte com a implementação pode ser encontrado no seguinte repositór
     </dependency>
     ```
 
-**3.Implementar o Circuit Breaker no Serviço:**
+3. **Implementar o Circuit Breaker no Serviço:**
 
 * Configuramos o Circuit Breaker nas classes de serviço.
 *   Exemplo de configuração:
@@ -74,7 +74,7 @@ O código fonte com a implementação pode ser encontrado no seguinte repositór
 
 O código fonte completo dessa classe pode ser encontrado no seguinte repositório: [https://github.com/mateusbrandaot/TCC2\_Microservices/blob/main/agenday/registry/src/main/java/com/agenday/registry/service/InstitutionService.java](../../agenday/registry/src/main/java/com/agenday/registry/service/InstitutionService.java)
 
-**4.Configurar Parâmetros do Circuit Breaker:**
+4. **Configurar Parâmetros do Circuit Breaker:**
 
 *   Adicionamos configurações no `application.yml`:
 
@@ -94,7 +94,7 @@ O código fonte completo dessa classe pode ser encontrado no seguinte repositór
 
 ### **Análise dos Resultados da PoC**
 
-#### **Simulação e Teste**
+1. **Simulação e Teste**
 
 <figure><img src="../.gitbook/assets/image (7).png" alt=""><figcaption><p>Fonte: Autor</p></figcaption></figure>
 
@@ -109,7 +109,7 @@ O código fonte completo dessa classe pode ser encontrado no seguinte repositór
 
 * Realizamos novamente a solicitação POST para criar uma instituição. O Circuit Breaker deve ser ativado, e a lógica de fallback deve salvar os dados no MongoDB.
 
-**4.Verificação**
+2. **Verificação**
 
 <figure><img src="../.gitbook/assets/image (10).png" alt=""><figcaption><p>Fonte:Autor</p></figcaption></figure>
 
@@ -121,6 +121,6 @@ O código fonte completo dessa classe pode ser encontrado no seguinte repositór
 * **Banco de Dados Não Relacional (MongoDB):**
   * Verificamos a coleção `institutionFallback` no MongoDB para confirmar que os dados foram salvos e estes podem ser reprocessados posteriomente.
 
-#### Conclusão:
+### Conclusão:
 
 Com esses passos e a análise dos resultados, confirmamos que a implementação do Circuit Breaker com fallback está funcionando corretamente, garantindo a resiliência do sistema.