Share via

Migliori pratiche per la progettazione dell'applicazione Azure Service Fabric

  • Articolo

Questo articolo fornisce indicazioni sulle procedure consigliate per la creazione di applicazioni e servizi in Azure Service Fabric.

Acquisire familiarità con Service Fabric

Linee guida per la progettazione di applicazioni

Acquisire familiarità con l'architettura generale delle applicazioni di Service Fabric e le relative considerazioni di progettazione.

Scegliere un gateway API

Usare un servizio gateway API che comunica con i servizi back-end che possono quindi essere aumentati. I servizi gateway API usati più comuni sono:

Servizi senza stato

È consigliabile iniziare sempre creando servizi senza stato usando Reliable Services e archiviando lo stato in un database di Azure, Azure Cosmos DB o Archiviazione di Azure. Lo stato esternalizzato è l'approccio più familiare per la maggior parte degli sviluppatori. Questo approccio consente anche di sfruttare le funzionalità di query nell'archivio.

Quando usare servizi con stato

Prendere in considerazione i servizi con stato quando si ha uno scenario per bassa latenza ed è necessario mantenere i dati vicini al calcolo. Alcuni scenari di esempio includono dispositivi gemelli digitali IoT, stato del gioco, stato sessione, memorizzazione nella cache dei dati da un database e flussi di lavoro a esecuzione prolungata per tenere traccia delle chiamate ad altri servizi.

Decidere l'intervallo di tempo di conservazione dei dati:

  • Dati memorizzati nella cache. Usare la memorizzazione nella cache quando la latenza negli archivi esterni è un problema. Usare un servizio con stato come cache dei dati personalizzata o prendere in considerazione l'uso della cache open source SoCreate distribuita di Service Fabric. In questo scenario non è necessario preoccuparsi se si perdono tutti i dati nella cache.
  • Dati associati al tempo. In questo scenario è necessario mantenere i dati vicini al calcolo per un lasso di tempo per latenza, ma è possibile permettersi di perdere i dati in un'emergenza. In molte soluzioni IoT, ad esempio, i dati devono essere vicini al calcolo, ad esempio quando viene calcolata la temperatura media negli ultimi giorni, ma se questi dati vengono persi, i punti dati specifici registrati non sono così importanti. Inoltre, in questo scenario in genere non è necessario eseguire il backup dei singoli punti dati. È possibile eseguire il backup dei valori medi calcolati scritti periodicamente nell'archiviazione esterna.
  • Dati a lungo termine. Le raccolte affidabili possono archiviare i dati in modo permanente. In questo caso, tuttavia, è necessario prepararsi per il ripristino di emergenza, inclusa la configurazione dei criteri di backup periodici per i cluster. In effetti, è possibile configurare cosa accade se il cluster viene eliminato definitivamente in un'emergenza, in cui è necessario creare un nuovo cluster e come distribuire nuove istanze dell'applicazione e come eseguire il ripristino dal backup più recente.

Risparmiare sui costi e migliorare la disponibilità:

  • È possibile ridurre i costi usando i servizi con stato perché non comportano costi di accesso ai dati e transazioni dall'archivio remoto e perché non è necessario usare un altro servizio, ad esempio Cache Redis di Azure.
  • L'uso di servizi con stato principalmente per l'archiviazione e non per il calcolo è costoso e non è consigliabile. Si considerino i servizi con stato come calcolo con archiviazione locale a basso costo.
  • Rimuovendo le dipendenze da altri servizi, è possibile migliorare la disponibilità del servizio. La gestione dello stato con disponibilità elevata nel cluster isola l'utente da altri tempi di inattività del servizio o problemi di latenza.

Come usare Reliable Services

Service Fabric Reliable Services consente di creare facilmente servizi senza stato e con stato. Per ulteriori informazioni, consultare l'introduzione a Reliable Services.

  • Rispettare sempre il token di annullamento nel metodo RunAsync() per i servizi senza stato e con stato e il metodo ChangeRole() per i servizi con stato. In caso contrario, Service Fabric non sa se il servizio può essere chiuso. Ad esempio, se non si rispetta il token di annullamento, possono verificarsi tempi di aggiornamento dell'applicazione molto più lunghi.
  • Aprire e chiudere i listener di comunicazione in modo tempestivo e rispettare i token di annullamento.
  • Non combinare mai codice di sincronizzazione con codice asincrono. Ad esempio, non usare .GetAwaiter().GetResult() nelle chiamate asincrone. Usare asincrono fino all'interno dello stack di chiamate.

Come usare Reliable Actors

Reliable Actors di Service Fabric consente di creare facilmente attori virtuali con stato. Per ulteriori informazioni, consultare l'introduzione a Reliable Actors.

  • Prendere seriamente in considerazione l'uso della messaggistica pub/sub tra gli attori per ridimensionare l'applicazione. Gli strumenti che forniscono questo servizio includono pub/sub SoCreate di Service Fabric open source e il bus di servizio di Azure.
  • Rendere lo stato dell'attore il più granulare possibile.
  • Gestire il ciclo di vita dell'attore. Gli attori che non verranno usati nuovamente vanno eliminati. L'eliminazione di attori non necessari è di particolare importanza quando si usa il provider di stato volatile, perché tutto lo stato viene archiviato in memoria.
  • A causa della concorrenza basata su turni, gli attori vengono usati meglio come oggetti indipendenti. Non creare grafici di chiamate a un metodo multi-attore, sincrone (ognuna delle quali diventa più probabile una chiamata di rete separata) o creare richieste di attori circolari. Questi influiscono in modo significativo sulle prestazioni e sulla scalabilità.
  • Non combinare codice di sincronizzazione con codice asincrono. Usare asincrono in modo coerente per evitare problemi di prestazioni.
  • Non effettuare chiamate a esecuzione prolungata negli attori. Le chiamate a esecuzione prolungata bloccano altre chiamate allo stesso attore, a causa della concorrenza basata su turni.
  • Se si comunica con altri servizi usando la comunicazione remota di Service Fabric e si sta creando un ServiceProxyFactory, creare la factory a livello di servizio attore e non a livello di attore.

Diagnostica applicazioni

Esaminare attentamente l'aggiunta della registrazione delle applicazioni nelle chiamate al servizio. Consente di diagnosticare gli scenari in cui i servizi si chiamano tra loro. Ad esempio, quando A chiama B chiama C chiama D, la chiamata potrebbe avere esito negativo ovunque. Se la registrazione non è sufficiente, gli errori sono difficili da diagnosticare. Se i servizi registrano troppo a causa dei volumi di chiamata, assicurarsi di registrare almeno gli errori e gli avvisi.

Linee guida per la progettazione in Azure