Article
12/29/2015

Décembre 2015

Volume 30, numéro 13

Cet article a fait l'objet d'une traduction automatique.

Microsoft Azure : Azure Service Fabric et l’architecture des microservices

Par Cesar de la Torre, Singh approfondie approfondie | Décembre 2015

Microservices fait partie du jargon à chaud pour le moment. Bien que de nombreuses présentations et discussions de conférence sur le sujet, un grand nombre de développeurs restent confondus. Une question courante, que nous avons entendu : « N'est pas cette autre qu'une architecture orientée services (SOA) ou une approche de conception conduite par domaine (DDD)? »

Sans aucun doute, la plupart des techniques utilisées dans l'approche microservices dérivent de l'expérience des développeurs dans SOA et la conception pilotée par domaine. Vous pouvez considérer de microservices en tant que « SOA fait, » principes et modèles de services autonomes, le modèle de contexte délimité et pilotées par événements tous ayant leurs racines dans SOA et la conception pilotée par domaine.

Dans cet article, nous allons traiter la théorie de microservices et l'implémentation. Nous allons commencer par une brève introduction aux microservices et déplacez-le vers le côté pratique et comment vous pouvez générer et déployer les microservices avec Azure Service Fabric. Enfin, nous allons montrer pourquoi cette plate-forme est idéale lors de la création de microservices.

Comme son nom l'indique, architecture de microservices est une approche pour générer une application serveur comme un ensemble de petits services, chaque service en cours d'exécution dans son propre processus et de communiquer entre eux via des protocoles tels que HTTP et WebSocket. Chaque microservice implémente domaine spécifique, de bout en bout et des fonctionnalités professionnelles dans un certain contexte délimité par service et doit être développé de façon autonome et déployée indépendamment par les mécanismes automatisés. Enfin, chaque service doit posséder son modèle de données de domaine connexes et la logique de domaine et pouvez employer les technologies de stockage de données différentes (SQL, NoSQL) et les différents langages de programmation par microservice.

Exemples de microservices passerelles de protocole, les profils utilisateur, shopping paniers, traitement de l'inventaire, sous-système d'achat, traitement des paiements et files d'attente et les caches.

Pourquoi microservices ? Dans word, agilité. À long terme, microservices activer une facilité de gestion dans les systèmes de grandes, complexes et hautement évolutives en créant des applications basées sur de nombreux services pouvant être déployées indépendamment permettant la planification de la version granulaire.

Avantage supplémentaire, microservices peuvent évoluer indépendamment. Au lieu de blocs d'application monolithique géant que vous devez faire évoluer en même temps, vous pouvez étendre à la place des microservices spécifiques. De cette façon, juste la zone fonctionnelle nécessitant plus le traitement d'alimentation de bande passante réseau pour prendre en charge la demande peut être mis à l'échelle, plutôt que mise à l'échelle les autres zones de l'application qui ne peut vraiment pas le besoin.

Conception d'applications de microservices affinées permet une intégration continue et les pratiques de développement continu et accélère la livraison des nouvelles fonctions dans l'application. Décomposition précis des applications vous permet également d'exécuter et tester des microservices de manière isolée et d'évoluer indépendamment des microservices tout en conservant les contrats rigoureux entre eux. Tant que vous respectez bien les contrats ou les interfaces, vous pouvez modifier n'importe quelle implémentation de microservice sous le capot et ajouter de nouvelles fonctionnalités sans rupture microservices qui en dépendent.

En tant que Figure 1 montre, avec l'approche microservices tout est question de l'efficacité des modifications agiles et itération rapide, parce que vous êtes en mesure de modifier des parties spécifiques, petite de grande taille, des applications complexes et évolutives.

Approche de Microservices par rapport à l'approche d'Application serveur traditionnel
Figure 1 Microservices approche par rapport à l'approche d'Application serveur traditionnel

Souveraineté de données par Microservice

Une règle importante dans cette approche est que chaque microservice doit posséder ses données de domaine et de la logique d'un cycle de vie autonome, avec un déploiement indépendant par microservice. Cela n'est pas vraiment différent de la façon dont une application complète possède sa logique et les données.

Cette approche signifie que le modèle conceptuel du domaine diffèrent entre les sous-systèmes ou microservices. Envisagez d'applications d'entreprise, où client relation (CRM) des applications de gestion transactionnelle acheter des sous-systèmes et des sous-systèmes de prise en charge de client chaque appel sur les attributs d'entité de client unique et les données et utiliser un autre contexte délimité.

Ce principe est similaire dans la conception orientée domaine dans lequel chaque contexte délimité, est un modèle comparable à un sous-système/service, doit être propriétaire de son modèle de domaine (données et logique). Chaque contexte délimité DDD est corrélé à un microservice différent.

En revanche, l'approche traditionnelle (ou monolithique) utilisé dans de nombreuses applications est unique et centralisé de données (souvent une base de données normalisée) pour l'ensemble de l'application et de ses sous-systèmes internes, comme indiqué dans Figure 2. Cette approche ressemble initialement plus simple et semble pour permettre la réutilisation des entités dans différents sous-systèmes afin que tout est cohérent. Mais en réalité que vous retrouver avec des tables énormes qui desservent les nombreux sous-systèmes différents et incluent des attributs et des colonnes simplement ne sont pas nécessaires dans la plupart des cas. C'est comme essaie d'utiliser la même carte physique pour une courte piste de randonnée, en prenant une course de voiture de la journée et formation geography.

