Modèle de passerelle / proxy API pour les microservices déployés à l'aide d'Azure Service Fabric
Après avoir regardé les vidéos de la conférence BUILD pour Azure Service Fabric, je me demande comment cela pourrait convenir à notre architecture actuelle basée sur les microservices. Il y a une chose que je ne suis pas tout à fait sûr de la façon dont je voudrais résoudre, la passerelle/proxy API.
Envisagez une architecture de microservices moins banale dans laquelle vous disposez de N nombre de services exécutés dans Azure Service Fabric exposant REST points de terminaison. Dans de nombreuses situations, vous souhaitez regrouper ces points de terminaison d'API fragmentés dans un API à entrée unique que les consommateurs peuvent utiliser pour éviter qu'ils se connectent directement aux instances de structure de service. La solution Azure Service Fabric semble si complète dans tous les sens que je me demande en quelque sorte si j'ai raté quelque chose d'évident quand je ne le fais pas. voir un moyen de résoudre trivialement cela dans les capacités mentionnées lors des discussions BUILD.
Des services comme Vulcan visent à résoudre ce problème en demandant aux services d'enregistrer les chemins qu'ils souhaitent leur acheminer dans etcd . J'imagine qu'une façon de résoudre ce problème pourrait être de créer un service Web avec état distinct avec lequel d'autres services peuvent s'enregistrer, en fournissant le nom du service et les chemins dont ils ont besoin de leur être acheminés. Le service Web avec état peut ensuite acheminer le trafic vers l'instance appropriée en fonction de son état. Cela ne semble pas tout à fait idéal, cependant, avec des choses comme la suppression de routes lorsque les applications sont supprimées et la synchronisation de l'état avec les services déployés au sein du cluster. Quelqu'un a-t-il réfléchi à cela ou a-t-il des idées sur la façon de résoudre ce problème dans Azure Service Fabric?
L'enregistrement/découverte du service dont vous avez besoin pour le faire est déjà là. Il existe un service système avec état appelé Naming Service, qui est essentiellement un registraire des instances de service et des points de terminaison sur lesquels ils écoutent. Ainsi, lorsque vous démarrez un service - sans état ou avec état - et que vous ouvrez un écouteur dessus, l'adresse est enregistrée auprès du service de dénomination.
Maintenant, la partie que vous devez remplir est la "passerelle" avec laquelle les utilisateurs interagissent. Cela ne doit pas nécessairement être avec état car le service de dénomination gère la partie avec état. Mais vous devez trouver un schéma d'adressage qui fonctionne pour vous, puis il transmettra simplement les demandes au bon endroit. Fondamentalement, quelque chose comme ça:
- Recevoir la demande.
- Utilisez NS pour trouver le service qui peut prendre la demande.
- Renvoyez-lui la demande et la réponse à l'utilisateur.
- Si le service n'existe plus, 404.
En général, nous n'aimons pas dicter quoi que ce soit sur la façon dont vos services se parlent, mais nous réfléchissons à des moyens de résoudre ce problème pour HTTP en tant que solution intégrée complète.
Nous avons également implémenté un service de passerelle HTTP à cet effet. Pour nous assurer que nous pouvons avoir une passerelle HTTP pour n'importe quel protocole interne, nous avons implémenté la passerelle pour les services internes basés sur HTTP (comme ASP.NET WebAPI) à l'aide d'un middleware ASP.NET 5. Il achemine les demandes, par exemple/service, vers une adresse Service Fabric interne comme fabric:/myapp/myservice en utilisant ServicePartitionClient et une logique de nouvelle tentative depuis CommunicationClientFactoryBase.
Nous avons open source ce middleware et vous pouvez le trouver ici: https://github.com/c3-ls/ServiceFabric-HttpServiceGateway
Il y a aussi plus de documentation dans le wiki du projet.
Cette fonctionnalité est intégrée aux points de terminaison http, à partir de la version 5.0 de la structure de service. La documentation est disponible sur https://Azure.Microsoft.com/en-us/documentation/articles/service-fabric-reverseproxy/
Nous avons utilisé un projet open source appelé Traefik avec un succès incroyable. Il y a un Azure Service Fabri c wrapper autour de lui - c'est essentiellement un exe GoLang qui est déployé sur le cluster en tant qu'exécutable géré.
Il prend en charge les disjoncteurs, le round robin LB pondéré, le routage des versions de chemin et d'en-tête (c'est génial pour l'hébergement de plusieurs versions d'API), la liste continue. Et son portail est pratique pour afficher les statistiques de configuration et de santé.
Le vrai pouvoir réside dans la façon dont vous le configurez. Cela se fait via le service lui-même dans le ServiceManifest.xml. Cela vous permet de déployer de nouveaux services et de les diriger immédiatement vers - pas besoin de mettre à jour une table de routage, etc.
Exemple
<StatelessServiceType ServiceTypeName="WebServiceType">
<Extensions>
<Extension Name="Traefik">
<Labels xmlns="http://schemas.Microsoft.com/2015/03/fabact-no-schema">
<Label Key="traefik.frontend.rule.example">PathPrefixStrip: /a/path/to/service</Label>
<Label Key="traefik.enable">true</Label>
<Label Key="traefik.frontend.passHostHeader">true</Label>
</Labels>
</Extension>
</Extensions>
</StatelessServiceType>
Hautement recommandé!
Azure Service Fabric facilite la mise en œuvre de l'architecture standard pour ce scénario: un service de passerelle en tant que frontend auquel les clients peuvent se connecter et tous les N services backend communiquant avec la passerelle frontale. Il existe quelques piles d'API de communication disponibles dans le cadre de Service Fabric qui facilitent la communication entre les clients et les services et au sein des services eux-mêmes. Les piles d'API de communication fournies par Service Fabric masquent les détails de la découverte, de la connexion et de la nouvelle tentative de connexions afin que vous puissiez vous concentrer sur l'échange réel d'informations. Lors de l'utilisation des API de communication Service Fabric, les services n'ont pas à implémenter le mécanisme d'enregistrement de leurs noms et points de terminaison dans un service de routage spécifique, à l'exception des étapes habituelles dans le cadre de la création du service lui-même. Les API de communication prennent l'URI de service et la clé de partition et résolvent et se connectent automatiquement à la bonne instance de service. Cet article fournit un bon point de départ pour aider à prendre une décision quant aux API de communication qui seront les mieux adaptées à votre cas particulier, selon que vous utilisez des acteurs fiables ou des services fiables, ou des protocoles tels que HTTP ou WCF, ou le choix du langage de programmation dans lequel les services sont écrits. À la fin de l'article, vous trouverez des liens vers des articles et des didacticiels plus détaillés pour différentes API de communication. Pour un didacticiel sur la communication dans les services d'API Web, voir this .
Lorsqu'un service est démarré, il enregistre son point de terminaison auprès du service d'attribution de noms de structure. À l'aide des API client Fabric, vous pouvez ensuite demander à Fabric les points de terminaison enregistrés, associés au nom de service enregistré.
Alors oui, tout comme vous avez décrit votre cas, vous auriez une passerelle qui accepterait un URI entrant pour la connexion, puis utiliserait ces informations de chemin d'accès comme recherche de nom de service, pour créer ensuite une connexion proxy entre la demande entrante et le véritable interne emplacement du point de terminaison.
On dirait que l'équipe a posté l'un des exemples qui montre comment faire: https://github.com/Azure/servicefabric-samples/tree/master/samples/Services/VS2015/WordCount
Je me demande au lieu d'exposer Rest at N + services, utilisez la pile de communication par défaut partout dans le tissu de service (ou autant que possible pour garder les choses simples en interne). Exposer REST uniquement au (x) point (s) d'entrée Edge dans le fabric. Utilisez une api std web 2.x sans état qui enveloppe les proxy de fabric de vos services et acteurs, et/ou utilisez un fabric service exposant le repos de la même manière. Agréger vos API selon les besoins dans le (s) service (s) de repos orienté vers l'avant. semble simplement un exercice d'organisation (et de sécurisation) des points d'extrémité de repos avec un espace de noms souhaité (c'est-à-dire un motif de façade).
Nous utilisons SF avec un modèle de passerelle et environ 13 services derrière la passerelle. Nous utilisons le service DNS intégré fourni par SF, voir: https://docs.Microsoft.com/en-us/Azure/service-fabric/service-fabric-dnsservice , cela permet à l'interne service à service avec des noms DNS connus (internes à SF), y compris le service de passerelle vers des services internes. Il existe des passerelles de base asp.net bien connues (Ocelot, ProxyKit) à utiliser, mais nous avons lancé la nôtre. Nous avons un équilibreur de charge externe pour router vers plusieurs instances de passerelle dans SF.