0
votes

As I know, in Azure service fabric, service communication can be possibles either by directly accessing the endpoints (or) reverse-proxy. Currently I'm directly accessing the other service endpoints using below code:

        var service = $"fabric://myapp/**service1**";
        var servicePartitionResolver = ServicePartitionResolver.GetDefault();

        var partition = await servicePartitionResolver.ResolveAsync(new System.Uri(service),
            new ServicePartitionKey(), default(CancellationToken));
        var serviceEndpointJson = partition.GetEndpoint().Address;

        string endpointUrl = JObject.Parse(serviceEndpointJson)["Endpoints"][string.Empty].Value<string>();

Will this approach work if service1 instance is not available on expected node1 but available on node2 of the SF cluster?

Is directly accessing service endpoints - approach uses 'Naming Service' like reverse-proxy approach to identify the requested service address via service url?

Any disadvantages of using above direct access call implementation to discover services for internal service communication?

1

1 Answers

0
votes

The resolved endpoint should work, but you can do this in a simpler way:

The DNS allows you to get an endpoint by passing in the application and target service details. SF remoting works in a similar way. The main advantage of the last, is that the SF remoting client has built-in transient error handling (it retries calls whenever the remote service is temporarily unavailable).