Architettura di GC.Platform
Documentazione tecnica per i team di architettura e sviluppo lato cliente. Qui trovi su quale stack tecnologico funziona GC.Platform, come è organizzata, come si integra e come si scala.
L'architettura in un'unica immagine
GC.Platform è un'architettura a microservizi, multi-cloud, ospitata interamente nell'Unione Europea. Ogni modulo funziona come un servizio indipendente, con il proprio ciclo di deployment e scalabilità. Il quadro completo dei componenti principali:
Lo schema mostra i componenti principali che gestiscono il flusso dall'utente finale ai dati di prodotto. I backend dei moduli (GC.Catalog, GC.Platform API, ERP, CART, AUTH, DASHBOARD, Messaging, AI.Assistant) operano in modo indipendente, comunicando tramite API ed eventi. Ognuno ha il proprio App Service Plan e si scala individualmente.
Ospitiamo in tre regioni UE, su due cloud
GC.Platform funziona in modalità multi-cloud con tre regioni cloud nell'Unione Europea: Microsoft Azure in Polonia, Microsoft Azure in Germania e Oracle Cloud in Germania. Ogni livello del sistema sta nel cloud in cui funziona meglio: dati transazionali e applicazioni in Azure, dati di prodotto (livello MDM) in Oracle Cloud.
Il traffico dei clienti della tua piattaforma è gestito da Cloudflare — il livello edge che protegge dagli attacchi DDoS, filtra il traffico nel WAF e accelera i contenuti statici a livello globale. Sotto Cloudflare opera Azure Front Door — il load balancer multi-regione di Microsoft, che indirizza il traffico verso l'istanza applicativa più vicina disponibile e lo reindirizza automaticamente in caso di indisponibilità di un componente.
Ogni microservizio di GC.Platform funziona su almeno due istanze applicative in Azure App Service, su un piano dedicato. I dati transazionali in Azure SQL operano in modalità Zone Availability — resilienti ai guasti di una singola zona di disponibilità. È un approccio standard per l'architettura enterprise, ma spesso ignorato dalle piattaforme e-commerce che si presentano come «cloud».
Cosa c'è sotto il cofano
Selezioniamo le tecnologie consapevolmente — per il compito specifico, non per moda. Lo stack di GC.Platform combina soluzioni mature e collaudate con strumenti moderni dove apportano un reale vantaggio.
Backend
- •.NET (versioni LTS attuali) — servizi backend (GC.Platform API, ERP, CART, AUTH, DASHBOARD, Messaging, AI.Assistant)
- •PHP — server-side rendering per GC.Catalog, ottimizzato per SEO e tempo di primo rendering di cataloghi con grandi basi di SKU
- •Azure App Service — runtime applicativo per tutti i backend
Frontend
- •GC.Catalog — JavaScript nativo ES6+ senza framework, SCSS per gli stili, Vite come bundler. Decisione consapevole: per i cataloghi automotive un livello leggero di interattività lato browser dà risultati SEO e prestazioni migliori di un framework SPA pesante
- •GC.Dashboard — React, per l'interfaccia amministrativa avanzata
- •AI.Assistant — React, componente chat incorporato in GC.Catalog
Dati
- •Azure SQL Pool — dati transazionali di GC.CART, GC.Messaging, GC.AUTH (ogni modulo con un'istanza SQL separata)
- •Oracle Cloud — livello GC.MDM (Master Data Management), dove struttura e prestazioni delle query di prodotto sono fondamentali
- •Azure Cognitive Search — ricerca sul catalogo prodotti, indicizzazione e facet
- •Azure Cache for Redis — livello di cache per i dati interrogati frequentemente
Comunicazione tra servizi
- •Azure Service Bus — code e topic per gli eventi business (ordini, cambi di stato, integrazioni)
- •Azure Storage Queues — code per i task in background e l'elaborazione asincrona
Infrastruttura edge
- •Cloudflare — WAF, protezione anti-DDoS, accelerazione CDN
- •Azure Front Door — load balancing multi-regione
Sicurezza e identità
- •Microsoft Entra ID — gestione dell'identità per il team che mantiene la piattaforma, MFA imposta
- •Azure Key Vault — segreti, chiavi crittografiche, certificati
- •Azure Log Analytics, Application Insights — log, monitoraggio, audit
Ogni modulo indipendente
GC.Platform non è un monolite. Ogni modulo — GC.CATALOG, GC.CART, GC.AUTH, GC.MDM, GC.CMS, GC.DASHBOARD, AI.Assistant — è un servizio backend separato, su un proprio App Service Plan, con istanze proprie e responsabilità propria. La comunicazione tra i moduli avviene tramite REST API e tramite eventi su Azure Service Bus.
Conseguenza pratica: quando il traffico sul catalogo cresce nella stagione del cambio gomme, scaliamo GC.CATALOG. Quando il numero di ordini cresce, scaliamo GC.CART. Quando AI.Assistant gestisce più conversazioni, scaliamo proprio quel servizio. Senza spegnimenti, senza interruzioni, senza effetto domino su altre parti della piattaforma.
Ogni modulo ha la propria pipeline CI/CD in Azure DevOps e può essere distribuito indipendentemente dagli altri. Significa che l'aggiornamento di un elemento non richiede il redeploy dell'intera piattaforma.
API aperta per l'integrazione ERP
GC.Platform espone API in architettura REST. Tutti i servizi backend (GC.Platform API, ERP API, CART API, AUTH API, DASHBOARD API, Messaging API, AI.Assistant) comunicano con lo stesso standard — questo semplifica il lavoro dei team di integrazione lato cliente.
Integration API — l'interfaccia dedicata all'integrazione con i sistemi ERP del cliente — ha una documentazione pubblica. L'ambito standard dell'integrazione copre lo scambio di prezzi, disponibilità, ordini, fatture e rotte di trasporto tra GC.Platform e l'ERP del cliente. L'ambito dettagliato viene stabilito nella fase di analisi dell'implementazione, adattandolo alle specificità dell'ERP lato cliente.
Le altre interfacce — interne tra i moduli di GC.Platform, frontend tra le applicazioni client e il backend, di integrazione con i partner di settore — vengono documentate in fase di implementazione e messe a disposizione del tuo team nell'ambito dei lavori di integrazione.
Ciclo di vita del sistema dopo l'implementazione
Ogni implementazione di GC.Platform comprende almeno due ambienti: produzione e staging. L'ambiente staging serve per i test di integrazione, la verifica degli aggiornamenti e la prova di modifiche di configurazione prima del loro rilascio in produzione.
Distribuiamo gli aggiornamenti di GC.Platform in modo asincrono — significa che non c'è una rigida «finestra di manutenzione» da sorvegliare. Ogni modulo viene aggiornato in modo indipendente, senza interruzioni di servizio degli altri componenti. Nei casi necessari — ad es. un cambiamento strutturale importante o un aggiornamento che richiede una migrazione dei dati — concordiamo in anticipo una finestra di manutenzione, in accordo con il tuo team.
Il deployment in produzione è eseguito dal nostro team, tramite la pipeline CI/CD in Azure DevOps. Ogni deployment ha la possibilità automatica di rollback — in caso di problema dopo un rilascio, possiamo riportare rapidamente il sistema alla versione precedente funzionante. Senza riconfigurazione manuale, senza rischio di errori umani in una situazione di stress.
Sicurezza a livello cloud Enterprise
Tutta la comunicazione — tra il client e la piattaforma e all'interno di GC.Platform — avviene tramite TLS 1.2 o superiore. I dati nei database Azure SQL sono crittografati tramite Transparent Data Encryption (TDE), le chiavi sono archiviate in Azure Key Vault. Il team che mantiene la piattaforma accede tramite Microsoft Entra ID con autenticazione a più fattori, ogni operazione in produzione è registrata e verificabile. L'infrastruttura su cui funziona GC.Platform è certificata secondo gli standard ISO 27001, SOC 1, SOC 2 e SOC 3.
La politica completa di sicurezza, protezione dei dati e GDPR è descritta nella pagina Dati e sicurezza.
Torna a GC.Platform
La descrizione dei moduli, gli scenari di utilizzo e il quadro completo della piattaforma li trovi nella pagina GC.Platform.