Applicazioni WCF scalabili che utilizzano la cache distribuita

Autore: Iqbal Khan

Dopo l'esplosione delle applicazioni Web per soddisfare l'utilizzo ad alto traffico, la prossima grande ondata è diventata l'architettura orientata ai servizi (SOA). La SOA ha cambiato il panorama dello sviluppo e dell'integrazione delle applicazioni. È destinato a diventare un modo standard per lo sviluppo di applicazioni estremamente scalabili e le piattaforme di cloud computing come Windows Azure e Windows Communication Foundation (WCF) rappresentano un passo da gigante nel muovere SOA verso il raggiungimento di questo obiettivo. L'obiettivo principale della SOA è raggiungere la scalabilità e sostenere tutto il carico che viene immesso per ottenere una maggiore agilità e una maggiore produttività.

Tuttavia, una vera applicazione SOA dovrebbe scalare facilmente per quanto riguarda l'architettura dell'applicazione. Tuttavia, ci sono molti colli di bottiglia delle prestazioni che devono essere affrontati per ottenere una reale scalabilità.

• I dati dell'applicazione sono di gran lunga l'utilizzo dei dati più pesante in un servizio WCF e la loro archiviazione e accesso rappresentano un importante collo di bottiglia nella scalabilità a causa della latenza che deriva dall'accesso ai dati relazionali.
• Gli ambienti con origini dati altamente distribuite e disparate rappresentano la sfida più grande per il raggiungimento degli obiettivi di performance della SOA. Sebbene il livello dell'app possa scalare bene, una delle principali preoccupazioni che rimangono in un'architettura orientata ai servizi (SOA) è la prestazione dei servizi dati partecipanti.
• Il livello dati non può scalare in modo lineare in termini di capacità di gestione delle transazioni, causando potenzialmente notevoli ritardi nel tempo di risposta complessivo.
• Inoltre, un servizio SOA dipende da altri servizi, che potrebbero non essere disponibili localmente, quindi una chiamata WAN a un altro servizio potrebbe diventare un altro collo di bottiglia.
• Inoltre, se la SOA viene utilizzata nell'implementazione di un livello di virtualizzazione dei dati, le prestazioni dei servizi di dati sono di fondamentale importanza, nel qual caso le prestazioni dell'applicazione sono direttamente proporzionali al tempo necessario per recuperare i dati sottostanti. I servizi dati potrebbero accedere a dati sia relazionali che non relazionali, spesso distribuiti su più data center geograficamente distribuiti, il che potrebbe causare latenza della risposta, ostacolando così le prestazioni complessive dell'applicazione.

Cache distribuita (NCache) per la scalabilità del servizio

Per ridurre la latenza di risposta dell'intera soluzione, un approccio onnicomprensivo consiste nell'utilizzare un sistema di memorizzazione nella cache ad alte prestazioni da utilizzare in tandem con i servizi dati o nel livello di virtualizzazione dei dati. I servizi SOA trattano due tipi di dati. Uno sono i dati sullo stato del servizio e l'altro sono i dati sui risultati del servizio che risiedono nel database. Entrambi causano colli di bottiglia di scalabilità.

La memorizzazione nella cache può svolgere un ruolo molto importante nel migliorare la velocità di accesso sia allo stato del servizio che ai dati dell'applicazione, consentendo allo stesso tempo di scalare i servizi verso l'esterno. La memorizzazione nella cache consente di ridurre al minimo la quantità di traffico e la latenza tra i servizi che utilizzano la cache e i fornitori di dati sottostanti. La figura 1 illustra l'uso di NCache cache distribuita per raggiungere questo obiettivo.

Memorizzazione nella cache dei dati dell'applicazione

Una cache distribuita come NCache viene utilizzato per memorizzare nella cache solo un sottoinsieme dei dati che si trova nel database in base a ciò di cui il servizio WCF ha bisogno in una piccola finestra di poche ore. Una cache distribuita può dare a un'applicazione SOA un notevole aumento della scalabilità perché:

• La cache distribuita può essere ridimensionata in base all'architettura utilizzata.
• Mantiene le cose distribuite su più server e offre comunque alla tua applicazione SOA una vista logica in modo da pensare che sia solo una cache. Ma la cache in realtà vive su più server e questo è ciò che consente alla cache di scalare davvero.
• Se usi la cache distribuita come NCache tra il livello di servizio e il database, migliorerai notevolmente le prestazioni e la scalabilità del livello di servizio in quanto risparmierà un gran numero di viaggi del database che richiedono tempo.

La logica di base da implementare è che, prima di accedere al database, controllare se la cache contiene già i dati. Se lo fa, prendilo dalla cache. Altrimenti, vai al database per recuperare i dati e metterli nella cache per la prossima volta. La figura 2 mostra un esempio.

using System.ServiceModel;
using Alachisoft.NCache.Web.Caching;

namespace MyWcfServiceLibrary {
  [ServiceBehavior]
  public class EmployeeService : IEmployeeService {
    static string _sCacheName = "myServiceCache";
    static Cache _sCache = 
      NCache.InitializeCache(_sCacheName);

