Azure 服务总线是否应该取代您的 SOA

Question

以前在我的 Web 应用程序中，当（从 UI）进行 CRUD 操作（或任何其他任务）时，我会使用如下简单的模式，利用 WCF。

GetUserByIDResponse response = new UserServiceClientProxy().GetByID(new GetUserByIDRequest() { UserID = UserID });

if (response.success) {
    //response.data - Do something!
} else {
    //Show error response.message
}

然而，从我的研究看来，如果打算在 Azure 平台上运行并使用 Cloud Services 模型进行部署，最好的方法是将此服务总线概念与如下代码一起使用

QueueClient requestClient = CreateQueueClient("RequestQueueName"); 
QueueClient responseClient = CreateQueueClient("ResponseQueueName");

MessageSession receiver = responseClient.AcceptMessageSession(ReplyToSessionId); 
//blah blah

在通信时，我假设我的所有服务类型操作现在都通过服务总线处理正确吗？还是只考虑在应用程序的某些特定方面使用这种技术？

我想我要问的是，“服务总线是否可以替代为 Azure 平台设计的 SOA（面向服务的架构）？”

希望这是有道理的。

Answer 1

“服务总线是 SOA（面向服务 架构）专为 Azure 平台设计？”

绝对不！

您现在在 Web 应用程序中使用 WCF 所做的事情，您当然可以在云服务中做同样的事情，不用担心！

Azure 服务总线队列和 Azure 存储队列（在我看来）是用于解耦应用程序块/模块的机制。假设您有一个模块 A（或 Web 应用程序），它需要发送一些长时间运行的重 CPU 密集型任务以由模块 B 完成。但是，模块 B 被设计为仅在夜间打开（可用）。模块 A 可以安全地将任务消息发送到队列并忘记它。模块 B 稍后将“唤醒”并检查队列中是否有任何任务消息。将一项一项地处理任务（或并行处理，现在并不重要），并可以将结果报告给另一个队列，或其他形式的通知。

深入了解 Azure 服务总线队列，他们了解并实现了 Publish-Subscribe 模式。这意味着您可能有一个发布者（将消息发送到队列），但有多个订阅者（从队列中读取）。甚至更多 - 您可以为每个订阅者应用过滤器。

更进一步，ASB 更像是企业服务总线，或云中的 BizTalk（我不是说 它是，我说 它类似于与 BizTalk )。

总结：

在当前设置中使用 Windows Azure 云服务中的 WCF。 Azure 服务总线不是 WCF 的“替代品”。它还有另一个目的。

更新

我会说use queues when you want to *decouple* system components。解耦意味着模块 A（调用者）不依赖模块 B（执行者）的可用性。

在 WCF 服务的情况下，我们在模块 A（调用者）和模块 B (WCF) 之间有非常紧密的耦合。如果 WCF 服务不可用，则调用者会立即失败。

在您的特定情况下，如果您有 WCF 服务来处理 UI 调用，那么严重依赖 WCF 服务是可以接受的。特别是在您将 Web 应用程序中的 WCF 服务作为 UI 本身托管的情况下。

但在这种情况下，我有一个桌面应用程序（模块 A），它必须将任务发送到某个远程执行程序（模块 B），并且该任务需要可靠地发送，并且无论执行程序是否可用，我都会使用一些队列。

Answer 2

没有； WCF 和 ASB 都不能替代 SOA，因为 SOA 都不是。

SOA 意味着服务。 ASB 是消息代理和实际服务总线的最小部分。 WCF 是一个 RPC 框架。

服务是独立运行的程序，无论您使用什么软件将它们链接在一起。它们通常与队列链接在一​​起，并且它们还需要一些身份、路由或查找其他服务的能力。他们经常使用其他服务作为资源。

关于 WCF - 如果您以这种方式进行 SOA，那么您基本上是在弄乱您的架构。如果你想使用 ASB，我可以推荐 MassTransit-AzureServiceBus，它处理了很多恼人的路由逻辑、重试逻辑、进程内队列、异步调用和消息处理逻辑，而不是服务总线 Azure 服务总线没有实现。