Sim. E pelo inventário que enviaste, eu não começaria pela alteração das dependências Maven. Neste projeto, a migração 2.17 → 3.1 é essencialmente uma mudança de arquitetura.

O próprio Apache é explícito: código Ignite 2 não pode ser reutilizado diretamente em Ignite 3, a configuração mudou bastante, e os clientes em Ignite 3 seguem outro modelo. (Apache Ignite)

Primeiro: o modelo mental que precisas

Pensa assim:

Ignite 2.x: muito orientado a distributed cache / data grid. A aplicação pode arrancar um node/client node dentro da própria JVM, configurar CacheConfiguration, usar IgniteCache, locks, semáforos, services, events, compute, Spring Cache, etc.

Ignite 3.x: muito mais orientado a uma distributed database schema-driven. O conceito central deixa de ser Cache e passa a ser Table; o acesso key/value continua possível através de KeyValueView/RecordView, mas sobre tabelas com schema e primary key. Placement/replicação passa por distribution zones, e a consistência é fortemente baseada em Raft. (Apache Ignite)

Portanto, a pergunta correta não é:

“Como substituo IgniteCache por alguma coisa do Ignite 3?”

É:

“Que comportamento esta aplicação obtém hoje através do Ignite 2, e como reproduzimos cada um desses comportamentos no modelo do Ignite 3?”

Essa distinção vai poupar-te muito tempo.

---

O que eu já consigo perceber do teu projeto

O inventário é bastante útil. A arquitetura atual parece ser aproximadamente:

text
                    ┌──────────────────┐
                    │   cluster-node   │
                    │ Ignite servers   │
                    │ sem business     │
                    │ logic            │
                    └────────┬─────────┘
                             │
                       Ignite cluster
                             │
                    ┌────────┴─────────┐
                    │    ignite-app    │
                    │ client-mode node │
                    │ REST + loaders   │
                    └────────┬─────────┘
                             │
                  dataframe / repositories
                             │
                   caches distribuídas

O próprio inventário confirma que cluster-node é essentially server puro e que ignite-app entra no cluster como um client-mode node, mantendo REST API e carregamento de dados. (ignite-inventory-report.md)

Além disso, há uma camada importante:

@Cacheable/@CachePut/@CacheEvict → JsonCacheProxyManager → JsonCacheProxy → Ignite

(ignite-inventory-report.md)

Ou seja: felizmente, parte do acesso ao Ignite já está relativamente encapsulada. Isto pode vir a ser uma vantagem enorme.

---

Eu dividiria a migração em 7 fases

Fase	Objetivo	Resultado esperado
1. Compreender o sistema atual	Perceber por que razão cada feature Ignite existe	Architecture + behavioural map
2. Compatibility assessment	Comparar cada feature 2.17 com 3.1	Migration matrix
3. Desenhar arquitetura Ignite 3	Decidir como ficará cluster, clients, tables e infra	Target architecture
4. Resolver os blockers	TTL, locks, Spring Cache, services, etc.	Architecture decisions
5. Fazer uma vertical slice	Migrar um fluxo pequeno end-to-end	PoC funcional
6. Migrar por componentes	Migrar armazenamento, coordination, compute, etc.	Aplicação completa
7. Cutover e validação	Dados, performance, failure scenarios	Produção

O importante é não misturar estas fases. Se começares imediatamente a tentar fazer o projeto compilar com Ignite 3, vais descobrir problemas um a um sem saber se a arquitetura final faz sentido.

---

Fase 1 — perceber o projeto antes de perceber Ignite

Aqui eu começaria.

Não tentes estudar todas as classes. Escolhe fluxos de negócio.

Por exemplo, no inventário aparecem FX_RATE e PRICE_BY_LISTING, que parecem ótimos candidatos. São caches REPLICATED, ATOMIC, com dados indexados e TTL. (ignite-inventory-report.md)

Segue um request de ponta a ponta:

Quem pede FX_RATE → quem lê → que repository usa → que cache acede → quem carrega essa cache → quando expira → o que acontece se estiver vazia → o que acontece se um node desaparecer.

Depois faz o mesmo para PRICE_BY_LISTING.

Depois estuda o fluxo de inicialização distribuída através de db_init e processInfo.

