Cloud Stream V2 x V3
Se você chegou a este artigo muito provavelmente você está buscando formas de migrar o Spring Cloud Stream (SCS) para a versão 3.x onde quase tudo mudou.
A versão 3.x tem um foco principalmente em aplicações serverless ou seja um serviço que vai executar uma única função e o conjunto de funções desempenham um fluxo de trabalho ou processo relacionado a uma determinada funcionalidade através de funções Consumer, Supplier e/ou Function, mas nem todas as aplicações são assim atualmente embora essa seja uma tendência.
Olhando pra versão 2.x Sink, Source e StreamListeners formam o conjunto de configurações que permitem consumir mensagens de um ou múltiplos tópicos ou filas onde é comum se utilizar informação de muitas fontes (upstream systems) para se processar uma determinada funcionalidade bem como publicar mensagens resultantes da execução desta funcionalidade.
Essa publicação tem o objetivo de demonstrar como a migração da versão 2.x para 3.x pode ser feita.
Em princípio a idéia do Cloud Function (CF) em conjunto com SCS é ser utilizado numa aplicação Function as a Service (FaaS) com uma função e responsabilidade únicas.
Uma aplicação não-FaaS pode consumir informação de várias fontes bem como publicar mensagens que serão consumidas por várias fontes, essa é um abordagem comum no SCS v2.x e será demonstrado a seguir como você pode fazer esse migração para SCS v3.x, se você já verificou o que há de novo no SCS versão 3 vai verificar que as as definições de Sink, Source e Processor foram substituídas por funções Consumer, Supplier e Function
Uma configuração que pode não ficar muito clara em princípio nessa nova forma de implementação é o mapeamento do nome da função com o tópico ou a fila utilizada, no SCS v2.x isso era explícitamente configurado e era possível identificar qual era o tópico ou a fila ser consumida pela aplicação através da configuração do Sink e agora você precisa mapear diretamente o nome da função que vai consumir as mensagens do tópico ou fila configurado no seu application.yaml
Particularmente eu não gostei muito dessa nova forma de configuração mas pode ser apenas a primeira impressão, dependendo do número de topicos ou filas que se consome e/ou para quantos se produz a lista de mapeamento de funções (spring.cloud.stream.function.definition) pode ficar extensa e não muito legível no arquivo de configuração mas ainda assim possível. Não verifiquei qual seria o limite de funções a ser declaradas no arquivo de configuração
Configuração
O arquivo application.yaml tem uma mistura de configuração dos Spring Cloud Stream e do Spring Cloud, as funções e definições de funções são parte da configuração do Spring Cloud
Não há grandes diferenças na configuração exceto pela entrada spring.cloud.stream.function.definition que contém as funções que devem mapear para os nomes de funções Consumer, Supplier e Function, e o sufixo padrão para configurações de entrada e saída que são respectivamente <nome da função>-in-0 e <nome-da-função>-out-0.
Consumindo mensagens
Na versão 2 utilizamos o Sink para configurar qual o tópico ou a fila que vai ser utilizada para ler as mensagens que chegam além da anotação StreamListener que permite uma série de configurações inclusive o filtro das mensagens que chegam na sua aplicação
Já na versão 3 uma função Consumer anotada como @Bean é utilizada e aquele filtro que antes era definido via anotação agora é deve ser feita programaticamente.
Produzindo mensagens
O método recomendado para se produzir mensagens é similar ao componente consumidor porém utilizando um Supplier, porém por uma outra forma e mais simples na minha opinião é utilizar StreamBridge que permite o envio de mensagens de forma simples e dinâmica.
CloudEvents (opcional)
Cloud Events é um padrão bastante utilizado e que vem crescendo cada vez mais, basicamente ele coloca a mensagem original em um “envelope” atribuindo características que enriquecem a mensagem como origem, quando evento foi publicado, seu tipo, tipo de conteúde, etc
Neste exemplo é possivel verificar a serializacao e deserializacao dos eventos, lembrando que CloudEvents completamente opcional
O SDK do CloudEvents oferece muitas facilidades que podem ser verificadas aqui, como por exemplo o conversor abaixo que permite integração ao Spring:
Conclusão e próximos passos
Esta publicação tem o intuito de auxilar com exemplos e configurações objetivas o que mudou entre as versões 2.x e 3.x do SCS e como essa atualização pode ser feita
É uma mudança brusca na forma como se utiliza o SCS e que pode causar resistência em alguns para se adequar as mudanças mantendo o modelo de programação depreciado ainda por algum tempo, ou impor alguns desafios para aplicações em produção exigindo uma bateria consistente de testes principalmente relacionada ao volume de carga que a aplicação recebe.
Os testes não foram abordados aqui e estes também sofreram grandes mudanças mas isso será abordado em posts futuros, se você não pode esperar aqui tem o necessário para seguir adiante
Espero que as informações aqui publicadas possam ser úteis
This post was also published here in en_US
Até a próxima
-Rogério