azure - 我们如何使用事件网格和服务总线改进我们的架构？

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭 5 年前。

Improve this question

我们使用 Azure 作为 PaaS 来托管多个 .NET Core API 项目，这些项目通过 HTTP 相互通信。当我们开始时，它只是几个端点，但今天和将来，我们需要在项目之间进行更多此类通信。

在今天的解决方案中，我们使用 HttpClient来执行这些通信。由于我们想要一个更独立的 API 项目，我们希望使用带有 webhooks 的总线。尽管我们知道自己需要什么，但我们有很多选择，而在 Azure 中感觉有点不知所措。

我们的要求是基本的，它将具有最小负载的请求发送到特定端点，例如创建了 id xx 的用户。

我们有点困惑，需要在Azure 平台中指明正确的方向。如果您需要更多信息来帮助我们，请随时询问!

问候

Answer 1

看起来您正在转向微服务架构，这很棒。我个人认为使用 HttpClient 没有任何问题。这正是我们的 Azure Service Fabric 应用程序中进行通信的方式。我们实现了一个带有重试策略的基本 HttpClient 库，以防万一我们从 API 收到暂时性错误，并且一切都按预期工作。您只需要确保您的服务不会太“喋喋不休”——这是一个常见的微服务问题。为此，必须精心设计服务，并以合乎逻辑且最有效的方式划分职责。

您还可以在 Azure 云中实现其他通信方式，我使用的是这些方式:

• ServiceBus 队列
• 存储队列
• 事件中心

它们都适用于特定场景。例如，如果您预计您的服务或某些第三方服务会停机，您可能需要考虑在 EventHub 中累积消息，直到服务重新启动并运行并准备好处理它们。

所以这一切都取决于您想要实现的特定场景，对于许多(大多数)场景来说，Http 通信应该工作得很好 - 它的最大好处是简单且易于实现。对于某些场景，您需要“出队”策略。有时您可以只使用共享数据库和 poll-every-N-interval。