Comparaison de souveraineté de données : Visual Studio Microservices. Monolithique
Figure 2 données souveraineté comparaison : Visual Studio Microservices. Monolithique

Microservices avec ou sans état ?

Comme mentionné précédemment, chaque microservice doit posséder son modèle de domaine. Dans le cas de microservices sans état, les bases de données sera externes, en utilisant les options relationnelles telles que les options de SQL Server ou NoSQL telles que MongoDB ou Azure Document DB. Pour aller plus loin, que les services eux-mêmes peuvent être avec état, ce qui signifie que les données se trouve dans le même microservice. Ces données peuvent exister non seulement dans le même serveur, mais dans les processus de la même microservice, en mémoire et conservées sur le disque dur et répliquées vers d'autres nœuds.

Sans état est une approche parfaitement valable et plus facile à implémenter que les microservices avec état, tel qu'il est similaire aux modèles traditionnels et connues. Mais la latence entre les processus et sources de données, tout en offrant également des éléments plus mobiles lors de l'amélioration des performances via les files d'attente et de cache supplémentaire imposent des microservices sans état. Le résultat : vous pouvez vous retrouver avec des architectures complexes avec trop de niveaux.

Les microservices avec état, peuvent quant à eux, excel dans des scénarios avancés, car il n'existe aucune latence entre la logique de domaine et les données. Lourd traitement des données de jeu précédent termine, bases de données en tant que service, et tous les autres scénarios d'une latence faible bénéficient des services avec état, qui activent l'état local pour un accès plus rapide.

L'inconvénient : Services avec état imposent un niveau de complexité pour la montée en charge. Fonctionnalité qui serait généralement implémentée dans les limites de la base de données externe doit être résolue pour les éléments tels que la réplication des données entre les réplicas de microservices avec état, et ainsi de suite le partitionnement des données. Mais c'est précisément un des domaines où le Service Fabric peut aider à la plupart, en simplifiant le développement et le cycle de vie de microservices avec état.

Avantages d'Azure Service Fabric

Tous les bienfaits livrée avec l'approche microservices est fourni avec un inconvénient. Distribué microservices informatiques et complexes, les déploiements peuvent être difficiles à gérer si vous le faites vous-même. Service Fabric fournit les éléments nécessaires pour créer, déployer, exécuter et gérer des microservices de manière efficace.

Quel est le Service Fabric ? Il est une plate-forme utilisée pour créer des hyper évolutif, fiable et facile à gérer des applications pour le cloud des systèmes distribués. Service Fabric résout les problèmes importants dans le développement et la gestion des applications de cloud. À l'aide de Service Fabric, les développeurs et les administrateurs peuvent éviter d'avoir à résoudre le focus et infrastructure complexe à la place sur l'implémentation de charges de travail critiques et les plus exigeants sachant qu'elles sont évolutives, fiables et gérables. Service Fabric représente la plateforme de middleware de nouvelle génération de Microsoft pour la création et la gestion d'entreprise de ces services de mise à l'échelle de cloud de niveau 1.

Service Fabric est un environnement de déploiement universel. vous êtes en mesure de déployer un fichier exécutable en fonction de n'importe quel langage (Microsoft .NET Framework, Node.js, Java, C++) ou même de la base de données runtimes tels que MongoDB.

Par conséquent, il est important de préciser que Azure Service Fabric n'est pas limité aux applications orientées sur microservices. Vous pouvez également l'utiliser pour héberger et déployer des applications traditionnelles (applications Web ou services) et bénéficiez de nombreux avantages liés à l'évolutivité, l'équilibrage de charge et déploiement rapide. Azure Service Fabric est une nouvelle plate-forme conçue dès le départ jusqu'à et particulièrement conçu pour « Hyper-extensibilité » et les systèmes basés sur des microservices, comme indiqué dans Figure 3.

Figure 3 Microsoft Azure Service Fabric

Voici quelques-uns des avantages du Service Fabric :

S'exécute sur Azure, localement ou dans n'importe quel cloud. Une caractéristique de Service Fabric très importante est que vous pouvez l'exécuter sur Azure, mais également en local, sur vos propres serveurs de vierge ou d'une machine virtuelle (VM) et même dans les autres fournisseurs tiers hébergé nuages. Il n'existe aucun verrou dans un cloud spécifique. Vous pouvez même exécuter un cluster Service Fabric dans Amazon Web Services (AWS).
Prend en charge Windows ou Linux. Actuellement (liaison tardive 2015) le Service Fabric prend en charge Windows, mais il prendra également en charge Linux et les conteneurs (images système Windows et Docker).
Entièrement contrôlé. Service Fabric a été utilisé depuis plusieurs années par Microsoft pour beaucoup de ses produits de cloud.

Service Fabric est issue de la nécessité de créer des services à grande échelle au sein de Microsoft. En prenant des produits tels que SQL Server et leur création, tout en étant agile, fiable, évolutive et économique requis une technologie distribuée qui peut répondre à toutes ces demandes efficacement, en tant que services disponibles dans le cloud (de base de données SQL Azure). Bien que la technologie résolu ces scénarios complexes a été créée, il est devenu évident que SQL Server n'a pas le seul produit qui a été telle une année bissextile. Produits, tels que Skype entreprise devaient résoudre des problèmes similaires sur le chemin d'accès pour devenir une application basée sur les microservices. Service Fabric est la plate-forme d'application qui a évolué hors de ces défis et a été utilisée dans plusieurs services à grande échelle chez Microsoft avec différentes architectures et configuration requise pour l'exécution à l'échelle. InTune, DocumentDB et le serveur principal pour Cortana et Skype pour toutes les entreprises sont des services qui s'exécutent sur le Service Fabric.

