Garbage Collector | Compactação e Fragmentação | STW (Stop-The-World) | Uso recomendado | Estrutura da Heap | Processos do GC | Trade-offs | Recursos Recomendados | Outros detalhes |
---|---|---|---|---|---|---|---|---|
Serial GC | ✅ Compacta após Major GC ❌ Pode sofrer fragmentação antes da compactação |
🔴 Alto (pausa total na coleta). | Aplicações pequenas com pouca alocação de memória. | Young Gen (Eden + Survivor) + Old Gen | Mark → Sweep → Compact | ✅ Baixo consumo de memória ❌ STW muito longo |
🔹 1 CPU Core 🔹 ≤ 1GB RAM |
Usa uma única thread, causando longas pausas. |
Parallel GC | ✅ Compacta após Major GC ou Full GC ❌ Pode sofrer fragmentação antes da compactação | 🔴 Alto (mas usa múlt |
Configuração de Limit de CPU | Vantagens | Desvantagens | Quando Usar |
---|---|---|---|
Sem Limit de CPU | Permite que a JVM utilize todos os recursos disponíveis do nó, melhorando o desempenho e reduzindo contenção de CPU. | Pode causar concorrência com outras cargas de trabalho no cluster, levando a variações imprevisíveis de desempenho. | Recomendado para aplicações que requerem máximo desempenho e não competem por CPU com outras workloads. |
Limit de CPU Definido | Garante que a aplicação não utilize mais CPU do que o estipulado, proporcionando maior previsibilidade e controle. | Pode causar throttling e reduzir a eficiência da JVM, especialmente para workloads de alto desempenho. | Útil para clusters compartilhados onde a CPU precisa ser alocada de forma controlada entre diferentes aplicações. |
Data: 07/01/2025
Status: Aprovado
Precisamos de um banco de dados para armazenar informações de produtos, incluindo descrições, preços e categorias. O sistema deve suportar um alto volume de consultas e permitir buscas eficientes.
apiVersion: networking.k8s.io/v1 | |
kind: Ingress | |
metadata: | |
name: ingress-my-services | |
namespace: my-services | |
annotations: | |
alb.ingress.kubernetes.io/actions.ssl-redirect: > | |
{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}} | |
alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-east-1:xxxx:xxxxx | |
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]' |
(artigo recuperado do helpdev.com.br - criado em 08/2019)
Esse post vou abordar como realizar a instalação e configurações basicas do GitLab - CE
, também como criar os executores de CI/CD
para seu ambiente e mostrarei um caso prático de execução de uma pipeline
. Não entrarei em detalhes sobre todas as coisas, pois a intenção é de uma documentação simples dos processos de instalação dessa ferramenta incrível;
É necessário para a execução do processo como um todo um ambiente linux com o Docker
e docker-compose
préviamente instalado, não vou abordar como realizar esses procedimentos nesse tutorial.
A instalação do Gitlab - CE
é relativamente simples quando utilizamos o Docker, a seguir segue o compose
já com algumas configurações de mapeamento de volumes e configuração de endereços, note que o IP
representado no arquivo é da maquina local que estou realizando a configuração, caso tenha um domínio próprio basta subistituir, caso não tenha insira seu IP
local.
(o projeto: https://github.com/gbzarelli/events-distribution-platform)
O projeto events-distribution-platform
tem como intuito validar uma arquitetura que seja capaz de distribuir eventos utilizando o Kafka
como plataforma de Streamming e notificar clientes via Webhooks.
Os webhooks serão cadastrados em uma base NoSQL baseado em filtros de tipo de eventos, assim cada usuário (associado a uma organização) poderia ter diferentes tipos de filtros para notificar diferentes endereços.
// Definição dos pinos | |
const int gasSensorPin = A3; // Pino analógico do sensor MQ-2 | |
const int buzzerPin = 8; // Pino digital para o buzzer | |
// Definição do valor limite para acionar o buzzer (ajuste conforme necessário) | |
const int gasThreshold = 100; | |
const int maxGasLevel = 1023; // Valor máximo que o sensor pode ler (10 bits) | |
// Frequência mínima e máxima para o buzzer | |
const int minFrequency = 100; // Frequência mínima do buzzer em Hz |
@AllArgsConstructor | |
public class ReshippingOrderUseCase { | |
private final OrderRepository orderRepository; | |
private final CustomerRepository customerRepository; | |
private final OrderRepository orderRepository; | |
private final ShippingProviderClient shippingProviderClient; | |
private final LogisticClient logisticsClient; | |
A Arquitetura Hexagonal promove a modularidade, flexibilidade e manutenibilidade do código, permitindo que as mudanças nos componentes externos não afetem diretamente a lógica de negócios. Essa abordagem é especialmente útil em sistemas nos quais a evolução das regras de negócio é frequente, e a capacidade de adaptação a mudanças é crucial.
A estrutura proposta por Alister Cockburn em seu artigo, visa o isolamento da camada de aplicação (core do negócio) fornecendo portas para as implementações de entrada e saída da aplicação, para atender os padrões propostos pela arquitetura, usamos o seguinte modelo de estrutura para implementação