我试图了解在Azure Service Fabric中使用服务远程处理vs进行安静呼叫的特定用例。对于性能，安全性和任何相关方面的任何见解都将受到赞赏。
答案 0 :(得分：1)
好吧，让我们看看。当涉及外部客户端和SF服务之间的通信时，我将使用Restful调用，因为服务远程处理是针对SF的，并且Restapi可以在几乎所有使用任何语言的平台上使用。
对于SF内部服务之间的通信，您可以使用服务远程处理。基本上，这是Service Fabric的.NET RPC实现，请参见this excellent answer。您可以使用其他机制，但是该机制是开箱即用的，可为您提供重试策略和服务解析以及更多的功能。
但是很难给出最终建议，因为这将取决于服务的类型及其目的。有时您希望使用远程处理进行直接通信，而有时您希望在两个服务之间建立一条消息总线。
最重要的收获是使用https与集群进行通信，因此对于公共可访问的SF服务。
更多背景资料：
答案 1 :(得分：0)
您没有提及交流的目的，因此答案可能非常广泛：
从技术上讲，
REST
REST通信是通用的，可以在任何平台上的任何客户端使用，这是使用HTTP协议向SF群集之外的客户端公开服务的更好方法。
服务可以在不破坏与现有客户端兼容性的前提下发展，客户端与服务之间没有硬性合同。
这种“服务到服务”通信方法的问题在于，该服务必须公开HTTP服务器以接收REST调用，并且每个调用都序列化为JSON。 http服务器必须具有一些路由规则，才能将调用重定向到正确的处理程序，从而在简单情况下向服务中添加了很多不需要的内容。
SF远程处理
SF Remoting是.Net Remoting的实现，.Net Remoting是.Net的一个组件，用于通过TCP提供二进制通信。它更快，因为它不需要将数据序列化为JSON并验证所有JSON规则以进行序列化。
用法是服务和客户端之间的简单接口实现。您无需托管HTTP服务器并为其配置路由规则，因此使用起来更加简单。
缺点
远程处理的第一个问题是客户端和服务必须使用相同的语言，在这种情况下为.Net（PS：您也可以使用其他语言，但不是直接使用的语言），并且还讨论了相同的主题，这就是为什么两个人都需要访问合同（接口）的原因，该合同将说明他们应该如何相互通信。这将客户端与服务耦合在一起，并且很可能在双方同时进行更新。
第二，由于首先，您仅限于.Net和Service Fabric，因此无法在群集外部运行SF Remoting，它与SF Runtime高度相关。
远程处理在HTTP协议下的某个级别上进行，将其公开到Internet的风险要高于HTTP服务器。这并不意味着它是不安全的，但是它不会像WebServers那样频繁地进行升级。
摘要
如果需要性能和服务之间的简单通信，请使用Remoting。
使用REST如果您不希望将客户端与服务和灵活性结合在一起，则任何客户端\平台都将使用它。
或者，也许您可以使用其他协议。该SO具有一些可能有用的信息：Azure ServiceBus vs ServiceRemoting, HTTP and WCF