Développer Azure Microservices & App Services avec NCache
Webinaire enregistré
Par Ron Hussain et Adam J. Keller
Optimisez les performances et l'évolutivité de vos applications cloud Azure pour qu'elles s'exécutent en cas de pic de charge. Utilisez un référentiel de données rapide, évolutif et commun pour améliorer l'expérience des applications de service Azure sans aucune perte de données ou de session.
Ce webinaire montre comment intégrer Azure Microservices et App Services avec un cache distribué .NET dans le cloud.
Nous couvrirons :
- Introduction aux microservices Azure et aux services d'application
- Utilisation des packages NuGet pour NCache ressources des applications clientes
- Fabrication NCache Appels d'API depuis les services Azure
- Créer et déployer un cache distribué dans Azure
- Utilisation du cache pour les services Azure
- Surveillance du cache qui exécute Azure Microservices et App Services
Le sujet que nous avons sélectionné aujourd'hui utilise NCache qui est le principal système de mise en cache distribué dans les services Azure. Mon objectif principal aujourd'hui sera les microservices Azure. Je vais parler de quelques détails architecturaux des microservices. Je parlerai de quelques détails sur les raisons pour lesquelles vous avez besoin d'un cache distribué dans les micro-services, quelles sont les limitations, puis je parlerai également des services d'application Projets de service d'application Web Microsoft Azure, où vos applications Web peuvent également avoir besoin d'un système de mise en cache distribué pour traitement des données, pour les sessions, mise en cache de sortie. Donc, ce genre de fonctionnalités que je vais mettre en évidence. L'ordre du jour principal que je vais couvrir aujourd'hui, la partie pratique de ce webinaire va se concentrer sur l'architecture de déploiement. Comment exactement un cache distribué est déployé et comment exactement vos applications devraient s'y connecter.
Microservices et services d'application Azure
Donc, je vais d'abord parler de quelques détails d'introduction sur les microservices Azure et les services d'application
Qu'est-ce qu'un microservice?
Qu'est-ce qu'un microservice ? Donc, c'est un terme très courant que nous entendons beaucoup ces jours-ci. C'est une plate-forme et elle est offerte par Microsoft Azure. Il existe des AWS, puis des fournisseurs tiers également. En règle générale, je nommerais simplement Akka.NET, c'est aussi une plate-forme très populaire sur Java, puis ils l'ont également mise sur .NET. Un microservice est une plate-forme qui encapsule les scénarios commerciaux du client et prend en charge certains problèmes rencontrés par le client au sein de l'application. Ainsi, il pourrait être développé par une petite équipe d'ingénieurs. Il peut être écrit dans n'importe quel langage de programmation.
Il peut être avec état ou sans état, mais c'est quelque chose d'indépendant au sein de l'application. Ainsi, il peut être versionné, implémenté, déployé de manière indépendante, puis l'avantage de l'architecture de microservices est qu'il peut être mis à l'échelle indépendamment. Vous n'avez pas besoin de faire évoluer une application entière. Si une partie de l'application remplit ces caractéristiques, vous pouvez simplement l'implémenter en tant que microservice. Votre application peut l'utiliser comme ressource de microservice, puis vous pouvez faire évoluer cette partie particulière sans avoir à vous soucier de l'évolutivité de l'ensemble de l'application. Ainsi, cela vous donne une approche plus granulaire des différents segments de l'application.
J'ai souligné deux points communs ici, à savoir que vos microservices sont des protocoles d'interface bien définis et qu'ils interagissent également avec d'autres microservices. Et, ensuite, ils ont des noms uniques que vous obtenez dans Microsoft Azure, puis ils doivent rester cohérents et disponibles en cas de panne. C'est donc une autre caractéristique importante d'un microservice. C'est quelque chose que j'ai copié du site Web de Microsoft MSDN. Donc, et je suis presque sûr que tout le monde sait ce qu'est le microservice. Donc, cela devrait couvrir quelques détails de base sur le microservice, d'accord ?
Structure de services Microsoft Azure
Voici le diagramme où votre type d'application a un type de service, il peut être avec ou sans état. J'ai déjà couvert cela.
Il existe un autre type d'application qui pourrait également avoir ses propres microservices, puis il peut parler à certaines sources de données principales pour le code, pour les configurations. Il peut appeler un service Web. Il pourrait également avoir des données auxquelles il a besoin d'accéder et puis ils le sont, vous savez... C'est juste une idée de la façon dont les microservices sont architecturés. Il pourrait y avoir plusieurs applications et chaque application pourrait avoir plusieurs microservices, qui sont à leur tour un cluster de serveurs, des clusters d'instances. Vous pourriez avoir des partitions dans le microservice. Il s'agit principalement d'un microservice avec état. Si vous avez plusieurs microservices, vous pouvez choisir d'avoir des microservices avec état ou sans état.
S'il s'agit de microservices avec état, vous auriez une partition de données, puis des répliques d'une autre partition. Ainsi, si une partition tombe en panne, la sauvegarde sera automatiquement disponible. Donc, cela fait partie de Microsoft Azure, cela fait également partie de l'architecture des microservices et c'est ce qu'Amazon vous offre également, Akka.NET qui a également le même type de format de question. Ainsi, le microservice est quelque chose qui fournit un état en lui-même dans son architecture par défaut. Donc, je vais souligner où exactement vous avez besoin d'une mise en cache distribuée comme NCache. Pourquoi exactement vous avez besoin d'un cache distribué et il y a quelques goulots d'étranglement, il y a quelques problèmes que le cache distribué va aider à résoudre dans le cadre de ce webinaire, que je vais couvrir.
Présentation des services d'application Web Azure
Ensuite, je parlerai également des services d'application Web Azure. Il est plus facile de déployer des applications Web dans Microsoft Azure.
Vous n'avez pas besoin d'avoir une machine virtuelle entière. Cela réduit en fait votre temps DevOps, la quantité d'expertise nécessaire, le temps que cela prend, c'est quelque chose qui est géré. Ainsi, vous pouvez simplement obtenir une application basée sur une instance déployée dans Microsoft Azure. Il s'agit d'un environnement dédié entièrement isolé pour vos applications. Vous pouvez le mettre à l'échelle. Vous pouvez héberger plusieurs applications. Il peut s'agir de vos applications mobiles, du Web ou de vos applications de fonction, selon ce qui est requis à ce stade, vous pouvez l'utiliser à l'aide de notre modèle de service d'application Web Microsoft Azure.
Et, puis c'est très évolutif, j'ai déjà mentionné que l'isolement est garanti. Vous obtenez un accès réseau sécurisé et vous pouvez également utiliser une utilisation élevée de la mémoire et d'autres ressources nécessaires. Et, c'est une transition que la plupart des déploiements prennent où vous avez réellement au lieu d'avoir l'intégralité de la VM hébergeant votre application dans un formulaire Web ou un scénario de jardin Web où vous devez gérer l'intégralité de la VM, vous pouvez avoir une approche basée sur les instances où une application basée sur un service peut être déployée et il pourrait s'agir d'une application MVC typique qui peut utiliser des sessions, qui peuvent utiliser des appels de base de données. Donc, toutes sortes de concepts liés aux applications Web MVC classiques, mais c'est juste que le déploiement est légèrement différent.
Mise en cache distribuée
Maintenant que nous avons défini les microservices Azure et les services d'application Web Azure, n'est-ce pas ? Ainsi, le microservice dans Microsoft Azure est un projet Service Fabric, tandis que les services d'application Web sont un projet de service d'application. Je vais donc mettre en évidence les détails à ce sujet et parler de l'élément réseau dont vous avez besoin pour utiliser le cache distribué.
Qu'est-ce qu'un cache distribué en mémoire ?
Tout d'abord, je parlerai des concepts de mise en cache distribuée en général.
Qu'est-ce qu'un cache distribué ? Un cache distribué est un cluster de services de mise en cache peu coûteux qui sont regroupés pour la mémoire et leurs ressources pour la puissance de calcul, puis leur puissance de stockage et dans le cas du cache distribué, c'est la mémoire qui présente le stockage principal. Ainsi, vous regroupez toutes les ressources de mémoire dans une capacité logique.
Ensuite, vous pouvez synchroniser vos mises à jour de cache sur tous les serveurs de cache. Par exemple, toute mise à jour appliquée sur un serveur donné est appliquée sur tous les serveurs de mise en cache. Ainsi, le cache distribué est un cluster de plusieurs serveurs de cache peu coûteux qui sont réunis en une capacité logique. Vous avez plusieurs serveurs dans Microsoft Azure, ce seront des machines virtuelles. Alors, NCache est déployé sur une machine virtuelle. Il s'agit de l'option de déploiement actuelle. NCache peut également être déployé dans docker, non ? C'est donc une autre option de déploiement. Ainsi, le serveur de cache s'exécutant sur une machine virtuelle mais sera traité comme une ressource distincte dans Microsoft Azure et c'est le déploiement typique aussi loin que NCache la configuration côté serveur est concernée.
La caractéristique suivante d'un cache distribué est que vous devez synchroniser toutes vos mises à jour de cache sur tous les serveurs de mise en cache. Vous pourriez avoir 2 3 4 serveurs de mise en cache et ils devraient avoir une vue cohérente des données. Les données doivent être visibles dans un même état pour toutes les applications qui y sont connectées.
Et, alors, il se peut qu'il devrait évoluer de manière linéaire pour la mémoire et les transactions à mesure que vous augmentez votre capacité, vous avez besoin de plus de stockage, de plus de ressources, vous pouvez simplement introduire de plus en plus de serveurs de mise en cache et cela devrait croître de manière linéaire. Et .. alors la réplication est une autre partie de celle-ci qui devrait répliquer les données, pour toutes les données qui sont ajoutées si le serveur tombe en panne, elles doivent être automatiquement répliquées. La réplication doit être effectuée en fonction du fonctionnement, puis les données doivent être mises à disposition si un serveur tombe en panne.
Voici donc quelques caractéristiques communes du cache distribué.
Le stockage de données est un goulot d'étranglement pour l'évolutivité
En règle générale, vos applications, qu'il s'agisse de services d'application ou de microservices, peuvent communiquer avec certaines sources de données principales. Dans Microsoft Azure, vous pouvez avoir une instance de serveur de suite qui peut se trouver sur le même réseau V ou un réseau V croisé, mais vous parlez toujours au serveur de base de données.
Donc, cela pourrait être lent, il se peut que ce ne soit pas très évolutif. Il est donc plus logique d'introduire également une couche de mise en cache distribuée dans Microsoft Azure. Et je parlerai également des cas d'utilisation en ce qui concerne les services intégrés aux microservices.
NCache Déploiement
Il s'agit d'un déploiement typique de NCache.
Ainsi, dans Microsoft Azure, vous auriez des machines virtuelles qui évolueraient horizontalement, vous pourriez simplement créer un réseau virtuel, créer des machines virtuelles, puis installer NCache sur ces machines virtuelles ou utilisez nos images Azure ou AWS. Donc, pour parler, vos applications peuvent connecter des microservices, des applications API, des applications hébergées IIS typiques sur d'autres machines virtuelles ou il peut s'agir de services d'application auxquels elles peuvent toutes se connecter et cela vous évite des déplacements vers les sources de données principales. C'est donc l'idée générale d'un déploiement typique de NCache et j'y reviendrai une fois que nous passerons à notre déploiement pour les microservices et les services d'application Azure. Dans le cloud, cela changerait légèrement. Alors, on en reparlera.
Trois utilisations courantes de NCache
D'ACCORD! c'est la diapositive la plus importante de ce webinaire. Je veux souligner où exactement vous utiliseriez un cache distribué dans les services Microsoft Azure, n'est-ce pas ? Ainsi, on parle généralement d'applications Web, de services Web, d'applications back-end, de services de fenêtre, qui doivent accéder aux données à partir d'une source centralisée et qui ont besoin d'un référentiel très rapide. Donc, c'est un cas d'utilisation typique. Dans Microsoft Azure, vous disposez déjà d'une plateforme très évolutive. Vos applications peuvent évoluer de manière linéaire et c'est également le cas typique des formulaires Web et du jardin Web.
J'ai donc répertorié quelques cas d'utilisation importants que vous pouvez utiliser dans Microsoft Azure pour les services.
Mise en cache des données d'applicationTout d'abord, vous pouvez l'utiliser pour la mise en cache des données et cela s'applique aux microservices Microsoft Azure ainsi qu'aux services d'application. S'il existe des services sans état, n'est-ce pas ? Parce que les services avec état nécessiteraient leur propre ensemble de partitionnement et que vous auriez également des répliques, mais sans état n'ont pas de répliques. Donc, un aspect important est que vous avez une application sans état mais que vous voulez toujours avoir des données fiables, n'est-ce pas ? Donc, dans ce cas, vous pouvez mettre des données dans un cache distribué. Le cache distribué de par sa conception peut couvrir l'aspect réplication et l'aspect haute disponibilité. Ainsi, vos données seraient mises à disposition même pour les microservices sans état.
Et, le prochain avantage pourrait également être au sein du microservice ou du service d'application s'il existe une application Web, elle peut communiquer avec une source de données principale telle que le serveur SQL. Ainsi, le serveur SQL est lent. Ce n'est pas quelque chose qui peut gérer une charge de transaction énorme. En réponse à cela, un cache distribué peut avoir plusieurs serveurs, qui sont mis à l'échelle linéairement et ils sont joints dans une capacité logique, n'est-ce pas ? Ainsi, vous pouvez ajouter de plus en plus de serveurs à la volée. Et, dans Microsoft Azure, il est très simple de gérer cela. Vous pouvez simplement créer une nouvelle machine virtuelle et doubler votre capacité à mesure que vous ajoutez de plus en plus de serveurs de mise en cache. Ainsi, le cas d'utilisation de la mise en cache des données, c'est d'abord en mémoire. Ainsi, sa base de données de capacité est ultra-rapide, puis c'est une plate-forme très évolutive, même dans Microsoft Azure, par rapport à votre serveur Microsoft SQL. Ce sont donc deux avantages que vous obtenez dans les services d'application Microsoft Azure et le cas d'utilisation de Microsoft. Il vous suffit de présenter NCache Appel d'API et vous continuez à ajouter des données dans une paire clé-valeur.
Mise en cache spécifique à ASP.NETLe deuxième cas d'utilisation est spécifique aux services d'application Web Microsoft. Il s'agit de la mise en cache spécifique à ASP.NET. Donc, si vous avez un service d'application, vous pouvez utiliser NCache, où votre service d'application communique avec NCache pour les sessions ainsi que pour les données de mise en cache de sortie. Il peut également utiliser l'API de mise en cache d'objets, car ce cas d'utilisation s'applique également aux services d'application ASP.NET. Ainsi, votre état de session fera généralement partie de la même instance de service d'application qui exige que vous ayez besoin d'un équilibrage de charge de session persistant ou il pourrait faire partie de la base de données. Dans les deux cas, s'il s'agit d'une session persistante, il est limité où vous devez avoir un équilibrage de charge persistant qui est l'option par défaut. Et, puis du côté de la base de données, ça va encore être lent et c'est aussi le point de défaillance unique.
Avec les services d'application, en utilisant NCache en tant que fournisseur de sessions, tout d'abord, il est très évolutif. C'est extrêmement rapide et il n'y aurait pas de point de défaillance unique. Les sessions sont répliquées sur les serveurs, c'est donc là que vous obtenez un bord où vous devriez envisager d'utiliser un cache distribué pour vos applications ASP.NET. Et, alors cela pourrait aussi être un déploiement multi-sites et c'est quelque chose que je prévois de couvrir aujourd'hui également où nous aurions une application déployée sur un site qui parle aux serveurs de mise en cache sur le même site et ensuite il a la capacité de parler aux serveurs de mise en cache sur le site également. Et je soulignerai les configurations nécessaires dans Azure, mais c'est impossible dans NCache offres de mise en cache distribuée dans Microsoft Azure.
Le deuxième cas d'utilisation concerne la mise en cache de sortie, n'est-ce pas ? Ainsi, vous pouvez utiliser vos pages statiques dans un service d'application au sein d'une application Web déployée en tant que service d'application. S'il existe des pages statiques, vous mettez en cache le contenu de ces pages. La sortie de page entière peut être mise en cache et vous pouvez utiliser cette sortie de page la prochaine fois que vous aurez besoin d'accéder à la même page. Donc, c'est un autre avantage. C'est quelque chose que je couvre dans notre webinaire typique sur les performances et l'évolutivité d'ASP.NET, où je parle de quatre façons différentes d'optimiser les performances d'ASP.NET. Ainsi, le même concept serait appliqué sur les services d'application Microsoft Azure, où une application Web est déployée en tant que service d'application.
Partage de données Pub/Sub et RuntimeMaintenant, troisième cas d'utilisation important et c'est le plus important en ce qui concerne les microservices. Bien que cela s'applique également aux services d'application. Vos services d'application peuvent nécessiter le partage de données entre un service d'application et un autre service d'application ou il peut s'agir de données partagées entre deux applications différentes. Ainsi, il existe des applications web qui sont de nature différente mais qui dépendent des mêmes données. Il pourrait y avoir une application de rapport et il pourrait y avoir un consommateur de cela, ou il pourrait y avoir un producteur en termes de catalogues de produits et puis il y a une autre application qui doit en dépendre, elle doit générer des rapports basés sur la première application . Ainsi, ce cas d'utilisation exige que vos applications partagent des données entre elles. Donc, il n'y a aucun moyen d'utiliser la base de données pour partager des données, mais c'est lent et c'est aussi un point de défaillance unique dans certains cas. Le cache distribué est plus logique car vos applications peuvent s'y connecter dans un modèle client-serveur. Plusieurs applications peuvent se connecter au même niveau de mise en cache, puis elles peuvent utiliser les mêmes ressources de cache et accéder aux mêmes données et c'est quelque chose que vous pouvez activer.
Dans les microservices Azure, nous devons passer à un autre niveau. Dans les microservices Azure, bien que ceux-ci soient en cluster et que j'ai déjà mentionné qu'ils pourraient être avec et sans état, n'est-ce pas ? Il pourrait y avoir une exigence et c'est quelque chose que j'ai mentionné que vos microservices pourraient également avoir besoin d'interagir avec les microservices, n'est-ce pas ? Ainsi, de par sa conception, l'architecture des microservices nécessite que vos instances de service puissent avoir besoin d'interagir les unes avec les autres, puis de partager des données entre elles. Et c'est une exigence fondamentale en ce qui concerne la plate-forme de microservices. Nous avons simplement besoin que plusieurs instances d'application partagent des données entre elles. Un microservice envoie des données et il est disponible pour d'autres instances de microservices, s'il s'agit d'un état ou si plusieurs applications peuvent interagir sur les mêmes lignes, mais dans deux microservices, c'est quelque chose qui est indispensable et donc de nombreux fournisseurs tiers sont fournir le partage de données et le modèle pub/sub dans le cadre de leurs offres, n'est-ce pas ?
Ainsi, dans Microsoft Azure, s'il existe une exigence où vous devez gérer le partage de données lorsqu'une application parle à un magasin et qu'elle contient des données nécessaires à une autre application, une autre instance de microservice, vous avez donc besoin d'une plate-forme pour gérer cela et NCache offre cette plate-forme où les données sont mises à disposition de manière centralisée. C'est un référentiel extrêmement rapide. De plus, il est extrêmement évolutif. Plusieurs instances de microservices, différents services ou instances des mêmes services, peuvent se connecter à ce cache, puis ils peuvent utiliser les fonctionnalités de partage de données. Ainsi, les données sont disponibles de manière centralisée plus rapidement.
Ensuite, nous avons un modèle de pub/sub basé sur des sujets. Nous avons une plate-forme de messagerie en dehors de cela. Ainsi, un message peut être envoyé, il peut s'agir de messages pilotés par des données ou de messages pilotés par une application ou d'un message basé sur un sujet où l'application du producteur et c'est une instance de microservice qui envoie des données au cache, puis ce message est transmis à tous les destinataires sur cette fin d'abonné. Et, de même, les abonnés peuvent également être des producteurs dans certains cas. Ainsi, vous pouvez utiliser la messagerie pub/sub entre plusieurs instances de microservice Azure. Il peut également s'agir d'un partage de données événementiel entre plusieurs instances. Et, en plus, nous avons une notification d'événement et un système de requête continue. Il peut s'agir d'une commande SQL et sur cette base, vous pouvez définir à nouveau un ensemble de données par rapport auquel vous pouvez obtenir des messages basés sur les données. C'est donc le cas d'utilisation que vous envisagez d'utiliser le cache distribué Microsoft Azure dans les microservices Microsoft Azure.
NCache Scénarios de déploiement dans MS Azure
Ensuite, je parlerai également des services d'application Web Azure. Il est plus facile de déployer des applications Web dans Microsoft Azure.
Très bien. Nous avons donc maintenant deux types de scénarios. Ainsi, nous aurions tout déployé dans une seule région sur un seul site au sein du même groupe de ressources ou au sein du même réseau virtuel de préférence, n'est-ce pas ? Donc, j'en ai déjà parlé NCache va être déployé sur des machines virtuelles dans Microsoft Azure alors que vos applications peuvent être soit des machines virtuelles accédant à ces machines virtuelles de NCache ou ceux-ci pourraient être des services Azure et nous nous concentrerons sur les services Azure aujourd'hui. Le cas de la VM est très typique où vous générez une VM, accédez à l'iAS, hébergez votre application là-dedans, puis faites en sorte que votre application se connecte à NCache en utilisant NCache API ou fournisseur de magasin de sessions. Mais, en ce qui concerne les services, vous devez effectuer une configuration réseau. Alors, que votre service parle à NCache.
Nous avons donc un déploiement sur un seul site où vos services Azure et NCache sont déployés dans la même région sur le même site. Ainsi, votre service Azure lorsque vous le déployez, vous devez l'attacher au même groupe de ressources et également au même réseau virtuel. Donc, c'est l'approche recommandée. Vous n'auriez besoin d'aucun intermédiaire. Il n'y aurait pas de sauts multiples qui ne ralentiraient pas les choses. C'est donc le scénario recommandé pour notre site.
Deuxième scénario, c'est aussi un scénario très valable selon lequel vous pouvez avoir plusieurs sites, n'est-ce pas ? Nous recommandons toujours que votre cache et vos applications, vos services d'application de microservices, ils doivent toujours être dans la même région, ils doivent pouvoir se connecter les uns aux autres. Depuis NCache est un protocole TCP-IP. Ainsi, il utilise des adresses IP et des ports pour toutes les communications et ce sont des ports TCP-IP. Il doit donc être déployé de manière à ce que vos applications soient à proximité. Ils sont déployés en combinaison les uns avec les autres. Ils sont à proximité, ils ne sont pas différents houblons disponibles. Par conséquent, nous vous recommandons de déployer votre cache sur le même site où se trouvent vos applications, mais il peut y avoir un scénario dans lequel vous utilisez des fonctionnalités multi-sites. Où votre application peut avoir besoin de communiquer avec le cache sur un autre site ou vos caches doivent communiquer entre eux. Nous avons donc besoin d'une communication de site à site entre NCache également.
Donc, c'est l'ordre du jour que je vais couvrir ces deux scénarios. Le scénario 1 est recommandé, tout est dans les célibataires les plus proches de votre candidature. Le deuxième scénario est que vous pouvez avoir plusieurs sites et que votre application du site un parle aux serveurs de mise en cache du site deux ou il peut s'agir de serveurs de mise en cache. Par exemple, pour la fonction de réplication WAN, vous pouvez avoir un pont entre les caches du site un et du site deux.
Scénario 1 : Déploiement sur un seul site pour les services Azure et NCache (Recommandé)
Donc, déploiement de site unique pour les services Azure, je couvrirai quelques étapes détaillées à ce sujet. Je vais parler du développement d'applications, de la façon dont vous introduisez NCache appels à l'intérieur de votre application et nous utiliserons un projet de service pour cela comme exemple de référence. Très bien. Voici donc le diagramme qui devrait couvrir tous les détails que je prévois de couvrir dans ce webinaire.
Je l'ai déjà mentionné NCache les serveurs vont être des machines virtuelles dans Microsoft Azure. À droite? Vous devez donc vous occuper du réseau virtuel qui prend en charge ces machines virtuelles, puis NCache doit être installé sur ceux-ci, puis sur vos applications Web, qui sont déployées en tant que services d'application, il peut s'agir d'applications API ou d'applications de microservices, n'est-ce pas ? Ce sont toutes des instances de service. Ce ne sont pas des machines virtuelles sous-jacentes. Donc, cela signifie également que vous ne pouvez pas installer NCache sur ces ressources, vous devez l'inclure dans les ressources de l'application. Il existe donc des packages NuGet que nous allons mettre en évidence. Très bien! Donc, nous avons des applications Web, puis nous avons des applications API et il pourrait également y avoir des microservices et d'autres applications.
Il s'agit donc d'un déploiement typique sur un seul site où nous avons le même réseau virtuel Azure hébergeant vos applications ainsi que le VMS de NCache. Et, ce que nous faisons vraiment dans ce domaine, c'est un VPN point à site entre vos applications Web et vos applications de service et NCache un service. Voilà à quoi ressemble le réseau global. Cela fait partie du même réseau virtuel où nous utiliserons réellement un projet de service. Nous allons introduire NCache ressources qu'il contient, nous créerons des ressources côté serveur pour NCache. Ainsi, que nos machines virtuelles sont opérationnelles, nous revenons simplement à l'application et attachons notre application au même réseau virtuel où notre NCache Les VM existent. Donc, cela en ferait simplement un site unique et utiliserait le même réseau virtuel que celui de notre service de mise en cache.
Alors, passons en revue les étapes avec ceux-ci.
Très bien! La première étape est que vous avez NCache Côté serveur soit et préchauffez-le configuré, ce qui signifie en fait configurer des machines virtuelles Azure pour NCache et cette étape est commune à toutes sortes de déploiements, qu'il s'agisse d'un déploiement sur un seul site ou d'un déploiement sur plusieurs sites. Pour un déploiement sur site unique, il vous suffit que votre NCache les serveurs sont configurés, ce sont des VM, puis NCache est installé sur ceux-ci. Je vais donc vous emmener rapidement sur notre portail Azure, n'est-ce pas ? Et, si je vais simplement dans les groupes de ressources, je viens de créer un groupe de ressources, laissez-moi simplement le trier. Mon premier groupe de ressources est le groupe de ressources de démonstration XNUMX, n'est-ce pas ? Et, ici, nous avons toutes sortes de machines virtuelles, par exemple, nous avons la première machine virtuelle de démonstration, puis nous avons également la deuxième machine virtuelle de démonstration et, en fait, j'ai utilisé le même réseau virtuel, mon mauvais... D'accord ! J'ai utilisé le même réseau virtuel pour ces deux machines de démonstration.
Laissez-moi juste vous montrer rapidement le... laissez-moi juste l'amener ici. Très bien! Donc, nous avons la VM de démonstration un si vous regardez ceci, elle est déployée en Europe de l'Ouest, puis nous avons la VM de démonstration deux et puis il y a une VM de démonstration v-net, n'est-ce pas ? Si je clique dessus, je peux voir la démo VM 1 et la démo VM 2 en faire partie et ce sont les adresses IP 10.4.0.4 et 10.4.0.5. Donc, cela représente nos deux NCache VMs et si je vous emmène rapidement dans cet environnement ici.
Donc, ce que j'ai vraiment fait, c'est que j'ai créé une machine virtuelle, une image vide de 2012 ou 2016 ferait l'affaire, puis je suis allé à notre Alachisoft site Web et tout ce dont vous avez besoin, il n'y a pas d'installateur spécial pour NCache. Il vous suffit d'utiliser le programme d'installation existant. Accédez à la page de téléchargement et téléchargez la version d'essai de 30 jours de NCache de notre site Web et une fois que vous avez fait cela, j'ai installé NCache sur la VM de démonstration 1 et la VM de démonstration 2. Et puis j'ai également créé un cache net V de démonstration. Les étapes de création du cache sont très simples. Il vous suffit d'aller dans le cache de démonstration, de prendre la topologie de mise en cache, asynchrone, et de spécifier la VM de démonstration 1, puis je pense que la VM de démonstration 2 devrait choisir l'adresse IP telle quelle. Oui. Ainsi, ces serveurs sont capables de se parler.
Une étape supplémentaire que j'ai franchie, si je reviens à la présentation, ce sont les étapes qui sont nécessaires pour la mise en place NCache service pour Microsoft Azure. Vous créez un réseau virtuel Azure, n'est-ce pas ? C'est quelque chose que vous avez peut-être déjà dans votre environnement. Et puis vous créez des machines virtuelles sur ces réseaux virtuels Azure. Ainsi, vous pourriez avoir un ensemble dédié de machines virtuelles pour NCache; serveur un serveur deux serveur trois. Et, ensuite, vous vous assurez de conserver les mêmes sous-réseaux. C'est quelque chose que nous recommandons et ensuite vous installez NCache sur toutes ces machines virtuelles. Ensuite, une autre chose est que vous ouvrez NCache ports pour les communications. Il existe deux types de ports, deux types de considérations réseau dont vous avez besoin. La première est que vous devez désactiver le pare-feu interne, puis sur le réseau où se trouvent ces machines virtuelles, vous devriez avoir un groupe de sécurité réseau, n'est-ce pas ?
Ainsi, par exemple, démo VM un groupe de sécurité réseau, nous aurions déjà ces ports ouverts, n'est-ce pas ? Donc, si je vous montre rapidement le NCache ports, tout ce dont nous avons besoin est le port 9800 et 48250. Ceci est aussi bien pour la communication entrante que pour la communication sortante. 9800 et 48250 Donc, cela garantirait que toute application essayant d'utiliser NCache, qui utilise le port 9800, est capable de se connecter à ces serveurs de mise en cache, puis à toute application qui essaie de gérer, par exemple, il pourrait y avoir une autre machine virtuelle qui essaie de gérer cela et pourrait être un réseau virtuel croisé, mais cela fait partie du même groupe de ressources, ces groupes de sécurité réseau vous permettent d'avoir cette communication en cours sur ces ports. Alors c'est tout. C'est la considération que vous devez avoir.
J'ai désactivé le pare-feu sur les serveurs de mise en cache eux-mêmes. Et, ces ports sont ouverts et je viens de créer un cache et je peux voir les statistiques. Je peux simplement exécuter une application d'outil de test de stress directement sur ces machines et je peux rapidement, il y a un peu de décalage, alors s'il vous plaît, soyez indulgent avec moi. Et, je peux juste simuler un peu de stress sur ceux-ci aussi. Donc, nous avons, je suis désolé, V net one cache et nous exécutons et simulons simplement l'activité sur ces deux serveurs de mise en cache. C'est donc aussi simple que cela en ce qui concerne la configuration côté serveur. Maintenant, vous devez revenir à votre application et y jeter un œil. Ouais! Voilà. Donc, nous avons de l'activité qui arrive. Donc, tout va bien. Je vais juste fermer ça.
Étape 2 pour le déploiement sur un seul site : déployer le service Azure dans l'environnementEnsuite, maintenant que nous avons configuré des machines virtuelles, j'ai également créé un cluster de cache. Ensuite, j'ai besoin d'une application Web capable de communiquer avec ce cluster de cache, n'est-ce pas ? Donc, je reviens rapidement à ma présentation ici, n'est-ce pas ?
Donc, du point de vue de vos applications, ce dont vous avez vraiment besoin, c'est d'une configuration de réseau point à site entre votre application, dans votre service d'application dans NCache. Donc, tout d'abord, je l'ai déjà fait, n'est-ce pas? juste pour le souligner. Maintenant, si vous revenez au groupe de ressources, nous avons le groupe de ressources de démonstration 1. Nous avons donc une passerelle de réseau virtuel de démonstration, n'est-ce pas ? Nous avons créé une passerelle à ce sujet, n'est-ce pas ? Et, ensuite, nous avons un point sur le site. Il s'agit d'une passerelle de réseau virtuel qui utilise demo v-net, c'est le réseau principal de notre service de mise en cache. Donc, si je reviens ici, si vous regardez ce diagramme, il utilise en fait une passerelle de réseau virtuel ici, qui fait partie de ce réseau virtuel, puis mes applications que je vais déployer sous peu vont avoir un point à site communication en cours entre cela afin que cela soit attaché au même réseau virtuel. C'est l'exigence de Microsoft Azure. Pour que votre service d'application puisse communiquer avec des ressources qui se trouvent sur un réseau virtuel, par exemple des machines virtuelles, vous devez avoir un point à site configuré.
Alors, reviens ici. Nous avons donc un groupe de ressources de démonstration. Même si je vous montre le point à site, laissez-moi juste venir ici, si je vous montre les configurations point à site, nous avons cette adresse IP qui est une adresse IP générale pour nos services d'application. Ainsi, une fois qu'un service d'application est déployé, cliquez dessus, puis attachez-le au réseau virtuel correspondant.
Donc, je reviens à mon projet, je pense que je ne l'ai pas montré plus tôt, mais c'est un exemple d'application qui est une application de service. Je vais vous montrer ce qu'il faut. Donc, si vous faites un clic droit dessus, vous avez des packages NuGet disponibles pour Microsoft Azure.
Ainsi par exemple, nous avons Alachisoft.NCache.SDK. Ceux-ci sont disponibles en privé avec nous, n'est-ce pas ? Ceux-ci équipent vos applications de tous les NCache pointe sur les ressources car il n'y a pas d'installation de NCache côté client. Typique NCache déploiement est que vous avez installé le client, vous avez installé un serveur. Alors, couvre-le, non ? Mais, avec les services, c'est une instance. Ainsi, vous n'avez pas accès à la machine virtuelle sous-jacente. Donc, dans ce cas, vous avez besoin des packages NuGet. Ainsi, toutes les ressources dont vous avez besoin sont intégrées à l'intérieur de l'application. Donc, c'est le package nougat que j'ai déjà installé. Qu'est-ce qu'il a vraiment ajouté tous les NCache bibliothèques du site client, n'est-ce pas ? Donc, c'est qu'il a également ajouté quelques configurations. Donc, nous avons client.ncconf, c'est le fichier principal qui se connecte à n'importe quel cache.
Par exemple, j'ai déjà des paramètres pour me connecter au cache V net one qui est le nom, puis j'ai également les adresses IP internes pour me connecter à ceux-ci. La prochaine chose est que je publie cette application et ensuite cette application devrait pouvoir accéder à 10.4.0.4 pour la VM un et 10.4.0.5 pour la VM deux. Donc, je dois m'assurer qu'il existe un point de communication du site où cette adresse IP publique est accessible à mon application, alors seulement elle pourra se connecter avec ce cache.
Donc, pour en revenir à l'application, je montre quelques appels de cache. Ainsi, dans ce projet MVC, nous avons notre contrôleur principal où nous avons cette instance de cache, puis j'utilise une instance de cache. InitializeCache. Permettez-moi de passer à cette méthode ici. Donc, c'est la méthode initialisée, NCache.initializeCache, puis nous appelons également cache.insert pour ajouter un élément, Cache.delete pour supprimer cet élément, cache.get pour récupérer l'élément, puis si je ne suis pas sûr d'avoir effectué un test de charge, ouais ! Ainsi, il existe un autre test de charge de méthode qui charge réellement l'élément, des milliers d'éléments sont chargés dans le cache, puis ceux-ci sont également récupérés. Donc, cela devrait prendre en charge la logique principale ainsi que notre application.
Il y a quelques vues que je vais vous montrer. Donc, nous avons également supprimer, obtenir, indexer et tester la charge et ceux-ci sont simplement appelés via notre application. Donc, ce que je vais faire, c'est que ce sont des bases NCache appels. Donc, ce que je vais faire ensuite, c'est que je déploie simplement ceci sur Microsoft Azure. Donc, j'ai déjà mis en place tous les groupes de ressources et les éléments de réseautage, ici. Mais, ce dont vous avez vraiment besoin, c'est que s'il s'agit d'une application Microsoft Azure, vous créez simplement un nouveau nom d'application Web en fonction de votre abonnement. Attendons un peu de temps. Donc, qu'il choisit l'abonnement. Voilà. Ainsi, il a automatiquement choisi l'entreprise Visual Studio, puis le groupe de ressources, je prévois simplement d'utiliser le groupe de ressources de démonstration. Donc, que j'utilise le déploiement sur un seul site. Donc, cela fait partie du même groupe de ressources, puis je sélectionne le plan de service, puis je choisis simplement de créer. Vous pouvez simplement mettre nouveau ici aussi. Donc, que même l'emplacement est l'Europe de l'Ouest, d'accord ? Choisissez OK à ce sujet, puis choisissez Créer et il démarrera automatiquement.
Depuis, je l'ai déjà fait. Donc, ce que je fais ensuite, je vais simplement aller dans ma configuration Web, m'assurer qu'il utilise le cache V net one et à l'intérieur de client.ncconf, nous avons le cache V net one. Ainsi, cette application va être déployée sur le même site. Même fin de groupe de ressources, puis je l'attacherai au réseau virtuel qui fait partie de mon NCache serveurs VM.
Pour en revenir à Microsoft Azure, dans un instant, si je vais au groupe de ressources un, nous devrions avoir cette application quelque part. Voilà! Si vous cliquez dessus, puis sur la partie réseau de cette application une fois déployée, n'est-ce pas ? Alors, c'est vrai ! Donc, vous allez sur le réseau, vous cliquez dessus et il est déjà connecté à la démo v-net one, n'est-ce pas ? J'ai déjà fait ça, non ? Donc, dans votre cas, une fois que vous avez établi une connexion point à site sur votre passerelle de réseau virtuel, vous avez un groupe de ressources de démonstration, n'est-ce pas ? Ramenons ça, ici. Ainsi, une fois que vous créez un réseau virtuel, créez un point vers le site, puis cette IP de service d'application est exposée, après avoir déployé votre service d'application, vous devez l'attacher au réseau virtuel, n'est-ce pas ? Donc, c'est quelque chose qui est une étape supplémentaire qui est nécessaire, ici même. Donc, mon application, j'espère qu'elle est chargée. Je l'attends ouais !
Maintenant, côté serveur, je vais juste effacer le contenu et insérer un élément. Ajouté avec succès dans le cache. Et, vous pouvez voir un article dessus, je vais juste l'obtenir rapidement. Je suis désolé, je ne peux pas vraiment vous montrer les compteurs, mais il l'a effectivement récupéré et je peux ensuite le supprimer, n'est-ce pas ? Donc, et comme cela fait partie du même réseau virtuel, c'est beaucoup plus rapide en comparaison.
Maintenant, je vais simplement simuler des tests de charge. Je vais simplement ajouter des milliers d'éléments et vous devriez voir une certaine activité. Voilà, non ? Ainsi, les requêtes par seconde et ces éléments sont ajoutés, puis vous pouvez voir environ 600 éléments ici, environ 400 éléments ici, puis il ne récupère pas ces éléments. Il s'agit donc d'un déploiement typique de vos services, qu'il s'agisse de microservices, de services d'application, d'applications d'API, de toute application déployée dans un modèle de service. Il vous suffit d'introduire les packages NuGet, de créer une connexion point à site pour NCache Les machines virtuelles via ce que votre passerelle réseau, puis votre instance d'application peuvent être attachées à la machine virtuelle. Donc, ce sont toutes les configurations de réseau Microsoft Azure et NCache a juste besoin d'adresses IP privées pour être exposées sur le canal TCP-IP. Donc, c'est tout ce dont nous avons besoin.
Scénario 2 : Déploiement multisite pour les services Azure et NCache
Donc, ensuite, puisque nous avons moins de temps disponible, je pense que dans les 10 dernières minutes, je couvrirai également le scénario multi-sites. Les configurations sont presque similaires.
Nos applications Web ou services Microsoft ou services d'application sont déployés sur un réseau virtuel Azure ou sur un site, puis NCache VM ou un autre site et pour cela, nous avons vraiment besoin d'une passerelle de réseau local ici et d'une passerelle de réseau virtuel ici, puis nous avons besoin d'une connexion site à site entre ces deux. Encore une fois, ce sont à nouveau tous les paramètres Microsoft Azure qui permettent aux deux parties de se connecter l'une à l'autre à l'aide d'une connexion de site à site et NCache utilise ceux-ci et les adresses IP internes sont mappées de chaque côté. Alors, votre NCache les IP internes du serveur sont mappées sur votre réseau virtuel de services d'application et vice versa.
Et pour cela je vais vous montrer rapidement les configurations. Si je vous ramène aux groupes de ressources, nous avons le groupe de ressources de démonstration deux, n'est-ce pas ? Donc, c'est un autre réseau virtuel. Et, nous avons la démo v-net deux, juste ici, et j'ai aussi deux boîtes sur ce réseau virtuel, la démo VM 3 et la démo VM 4. Donc, cet environnement ici est 10. 4.0.4 c'est un autre réseau virtuel. Il pourrait également s'agir d'un site à l'autre. J'utilise simplement l'analogie d'un autre réseau virtuel en tant qu'autre site. Mais, il pourrait s'agir d'un site croisé, il pourrait s'agir d'un autre centre de données dans une autre région de Microsoft Azure.
Étapes pour le déploiement multisite : déployer le service Azure dans l'environnementDonc, ce dont vous avez vraiment besoin, c'est de conserver les mêmes paramètres pour cela, comme je l'ai déjà expliqué.
Gardez la partie VM sur le même réseau virtuel même sous-réseau, créez un cache, démarrez ce cache et maintenant votre application doit se connecter à notre cache qui est un site croisé. Pour cela, vous avez besoin d'une communication de site à site. Et, si je reviens ici sur ce groupe de ressources de démonstration, puisque nous avons un réseau virtuel de démonstration et une passerelle de réseau virtuel de démonstration, oui, voilà, la passerelle de réseau virtuel 2, n'est-ce pas ? Donc, c'est une passerelle sur le deuxième site. Donc, si nous allons aux connexions, nous avons la connexion de site à site de démonstration 2. Nous avons donc une connexion de site à site à la passerelle de réseau local de démonstration 2. Donc, c'est quelque chose que j'ai configuré, n'est-ce pas ? Ainsi, cela permet à mon réseau virtuel un de se connecter au réseau virtuel deux qui se trouve sur le site. Donc, c'est exactement ce que nous avons fait.
Je vais juste vous montrer rapidement le NCache application que rien ne change ici. Il vous suffit de changer le nom du cache, puis vous devriez avoir les adresses IP pour vous connecter aux serveurs de mise en cache que j'ai dans le cadre de la pile. Donc, V-net pour mettre en cache et j'utiliserai la même application pour me connecter maintenant, j'ai juste besoin de la publier une fois de plus, et remarquez que je la publie toujours dans le groupe de ressources de démonstration un. Alors que nos machines virtuelles sont dans le groupe de ressources de démonstration deux. Et, c'est la VM 3, juste ici, où nous avons deux serveurs de mise en cache. Donc, je vais juste publier ceci une fois de plus en gardant une connexion de site à site déjà configurée. Je vais juste publier ceci et la même application passerait maintenant sur le réseau, sur le site du réseau virtuel 1 au réseau virtuel 2 et serait capable de s'y connecter. Donc, j'attendrai juste qu'il soit publié, puis je reviendrai ici et vous montrerai une fois de plus l'article sur le réseautage.
Donc, ce dont vous avez vraiment besoin, c'est de la même configuration pour les machines virtuelles, gardez le même réseau virtuel ici, même sous-réseau, générez le VMS, installez NCache sur eux, désactivez le pare-feu, configurez le groupe de sécurité réseau afin que NCache les ports sont ouverts et vous avez besoin d'une connexion de site à site entre vos applications en tant que services se connectant à NCache un service. Donc, si vous avez déjà un réseau virtuel auquel vos services d'application sont attachés, il vous suffit de vous assurer que le réseau virtuel 1 est maintenant capable de parler au réseau virtuel 2, puis il y a un site croisé et c'est exactement ce que j'ai fait dans Microsoft Azure également. Ainsi, la publication a été un succès. Je pense que c'était ça. Laissez-moi juste le fermer et laissez-moi juste insérer un élément, d'accord ? Et voyons si un élément a été ajouté, voilà. Donc, maintenant, l'élément a été ajouté. Donc, maintenant, il parle d'un site à l'autre, d'un site à l'autre, puis si j'obtiens cet élément, il sera simplement récupéré. Si je le supprime, cet élément disparaîtrait de ma démo VM 3, aucun élément n'est là, et de même, je vais juste simuler un test de charge où je commencerai à utiliser le même environnement mais je simule juste une activité sur ce.
Donc, maintenant mon site un, les services d'application parlent au service de cache du site 2. Ils traversent le site. Ce n'est pas un scénario recommandé car il y a une réplication WAN ou une latence WAN qui peut en faire partie. Nous vous recommandons donc de tout conserver sur le même site, mais il est possible qu'il y ait un scénario dans lequel votre fonctionnalité basée sur des sessions multi-sites, par exemple, est basée sur la fonctionnalité d'application de bannière de NCache. Il se peut que les applications sur site communiquent avec Azure ou que les applications Azure communiquent avec une seule prémisse et vice versa. Donc, ce sont les exigences et notre test de charge est maintenant également terminé, de sorte qu'il a été exécuté avec succès.
Cela couvre donc notre déploiement Azure.
Options de mise en cache distribuée pour .NET
Quelques choses que je voudrais mentionner à ce stade et il y a un Redis comparaison aussi.
On parle d'Azur. Donc, nous allons certainement parler de Redis. Elle est donc disponible sur notre site Internet. NCache est 100 % .NET. Il est développé en do dièse. Il est entièrement pris en charge pour.NET et Java. En comparaison, Redis dans les coulisses est sous Linux, vous n'avez pas le contrôle sur le VMS. Dans NCache vous avez un contrôle total sur le VMS. vous pouvez exécuter du code côté serveur sur NCache ainsi que la version Microsoft d'une version Windows de Redis n'est pas que vous savez stable. C'est la version Linux qui est utilisée dans les coulisses et ensuite fournie en tant que modèle de service. Et puis, NCache peut également être utilisé sur Dockers. Si vous prévoyez d'utiliser NCache sur les conteneurs Dockers côté serveur, vous pouvez l'utiliser.
Et puis, je parlerai également de quelques détails concernant les options de déploiement. tu viens d'installer NCache partie serveur, vous obtenez une version Azure de notre part. Il s'agit d'une version serveur uniquement et vous avez ensuite besoin des packages NuGet pour que vos applications soient équipées de NCache et c'est quelque chose que vous pouvez également obtenir auprès de notre équipe d'assistance ou de vente. Donc, c'est quelque chose qui n'est pas accessible au public. C'est intentionnel, mais il vous suffit de nous en faire la demande, puis nous vous fournirons la version pour Azure ainsi que les packages NuGet. Après cela, ce n'est que l'élément réseau dont vous avez besoin pour une configuration de site unique ou une configuration multisite. En règle générale, nous recommandons un site unique et dans ce cas, vous avez besoin d'une communication point à site et en multi-site, vous avez besoin d'une communication site à site.
Donc, cela complète notre présentation.