【发布时间】:2017-10-15 00:50:36
【问题描述】:
我有两个不同的服务结构应用程序。两者都是无状态的 web api 模型。我确实有一种情况,即从应用程序 1 中的服务 1,我需要调用服务 2,它是应用程序 2 的一部分。我将两个应用程序部署在同一个集群中。有人可以在这里建议最佳做法。什么可能是最好的沟通方式。也请提供一些样本。
【问题讨论】:
标签: asp.net-web-api azure-service-fabric
我有两个不同的服务结构应用程序。两者都是无状态的 web api 模型。我确实有一种情况,即从应用程序 1 中的服务 1,我需要调用服务 2,它是应用程序 2 的一部分。我将两个应用程序部署在同一个集群中。有人可以在这里建议最佳做法。什么可能是最好的沟通方式。也请提供一些样本。
【问题讨论】:
标签: asp.net-web-api azure-service-fabric
Fabric Transport (aka Service Remoting)是sdk内置的通信模型。与通过 HTTP 或 WCF 的通信相比,它做得更多,尤其是在通信的客户端。
在与 Service Fabric 服务(或者实际上是任何分布式系统服务)进行通信时,您的通信应该考虑到连接可能在初次尝试时无法建立,或者在通信过程中被中断,您确实应该这样做不要构建您的解决方案以期望它始终完美运行。其原因在于 Service Fabric 如何随时决定将主节点从一个节点移动到另一个节点,节点本身可能会关闭并且服务可能会崩溃。 Service Fabric 的优点并不奇怪,它为您完成了很多繁重的工作,需要随着时间的推移维护您的服务和节点。
因此,就通信而言,这意味着客户端需要能够做三件事(才能真正在分布式环境中工作);
Fabric Transport does all this 当您使用服务远程处理客户端(如 ServiceProxy)和服务端侦听器时。
这是 Fabric Transport 的优点,您可以立即使用所有这些功能,而且大多数情况下您也不必更改默认设置。不好的部分是它仅适用于集群内部的通信,即您无法使用 Fabric Transport 从外部与集群中运行的服务进行通信。为此,您需要 HTTP 或 WCF。
HTTP(s) 和 WCF(通过 HTTP(s))通信允许您构建自己的客户端并自己处理通信。有许多关于如何为 HTTP 客户端进行解析、连接和重试的示例,this one for instance
【讨论】:
根据Microsoft,有三个内置的通信选项。由您决定哪一个最适合您。我个人使用的是service remoting,它很容易快速设置。它还允许您在客户端服务中进行异常处理。
【讨论】: