Articolo
12/29/2015

Dicembre 2015

Volume 30 numero 13

Il presente articolo è stato tradotto automaticamente.

Microsoft Azure - Infrastruttura di servizi di Azure e architettura dei microservizi

Da Cesar de la Torre, Singh complete complete | Dicembre 2015

Microservizi sono un girava attivo al momento. Anche se sono presenti molte presentazioni e discussioni di conferenza sull'oggetto, molti sviluppatori restano confuso. Una domanda comune che finora sono state formulate: "Non è questa architettura orientata ai servizi (SOA) un altro approccio di progettazione basata su domini (DDD) o?"

Certamente, molte delle tecniche utilizzate per l'approccio di microservizi derivare le esperienze di sviluppatori in SOA e DDD. Può essere considerato di microservizi come "SOA ben sfruttata," con i principi e modelli come servizi autonomi, modello associata al contesto e guidati da eventi tutti con le radici SOA e DDD.

In questo articolo verranno affrontati i microservizi teoria e implementazione. Si sarà iniziare con una breve introduzione ai microservizi e quindi passare al lato pratico e come è possibile compilare e distribuire microservizi con Azure Service Fabric. Infine, ecco perché la piattaforma è un'ottima soluzione durante la creazione di microservizi.

Come suggerisce il nome, l'architettura dei microservizi è un approccio per compilare un'applicazione server come un set di servizi di piccole dimensioni, ogni servizio in esecuzione nel proprio processo e la comunicazione tra loro tramite protocolli quali HTTP e WebSocket. Ogni microservizio implementa dominio specifico, end-to-end e le funzionalità di business all'interno di un determinato Bounded-contesto per ogni servizio e deve essere sviluppata in modo autonomo e distribuito in modo indipendente dai meccanismi automatizzati. Infine, ogni servizio deve possedere il modello di dati correlati di dominio e logica di dominio e può utilizzare tecnologie di archiviazione di dati diversi (SQL, No-SQL) e diversi linguaggi di programmazione per microservizio.

Esempi di microservizi i gateway di protocollo, i profili utente, carrelli delle spese, l'elaborazione di inventario, il sottosistema di acquisto, elaborazione dei pagamenti e le code e cache.

Perché microservizi? Una parola, agilità. A lungo termine, microservizi attivare manutenibilità superiore nei sistemi di grandi dimensioni, complessi e altamente scalabili, la progettazione di applicazioni basate su molti servizi distribuibili in modo indipendente che consente di pianificazione del rilascio granulare.

Come ulteriore vantaggio, microservizi possono scalare orizzontalmente in modo indipendente. Anziché blocchi applicazione monolitico enorme che prevedono la scalabilità orizzontale in una sola volta, è invece possibile scalare orizzontalmente microservizi specifici. In questo modo, solo l'area funzionale che richiede più l'elaborazione dell'alimentazione o rete della larghezza di banda per supportare richiesta può essere scalato, anziché ridimensionamento le altre aree dell'applicazione che effettivamente non necessaria.

Architettura delle applicazioni con granularità fine microservizio consente l'integrazione continua e procedure consigliate di sviluppo continuo e accelera la consegna di nuove funzioni nell'applicazione. Scomposizione di granularità delle applicazioni consente inoltre di eseguire e testare microservizi in isolamento e far evolvere in modo indipendente microservizi mantenendo rigorosi contratti tra di essi. Come si non infrangere i contratti o le interfacce, è possibile modificare qualsiasi implementazione microservizio dietro le quinte e aggiungere nuove funzionalità senza interrompere l'altro microservizi che dipendono da esso.

Come Figura 1 Mostra, con l'approccio di microservizi è una questione di efficienza modifiche agile e rapido iterazione, perché si è in grado di modificare parti specifiche di piccole dimensioni di grandi dimensioni, le applicazioni complesse e scalabile.

Approccio di Microservizi rispetto al Server tradizionale approccio dell'applicazione
Figura 1 Microservizi approccio rispetto al Server tradizionale approccio dell'applicazione

E sovranità dei dati Per Microservizio

Una regola importante in questo approccio è che ogni microservizio deve essere proprietari di dati di dominio e logica in un ciclo di vita autonomo, con distribuzione indipendente per ogni microservizio. Veramente non è diverso da come proprietario di un'applicazione completa la logica e i dati.

Questo significa che il modello concettuale del dominio variano tra i sistemi secondari o microservizi. Prendere in considerazione le applicazioni aziendali, in cui customer relationship management (CRM) applicazioni transazionale acquistano sottosistemi e i sottosistemi di supporto clienti ogni chiamata sugli attributi di entità cliente e i dati e utilizzano un contesto Bounded diverso.

Questo principio è simile in DDD in ogni contesto Bounded, ovvero un modello paragonabile a un sottosistema o servizio deve essere proprietaria relativo modello di dominio (dati e logica). Ogni contesto Bounded DDD sarebbe correlato a un microservizio diversi.

D'altra parte, l'approccio tradizionale (o monolitico) utilizzato in molte applicazioni è utilizzare un unico e centralizzato database (spesso un database SQL normalizzato) per l'intera applicazione e tutti i relativi sottosistemi interni, come illustrato nella Figura 2. Questo approccio sembra inizialmente più semplice e sembra abilitare riutilizzo di entità in sottosistemi diversi per qualsiasi coerente. Ma in realtà che si finisce con grandi tabelle che hanno molti diversi sottosistemi e includono gli attributi e le colonne che semplicemente non sono necessari nella maggior parte dei casi. È come provare a usare la stessa mappa fisica per fare escursioni un breve riepilogo, accettando un viaggio di auto giornata e formazione geography.

Confronto sovranità dei dati: Visual Studio Microservizi. Monolitico
Figura 2 dati sovranità confronto: Visual Studio Microservizi. Monolitico

Microservizi con o senza stati?

Come accennato in precedenza, ogni microservizio deve essere proprietaria del modello di dominio. Nel caso di microservizi senza stati, i database saranno esterni, che utilizza opzioni relazionale come opzioni di SQL Server o database NoSQL come MongoDB o Azure Document DB. Proseguire, che i servizi stessi possono essere con stati, ovvero i dati si trova all'interno di microservizio stesso. Questi dati possono esistere non solo nello stesso server, ma nel processo del microservizio stesso, in memoria e persistente sul disco rigido e replicato ad altri nodi.

Senza stato è un approccio perfettamente valido e facili da implementare che microservizi con stato, che è simili ai modelli tradizionali e noti. Ma microservizi senza impongono la latenza tra le origini dati e dei processi, presentando anche più lo spostamento di parti quando miglioramento delle prestazioni tramite code e cache aggiuntiva. Il risultato: si finisce con architetture complesse con un numero eccessivo di livelli.

Microservizi con stato, d'altra parte, possono excel negli scenari avanzati, perché non esiste alcuna latenza tra la logica di dominio e i dati. Elaborazione dati, il gioco termina, database come servizio, e tutti gli altri scenari a bassa latenza usufruiscono dei servizi con stati, che consentono un accesso più rapido dello stato locale.

Lo svantaggio: I servizi con stato impongono un livello di complessità per scalabilità orizzontale. Funzionalità che potrebbe essere implementata in genere entro i limiti di database esterni devono essere risolti, ad esempio, la replica dei dati tra le repliche di microservizi con stato, dati il partizionamento e così via. Ma questo è esattamente una delle aree in cui Service Fabric può aiutare la maggior parte, semplificando lo sviluppo e il ciclo di vita di microservizi con stato.

Vantaggi di Azure Service Fabric

Tutti gli altri vantaggi che viene fornito con l'approccio di microservizi viene fornito con uno svantaggio. Distributed computing e complessi microservizi distribuzioni possono essere difficile da gestire se si esegue autonomamente. Service Fabric fornisce l'infrastruttura necessaria per creare, distribuire, eseguire e gestire microservizi in modo efficace ed efficiente.

Informazioni su Service Fabric È un sistema distribuito piattaforma utilizzati per compilare hyper scalabili e affidabili e facilmente gestibili le applicazioni per il cloud. Service Fabric per affrontare le sfide significative nello sviluppo e la gestione di applicazioni cloud. Utilizzando Service Fabric, sviluppatori e amministratori possono evitare di dover risolvere complessi problemi di infrastruttura e lo stato attivo invece sull'implementazione di carichi di lavoro mission-critical, complesse sapere che rivestano scalabile, affidabile e gestibile. Service Fabric rappresenta una piattaforma middleware di prossima generazione di Microsoft per creare e gestire questi di livello aziendale, i servizi cloud di livello 1.

Service Fabric è un ambiente di distribuzione universale; si è in grado di distribuire qualsiasi file eseguibile in qualsiasi linguaggio (Microsoft .NET Framework, Node. js, Java, C++) o di un database anche runtime come MongoDB.

Pertanto, è importante chiarire che Azure Service Fabric non è limitato alle applicazioni orientate ai microservizi. È possibile inoltre utilizzare per ospitare e distribuire le applicazioni tradizionali (app Web o servizi) e ottenere molti vantaggi correlati alla scalabilità, bilanciamento del carico e veloce distribuzione. Azure Service Fabric è una nuova piattaforma costruita dal basso verso l'alto e in particolare progettata per un'iperscalabilità e sistemi basati su microservizi, come illustrato nella Figura 3.

Figura 3 Microsoft Azure Service Fabric

Ecco alcuni dei vantaggi dell'infrastruttura di servizi:

Viene eseguito in Azure, locale o in qualsiasi cloud. Una caratteristica importante dell'infrastruttura di servizi è che è possibile eseguirlo in Azure, ma anche in locale nel server bare metal o nella macchina virtuale (VM) e anche in altre terze parti ospitato cloud. Non vi è alcun blocco aggiuntivo per un cloud specifico. È anche possibile eseguire un cluster Service Fabric in Amazon Web Services (AWS).
Supporta Windows o Linux. Attualmente (tardiva 2015) Service Fabric supporta Windows, ma anche supporterà Linux e i contenitori (immagini di Windows e le immagini Docker).
Completamente esaminate. Service Fabric è stato utilizzato per diversi anni da Microsoft per molti prodotti cloud.

Service Fabric è nata dalla necessità di creare servizi su larga scala all'interno di Microsoft. Accettando i prodotti, ad esempio SQL Server e sulla creazione di servizi disponibili nel cloud (Database di SQL Azure) mentre agile, affidabile, scalabile e conveniente richiesto una tecnologia distribuita che può soddisfare tutte le richieste in modo efficace. Anche se è stata generata la tecnologia che è possibile risolvere questi scenari complessi, è diventato evidente che SQL Server non è stato prodotto solo quella che tali un passo avanti. Prodotti come Skype for Business era necessario risolvere altri problemi simili nel percorso per diventare un'applicazione basata su microservizi. Service Fabric è la piattaforma di applicazione che si è evoluta da queste sfide ed è stata utilizzata in molti servizi su larga scala in Microsoft con diverse architetture e requisiti per l'esecuzione su vasta scala. InTune, DocumentDB e il back-end per Cortana e Skype for Business tutti sono servizi in esecuzione nell'infrastruttura del servizio.

