2017-07-03 3 views
0

J'ai créé une application de services fiable qui fonctionne parfaitement sur les clusters locaux.Comment configurer des services fiables pour fonctionner sur le cluster distant Azure

Il dispose de 1 service sans état et d'un service d'acteur et utilise le service à distance. Les points de terminaison ne sont pas définis sur ces services (uniquement le nom du point de terminaison) et les deux services utilisent des écouteurs par défaut (aucun substitut CreateServicesListeners) L'application client est une application de console qui utilise l'accès distant pour communiquer avec l'application (ActorProxy et ServiceProxy).

Maintenant, je veux le déployer sur un cluster Azure.

Que dois-je faire pour que le client communique correctement avec l'application sur le cluster?

Je sais que je dois:

  • Configurer paramètres TCP sur les paramètres xml
  • Configurer Azure Load Balancer

Mais devrais-je si certaines de ces choses? Et dans ce cas comment?

  • Override CreateServiceListeners
  • Utilisation FabricClient sur le client
  • Utilisation ServicePartitionClient sur le client

Mon principal problème est de savoir comment créer ActorProxy et ServiceProxy

Répondre

0

Vous ne devriez pas utiliser le ActorProxy et ServiceProxy classes en dehors du cluster. Utilisez plutôt un service public comme un API Web qui utilise https par exemple pour agir comme une passerelle vers les services. Ensuite, ouvrez le port https sur Azure Load Balancer.

Veuillez lire the docs car ils listent chaque étape que vous devez prendre.

Voici un exemple (extrait de la documentation) d'un service qui utilise https:

class HttpCommunicationListener : ICommunicationListener 
{ 
    ... 

    public Task<string> OpenAsync(CancellationToken cancellationToken) 
    { 
     EndpointResourceDescription endpoint = 
      serviceContext.CodePackageActivationContext.GetEndpoint("WebEndpoint"); 

     string uriPrefix = $"{endpoint.Protocol}://+:{endpoint.Port}/myapp/"; 

     this.httpListener = new HttpListener(); 
     this.httpListener.Prefixes.Add(uriPrefix); 
     this.httpListener.Start(); 

     string publishUri = uriPrefix.Replace("+", FabricRuntime.GetNodeContext().IPAddressOrFQDN); 
     return Task.FromResult(publishUri); 
    } 

    ... 
} 

class WebService : StatelessService 
{ 
    ... 

    protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners() 
    { 
     return new[] { new ServiceInstanceListener(context => new HttpCommunicationListener(context))}; 
    } 

    ... 
} 

Le service public comme celui ci-dessus devraient utiliser les classes ActorProxy et ServiceProxy de déléguer le travail aux services sous-jacents et acteurs.

Donc, pour résumer:

Mais devrais-je si certaines de ces choses? Et dans ce cas comment?

  • Override CreateServiceListeners Oui

  • Utilisation FabricClient sur le client Pas

  • Utilisation ServicePartitionClient sur le client Pas

Mon principal pro blème est de savoir comment créer ActorProxy et ServiceProxy Ceci est valable uniquement pour la communication entre les services du cluster

+0

Alors, que vous parlez est d'utiliser cette interface de programmation comme une passerelle et chaque méthode que je l'habitude d'appeler via Remoting service je dois appelez-le via Api maintenant, non? J'ai quelques questions maintenant: Mon application est un jeu en ligne et mon client est une application de console. Il utilise des méthodes à distance pour interagir avec le service sans état (service de connexion) et avec le service d'acteur (session de jeu). Comment mon client appelle-t-il maintenant les méthodes Api (qui fonctionnent comme interface entre les méthodes client et service) et reçoit la valeur de retour de ces méthodes de service? Mon client a utilisé des événements d'acteur. Comment mon client le recevrait-il maintenant? – Shkire

+0

Votre client peut simplement appeler l'API web/wcf comme vous le feriez pour n'importe quel autre service, en utilisant le nom de domaine complet du cluster avec le bon numéro de port. Les événements d'exposition d'acteurs peuvent être un peu plus difficiles. Peut-être que SignalR ou avoir un auditeur le client que le service peut appeler est une option –