Isso vai ensinar-te Ignite através de necessidades reais do sistema.

Por exemplo, o inventário diz que processInfo é utilizado para distributed locking e db_init para coordenação da inicialização do cluster. (ignite-inventory-report.md) (ignite-inventory-report.md)

Portanto, não estudes DistributedLockExecutorServiceImpl perguntando apenas “o que faz este código?”. Pergunta:

“Que problema de concorrência estão a resolver com este lock?”

Pode ser que Ignite 3 tenha outra forma de resolver o problema — e nesse caso não queres portar a implementação antiga.

---

Fase 2 — cria a tua Migration Matrix

Este seria provavelmente o documento mais importante da task.

O teu inventário já contém quase toda a coluna da esquerda.

Eu criaria algo conceptualmente deste género:

Ignite 2 no projeto	Para que serve aqui	Ignite 3	Decisão
IgniteCache	armazenamento KV	Table / KeyValueView	migrar
CacheConfiguration	schema/configuração	tables + zones	redesenhar
IgniteSpringBean	embedded/client node	thin client ou embedded	decisão arquitetural
SpringCacheManager	Spring @Cacheable	investigar integração	⚠️
@QuerySqlField	schema/indexação	schema explícito/mapping	redesenhar
IgniteCache.lock()	distributed lock	sem equivalência 1:1 assumida	⚠️
Semaphore	coordenação	investigar/redesenhar	⚠️
Ignite Services	serviços distribuídos	investigar/redesenhar	⚠️
IgniteCallable	remote compute	Ignite 3 Compute	migrar conceito
peer class loading	enviar classes	deployment units	redesenhar
Events	restart/failure handling	event/lifecycle diferente	redesenhar
Visor/control utility	operações	Ignite 3 CLI/REST	substituir
ExpiryPolicy/TTL	expiração	problema crítico	🔴

Essa matrix não deve responder apenas “API X virou API Y”. Deve conter uma coluna chamada Business semantic.

Isso é essencial porque ATOMIC, TRANSACTIONAL, REPLICATED, FULL_ASYNC etc. pertencem ao modelo Ignite 2.

O teu projeto, por exemplo, tem:

FX_RATE: ATOMIC + REPLICATED + FULL_ASYNC
PRICE_BY_LISTING: ATOMIC + REPLICATED + FULL_ASYNC
processInfo: TRANSACTIONAL + REPLICATED + FULL_SYNC. (ignite-inventory-report.md)

Não tentes traduzir isso mecanicamente para Ignite 3.

Pergunta antes:

Por que é replicated?

Quantas cópias precisamos realmente?

Que perda de dados é aceitável?

Precisamos de read-your-writes?

Por que FULL_ASYNC?

Por que processInfo tem de ser transactional?

Ignite 3 tem um modelo diferente de transações e consistência; as operações são transactional e as read-write transactions são serializable. (Apache Ignite)

---

Fase 3 — a maior mudança arquitetural do teu projeto

Para mim, esta é provavelmente a primeira decisão grande.

Hoje:

text
ignite-app
    ↓
IgniteSpringBean
    ↓
client-mode Ignite node
    ↓
faz parte da topologia Ignite

Em Ignite 3, os clients são todos thin clients. Um client não entra na cluster topology, não guarda partitions e não é destino de compute. (Apache Ignite)

Portanto é bastante provável que a arquitetura alvo fique mais parecida com:

text
┌─────────────────┐
│ Ignite 3 node   │
├─────────────────┤
│ Ignite 3 node   │
├─────────────────┤
│ Ignite 3 node   │
└────────┬────────┘
         │ :10800
         │
┌────────▼────────┐
│   ignite-app    │
│ Spring Boot app │
│ Ignite client   │
└─────────────────┘

Isso parece uma diferença pequena visualmente, mas conceptualmente é enorme.

O ignite-app deixa de ser um cidadão da topologia Ignite.

Consequentemente, tens de reavaliar toda a lógica que depende de coisas como ClusterNode, predicates de nodes, IgniteClientDisconnectedException, node events e restart automático.

No projeto atual existem precisamente predicates de nodes, eventos EVT_NODE_FAILED e lógica de restart que acaba em System.exit(...) e num shell script que volta a arrancar a aplicação. (ignite-inventory-report.md) (ignite-inventory-report.md)