I sistemi di importanza critica supporto esperienza ha consentito a Microsoft progettare una piattaforma che intrinsecamente riconosce le esigenze di applicazioni scalabili e risorse di infrastruttura disponibili. In questo modo l'aggiornamento automatico, la riparazione automatica comportamento che è essenziale per fornire servizi a elevata disponibili e durevoli su larga scala hyper. Microsoft rende ora disponibili questa tecnologia temprata per tutti gli utenti.

Modelli di programmazione di infrastruttura di Azure

Service Fabric offre due Framework ad alto livello per la creazione di servizi: le API dei servizi affidabili e API Reliable Actors. Mentre entrambi si basano sugli stessi componenti principali di Service Fabric, sono compromessi diversi tra semplicità e flessibilità in termini di concorrenza, partizionamento e comunicazione, come illustrato nella Figura 4. È utile comprendere come entrambi i modelli in modo che sia possibile scegliere il framework più adatto per il servizio. In molti scenari di applicazione, è possibile avere un approccio ibrido e utilizzare gli attori per determinati microservizi e utilizzano servizi affidabili per aggregare i dati generati da un numero di attori. Pertanto, un servizio affidabile può orchestrare servizi attore in molti scenari comuni.

Figura 4 il confronto dei modelli di programmazione di Service Fabric

API Reliable Actors	API Reliable Services
Lo scenario prevede molte piccole unità/oggetti indipendenti di stato e logica (live Internet delle cose oggetti o gli scenari di back-end di gioco sono ottimi esempi)	È necessario mantenere la logica e query in più tipi di entità e componenti
Si lavora con una notevole quantità di oggetti a thread singolo continuando a garantire scalabilità e coerenza	Utilizzare le raccolte reliable collections (come .NET affidabile dizionario e coda) per archiviare e gestire le entità o di stato
Si vuole che il framework per gestire la concorrenza e la granularità dello stato	Si desidera controllare la granularità e concorrenza dello stato
Si desidera Service Fabric per gestire l'implementazione di comunicazione per l'utente	Si desidera decidere, gestire e implementare i protocolli di comunicazione (API Web, WebSockets, Windows Communication Foundation e così via)
Si desidera Service Fabric per gestire lo schema di partizionamento dei servizi di attori con stato in modo trasparente per l'utente	Si desidera controllare lo schema di partizionamento del servizio con stato

Creazione di Microservizi senza stati con Azure Service Fabric

Un microservizio in Azure Service Fabric può essere qualsiasi processo nel server di cui che si desidera creare, se si tratta del .NET Framework, Node. js, Java o C++. Attualmente solo le librerie .NET e C++ dell'API di infrastruttura del servizio sono disponibili. Pertanto, è necessario implementare microservizi in .NET Framework o in C++ per le implementazioni di basso livello.

Come accennato, è un microservizio senza stato, uno in cui è un processo (ad esempio, un servizio front-end o un servizio di logica di business), ma non è letteralmente alcuno stato persistente all'interno del servizio o lo stato presente viene perso quando il processo termina e non richiede la sincronizzazione, la replica, persistenza o disponibilità elevata. Si potrebbe avere un stato esterno correlato, ma resi persistenti in un archivio esterno, ad esempio Database SQL di Azure, archiviazione di Azure, Azure DocumentDB o qualsiasi altro motore di archiviazione di terze parti (relazionale o NoSQL). Pertanto, qualsiasi servizio esistente, ad esempio servizio API Web ASP.NET in esecuzione in servizi Cloud, ruolo di lavoro o App Web di Azure facilmente la migrazione in servizi di Service Fabric senza stato.

Per impostare l'ambiente di sviluppo, è necessario disporre di Service Fabric SDK, che consente di eseguire un cluster di sviluppo locale che non è un emulatore, ma esegue gli stessi bit come in Azure. Inoltre, l'integrazione degli strumenti di Visual Studio 2015 consente lo sviluppo e il debug.

Prima della distribuzione e debug dei servizi nel computer locale, è necessario creare il cluster di nodi. Fatto che tramite l'esecuzione di Windows PowerShell script chiamato DevClusterSetup.ps1, come illustrato nella sezione "Installare e avviare un Cluster locale" della pagina relativa alla documentazione, "Preparazione dell'ambiente di sviluppo," si trova in bit.ly/1Mfi0LB. È possibile fare riferimento a questa pagina per una procedura dettagliata completa della configurazione processo.

Classe di Base del servizio senza stato deve derivare dalla classe Microsoft.ServiceFabric.Services.StatelessService qualsiasi classe di servizio di Service Fabric senza stato. Questa classe fornisce i metodi API e contesto correlate al cluster Service Fabric e l'ambiente di esecuzione e hook del ciclo di vita del servizio.

Se il servizio è con o senza stato, Reliable Services fornisce un semplice ciclo di vita che consente di collegare rapidamente il codice e introduzione. È solo uno o due metodi che è necessario implementare per ottenere il servizio di infrastruttura di servizi in esecuzione, in genere RunAsync e CreateServiceReplicaListeners, che verrà spiegato quando drill-down ai protocolli di comunicazione.

Si noti RunAsync, come illustrato nella Figura 5. Si tratta in cui il servizio può "lavoro" in background. Il token di annullamento fornito è un segnale quando tale operazione deve essere interrotta.

Figura 5 struttura di Base del servizio senza stato in Azure Service Fabric

using Microsoft.ServiceFabric.Services;
namespace MyApp.MyStatelessService
{ 
  public class MyStatelessService : StatelessService
  {
    //... Service implementation
    protected override async Task RunAsync(CancellationToken cancellationToken)
    {   
      int iterations = 0;
      while (!cancellationToken.IsCancellationRequested)
      {
        ServiceEventSource.Current.ServiceMessage(this, "Working-{0}",
          iterations++);
        // Place to write your own background logic.
        // Example: Logic doing any polling task.
        // Logic here would be similar to what you usually implement in
        // Azure Worker Roles, Azure WebJobs or a traditional Windows Service.
         await Task.Delay(TimeSpan.FromSeconds(1), cancellationToken);
      }
      } 
    }
}

Protocolli di comunicazione in Azure Service Fabric Reliable Services Azure Service Fabric Reliable Services fornisce un modello di comunicazione modulare. È possibile utilizzare il trasporto di propria scelta, ad esempio HTTP con l'API Web ASP.NET, WebSockets, Windows Communication Foundation, protocolli TCP personalizzati e così via.

È possibile implementare il proprio codice per il protocollo di comunicazione scelto nel servizio o utilizzare qualsiasi stack di comunicazione forniti con Service Fabric, ad esempio ServiceCommunicationListener/ServiceProxy è, è lo stack di comunicazione predefinito fornito dal Framework dei servizi affidabili in Service Fabric. Sarà inoltre necessario pacchetti NuGet separati con gli stack di comunicazione aggiuntive che è possibile collegare a Service Fabric.

Tramite ASP.NET Web API nel servizio Fabric Microservizi come indicato in precedenza, Service Fabric consente di decidere come si desidera che i servizi per comunicare, ma uno dei modi più comuni per creare servizi HTTP in .NET Framework è tramite l'API Web ASP.NET.

API Web in Service Fabric è la stessa API Web ASP.NET conosciuti. I controller vengono utilizzati, HttpRoutes ed è possibile compilare servizi REST allo stesso modo tramite gli attributi o MapHttpRoute sui metodi di cui che si desidera eseguire il mapping a route Http. La differenza quando si utilizza l'infrastruttura di servizi è come ospitare un'applicazione API Web. Prima per prendere in considerazione è che non è possibile utilizzare IIS in Azure Service Fabric, in quanto utilizza processi semplici replicati all'interno del cluster, è necessario ospitare il listener HTTP nel codice in modo automatico. A tale che per i servizi API Web, sono disponibili due opzioni:

Utilizzare API Web ASP.NET 5 (nome in codice "Progetto K") per l'hosting indipendente il listener HTTP all'interno del processo di microservizi di Service Fabric.
Utilizzare OWIN/Katana e ASP.NET Web API 4. x per l'hosting indipendente il listener HTTP all'interno del processo di microservizi di Service Fabric.

Esecuzione di ASP.NET 5 su Azure Service Fabric è la soluzione ottimale per la creazione di microservizi perché, come indicato in precedenza, Service Fabric consente di distribuire i servizi in ogni nodo/macchina virtuale, consentendo di microservizi ad alta densità per ogni cluster. Inoltre, che ad alta densità verrà visualizzato meglio quando Service Fabric invia infine .NET Core 5 e il supporto di CoreCLR in futuro (di sotto di ASP.NET 5). Si tratterà di "migliore scelta" per ottenere densità molto elevata di microservizi perché .NET Core 5 è un framework chiaro con un footprint di memoria molto piccole rispetto alle completa di .NET Framework 4.

Using "Tipo MVC" Web App e servizio Fabric Microservizi ASP.NET MVC è un framework molto diffuso per i siti Web tradizionali, ma non è possibile utilizzare "precedente" MVC framework MVC (5 o versione precedente) con Service Fabric. Ciò è dovuto al fatto che in Service Fabric è necessario il listener HTTP nel processo di servizio indipendente e OWIN/Katana non è supportato in ASP.NET 4. x MVC (è supportato solo in API Web ASP.NET 4. x.) Di conseguenza, le opzioni che disponibili per implementare un'applicazione Web "Tipo MVC" in servizi di Service Fabric sono i seguenti:

Utilizzare MVC 6 in ASP.NET 5 per l'hosting indipendente il listener HTTP all'interno del processo di microservizi di Service Fabric. Supporta MVC poiché in ASP.NET 5, API Web e MVC vengono consolidati e sono in effetti lo stesso framework con il controller stesso senza dipendenza da IIS. Non appena viene rilasciato ASP.NET 5 per produrre sarà la scelta migliore.
Utilizzare API Web ASP.NET 4. x con OWIN/Katana per l'hosting indipendente il listener HTTP all'interno del processo di microservizi di Service Fabric e simulare controller MVC con controller API Web e di output anziché il contenuto Web API normale, JSON/XML, HTML/JavaScript. La pagina di documentazione all'indirizzo bit.ly/1UMdKIf viene illustrato come implementare questa tecnica.

Implementare self-Hosting OWIN/Katana e API di Web ASP.NET 4. x

Per questo approccio, l'applicazione API Web che si è abituati a lavorare con non cambia. Non è diversa dalle applicazioni API Web che scritti in passato e dovrebbe essere possibile spostare semplicemente la maggior parte del codice dell'applicazione su. Ospita l'applicazione potrebbe essere leggermente diverso da ciò che si è abituati ad se è stata ospitati in IIS.

CreateServiceReplicaListeners metodo nella classe di servizio questo è il servizio definisce la comunicazione stack si desidera utilizzare. Lo stack di comunicazione, ad esempio API Web, è ciò che definisce gli endpoint in ascolto per il servizio, nonché come i messaggi che compaiono interagirà con il resto del codice del servizio.

Tornando alla classe del servizio indicato in precedenza Figura 4, ora sufficiente aggiungere un nuovo metodo denominato CreateServiceReplicaListeners, che consente di specificare almeno uno stack di comunicazione si desidera utilizzare. In questo caso, è il OwinCommunicationListener usate dall'API Web, come illustrato Figura 6.

