从 Azure Service Fabric 中的不同应用程序与无状态 Web Api 服务通信

Posted 2023-03-27

【中文标题】从 Azure Service Fabric 中的不同应用程序与无状态 Web Api 服务通信

【英文标题】：Communicate to stateless web Api service from a different application in Azure Service Fabric

【发布时间】：2017-10-15 00:50:36

【问题描述】：

我有两个不同的服务结构应用程序。两者都是无状态的 web api 模型。我确实有一种情况，即从应用程序 1 中的服务 1，我需要调用服务 2，它是应用程序 2 的一部分。我将两个应用程序部署在同一个集群中。有人可以在这里建议最佳做法。什么可能是最好的沟通方式。也请提供一些样本。

【参考方案1】：

Fabric Transport (aka Service Remoting)是sdk内置的通信模型。与通过 HTTP 或 WCF 的通信相比，它做得更多，尤其是在通信的客户端。

在与 Service Fabric 服务（或者实际上是任何分布式系统服务）进行通信时，您的通信应该考虑到连接可能在初次尝试时无法建立，或者在通信过程中被中断，您确实应该这样做不要构建您的解决方案以期望它始终完美运行。其原因在于 Service Fabric 如何随时决定将主节点从一个节点移动到另一个节点，节点本身可能会关闭并且服务可能会崩溃。 Service Fabric 的优点并不奇怪，它为您完成了很多繁重的工作，需要随着时间的推移维护您的服务和节点。

因此，就通信而言，这意味着客户端需要能够做三件事（才能真正在分布式环境中工作）；

解析

服务的地址（找出它在哪个节点上，它正在侦听哪个端口，哪个分区 id 和要定位的副本等等）

连接

到服务，打包和发送请求，然后接收和解包响应 如果通信失败，

重试

解析并连接

Fabric Transport does all this 当您使用服务远程处理客户端（如 ServiceProxy）和服务端侦听器时。

这是 Fabric Transport 的优点，您可以立即使用所有这些功能，而且大多数情况下您也不必更改默认设置。不好的部分是它仅适用于集群内部的通信，即您无法使用 Fabric Transport 从外部与集群中运行的服务进行通信。为此，您需要 HTTP 或 WCF。

HTTP(s) 和 WCF（通过 HTTP(s)）通信允许您构建自己的客户端并自己处理通信。有许多关于如何为 HTTP 客户端进行解析、连接和重试的示例，this one for instance

【参考方案2】：

根据Microsoft，有三个内置的通信选项。由您决定哪一个最适合您。我个人使用的是service remoting，它很容易快速设置。它还允许您在客户端服务中进行异常处理。

【讨论】：

我相信服务远程处理适用于目标服务未绑定任何通信协议的情况。在我的例子中，它是一个无状态的 web api。那么它是DNS服务和反向代理之间的选择吗？你的意思是一样的吗？

我假设他的 web api 只是为了与外部（集群外）客户端程序进行通信。因此，他并没有按照定义绑定到他的 web api 来与其他服务进行通信。