    public Employee Load(string employeeId) {
// Create a key to lookup in the cache.
      // The key for will be like "Employees:PK:1000".
      string key = "Employee:EmployeeId:" + employeeId;

      Employee employee = (Employee)_sCache[key];
      if (employee == null) {// item not found in the cache. 
        // Therefore, load from database.
        LoadEmployeeFromDb(employee);

        // Now, add to cache for future reference.
       _sCache.Insert(key, employee, null,
          Cache.NoAbsoluteExpiration,
          Cache.NoSlidingExpiration,
          CacheItemPriority.Default);
      }

      // Return a copy of the object since ASP.NET Cache is InProc.
      return employee;
    }
  }
}

Importanti funzionalità di memorizzazione nella cache

Un progetto di memorizzazione nella cache per un servizio deve considerare problemi quali: la frequenza con cui i dati sottostanti cambiano, la frequenza con cui i dati memorizzati nella cache devono essere aggiornati, se i dati sono specifici dell'utente o a livello di applicazione, quale meccanismo utilizzare per indicare che la cache necessita di aggiornamento, livello di tolleranza dell'applicazione per dati sporchi, ecc. Quindi una soluzione di memorizzazione nella cache deve avere le capacità richieste per ordinare tutti questi requisiti.

Di seguito vengono illustrate alcune delle funzionalità chiave nella gestione scalabile dei dati tramite i servizi di dati che utilizzano la memorizzazione nella cache distribuita.

Dati memorizzati nella cache in scadenza

Le scadenze consentono di specificare per quanto tempo i dati devono rimanere nella cache prima che la cache li rimuova automaticamente. Ci sono due tipi di scadenze in cui puoi specificare NCache: scadenza in tempo assoluto e scadenza in tempo scorrevole o inattivo.

Se i dati nella tua cache esistono anche nel database, sai che questi dati possono essere modificati nel database da altri utenti o applicazioni che potrebbero non avere accesso alla tua cache. Quando ciò accade, i dati nella tua cache diventano obsoleti, cosa che non desideri. Se sei in grado di indovinare per quanto tempo pensi che sia sicuro conservare questi dati nella cache, puoi specificare la scadenza in tempo assoluto. Inoltre, la scadenza scorrevole può rivelarsi molto utile per le applicazioni basate su sessioni in cui si archiviano le sessioni nella cache distribuita.

Sincronizzazione della cache con un database

La necessità della sincronizzazione del database sorge perché il database viene effettivamente condiviso tra più applicazioni e non tutte queste applicazioni hanno accesso alla cache. Se l'applicazione del servizio WCF è l'unica ad aggiornare il database e può anche aggiornare facilmente la cache, probabilmente non è necessaria la funzionalità di sincronizzazione del database.

Ma, in un ambiente di vita reale, non è sempre così. Le applicazioni di terze parti aggiornano i dati nel database e la cache diventa incoerente con il database. La sincronizzazione della cache con il database garantisce che la cache sia sempre a conoscenza di queste modifiche al database e possa aggiornarsi di conseguenza.

La sincronizzazione con il database di solito significa invalidare il relativo elemento memorizzato nella cache dalla cache, quindi la prossima volta che l'applicazione ne avrà bisogno, dovrà recuperarlo dal database perché la cache non lo ha.

Gestione delle relazioni tra i dati nella cache

La maggior parte dei dati proviene da un database relazionale e, anche se non proviene da un database relazionale, è di natura relazionale. Ad esempio, stai tentando di memorizzare nella cache un oggetto cliente e un oggetto ordine ed entrambi gli oggetti sono correlati. Un cliente può avere più ordini.

Quando hai queste relazioni, devi essere in grado di gestirle in una cache. Ciò significa che la cache dovrebbe conoscere la relazione tra un cliente e un ordine. Se aggiorni o rimuovi il cliente dalla cache, è possibile che la cache rimuova automaticamente l'oggetto dell'ordine dalla cache. Questo aiuta a mantenere l'integrità dei dati in molte situazioni.

Se una cache non è in grado di tenere traccia di queste relazioni, dovrai farlo da solo e ciò rende la tua applicazione più ingombrante e complessa.

Conclusione

Pertanto, un'applicazione SOA non può scalare in modo efficace quando i dati che utilizza sono conservati in uno spazio di archiviazione non scalabile per transazioni frequenti. Questo è il punto in cui la cache distribuita piace NCache aiuta davvero. In un ambiente aziendale, l'ambiente applicativo basato su SOA non può davvero scalare senza utilizzare una vera infrastruttura di cache distribuita. Anche i tradizionali server di database stanno migliorando, ma senza la memorizzazione nella cache distribuita, le applicazioni di servizio non possono soddisfare la crescente domanda di scalabilità nell'ambiente di applicazioni complesse di oggi.

---

Autore:Iqbal Khan lavora per Alachisoft , azienda di software leader nella fornitura di soluzioni di caching distribuito .NET e Java, mappatura O/R e ottimizzazione dello storage di SharePoint. Puoi raggiungerlo a iqbal@alachisoft.com.