Eu classificaria toda esta área como “redesign, não port”.

---

Fase 4 — caches deixam de ser o centro do modelo

Isto provavelmente será a parte maior da migração funcional.

Hoje tens muitos CacheConfiguration, caches criadas programaticamente, templates, @QuerySqlField, etc. (ignite-inventory-report.md)

Ignite 3 muda para um modelo schema-driven:

text
Ignite 2
Cache<K,V>
CacheConfiguration
@QuerySqlField

          ↓

Ignite 3
Table
Primary Key
Columns
Indexes
Distribution Zone
KeyValueView / RecordView

Ignite 3 permite continuar a pensar em key/value: KeyValueView separa key e value conceptualmente, por isso não tens necessariamente de transformar a aplicação numa aplicação SQL. (Apache Ignite)

Mas agora o schema passa a importar muito mais.

E isso significa que eu faria um exercício explícito para cada cache:

text
Nome da cache
↓
Qual é a key?
↓
Qual é o value?
↓
Quais campos precisam de ser columns?
↓
Qual é a primary key?
↓
Que indexes existem?
↓
Qual é a política de distribuição?
↓
Qual é a política de persistence?
↓
Qual é a política de expiration?

O Apache disponibiliza inclusive tooling de migração que analisa configurações Ignite 2 e gera DDL para reproduzir caches como tables Ignite 3. (Apache Ignite)

Eu usaria essa ferramenta como instrumento de análise, não como verdade absoluta.

---

Há um blocker que eu investigaria imediatamente: TTL

Aqui tens um problema real.

O teu projeto usa expiry extensivamente: existem caches 1DAY, templates com TTL e FX_RATE/PRICE_BY_LISTING têm entityTtl. (ignite-inventory-report.md)

Apache Ignite 3.1 não fornece a funcionalidade de expiration/TTL equivalente. Há inclusive um ticket do Apache que remove documentação/metrics de expiration porque a feature não existe em Ignite 3; esse ticket afeta 3.0 e foi corrigido documentalmente para 3.1. (Apache Issues)

Para mim, isto sobe imediatamente para:

🔴 Architecture decision required.

Antes de migrares muita coisa, tens de perceber:

text
Por que razão estes dados expiram?
        ↓
correção?
memória?
regra de negócio?
freshness?
cleanup?
        ↓
O sistema continua correto
se o record não desaparecer automaticamente?

Dependendo da resposta, a solução arquitetural pode ser muito diferente: guardar explicitamente a validade e ignorar dados expirados, fazer purge periódico, substituir apenas certas caches por outra tecnologia de cache, ou perceber que a expiração não é realmente necessária porque o loader sobrescreve os dados.

Mas isso é uma decisão funcional/arquitetural, não uma simples alteração de API.

---

Outro ponto crítico: Spring Cache

O teu projeto usa SpringCacheManager e ignite-spring-cache-ext:1.0.0. (ignite-inventory-report.md)

Essa extensão pertence ao ecossistema Ignite 2; a própria documentação da integração descreve SpringCacheManager e IgniteClientSpringCacheManager sobre as APIs Ignite 2. (Apache Ignite)

Não assumiria que podes simplesmente trocar a versão.

Como a aplicação passa por:

text
Spring annotations
      ↓
JsonCacheProxyManager
      ↓
JsonCacheProxy
      ↓
Ignite

(ignite-inventory-report.md)

eu estudaria muito bem JsonCacheProxyManager e JsonCacheProxy.

Podem ser a boundary ideal da migração.

Idealmente, controllers, services e lógica de negócio deveriam saber o mínimo possível sobre se por baixo existe IgniteCache ou KeyValueView.

---

Locks, semáforos e services são outra zona vermelha

O projeto não usa apenas armazenamento.

Tem explicit distributed locks, distributed semaphores e Ignite Services. (ignite-inventory-report.md)

Eu não tentaria encontrar classes Ignite 3 com nomes parecidos.

Começaria pelo significado:

text
DistributedLockExecutorServiceImpl
→ que recurso protege?
→ contra quem?
→ qual o failure model?
→ quanto tempo dura o lock?
→ o que acontece se o owner morrer?

Depois:

text
SemaphoreShellComponent
→ é só tooling/debug?
→ ou produção depende de semáforos?

E:

text
CacheInfoService / RatesJsonService
→ são realmente Ignite Services distribuídos?
→ ou podiam ser simplesmente serviços da aplicação?

O compute é diferente. Ignite 3 continua a ter distributed compute, mas o deployment model mudou: código remoto é colocado no cluster como versioned deployment units. (Apache Ignite)

Portanto IgniteCallable não deveria ser portado mecanicamente; deves primeiro perceber por que querem executar essa lógica remotamente.

---

Também não migres a configuração propriedade a propriedade

Atualmente tens TcpDiscoverySpi, Kubernetes IP Finder, Multicast, static discovery, TcpCommunicationSpi, data regions, collision SPI, segmentation policy, etc. (ignite-inventory-report.md)

Ignite 3 usa outra configuração, em HOCON/JSON, dividida conceptualmente entre node, cluster e distribution zones. Storage também foi redesenhado para storage engines → storage profiles → distribution zones → tables. (Apache Ignite)

Ou seja, evita isto:

text
DataRegionConfiguration → qual é a classe Ignite3 equivalente?
TcpDiscoverySpi → qual é a classe Ignite3 equivalente?
CacheMode.REPLICATED → qual é o enum Ignite3 equivalente?

Faz antes:

text
Qual era o objetivo desta configuração?
             ↓
Como Ignite 3 resolve esse objetivo?

Por exemplo, discovery continua a existir, mas passa pelo network.nodeFinder, que suporta configurações próprias como STATIC/MULTICAST. (Apache Ignite)

---

Antes de falar em migração de dados, descobre uma coisa

Este cluster usa persistence ou é efetivamente um cache rebuildable?

O inventário mostra Data Regions e work directories, mas não me permite afirmar que persistence está efetivamente ligada.

Esta resposta muda radicalmente o projeto.

Se os dados forem reconstruídos pelos loaders:

text
Ignite 2
   X

Ignite 3 vazio
   ↓
loader
   ↓
dados reconstruídos

pode não existir uma verdadeira “data migration”.

Se forem dados persistentes que precisam de ser preservados, aí precisas de uma estratégia dedicada. Ignite 3.1 inclui migration tooling para transformar persistent Ignite 2 caches em Ignite 3 tables. A própria documentação avisa que o armazenamento persistente do Ignite 2 não é diretamente compatível com Ignite 3. (Apache Ignite)

Esta é uma das primeiras coisas que eu confirmaria com alguém da equipa.

---

A PoC que eu faria

Não faria uma PoC chamada:

“Conseguir arrancar Ignite 3.”

Isso prova muito pouco.

Faria uma vertical slice de negócio.

Por exemplo FX_RATE.

Objetivo da PoC:

text
Ignite 3 cluster
       ↓
table FX_RATE
       ↓
ignite-app conecta como client
       ↓
loader carrega FX rates
       ↓
repository escreve
       ↓
REST endpoint lê
       ↓
resultado funcionalmente igual ao atual

E durante essa PoC verificaria também schema, serialization/mapping, indexação, replicated semantics, failure/reconnect, performance básica e estratégia de TTL.

Se conseguires fazer um fluxo inteiro, aprendes provavelmente 60–70% dos problemas que aparecerão nas restantes caches.

Migrar vinte classes parcialmente ensina-te muito menos.

---

A ordem em que eu atacaria o projeto

Se estivesse no teu lugar, nos próximos dias faria apenas estas coisas:

1. Desenhar a arquitetura atual, usando o inventory como base.

2. Escolher FX_RATE e seguir todo o fluxo end-to-end no código.

3. Fazer o mesmo para processInfo/db_init, porque aí vais compreender distributed coordination.

4. Criar a Migration Matrix feature por feature.

5. Marcar cada feature como straightforward, redesign, unknown ou blocker.

6. Resolver primeiro os grandes unknown/blocker: TTL, Spring Cache, locks/semaphores, Services, persistence e client-node architecture.

7. Só depois desenhar a arquitetura alvo e fazer a PoC FX_RATE.

Essa seria a minha sequência.

---

E há algo importante sobre a tua posição na task

Não precisas de te tornar expert em Apache Ignite antes de começar.

Neste momento precisas sobretudo de conseguir responder a três perguntas para cada pedaço do projeto:

“O que isto faz?” → “Por que o sistema precisa disto?” → “Qual é o conceito equivalente ou alternativa no Ignite 3?”

Se fizeres isso sistematicamente, a migration matrix praticamente se transforma no plano de implementação.

E neste projeto já tens uma excelente base para começar: o inventário identificou todas as classes que usam Ignite, todas as caches, features, propriedades, configuração e dependências. (ignite-inventory-report.md)

Se quiseres, no próximo passo posso pegar neste inventory especificamente e construir contigo uma Migration Matrix completa, feature por feature, classificando cada item como 🟢 simples, 🟡 exige redesign, 🔴 potencial blocker e dizendo o que deves investigar em cada um, ainda sem escrever código.

A ideia principal do agente está certa, mas ele simplificou demasiado e há pelo menos uma afirmação que eu considero perigosa. Eu não usaria essa explicação como base para começar já a alterar o cliente.

A parte certa é esta: em Ignite 3.1, é perfeitamente normal o cluster server-side ser executado como produto standalone, sem uma aplicação Java da equipa a arrancar IgniteSpringBean. A própria documentação mostra o Ignite 3.1 a correr diretamente a partir da distribuição ou da imagem Docker oficial, com configuração externa e depois um cluster init. (Apache Ignite)

No teu Ignite 2, pelo contrário, cluster-node é efetivamente uma aplicação Java que constrói o servidor Ignite através de IgniteConfiguration, discovery SPI, data regions, etc. (ignite-inventory-report.md) Portanto, essa mudança de modelo que o agente descreveu é real.

Mas eu corrigiria a conclusão para:

“O código Java custom do cluster-node provavelmente desapareceu. A responsabilidade server-side não desapareceu; passou sobretudo para configuração e infraestrutura.”

Isso é muito diferente de “não migras o server”.

O que eu considero correto e incorreto no que ele te disse

Afirmação	Veredicto	Porquê
“Agora pode não existir Java custom no server”	✅ Sim	Ignite 3.1 pode correr diretamente como produto standalone
“Dockerfile + configuração + K8s manifests + init”	✅ Muito plausível	É precisamente um deployment normal de Ignite 3
“Discovery/storage/replication são tratados pela binary”	✅ Sim	O engine Ignite implementa isso; vocês configuram o comportamento
“IgniteConfig.java deixa de existir”	✅ Provavelmente	Para um cluster standalone, sim
“ignite.yaml é a config standard Ignite”	⚠️ Estranho	Ignite 3.1 documenta HOCON ou JSON, normalmente ignite-config.conf, não YAML (Apache Ignite)
“Tu não migras o server”	⚠️ Simplificação excessiva	Alguém teve de migrar discovery, storage, persistence, topology, security, cluster init, zones, etc.
“Tu apenas apontas o cliente para :10800”	❌ Não	Isso só resolve connectivity
“Locks e semaphores já vêm na binary”	❌/⚠️ Muito enganador	Há locks internos de transactions; isso não significa que existe equivalente ao IgniteCache.lock()/IgniteSemaphore usado pela aplicação
“Novo IgniteConfig são ~15 linhas”	⚠️ Só para abrir conexão	Não resolve caches→tables, Spring Cache, TTL, compute, services, locks, schema etc.

E este último ponto é particularmente importante no teu projeto.

---

Por isso: SIM, eu analisaria primeiro o projeto do Ignite 3.1 em K8s

Acho até que deves fazer isso antes de mudar o código da aplicação.

Não porque esperes encontrar um novo IgniteConfig.java.

Mas porque queres responder à pergunta:

“Qual é exatamente o ambiente Ignite 3.1 para o qual esta aplicação vai ser migrada?”

Esse repo pode dizer-te coisas extremamente importantes.

Por exemplo, no teu sistema atual tens:

text
Ignite 2

cluster-node
    │
    ├── IgniteConfig.java
    ├── IgniteProperties.java
    ├── TcpDiscoverySpi
    ├── Kubernetes IP Finder
    ├── DataRegionConfiguration
    └── ...

(ignite-inventory-report.md)

No novo mundo podes encontrar algo aproximadamente assim:

text
Ignite 3.1
Kubernetes
    │
    ├── Docker image
    ├── Ignite node config
    ├── StatefulSet
    ├── Services
    ├── PersistentVolumes
    ├── ConfigMaps/Secrets
    ├── cluster-init Job
    └── possivelmente criação de zones/tables

Esses ficheiros são a nova arquitetura server-side.

Não são “só DevOps”.

---

Há uma coisa no texto do agente que me deixa logo de pé atrás

Ele diz:

ignite.yaml

Mas o Ignite 3.1 nativamente documenta configuração em HOCON ou JSON. O ficheiro default da distribuição é etc/ignite-config.conf. (Apache Ignite)

Por exemplo, a própria documentação mostra conceitos do género:

text
ignite {
    network {
        ...
    }
}

e o Docker monta isso como:

text
/opt/ignite/etc/ignite-config.conf

(Apache Ignite)

Pode perfeitamente existir um ignite.yaml no projeto da tua empresa porque alguém criou alguma abstraction/template/config K8s.

Mas eu perguntaria:

Esse ignite.yaml é configuração do Apache Ignite ou é YAML usado pelo deployment da nossa empresa?

Porque oficialmente, “traduzimos o IgniteConfig.java para YAML” não é exatamente a descrição correta.

Mais correto seria:

“As responsabilidades que estavam no IgniteConfig.java foram parcialmente substituídas pela configuração declarativa do Ignite 3 e parcialmente deixaram de existir ou mudaram de conceito.”

E isto é precisamente o que queres descobrir analisando esse repo.

---

Mais importante: :10800 não é “a migração”

É verdade que a conexão inicial ao Ignite 3 é muito simples.

Ignite 3.1 diz explicitamente que todos os clients são thin clients. Eles ligam-se por socket e não passam a fazer parte da topologia, não guardam partitions e não recebem compute jobs. (Apache Ignite)

Portanto:

text
Hoje

ignite-app
   │
   │ IgniteSpringBean
   ▼
client-mode Ignite NODE
   │
   ▼
cluster

passa conceptualmente para:

text
Ignite 3

ignite-app
   │
   │ thin client protocol :10800
   ▼
┌─────────────────────┐
│ Ignite 3 cluster    │
│                     │
│ node 1              │
│ node 2              │
│ node 3              │
└─────────────────────┘

Isso está correto.

Mas criar a ligação só resolve:

text
Application
      ↓
  network
      ↓
Ignite cluster

Ainda não resolve:

text
IgniteCache
CacheConfiguration
SpringCacheManager
@Json/serialization
@QuerySqlField
REPLICATED caches
ATOMIC / TRANSACTIONAL
TTL
distributed lock
semaphore
services
compute
events
node predicates
restart logic

E o teu projeto usa tudo isto. (ignite-inventory-report.md)

Portanto não pensaria:

“Tenho 291 linhas de IgniteConfig; vão virar 15. Task quase feita.”

Pensaria:

“Aquelas 291 linhas server-side podem desaparecer, mas o verdadeiro trabalho está em descobrir quais das abstrações Ignite 2 usadas pelo resto da aplicação continuam a fazer sentido.”

---

E “locks já vêm no Ignite” é uma frase particularmente perigosa

Há dois significados completamente diferentes de “lock”.

Ignite 3 tem locks internos à implementação de transactions. A documentação explica, por exemplo, que read-write transactions adquirem locks nas keys envolvidas e os mantêm até commit/rollback. (Apache Ignite)

Isso é:

text
transaction
   ↓
Ignite internals
   ↓
lock rows/keys
   ↓
consistency

Mas o teu projeto usa:

text
application
   ↓
IgniteCache.lock()
   ↓
distributed application lock
   ↓
coordenação entre processos

O inventário diz explicitamente que o processInfo cache é usado para distributed locking. (ignite-inventory-report.md)

Não são a mesma coisa.

Também tens distributed semaphore no projeto. (ignite-inventory-report.md)

A documentação que encontro para IgniteSemaphore é da API Ignite 2.x, não da API Ignite 3.1. (Apache Ignite) Portanto eu definitivamente não partiria do princípio de que “semáforos já estão tratados pela binary”.

É exatamente um dos itens que colocaria como:

🔴 verificar / redesign necessário.

