Azure Service Fabric中的服务远程处理与RestFul调用

Question

我试图了解在Azure Service Fabric中使用服务远程处理vs进行安静调用的特定用例。 对于性能，安全性和任何相关方面的任何见解都将受到赞赏。

Answer 1

好吧，让我们看看。 当涉及外部客户端和SF服务之间的通信时，我将使用Restful调用，因为服务远程处理特定于SF，并且在几乎所有使用任何语言的平台上都可以使用Restful api。

对于SF内部服务之间的通信，您可以使用服务远程处理。 基本上，这是Service Fabric的.NET RPC实现，请参见此出色的答案 。 您可以使用其他机制，但是此机制是开箱即用的，可为您提供重试策略和服务解析等方面的内容。

但是很难给出最终的建议，因为这将取决于服务的类型及其目的。 有时您希望使用远程处理进行直接通信，而有时您希望在两个服务之间建立一条消息总线。

最重要的收获是使用https与集群进行通信，因此对于公共可访问的SF服务。

更多背景资料：

在Service Fabric中连接服务并与之通信

安全服务远程通信

Answer 2

您没有提及交流的目的，因此答案可能非常广泛：

从技术上讲

休息

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那样频繁地进行升级。

综上所述，

如果您想要性能和服务之间的简单通信，请使用远程处理。

使用REST如果您不希望将客户端与服务和灵活性结合在一起，则任何客户端\\平台都可以使用REST。

或者，也许您可​​以使用其他协议。 该SO具有一些可能有用的信息： Azure ServiceBus与ServiceRemoting，HTTP和WCF