Figura 6 aggiunta del metodo CreateServiceReplicaListeners alla classe del servizio senza stato

using Microsoft.ServiceFabric.Services;
namespace MyApp.MyStatelessService
{ 
  public class MyStatelessService : StatelessService
  {
    //... Service implementation.
    protected override async Task RunAsync(CancellationToken cancellationToken)
    {            
      // Place to write your own background logic here.
      // ...         
    }
    protected override IEnumerable<ServiceReplicaListener>
      CreateServiceReplicaListeners()
      {
        return new List<ServiceReplicaListener>()
        {
          new ServiceReplicaListener(parameters =>
            new OwinCommunicationListener(
            "api", new Startup()))
        };
      } 
    }
}

È importante sottolineare che è possibile avere più listener di comunicazione viene aggiunto al servizio.

La classe OwinCommunicationListener è il codice boilerplate che è necessario riutilizzare in tutte le microservizi. In modo analogo, è possibile collegare in altri protocolli (WCF, WebSocket e così via).

Se si sta creando un microservizio di API Web, si sarà ancora controller con codice tipico non diverso rispetto a ciò che potrebbero essere utilizzate per implementazione API Web services, come il codice seguente:

// Typical Web API Service class implementation
public class CustomerController : ApiController
{ 
  //// Example - GET /customers/MSFT
  [HttpGet]
  [Route("customers/{customerKey}", Name = "GetCustomer")]
  public async Task<IHttpActionResult> GetCustomer(string customerKey)
  {
    // ... Stateless method implementation.       
  }
}

Poiché in questo articolo viene fornita una panoramica end-to-end di Azure Service Fabric e microservizi, non sarà perfetto tramite ulteriori passaggi per l'implementazione di OWIN in microservizio di Service Fabric. È disponibile un semplice esempio su GitHub che è possibile scaricare e analizzare (bit.ly/1OW5Bmj): API e esempio HelloWorld infrastruttura del servizio Web (ASP.NET 4. x).

Implementare l'Hosting con l'API Web ASP.NET 5

Esecuzione di ASP.NET 5 su Azure Service Fabric è la soluzione ottimale per la creazione di microservizi perché Service Fabric consente di distribuire i servizi in ogni nodo/macchina virtuale, che consente di microservizi ad alta densità per ogni cluster. ASP.NET 5 fornisce anche funzionalità come il seguente:

Hosting flessibile: È ora possibile ospitare l'applicazione ASP.NET 5 in IIS o nel proprio processo. Nel proprio processo di hosting è fondamentale in Azure Service Fabric.
API Web, MVC e pagine Web: Questi sono tutti uniti, il numero di concetti.
Supporto completo side-by-side: ASP.NET 5 applicazioni ora possono essere installate in un computer senza influire sulle altre applicazioni nel computer che potrebbero utilizzare una versione diversa di .NET Framework. Questa è una funzionalità enorme per la gestione IT.
Supporto multipiattaforma: ASP.NET 5 in esecuzione ed è supportato in Windows, Mac OS X e Linux.
Cloud computing: Funzionalità come la diagnostica, lo stato della sessione, cache e configurazione sono progettate per funzionare in locale e nel cloud (ad esempio Azure) senza modifiche.

Guardando al futuro, funzionalità ad alta densità otterranno migliore quando Service Fabric invia infine .NET Core 5 e il supporto di CoreCLR.

Mentre il supporto per .NET Core e rimane CoreCLR in lavori per Service Fabric, è chiaro il vantaggio quando tale supporto in linea. L'esecuzione di ASP.NET 5 su .NET Core 5 offre un leggero .NET framework e runtime CoreCLR con un footprint di memoria molto piccole rispetto alle tradizionali .NET 4. x. Che combinazione consentirà densità incredibile microservizi, come mostrato nel pannello "Microservizio B" Figura 7.

Figura 7 confronto tra ASP.NET 5 in esecuzione in Visual Studio CLR. CoreCLR all'interno del contesto di infrastruttura di servizio

Mentre il supporto .NET Core 5 e CoreCLR è un'opzione future, le aziende possono prepararsi a oggi lo sviluppo di servizi di ASP.NET 5 su .NET 4. x in Service Fabric. In tal modo più semplice eseguire la migrazione di CoreCLR in futuro.

Funzionamento e della distribuzione Iperscalabili Microservizi

Le operazioni e Gestione distribuzione fornite da Service Fabric sono altri motivi per cui è ideale per la compilazione e in esecuzione in produzione iperscalabili microservizi. È possibile concentrarsi sullo sviluppo di microservizi e i Service Fabric forniscono tutte le attività complesse dietro le quinte.

La densità elevata di microservizi è un grande vantaggio se ci si preoccupa la riduzione dei costi di infrastruttura. Un cluster Service Fabric è composta da un pool di molte macchine virtuali o dei server (e contenitori in futuro) denominati nodi del cluster. In ogni nodo Service Fabric distribuisce automaticamente numerosi servizi, a seconda della potenza di ogni server/macchina virtuale è molto elevata densità di microservizi all'interno del cluster.

In Azure Service Fabric è la possibilità di eseguire centinaia di istanze del servizio in ogni computer o di una macchina virtuale. Che offre grandi risparmi per il costo totale di proprietà (TCO). Per la stessa quantità di servizi, è necessario meno hardware. Pertanto, ad alta densità è un elemento di differenziazione big durante il confronto di Azure Service Fabric con i servizi Cloud di Azure, in cui si è limitato a una macchina virtuale per ogni servizio. Se si intende distribuire microservizi come un ruolo Web o un ruolo di lavoro probabilmente era troppe risorse assegnate a un singolo microservizio, producendo rallentamenti durante la distribuzione e la gestione. Ad esempio, in Figura 8 è possibile visualizzare una macchina virtuale per ogni istanza del servizio sotto forma di ruolo di lavoro o del ruolo Web di Azure (colore indica i tipo di servizio mentre ogni forma o casella indica una macchina virtuale diversa e l'istanza del servizio). Questo approccio non consente di accedere rapidamente ad alta densità di microservizi, a meno di utilizzare macchine virtuali di piccole dimensioni. Tuttavia, è previsto un limite e non sarà in grado di raggiungere lo stesso livello di densità elevata in una distribuzione rispetto a Azure Service Fabric.

Confronto di densità di servizi, ovvero Visual Studio di servizi Cloud di Azure. Service Fabric
Figura 8 servizi densità confronto, ovvero Visual Studio di servizi Cloud di Azure. Service Fabric

Al contrario, in Service Fabric è possibile distribuire un numero qualsiasi di microservizi per ogni nodo, pertanto la densità dei servizi è molto più efficiente e dei costi viene ridotto. È possibile decine, centinaia o persino migliaia di macchine virtuali o dei server per cluster con decine o centinaia di istanze del microservizio e le repliche per ogni nodo/macchina virtuale. E poiché ogni microservizio è semplicemente un processo, la distribuzione e la scalabilità è molto più velocemente rispetto alla creazione di una nuova macchina virtuale per ogni servizio, come nel caso di servizi cloud di Azure.

Creazione di un Cluster nel Cloud di Azure prima di distribuire microservizi, è necessario creare il cluster di nodi in Azure o in server locali. Quando si crea il cluster nel cloud di Azure (ad esempio di produzione o un ambiente di gestione temporanea), è possibile utilizzare direttamente dal portale di Azure o usando Gestione risorse di Azure (ARM). In Figura 9, presente un cluster di Service Fabric è creata la sottoscrizione di Azure tramite il portale di Azure. Dietro le quinte, il processo di creazione del cluster è basato su ARM di Azure e i gruppi di risorse di Azure. In questo caso, abbiamo creato un cluster con cinque nodi o le macchine virtuali che vengono inserite anche all'interno di un gruppo di risorse di Azure.

Figura 9 Service Fabric Cluster nel portale di Azure

Applicazioni/servizi di distribuzione per il Cluster del cluster di nodi o macchine virtuali è in esecuzione, è possibile distribuire servizi. Durante la distribuzione in cluster di produzione in genere si utilizza uno script Windows PowerShell per distribuire le applicazioni e servizi del cluster in Azure, anche se per gli ambienti di gestione temporanea e test, è inoltre possibile distribuire direttamente da Visual Studio.

Durante la distribuzione in un cluster locale del computer usando Visual Studio 2015 di sviluppo, è necessario distribuire in genere direttamente dall'IDE di pulsante destro del mouse sul progetto di applicazione di Service Fabric e scegliendo Distribuisci. È inoltre possibile utilizzare Windows PowerShell per distribuire cluster di sviluppo in un computer portatile, poiché gli stessi bit di Service Fabric eseguite nei cluster di sviluppo come i cluster basati su cloud di Azure.

Operazioni quotidiane e la gestibilità delle distribuzioni è necessario mantenere i servizi in esecuzione in modo uniforme nel lungo termine e le funzionalità di gestione del ciclo di vita dell'applicazione sono state incorporate nell'infrastruttura di servizi, tenendo presente l'approccio basato su microservizi. Le operazioni e le funzionalità di gestione disponibili in Service Fabric includono distribuzioni rapide, gli aggiornamenti delle applicazioni di tempi di inattività, integrità e monitoraggio dei servizi di scalabilità del cluster di e riduzione. Gli aggiornamenti dei tempi di inattività sono possibili in quanto l'aggiornamento tecnico di Service Fabric fornisce una combinazione predefinita di distribuzione di aggiornamenti e controlli di integrità automatica rilevare e ripristinare le modifiche nell'aggiornamento se sono destabilizzare l'applicazione. Gestione dei cluster di infrastruttura di servizi e applicazioni è possibile tramite i comandi di Windows Powershell, fornendo tutte le potenzialità di CLI e scripting, supportando anche visual strumenti tra cui Visual Studio per facilità d'uso.

Gli aggiornamenti in sequenza vengono eseguiti in fasi. In ogni fase, l'aggiornamento viene applicato a un sottoinsieme di nodi del cluster, denominato dominio di aggiornamento. Di conseguenza, l'applicazione rimane disponibile durante l'aggiornamento. È anche possibile sicuro controllo delle versioni e supporto side-by-side in modo che è possibile distribuire le versioni v1 e v2 del microservizio stesso e Service Fabric verrà reindirizzato a uno o l'altro, a seconda delle richieste del client. Controllare la documentazione all'indirizzo bit.ly/1kSupz8 per ulteriori dettagli.

Durante il debug di servizi all'interno di cluster di sviluppo locale all'interno del PC, Visual Studio semplifica anche quando i processi dei servizi sono già in esecuzione prima di iniziare il debug. L'IDE si connette automaticamente a tutti i processi di microservizi correlati al progetto, rendendo più semplice iniziare e utilizzare i punti di interruzione normale nel codice di microservizi di Service Fabric. È sufficiente impostare i punti di interruzione nel codice e premere F5. Non è necessario sapere per i processi, è necessario collegare Visual Studio.

Service Fabric Explorer Service Fabric Explorer, illustrata nella Figura 10, è uno strumento basato sul Web fornito dal cluster per visualizzare lo stato delle applicazioni distribuite, esaminare il contenuto dei singoli nodi ed eseguire diverse azioni amministrative. Lo strumento Esplora viene gestito dallo stesso servizio HTTP Gateway che supporta le API REST di infrastruttura di servizi e può essere raggiunto passando a http://<your-cluster-endpoint>:19007/Explorer. Nel caso di un cluster locale, l'URL sarà http://localhost:19007/Explorer.

Figura 10 Service Fabric Explorer

Per ulteriori informazioni su Service Fabric Explorer, leggere la pagina della documentazione, "Visualizzazione del Cluster usando Service Fabric Explorer" (bit.ly/1MUNyad).

La piattaforma Service Fabric consente una gamma di funzionalità che consentono di concentrarsi sullo sviluppo di applicazioni invece di implementare integrità complesse e sistemi aggiornabili. tra cui:

Ampliamento di servizi senza stato motore di orchestrazione di Service Fabric consente di adattare automaticamente un'applicazione Web tra più computer ogni volta che vengono aggiunti nuovi nodi a un cluster. Durante la creazione di istanze di un servizio senza stato, è possibile specificare il numero di istanze che si desidera creare. Service Fabric posizionerà il numero di istanze nei nodi del cluster di conseguenza, assicurandosi di non creare più di un'istanza su un qualsiasi nodo. È inoltre possibile impostare Service Fabric per creare un'istanza in ogni nodo specificando "-1" per il numero di istanze. In questo modo si garantisce che ogni volta che si aggiungono nodi per scalare orizzontalmente il cluster, un'istanza del servizio senza stato verrà creata nei nuovi nodi.

Automatica bilanciamento delle risorse Service Fabric offre un servizio Bilanciamento delle risorse (o servizio orchestrazione) che comprende i totale delle risorse disponibili nel cluster (ad esempio il calcolo nelle macchine virtuali). Spostare automaticamente i microservizi a seconda della definizione di criteri e ottimizzare al meglio i vincoli come i servizi creati vengono posizionati nelle macchine virtuali (vedere Figura 11). Questo è incentrato sull'ottimizzazione dei costi e prestazioni.

Figura 11 Cluster che mostra la distribuzione di servizi per i nodi e il bilanciamento delle risorse automatico

Replica e Failover incorporatemacchine in qualsiasi Data Center o un cloud pubblico sono soggette a errori hardware non pianificato. Per proteggersi da tali scenari Service Fabric fornisce failover predefinito e la replica, il che significa che nonostante i problemi hardware la disponibilità dei servizi non verrà compromesse. Ciò è possibile perché Service Fabric può eseguire e gestire più istanze di ogni servizio tra più computer e domini di errore.

Vincoli di posizionamento è possibile indicare il cluster per eseguire operazioni quali non utilizzano i front-end microservizi stessi macchine/nodi di livello intermedio di microservizi e per evitare la collocazione di determinati tipi di microservizi nei nodi stesso. Questa operazione può essere eseguita per ridurre al minimo i conflitti noti o per garantire accesso prioritario a risorse per determinate microservizi.

Carico bilanciamento del carico delle richieste non deve per essere confuso con bilanciamento del carico di risorse automatico, le richieste di bilanciamento del carico non sono gestite da Service Fabric, ma dal bilanciamento del carico Azure o altra piattaforma esterna a Service Fabric.

Integrità consente di monitorare e diagnosticare i sistemi. Per fornire controlli di sicurezza in modo che gli aggiornamenti possono eseguire il rollback se l'aggiornamento ha un effetto destabilizzanti anche usato durante gli aggiornamenti dell'applicazione. Per ulteriori informazioni, vedere la pagina della documentazione, "Introduzione a Service Fabric il monitoraggio dello stato" (bit.ly/1jSvmHB).

Microservizi con stato in Azure Service Fabric

Supporto per i servizi con stati è un componente molto interessante e importante di Azure Service Fabric. È inoltre ampio che esplorazione dei servizi con stato esula dall'ambito di questo articolo, ma verrà illustrato brevemente che cos'è e complessi. Cercare un articolo che segue con stato attivo su un'area di Service Fabric in problemi futuri.

Un microservizio con stato in Service Fabric collocates compute e dati, con lo stato posizionato all'interno di microservizio stessa (in memoria e persistente su disco locale). L'affidabilità dello stato viene ottenuta tramite persistenza locale e la replica dei dati da altri nodi o macchine virtuali. In sostanza, ogni partizione di dati dispone di diversi servizi di replica associati. Ogni replica può essere distribuito in una diverso nodo o una macchina virtuale per garantire un'elevata disponibilità deve diventare la replica primaria verso il basso. È simile a come Database di SQL Azure funziona con le repliche di database, poiché si basa sull'infrastruttura di servizi Azure.

In applicazioni complesse e scalabili, i servizi con stato semplifica l'architettura e riduce il numero di componenti rispetto a un'architettura tradizionale, a tre livelli che deve utilizzare le code e cache esterna. Quando si utilizzano i servizi con stato, i vantaggi di una cache esterna tradizionale è ora intrinseco del servizio con stato. Inoltre, le code esterne non sono necessari perché possiamo implementare code interne all'interno di microservizi di Service Fabric.

Quando si utilizzano i servizi con stato, viene creato automaticamente database secondari di backup a caldo che possono prelevare le operazioni dallo stesso punto in cui è stato interrotto dopo un errore hardware primario. Servizi di numero di volte necessario scala per continuare a soddisfare le esigenze di una base di utenti in continua crescita, richiedere l'aggiunta di hardware nell'ambiente di esecuzione. Service Fabric Usa funzionalità come il partizionamento in modo che i servizi possono essere compilati in modo che vengono automaticamente distribuiti nel nuovo hardware senza l'intervento dell'utente.

Reliable Services con stato Azure forniscono una serie di funzionalità, tra cui supporto della partizione dati elezione Guida e supporto di replica, denominazione del servizio di replica e rilevamento degli indirizzi del servizio dal servizio gateway. Consente inoltre di gestione della concorrenza e granularità delle modifiche di stato utilizzando la capacità di mantenere la replica di uno stato coerente e l'utilizzo di affidabilità, transazioni distribuite raccolte chiave/valore (Reliabledictionary e Reliablequeue). La buona notizia è che Service Fabric gestisce la complessità e i dettagli di questi argomenti, è possibile concentrarsi sulla scrittura di applicazioni.

Gli attori Reliable Services in Azure Service Fabric

Azure Service Fabric Reliable Actors è un modello di programmazione attore per Service Fabric. Fornisce un modello basato su attori asincrono e a thread singolo. Un attore rappresenta un'unità di stato e calcolo. Per alcuni versi è simile per i progetti software open source "Orleans" creato da Microsoft Research. Il punto importante è che API Reliable Actors di Service Fabric si basa sull'infrastruttura sottostante fornita da Service Fabric.

Implementazione di istanze di attori per i dispositivi Internet delle cose (IoT) è un buon esempio di utilizzo di servizi attore. Un tipo di veicolo attore sotto forma di una classe c# necessario incapsulare la logica di dominio veicolo IoT e dei suoi Stati live come le coordinate GPS e altri dati. Quindi, sono potenzialmente milioni di oggetti degli attori o istanze della classe menzionate in classe, distribuiti in molti nodi del cluster.

Naturalmente, gli attori non sono limitati a IoT oggetti attivi, possono essere utilizzati per qualsiasi oggetto, ma "live IoT oggetti" sono uno scenario conoscitivi eccezionale.

Gli attori vengono distribuiti in tutto il cluster per ottenere scalabilità e disponibilità elevate e vengono trattati come oggetti in memoria in una macchina virtuale del cluster, ogni. Sono inoltre persistente su disco locale e replicate mediante il cluster.

Gli attori sono isolati gli oggetti a thread singolo che incapsulano lo stato e comportamento. Ogni attore è un'istanza di un tipo di attore, simile al codice .NET riportato di seguito:

// Actor definition (State+Behaviour) to run in the back end.
// Object instances of this Actor class will be running transparently
// in the service back end.
public class VehicleActor : Actor<Vehicle>, IVehicleActor
{
  public void UpdateGpsPosition(GpsCoordinates coord)
  { 
    // Update coordinates and trigger any data processing
    // through the State property on the base class Actor<TState>.
    this.State.Position= coord;
  }
}

Successivamente, il codice seguente mostra l'esempio di codice client per usare l'attore tramite un oggetto proxy:

// Client .NET code
ActorId actorId = ActorId.NewId();
string applicationName = "fabric:/IoTVehiclesActorApp";
IVehicleActor vehicleActorProxy =
  ActorProxy.Create<IVehicleActor>(actorId, applicationName);
vehicleActorProxy.UpdateGpsPosition(new GpsCoordinates(40.748440, -73.984559));

Tutta l'infrastruttura di comunicazione viene preso in considerazione dietro le quinte dal framework di Service Fabric Reliable Actors.

È possibile che i milioni di oggetti VehicleActor in esecuzione nel cluster in più nodi diversi/macchine virtuali e Service Fabric essere prestando attenzione del plumbing necessarie, incluse le partizioni e repliche in cui vengono distribuiti e bilanciati di milioni di attori.

L'API client Actors consente la comunicazione tra un'istanza di attore e un client di attore. Per comunicare con un attore, un client crea un oggetto proxy attore che implementa l'interfaccia dell'attore. Il client interagisce con l'attore richiamando metodi sull'oggetto proxy.

Per gli scenari in cui si adattino attori, semplifica notevolmente l'implementazione di microservizi, soprattutto rispetto a stateful reliable services in cui si dispone di più controllo ma è necessario implementare molta plumbing correlati al partizionamento dei dati, indirizzamento, repliche e il tipo di partizione. Se non è necessario il controllo granulare, è possibile evitare il lavoro aggiuntivo usando gli attori affidabili.

Avvolgendo

Architetture di Microservizi richiedono un impegno per approcci decentralizzati, disciplinati processi di progettazione e architettura, le nuove tecnologie come Azure Service Fabric e una modifica in dynamics team verso piccoli team di sviluppo e i principi Agile applicati per microservizio.

Cesar de la Torre è un senior program manager presso Microsoft e vive a Redmond, Washington. Il suo interesse includono lo sviluppo di Microsoft Azure e .NET con gli approcci, ad esempio le architetture di microservizi e design basato su dominio, nonché lo sviluppo di applicazioni per dispositivi mobili esponendo i servizi.

Singh complete Kunal è un senior program manager del team di Microsoft Azure Service Fabric. Prima di Azure ha lavorato su più versioni di Windows Phone, Silverlight e di sviluppo di giochi per Xbox titoli. Vive a Seattle, Washington.

Vaclav Turecek è un senior program manager presso Microsoft. Lavora sfinimento con un gruppo di persone per rendere la migliore piattaforma di prossima generazione di un servizio di Azure Service Fabric molto talento.

Grazie al seguente Microsoft esperto tecnico per la creazione di condivisione e la revisione dell'articolo: Mark Fussell
Mark Fussell è passione per la creazione di applicazioni con scalabilità cloud, visto che molti anni presso Microsoft, la creazione di prodotti, compreso l'accesso ai dati e le comunicazioni e altre tecnologie sul lato server. È orgogliosa verificare che Microsoft ha reso Service Fabric disponibile per tutti gli utenti per la creazione di applicazioni con un approccio di microservizi.