No artigo anterior, discuti o Brighter V10 RC 1 e suas atualizações significativas. Recentemente (10 de agosto de 2025), a equipe do Brighter lançou o Release Candidate 2, trazendo recursos adicionais, correções de bugs importantes e refinamentos para o framework. Este artigo explora o que há de novo no Brighter V10 RC2 e como essas mudanças podem beneficiar seus aplicativos.
Novos Recursos e Aperfeiçoamentos
Embora o Brighter V10 RC2 introduza mais algumas mudanças, a equipe confirmou que não estão planejadas mais alterações que quebrem compatibilidade para o lançamento final. Este RC2 foca na conclusão de recursos e melhorias de estabilidade.
Suporte ao AWS SDK v4
O Brighter V10 RC2 agora oferece suporte oficial ao AWS SDK v4, mantendo compatibilidade com o SDK v3. Essa abordagem de suporte duplo é particularmente valiosa para ambientes corporativos, onde atualizações de pacotes em larga escala podem ser complexas e demoradas. Muitas organizações têm dependências indiretas no AWS SDK v3 por meio de outras bibliotecas e podem precisar coordenar migrações em vários projetos.
Em um artigo futuro, demonstrarei exemplos práticos de implementação para ambas as versões do SDK.
Integração Oficial com RocketMQ
O Brighter V10 RC2 agora inclui suporte oficial para o RocketMQ, uma plataforma distribuída de mensagens e streaming originalmente desenvolvida pela Alibaba e atualmente mantida como projeto da Apache. O RocketMQ é projetado para mensagens de alta taxa de transferência (throughput) e baixa latência com garantias sólidas de durabilidade, tornando-o ideal para aplicações críticas que exigem entrega confiável de mensagens em escala.
Esta integração expande o ecossistema de mensagens do Brighter, dando aos desenvolvedores outra opção poderosa para construir sistemas distribuídos resilientes. Fornecerei exemplos detalhados de uso em um artigo futuro.
Suporte a Quorum Queues para RabbitMQ
O RC2 adiciona suporte completo às Quorum Queues do RabbitMQ, que representam um avanço significativo em relação às filas clássicas tradicionais. As Quorum Queues usam o algoritmo de consenso Raft para replicar mensagens entre nós, garantindo segurança dos dados e alta disponibilidade. Diferentemente das filas espelhadas clássicas, as Quorum Queues fornecem ordenação consistente de mensagens, eleição automática de líder durante falhas de nó e melhor utilização de recursos.
Este recurso é particularmente valioso para aplicações que exigem garantias sólidas de durabilidade onde a perda de mensagens não pode ser tolerada, como transações financeiras ou processos de negócios críticos.
UUID v7 para Identificadores de Mensagens
A partir do RC2, o Brighter agora usa UUID v7 como padrão para identificadores de mensagens ao executar no .NET 9+. O UUID v7 incorpora timestamps na estrutura do UUID, tornando os identificadores aproximadamente ordenados por tempo enquanto mantém a unicidade global.
Esta mudança oferece benefícios significativos de desempenho para padrões de inbox e outbox, especialmente ao usar esses IDs como chaves de banco de dados. UUIDs ordenados por tempo reduzem divisões de página e fragmentação em bancos de dados indexados, levando a um melhor desempenho de gravação e utilização mais eficiente do armazenamento.
Os desenvolvedores devem agora usar:
public class SomeCommand() : Command(Id.Random());
// ou
public class SomeCommand() : Command(Uuid.New());
Integração com Resilience Pipeline
O Polly v8 introduziu o poderoso conceito de Resilience Pipeline e o Brighter V10 RC2 agora adota totalmente esse padrão. Substituímos todo o uso interno do antigo padrão Policy pela abordagem mais flexível e performática do ResiliencePipeline.
O Resilience Pipeline permite combinar múltiplas estratégias de resiliência (como retry, timeout e circuit breaker) em um pipeline de execução coeso. Isso proporciona melhor desempenho através da redução do lançamento de exceções (usando o padrão Outcome), compartilhamento de contexto mais eficiente entre estratégias e características aprimoradas de alocação de memória.
Como mostrado na documentação do Polly, os Resilience Pipelines permitem padrões sofisticados como estratégias de timeout aninhadas com lógica de retry, proporcionando controle preciso sobre o tratamento de falhas em sistemas distribuídos.
Gerenciamento Dinâmico de Chave de Partição e Cabeçalhos
No Brighter V10 RC1, não era possível definir chaves de partição e cabeçalhos de mensagem dinamicamente com os mapeadores padrão. O RC2 resolve essa limitação por meio do objeto RequestContext, dando aos desenvolvedores controle granular sobre roteamento de mensagens e metadados.
processor.Post(new SomeRequest(), new RequestContext
{
Bag =
{
[RequestContextBagNames.PartitionKey] = "some-partition",
[RequestContextBagNames.Header] = new Dictionary<string, object>
{ ["some-header"] = "some-value" }
}
})
Circuit Breaker para o Padrão Outbox
O RC2 introduz funcionalidade de circuit breaker para o padrão outbox, abordando uma preocupação crítica de confiabilidade. Anteriormente, quando um tópico ou fila de destino estava indisponível (devido a problemas de infraestrutura), o Brighter tentava repetidamente entregar mensagens, potencialmente sobrecarregando o sistema.
A nova implementação do circuit breaker detecta falhas persistentes e interrompe temporariamente as tentativas de entrega para destinos problemáticos. Após um período de resfriamento configurado, ele retomará cautelosamente as tentativas de entrega. Isso evita desperdício de recursos em operações fadadas ao fracasso e permite que o sistema se recupere graciosamente de problemas transitórios de infraestrutura.
Correções de Bugs
Vários bugs importantes identificados no RC1 foram corrigidos neste lançamento
Geração Consistente de ID Aleatório
O RC1 tinha um problema onde Id.Random retornava o mesmo valor. Isso foi corrigido no RC2 mudando de propriedade para método e garantindo o uso de um valor diferente a cada vez.
Melhorias no Outbox de Banco de Dados Relacional
Um bug que afetava a inserção de mensagens no outbox de banco de dados relacional foi resolvido. O problema estava relacionado à forma como o Brighter armazenava valores URI.
Registro do Outbox Swapper & Archive
O processo de registro para os componentes outbox swapper e archive tinha problemas que poderiam impedir a inicialização adequada. Estes foram corrigidos para garantir inicialização e operação confiáveis desses serviços críticos em segundo plano.
Desligamento Gracioso do RabbitMQ
Uma das melhorias críticas no Brighter V10 RC2 aborda uma preocupação significativa de confiabilidade presente no RC1: a incapacidade de desligar conexões do RabbitMQ de forma graciosa.
Conclusão
O Brighter V10 RC2 representa um passo significativo em direção ao lançamento final, entregando os recursos prometidos enquanto aborda questões críticas descobertas durante os testes do RC1. A adição do suporte ao AWS SDK v4, integração com RocketMQ, Quorum Queues para RabbitMQ, identificadores UUID v7, Resilience Pipelines e capacidades de roteamento dinâmico de mensagens aprimora substancialmente a proposta de valor do Brighter para construção de sistemas distribuídos resilientes.
Com base na estabilidade atual e completude de recursos, a equipe do Brighter está visando um lançamento final da V10 no próximo mês, assumindo que nenhum problema importante seja descoberto. Caso problemas significativos surjam, um lançamento RC3 seria preparado para abordá-los antes do lançamento final.
Para desenvolvedores que estão considerando o Brighter para seu próximo projeto ou planejando uma atualização de versões anteriores, o RC2 traz o framework mais perto de seu estado mais robusto e completo em recursos até o momento. O caminho de migração cuidadoso da V9, combinado com as novas capacidades da V10, torna este um momento empolgante para trabalhar com o ecossistema Brighter.
Top comments (0)