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?
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).