---

A mesma coisa com Services e Compute

O teu projeto tem:

text
CacheInfoService
RatesJsonService

e usa Ignite Services. (ignite-inventory-report.md)

Também tem:

text
Ignite.compute().call(IgniteCallable)

(ignite-inventory-report.md)

No Ignite 3 existe distributed Compute, mas código custom executado nos nodes é agora distribuído através de deployment units. (Apache Ignite)

Portanto aqui aparece uma pergunta extremamente importante para o repo novo do K8s:

text
Existem deployment units?
        │
        ├─ SIM
        │   ↓
        │ alguém já preparou server-side custom code
        │
        └─ NÃO
            ↓
            qualquer comportamento atual que dependa
            de executar código nos nodes terá de ser
            reconsiderado

Isto é uma das razões pelas quais eu não começaria a alterar ignite-app ainda.

---

O que eu faria agora no teu lugar

A tua próxima investigação seria o repo/deployment Ignite 3.1, não o código Java antigo.

E não procuraria “código Ignite”.

Procuraria responder a estas perguntas:

1. Que imagem Ignite está realmente a correr? É apacheignite/ignite:3.1.0, uma imagem interna, ou uma imagem customizada?

2. Qual é a verdadeira configuração Ignite? Procura ignite-config.conf, ConfigMap, HOCON/JSON, ou vê de onde vem esse alegado ignite.yaml.

3. Como é feito o node discovery? Que hosts/Services aparecem em network.nodeFinder?

4. Como está configurado o client connector? Porta 10800, TLS, authentication, certificados, endpoints.

5. Existe persistent storage? StatefulSet, PVCs, mount de /opt/ignite/work, storage profiles.

6. Como é feito cluster init? Que nodes são CMG/metastorage, qual o cluster name, quem executa isto.

7. Onde são criadas Tables e Distribution Zones? Esta é enorme. Procura SQL, CREATE TABLE, CREATE ZONE, scripts de bootstrap/migration.

8. Há Deployment Units? Isto dá pistas sobre Compute/custom logic.

9. O que não existe no novo repo? Se não houver absolutamente nada relacionado com locks, semaphores, services ou business tables, isso também é informação importante: provavelmente ninguém “migrou” essas partes ainda.

Essa análise vai dar-te uma coisa muito valiosa:

text
                 TARGET PLATFORM

             Ignite 3.1 on K8s
                      │
          ┌───────────┴────────────┐
          │                        │
   já foi resolvido           falta resolver
          │                        │
    cluster setup             application API
    discovery                 cache → tables
    storage                   TTL
    replication               Spring Cache
    persistence               distributed lock
    networking                semaphore
    observability             services
                              compute

E então vais conseguir delimitar a tua task muito melhor.

---

Portanto, eu mudaria ligeiramente o plano que te dei antes

Antes eu disse:

entender Ignite 2 → migration matrix → target architecture → código.

Agora que me disseste que já existe um cluster Ignite 3.1 implementado por outra equipa/pessoa, faria:

text
1. Entender arquitetura Ignite 2 atual
            ↓
2. Analisar deployment Ignite 3.1 existente
            ↓
3. Comparar SOURCE vs TARGET
            ↓
4. Identificar o que já foi migrado server-side
            ↓
5. Identificar gaps
            ↓
6. Migration Matrix
            ↓
7. Só então começar a alterar ignite-app/common/client

Para mim, isto é bastante mais seguro.

E tens razão em desconfiar da conclusão do outro agente: a observação “provavelmente já não há Java no server” é boa; a conclusão “portanto só tens de fazer um thin client de 15 linhas” não decorre dela.

No teu projeto, o cluster-node poderá praticamente desaparecer da tua responsabilidade; mas as várias dependências semânticas que a aplicação tem de Ignite 2 continuam todas lá até provares o contrário.

Se tiveres acesso ao repo/manifests do Ignite 3.1 que está em K8s, podes mandar-me esses ficheiros (Dockerfile, ConfigMaps/config Ignite, StatefulSet, Services, init Job/scripts). Aí consigo ajudar-te a fazer precisamente essa análise: “o que já está resolvido no lado server vs. o que ainda terá de ser migrado na aplicação”, sem entrar ainda em implementação de código.