L'expérience de prise en charge des systèmes stratégiques a permis à Microsoft de concevoir une plate-forme qui intrinsèquement comprend les ressources de l'infrastructure disponibles et les besoins des applications évolutives. Il permet la mise à jour automatique, auto-réparation comportement qui est essentielle à la fourniture des services hautement disponibles et fiables à l'échelle hyper. Microsoft met désormais cette technologie renforcée bataille disponibles pour tout le monde.

Modèles de programmation Azure Service Fabric

Service Fabric propose deux infrastructures générales pour la création de services : les API des Services fiables et les API d'acteurs fiables. Si les deux reposent sur le même noyau Service Fabric, ils offrent différents compromis entre simplicité et flexibilité en termes de concurrence, partitionnement et communication, comme indiqué dans Figure 4. Il est utile de comprendre comment ces deux modèles de sorte que vous pouvez choisir l'infrastructure convient mieux à votre service. Dans de nombreux scénarios d'application, vous pouvez avoir une approche hybride et utiliser les acteurs pour certaines microservices et utiliser des services fiables pour agréger les données générées par un nombre d'acteurs. Par conséquent, un service fiable peut orchestrer des services d'acteur dans de nombreux scénarios courants.

Figure 4 Comparaison des modèles de programmation de Service Fabric

API d'acteurs fiables	API de Services fiables
Votre scénario implique de nombreuses petites unités/objets indépendants de l'état et la logique (Direct Internet des objets d'éléments ou des scénarios principaux jeux constituent d'excellents exemples)	Vous devez mettre à jour la logique et les requêtes sur plusieurs types d'entités et les composants
Vous travaillez avec un très grand nombre d'objets monothread tout en continuant à l'échelle et de maintenir la cohérence	Collections fiables (telles que le dictionnaire fiable .NET et file d'attente) vous permet de stocker et de gérer votre état/entités
Vous souhaitez que l'infrastructure gère la concurrence et la granularité de l'état	Vous souhaitez contrôler la granularité et la concurrence de l'état
Vous souhaitez que le Service Fabric pour gérer l'implémentation de communication pour vous	Vous souhaitez choisir, de gérer et d'implémenter les protocoles de communication (API Web, WebSockets, Windows Communication Foundation et ainsi de suite)
Vous souhaitez que le Service Fabric pour gérer le schéma de partitionnement des services d'acteur avec état afin qu'il soit transparent pour vous	Vous souhaitez contrôler le schéma de partitionnement de votre service avec état

Création de Microservices sans état avec Azure Service Fabric

Un microservice dans Azure Service Fabric peut être presque n'importe quel processus sur le serveur que vous souhaitez créer, s'il s'agit de .NET Framework, Node.js, Java ou C++. Actuellement uniquement les bibliothèques .NET et C++ de l'API de Service Fabric sont disponibles. Par conséquent, vous devez implémenter microservices dans le .NET Framework ou en C++ pour les implémentations de bas niveau.

Comme mentionné, un microservice sans état est une où il existe un processus (par exemple, un service frontal ou logique métier), mais aucun état n'est littéralement persistantes dans le service ou l'état qui est présent est perdu lorsque le processus se termine et ne nécessite pas la synchronisation, la réplication, persistance ou haute disponibilité. Il peut avoir un état externe, mais rendu persistant dans le stockage externe, telles que la base de données SQL Azure, le stockage Azure, Azure DocumentDB ou tout autre moteur de stockage tiers (relationnel ou NoSQL). Par conséquent, n'importe quel service existant comme service API Web ASP.NET s'exécutant sur les Services de cloud computing, le rôle de travail ou application Web Azure aurait facilement migrer vers les services sans état Service Fabric.

Pour configurer votre environnement de développement, vous devez avoir le SDK Service Fabric, ce qui vous permet d'exécuter un cluster de développement local qui n'est pas un émulateur, mais s'exécute les mêmes bits que dans Azure. En outre, Visual Studio 2015, intégration des outils rend le développement et le débogage.

Avant de déployer et déboguer les services sur votre ordinateur local, vous devez créer le cluster de nœuds. Vous faire qu'en exécutant Windows PowerShell script appelé DevClusterSetup.ps1, comme expliqué dans la section « Installer et démarrer un Cluster Local » de la page de documentation « Préparation de votre environnement de développement », situé à bit.ly/1Mfi0LB. Vous pouvez faire référence à cette page pour une présentation complète des processus de paramétrage.

Classe de Base de Service sans état n'importe quelle classe de service sans état Service Fabric doit dériver de la classe Microsoft.ServiceFabric.Services.StatelessService. Cette classe fournit des méthodes d'API et de contexte liée au cluster Service Fabric et l'environnement d'exécution et raccorde le cycle de vie de votre service.

Si votre service est avec ou sans état, les Services fiables fournissent un cycle de vie simple qui vous permet de brancher rapidement votre code et de prise en main. Il est simplement une ou deux méthodes que vous devez implémenter pour démarrer votre Service service Fabric en cours d'exécution et de — généralement RunAsync et CreateServiceReplicaListeners, que nous aborderons lors de l'exploration vers le bas sur les protocoles de communication.

Remarque RunAsync comme dans Figure 5. Il s'agit là que votre service peut « fonctionnent » en arrière-plan. Le jeton d'annulation fourni est un signal indiquant quand ce travail doit s'arrêter.

Structure de Base de la figure 5 de Service sans état dans 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);
      }
      } 
    }
}

Protocoles de communication de Services fiables Azure Service Fabric Services fiables Service Fabric Azure fournit un modèle de communication enfichable. Vous pouvez utiliser le transport de votre choix, tels que HTTP avec l'API Web ASP.NET, WebSockets, Windows Communication Foundation, les protocoles TCP personnalisés et ainsi de suite.

Vous pouvez implémenter votre propre code pour votre protocole de communication choisi dans votre service ou utiliser une pile de communication fournie avec le Service Fabric, telles que ServiceCommunicationListener/ServiceProxy, la pile de communication par défaut fournie par l'infrastructure de Services fiables dans Service Fabric. Il y aura également des packages NuGet séparés avec des piles de communication supplémentaires que vous pouvez connecter à Service Fabric.

à l'aide des API Web ASP.NET dans le Service Fabric Microservices comme mentionné précédemment, Service Fabric vous permet de choisir la façon dont vos services pour communiquer, mais une des façons plus communes pour créer des services HTTP dans le .NET Framework est à l'aide de l'API Web ASP.NET.

API Web dans Service Fabric est la même API Web ASP.NET vous connaissez et appréciez. Vous utilisez des contrôleurs, HttpRoutes et vous pouvez créer des services REST de la même façon en utilisant MapHttpRoute ou les attributs sur les méthodes que vous souhaitez mapper aux itinéraires de Http. La différence lors de l'utilisation de Service Fabric est votre façon d'héberger une application API Web. Tout d'abord afin de prendre en compte est que vous ne pouvez pas utiliser IIS dans Azure Service Fabric, qu'elle utilise des processus simples répliqués sur le cluster, pouvoir auto-héberger l'écouteur HTTP dans votre code. Pour ce faire pour les services API Web, vous avez deux possibilités :

API de Web ASP.NET 5 (nom de code « Projet K ») permet d'auto-hébergement l'écouteur HTTP dans votre processus de microservices Service Fabric.
Utiliser OWIN/Katana et ASP.NET 4.x les API Web pour auto-héberger l'écouteur HTTP dans votre processus de microservices Service Fabric.

Exécution d'ASP.NET 5 sur Azure Service Fabric est la meilleure solution pour la création de microservices parce que, comme mentionné précédemment, Service Fabric vous permet de déployer n'importe quel nombre de services dans chaque nœud/machine virtuelle, ce qui permet de densité élevée microservices par cluster. En outre, cette haute densité sera mieux même lorsque le Service Fabric remettent .NET Core 5 CoreCLR prise en charge et à l'avenir (sous ASP.NET 5). Il s'agit de « optimale de choix » pour obtenir de très haute densité de microservices .NET Core 5 étant une infrastructure légère avec une très faible encombrement mémoire par rapport à .NET complète 4.x Framework.

Service Fabric Microservices et les applications Web de Type « MVC » à l'aide ASP.NET MVC est une infrastructure très populaire pour les sites Web traditionnels, mais vous ne pouvez pas utiliser l'infrastructure MVC « ancien » (MVC 5 ou plu) avec Service Fabric. Cela est dû au fait que dans Service Fabric, vous avez besoin pour auto-héberger l'écouteur HTTP dans votre processus et qui OWIN/Katana n'est pas pris en charge dans ASP.NET 4.x MVC (il est possible que dans les API de Web ASP.NET 4.x). Par conséquent, les options que vous devez implémenter une application Web de type « MVC » sur les services Service Fabric sont les éléments suivants :

Utilisez MVC 6 dans ASP.NET 5 pour auto-héberger l'écouteur HTTP dans votre processus de microservices Service Fabric. Il prend en charge MVC car dans ASP.NET 5, API Web MVC sont consolidés et sont en fait la même infrastructure avec les mêmes contrôleurs sans dépendance sur IIS. Ce sera le choix préféré dès que l'ASP.NET 5 est libérée à la fabrication.
Utiliser des API Web ASP.NET 4.x avec OWIN/Katana pour auto-héberger l'écouteur HTTP dans votre processus de microservices Service Fabric et de simuler des contrôleurs MVC avec les contrôleurs d'API Web et utilisez plutôt que le contenu d'API Web standard (XML/JSON) de sortie HTML/JavaScript. La page de documentation à bit.ly/1UMdKIf montre comment implémenter cette technique.

Implémenter l'auto-hébergement avec ASP.NET 4.x Web API et OWIN/Katana

Pour cette approche, l'application API Web que vous êtes habitué à travailler avec ne change pas. Il ne diffère pas des applications API Web que vous avez écrit dans le passé et vous devez pouvoir simplement à déplacer vers la droite sur la plupart du code de votre application. L'application d'hébergement peut être légèrement différent de ce que vous êtes habitué à si vous avez été hébergement sur IIS.

Méthode CreateServiceReplicaListeners dans la classe de Service c'est là le service définit la communication des piles il souhaite utiliser. La pile de communication, tels que des API Web, est ce qui définit les points de terminaison écoute pour le service, ainsi que la manière dont les messages qui apparaissent interagissent avec le reste du code de service.

Pour revenir à la classe de service mentionné dans Figure 4, j'ai maintenant suffit ajouter une nouvelle méthode appelée CreateServiceReplicaListeners, qui spécifie d'utiliser au moins une pile de communication. Dans ce cas, il est OwinCommunicationListener utilisé par l'API Web, comme indiqué dans Figure 6.

Figure 6: ajout de la méthode CreateServiceReplicaListeners à la classe de Service sans état

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()))
        };
      } 
    }
}

Il est important de souligner que vous pouvez avoir plusieurs écouteurs de communication ajoutés à votre service.

La classe OwinCommunicationListener est du code réutilisable que vous devez réutiliser dans tous vos microservices. De la même façon, vous pourrez être branché autres protocoles (WCF, WebSockets, etc.).

Si vous créez un microservice d'API Web, vous devez toujours contrôleurs avec code de type similaire à ce qui vous permet de lors de l'application API Web services, tels que le code suivant :

// 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.       
  }
}

Étant donné que cet article est une vue d'ensemble de bout en bout d'Azure Service Fabric et microservices, nous n'entrerons pas par le biais des étapes supplémentaires pour implémenter OWIN dans votre microservice Service Fabric. Un exemple simple est disponible sur GitHub que vous pouvez télécharger et analyser (bit.ly/1OW5Bmj) : API et l'exemple HelloWorld de Fabric Service Web (ASP.NET 4.x).

Implémenter l'auto-hébergement avec l'API Web ASP.NET 5

Exécution d'ASP.NET 5 sur Azure Service Fabric est la meilleure solution pour la création de microservices, Service Fabric vous permet de déployer le nombre de services dans chaque nœud/machine virtuelle, ce qui permet de densité élevée microservices par cluster. ASP.NET 5 fournit également des fonctionnalités intéressantes telles que les éléments suivants :

Flexible d'hébergement : Maintenant, vous pouvez héberger votre application ASP.NET 5 sur IIS ou dans votre propre processus. Dans votre propre processus d'hébergement est fondamental dans Azure Service Fabric.
API Web, MVC et Web Pages : Ceux-ci sont tous fusionnés, simplifiant le nombre de concepts.
Prise en charge côte à côte complète : ASP.NET 5 applications peuvent désormais être installées sur un ordinateur sans affecter d'autres applications sur l'ordinateur que vous utilisez peut-être une autre version de .NET Framework. Il s'agit d'une fonctionnalité considérable pour les responsables informatiques.
Prise en charge multiplateforme : ASP.NET 5 s'exécute et est pris en charge sous Windows, Mac OS X et Linux.
Prête pour le cloud : Fonctionnalités, telles que des diagnostics, l'état de session, du cache et la configuration sont conçues pour fonctionner localement et dans le cloud (Azure) sans apporter de modifications.

Tourné vers l'avenir, capacité à densité élevée et obtenez encore mieux lorsque le Service Fabric remettent .NET Core 5 et prise en charge de CoreCLR.

Lors de la prise en charge de .NET Core et reste CoreCLR dans les ouvrages pour Service Fabric, l'avantage lorsque qui prennent en charge est en ligne est désactivée. Exécution d'ASP.NET 5 sur .NET Core 5 fournit un léger .NET framework et le runtime de CoreCLR avec un très faible encombrement mémoire par rapport à .NET traditionnel 4.x. Que combinaison permettra densité microservices incroyable, comme indiqué dans le panneau « Microservice B » dans Figure 7.

Comparaison entre ASP.NET 5 en cours d'exécution sur le CLR vs. CoreCLR dans le contexte de Fabric Service
Figure 7 comparaison ASP.NET 5 en cours d'exécution sur le CLR vs. CoreCLR dans le contexte de Fabric Service

Prise en charge .NET Core 5 et CoreCLR est une option future, les entreprises peuvent préparer dès aujourd'hui en développant des services ASP.NET 5 sur .NET 4.x sur Service Fabric. Cela rend plus facile de migrer vers le CoreCLR à l'avenir.

Fonctionnement et du déploiement d'une évolutivité Microservices

Les opérations et la gestion du déploiement fourni par le Service Fabric sont les autres raisons pour lesquelles il est très utile pour la création et l'exécution de production une évolutivité microservices. Vous pouvez vous concentrer sur le développement de microservices et permettent de fournir tous les éléments complexes en coulisses Service Fabric.

La densité élevée des microservices constitue un énorme avantage si vous souhaitez réduire le coût de l'infrastructure. Un cluster Service Fabric se compose d'un pool de nombreuses machines virtuelles et des serveurs (et conteneurs dans le futur) appelés les nœuds du cluster. Dans chaque nœud Service Fabric déploie automatiquement plusieurs services, en fonction de la puissance de chaque serveur/machine virtuelle, vous pouvez avoir une très haute densité de microservices sur votre cluster.

Dans Azure Service Fabric, vous avez la possibilité d'exécuter des centaines d'instances de service sur chaque ordinateur ou d'une machine virtuelle. Qui fournit très avantageux pour votre coût Total de possession (TCO). Pour la même quantité de services, vous aurez besoin de moins de matériel. Haute densité est donc un différenciateur volumineux lors de la comparaison d'Azure Service Fabric avec Azure Cloud Services, où vous êtes limité à un ordinateur virtuel par Service. Si vous avez déployé les microservices en tant que rôle Web ou rôle de travail pensiez trop de ressources affectées à un microservice unique, générant des ralentissements lors du déploiement et de gestion. Par exemple, dans Figure 8 vous pouvez voir un ordinateur virtuel par l'instance de service sous la forme d'un rôle Web Azure ou le rôle de travail (couleur indique le type de service lors de chaque forme ou zone indique une machine virtuelle différente et une instance de service). Cette approche ne permet pas si vous avez besoin pour que haute densité de microservices, sauf si vous utilisez de petites machines virtuelles. Malgré tout, il existe une limite et vous ne pourrez pas atteindre le même niveau de haute densité dans un déploiement par rapport à Azure Service Fabric.

Comparaison de la densité des services, Azure Cloud Services vs. Service Fabric
Comparaison de densité de Services figure 8: Visual Studio Azure Cloud Services. Service Fabric

En revanche, dans Service Fabric, vous pouvez déployer un nombre quelconque de microservices par nœud, par conséquent, la densité de services est beaucoup plus efficace et rentable sont réduit. Vous pouvez avoir des dizaines, des centaines ou milliers de machines virtuelles/serveurs par cluster, avec des dizaines ou des centaines d'instances de microservice et des réplicas par nœud/machine virtuelle. Et comme chaque microservice est simplement un processus, le déploiement et mise à l'échelle est beaucoup plus rapide que la création d'un nouvel ordinateur virtuel par service, en est le cas avec les services cloud Azure.

Création d'un Cluster dans Azure Cloud avant le déploiement de microservices, vous devez créer le cluster de nœuds de serveurs locaux ou Azure. Lors de la création du cluster dans le cloud Azure (comme votre production ou votre environnement intermédiaire), vous pouvez travailler directement à partir du portail Azure ou à l'aide d'Azure Resource Manager (ARM). Dans Figure 9, vous voyez un cluster Service Fabric que nous avons créés dans notre abonnement Azure à l'aide du portail Azure. En coulisses, le processus de création de cluster est basé sur Azure ARM et des groupes de ressources Azure. Dans ce cas, nous avons créé un cluster avec cinq nœuds/machines virtuelles qui sont également placés dans un groupe de ressources Azure.

Figure 9 la Cluster Service Fabric dans le portail Azure

Déploiement d'Applications et Services au Cluster une fois le cluster de nœuds/machines virtuelles en cours d'exécution, vous pouvez déployer des services. Lors du déploiement sur les clusters de production vous utilisez généralement un script Windows PowerShell pour déployer vos applications et services sur le cluster dans Azure, bien que pour les environnements de test vous pouvez également déployer directement depuis Visual Studio.

Lors du déploiement vers un cluster local sur le développement de votre PC à l'aide de Visual Studio 2015, vous serez généralement déployer directement à partir de l'IDE en cliquant sur le projet d'application Service Fabric et sélectionner déployer. Vous pouvez également utiliser Windows PowerShell pour déployer sur le cluster de développement de votre ordinateur portable, car les mêmes bits Service Fabric s'exécutent dans des clusters de développement que dans les clusters de cloud Azure.

Opérations quotidiennes et la gestion des déploiements est nécessaire pour conserver les services d'exécution sur le long terme et fonctionnalités de gestion du cycle de vie des applications ont été intégrées Service Fabric, en conservant l'approche basée sur les microservices à l'esprit. Les opérations et les fonctionnalités de gestion disponibles dans Service Fabric incluent les déploiements rapides, les mises à niveau sans interruption de service application, contrôle d'intégrité analyse des services et mise à l'échelle du cluster de l'échelle vers le bas. Mises à niveau sans interruption de service sont possibles, car la mise à niveau technique dans Service Fabric fournit une combinaison de restauration des mises à niveau et les vérifications d'intégrité automatique pour détecter et annuler les modifications dans la mise à niveau si elles déstabiliser l'application intégrée. Gestion des applications et des clusters Service Fabric est possible via les commandes Windows Powershell, en fournissant toute la puissance de l'interface CLI et les scripts, également la prise en charge des outils visual, notamment Visual Studio pour faciliter l'utilisation.

Mises à niveau sont effectuées lors des étapes. À chaque étape, la mise à niveau est appliquée à un sous-ensemble de nœuds de cluster, appelé un domaine de mise à niveau. Par conséquent, l'application reste disponible tout au long de la mise à niveau. Vous pouvez également avoir le contrôle de version fort et prise en charge côte à côte afin que vous pouvez déployer les versions de la même microservice v1 et v2 et Service Fabric redirige vers une ou l'autre, selon les demandes du client. Consultez la documentation à bit.ly/1kSupz8 pour plus de détails.

Lors du débogage de services au sein de votre cluster au sein de votre ordinateur de développement local, Visual Studio facilite même lorsque les processus des services sont déjà en cours d'exécution avant de démarrer le débogage. L'IDE joint automatiquement tous les processus microservices associés à votre projet, facilitant ainsi la mise en route et utiliser les points d'arrêt normales dans votre code de microservices Service Fabric. Simplement définir les points d'arrêt dans votre code et appuyez sur F5. Vous n'avez pas besoin de savoir à quel processus que vous devez attacher Visual Studio.

Service Fabric Explorer Service Fabric Explorer, illustré Figure 10, est un outil Web fourni par le cluster pour visualiser l'état des applications déployées, inspecter le contenu des nœuds individuels et effectuer différentes actions d'administration. L'outil Explorateur est servie à partir du même service de passerelle HTTP prenant en charge l'API REST de Service Fabric et peut être atteint en accédant à http://<your-cluster-endpoint>:19007/Explorer. Dans le cas d'un cluster local, l'URL serait http://localhost:19007/Explorer.

Figure 10 Service Fabric Explorer

Pour plus d'informations sur le Service Fabric Explorer, lisez la page de documentation « Visualiser votre Cluster à l'aide de Service Fabric Explorer » (bit.ly/1MUNyad).

La plateforme Service Fabric permet une variété de fonctionnalités qui vous permettent de vous concentrer sur le développement d'applications plutôt que l'implémentation de santé complexe et les systèmes conformes. Nous citerons entre autres :

Mise à l'échelle des Services sans état moteur d'orchestration le Service Fabric peut automatiquement mettre à l'échelle votre application Web sur plusieurs ordinateurs lorsque de nouveaux nœuds sont ajoutés à un cluster. Lors de la création d'instances d'un service sans état, vous pouvez spécifier le nombre d'instances que vous souhaitez créer. Service Fabric placera ce nombre d'instances sur les nœuds du cluster en conséquence, sans créer de plus d'une instance sur chaque nœud. Vous pouvez également demander à Service Fabric pour créer une instance sur chaque nœud en spécifiant « -1 » pour le nombre d'instances. Cela garantit que chaque fois que vous ajoutez des nœuds à l'échelle de votre cluster, une instance de votre service sans état sera créée sur les nouveaux nœuds.

L'équilibrage des ressources automatique Service Fabric fournit l'équilibrage des ressources service (ou l'orchestration des services) qui comprend les total des ressources disponibles dans le cluster (par exemple, le calcul à partir d'ordinateurs virtuels). Il déplace automatiquement microservices en fonction des stratégies définies et les contraintes au mieux optimiser comment les services créés sont placés entre les machines virtuelles (voir Figure 11). Cela est axé sur l'optimisation des performances et coûts.

Cluster montrant la Distribution des Services entre les nœuds et l'équilibrage des ressources automatique
Cluster de la figure 11 indiquant la Distribution des Services entre les nœuds et l'équilibrage des ressources automatique

Basculement intégré et réplicationMachines dans n'importe quel centre de données ou les clouds publics sont sujets à des défaillances matérielles non planifié. Pour éviter ces scénarios Service Fabric fournit le basculement intégré et la réplication, ce qui signifie que des problèmes matériels en dépit de la disponibilité des services n'est pas affectée. Ceci est possible parce que le Service Fabric peut exécuter et gérer plusieurs instances de chaque service sur les ordinateurs et les domaines de défaillance.

Les contraintes de placement vous pouvez indiquer le cluster pour effectuer certaines opérations comme ne pas placer les frontales microservices dans les mêmes machines/nœuds que les couche intermédiaire microservices et pour éviter la colocation certains types de microservices dans les mêmes nœuds. Cela est possible afin de minimiser les conflits connus ou pour garantir un accès prioritaire aux ressources pour certains microservices.

Charge équilibrage des demandes afin de ne pas pour confondre avec l'équilibrage des ressources automatique, les demandes d'équilibrage de charge ne sont pas gérées par Service Fabric, mais par les équilibreurs de charge Azure ou autre plateforme externe de Service Fabric.

L'intégrité vous permet de surveiller et diagnostiquer vos systèmes. Également utilisé lors de mises à niveau de l'application pour fournir des vérifications de sécurité afin que les mises à niveau peuvent être restaurées si la mise à niveau a un effet d'instabilité. Pour plus d'informations, consultez la page de documentation, « Introduction à Service Fabric contrôle d'intégrité » (bit.ly/1jSvmHB).

Microservices avec état dans Azure Service Fabric

Prise en charge des services avec état est un composant intéressant et important d'Azure Service Fabric. Il est également complexe et suffisamment importante pour qu'exploration des services avec état va au-delà de la portée de cet article, mais nous expliquerons brièvement ce qu'il est. Recherchez un article suivi axé sur cette zone de Service Fabric dans un prochain numéro.

Un microservice Service fabric avec état collocates de calcul et de données, avec l'état sont placés dans le microservice lui-même (en mémoire et conservées sur le disque local). La fiabilité de l'état s'effectue via la persistance locale et réplication des données aux autres nœuds/machines virtuelles. En fait, chaque partition de données doté de plusieurs services de réplica associés. Chaque réplica peut être déployé dans une autre nœud/machine virtuelle pour fournir une haute disponibilité doit le réplica principal tombe en panne. Cela est semblable au fonctionnement de la base de données SQL Azure avec les réplicas de base de données, car elle est basée sur Azure Service Fabric.

Dans des applications complexes et évolutives, les services avec état simplifie l'architecture et réduit le nombre de composants par rapport à une architecture à trois niveaux traditionnelle qui a besoin d'utiliser des files d'attente et le cache externe. Lorsque vous utilisez des services avec état, les avantages d'un cache externe traditionnels est désormais intrinsèque dans le service avec état. En outre, les files d'attente externes ne sont pas nécessaires, car nous pouvons implémenter des files d'attente internes au sein de microservices Service Fabric.

Lors de l'utilisation des services avec état, il crée automatiquement des serveurs secondaires sauvegarde à chaud qui peuvent reprendre les opérations à partir du même point où un principal s'est arrêté suite à une défaillance matérielle. Nombre de fois où les services doivent mettre à l'échelle de continuer à répondre aux exigences d'une base d'utilisateurs croissante, nécessitant l'ajout de matériel pour l'environnement en cours d'exécution. Service Fabric utilise des fonctionnalités telles que le partitionnement afin que les services peuvent être créés de façon qu'ils automatiquement répartis sur un nouveau matériel sans intervention de l'utilisateur.

Des Services fiables avec état Azure fournissent une multitude de fonctionnalités, notamment la prise en charge de partition de données, élection de prise en charge et responsable du réplica, noms de service de réplication et recherche d'adresses de service à partir du service de passerelle. Il permet également la gestion de l'accès concurrentiel et la granularité des changements d'état à l'aide de transactions, la possibilité de gérer la réplication cohérente et l'utilisation de fiable, distribué des collections de clé/valeur (dictionnaire fiable et file d'attente fiable). La bonne nouvelle est que Service Fabric gère la complexité et les détails de ces rubriques pour vous, du afin de vous concentrer sur l'écriture d'applications.

Services d'acteurs fiables dans Azure Service Fabric

Acteurs fiables Azure Service Fabric est un modèle de programmation d'acteur pour Service Fabric. Il fournit un modèle d'acteur asynchrone, monothread. Un acteur représente une unité d'état et de calcul. À certains égards, il est similaire au projet de logiciel open source « Orléans » créé par Microsoft Research. Le point important est que les API des acteurs fiables Service Fabric est basée sur l'infrastructure sous-jacente fournie par Service Fabric.

L'implémentation des instances d'acteur pour les périphériques Internet des objets (IoT) est un bon exemple d'utilisation de services d'acteur. Un type d'acteur véhicule sous la forme d'une classe c# serait encapsulent la logique de domaine IoT véhicule ainsi que ses États tels que des coordonnées GPS et d'autres données en direct. Ensuite, nous devrions potentiellement des millions d'objets de l'acteur ou les instances de ce mentionnés (classe), distribuée sur plusieurs nœuds du cluster.

Bien sûr, les acteurs ne sont pas limités à IoT objets actifs, ils peuvent être utilisés pour n'importe quel objet, mais « objets IoT actifs » sont un magnifique scénario didactique.

Les acteurs sont distribués au sein du cluster pour obtenir une disponibilité et une évolutivité élevée et sont traités comme des objets en mémoire dans les machines virtuelles de chaque cluster. Ils sont également conservés sur le disque local et répliquées dans le cluster.

Les acteurs sont des objets isolés monothread qui encapsulent l'état et le comportement. Chaque acteur est une instance d'un type d'acteur, comme le code .NET illustré ici :

// 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;
  }
}

Ensuite, le code suivant montre des exemple de code client à utiliser l'acteur via un objet 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));

L'infrastructure de communication est pris en charge sous le capot par l'infrastructure d'acteurs fiables Service Fabric.

Vous pouvez avoir des millions d'objets VehicleActor en cours d'exécution sur votre cluster entre les nœuds de différents nombreux/VM et Service Fabric est en prenant soin de la plomberie requise, y compris les partitions et réplicas où vos millions d'acteurs sont réparties et équilibrées.

L'API du client Actors assure la communication entre une instance d'acteur et un client d'acteur. Pour communiquer avec un acteur, un client crée un objet proxy d'acteur qui implémente l'interface d'acteur. Le client interagit avec l'acteur en appelant des méthodes sur l'objet proxy.

Pour les scénarios où interviennent les acteurs, il simplifie considérablement l'implémentation de microservices, en particulier par rapport aux fiable avec état services où vous avez contrôlent, mais doivent implémenter un grand nombre de plomberie relatifs au partitionnement des données, l'adressage, les réplicas et les autres de partition. Si vous n'avez pas besoin contrôle précis, vous pouvez éviter le travail supplémentaire à l'aide des acteurs fiables.

Synthèse

Architectures de Microservices nécessitent un engagement décentralisée des approches, des processus de conception et architecture disciplinés, nouvelles technologies telles que Azure Service Fabric et un changement dynamique de l'équipe vers Agile principes appliqués par microservice et de petites équipes de développement.

Cesar de la Torre est responsable de programme senior chez Microsoft et vit à Redmond, Wash. Il s'intéresse également Microsoft Azure et le développement .NET avec des méthodes telles que les architectures de microservices et de la conception pilotée par domaine, ainsi que de développement d'applications mobiles en exposant les services.

Singh approfondie Kunal est responsable de programme senior au sein de l'équipe Microsoft Azure Service Fabric. Avant Azure, il a travaillé sur plusieurs versions de Windows Phone, Silverlight et en tant qu'un développeur de jeux pour Xbox titres. Il vit à Seattle, Washington.

Vaclav Turecek est responsable de programme senior chez Microsoft. Il travaille sans relâche avec un groupe de personnes pour rendre Azure Service Fabric la meilleure plate-forme nouvelle génération en tant que Service très embarqué.

Je remercie l'expert technique Microsoft suivant pour la création et de révision de cet article : Mark Fussell
Mark Fussell est passionné de la création d'applications de l'échelle du cloud ayant passé plusieurs années chez Microsoft à créer des produits allant de l'accès aux données et les communications à d'autres technologies côté serveur. Il est très heureux de voir que Microsoft a publié Service Fabric à chacun d'eux pour créer des applications avec une approche microservices.