据我所知,在Azure服务结构中,可以通过直接访问终结点(或)反向代理来进行服务通信。目前,我正在使用以下代码直接访问其他服务端点:
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>();
如果service1实例在预期的节点1上不可用,但在SF群集的node2上可用,这种方法是否行得通?
是否直接访问服务端点-该方法使用像反向代理方法那样的'命名服务'来通过服务URL识别请求的服务地址?
使用上述直接访问呼叫实现来发现用于内部服务通信的服务有何缺点?
已解析的端点应该可以工作,但是您可以通过更简单的方式来做到这一点:
DNS允许您通过传递应用程序和目标服务详细信息来获取终结点。SF远程处理的工作方式与此类似。最后一个主要优点是SF远程处理客户端具有内置的瞬时错误处理(只要远程服务暂时不可用,它就会重试调用)。