NServiceBus官方文档翻译（一）NServiceBus 概况

NServiceBus 概况

NServiceBus 被设计用来组合面向业务的服务，它并不是用来替代诸如 WCF 一类的RPC技术。

NServiceBus 不只包含通信模块，像其他成熟的SOA和DDD项目一样，它使用了多种组合的方法和技术。

本篇文章探讨了 NServiceBus 和微软相关产品的相似点和不同点。

相比 BizTalk 更接近 WCF

当人们听到“服务总线”这个名词时，一般会描绘出如上图所示的画面，像 BizTalk 一样所有的通信都经过一个中央结点。这实际上描述的是一个代理的架构设计，而不是总线的架构设计。在总线架构中，物理实体并不是必须的。在这方面，NServiceBus 相比 BizTalk 与 WCF 更相似。

没有物理的 WCF 结点可以指向到网络拓扑结构中。NServiceBus 像 WCF 一样，是基础架构的一部分，运行进程内给定的应用程序代码。

就像你可以编写承载 WCF 的宿主进程并激活它一样，NServiceBus 也是如此。NServiceBus 中的总线是一个虚拟的概念，它指的是运行在各种应用程序之间的框架对象集合。你可以把它想象成运行在你的代码中的P2P网络，如下图:

有何不同？

[就像苹果与橘子的不同。]

NServiceBus 的设计原则使得它的鲁棒性可以经受住长期的考验。事实证明，经过无数的技术更迭，NServiceBus 所基于的消息队列不光是一个明智的实现选择，更体现了其最主要的架构思想。在 NServiceBus 的字典中不存在阻塞这个词。

作为一个通用的通信技术，WCF 并不强制使用消息队列模式。相反，NServiceBus 采用这种模式，这对架构的影响是极其深远的。

当依照 WCF 所支持的传统 RPC 技术进行系统开发时，虽然可以简单直接地使系统可以工作，但 RPC 原则在本质上会对系统的可扩展性和容错性造成阻碍。在这一点上，即使是增加更多的硬件，收效也是微乎其微的。虽然 WCF 并不强制开发者沿着这条路走下去，但它也不能阻止问题的发生。NServiceBus 可以让你从一开始就避免这些问题。

单向消息传递的可扩展性

在可靠性、可用性和可扩展性中，架构应该首先关注可靠性，毕竟一个产生不可靠结果的高可用性和可扩展性的服务也没有什么价值的。消息队列一个显著的价值就是它可以应对各种错误场景。

就算错过了几分钟的消息记录，内部的消息仍然不会丢失。

学习曲线

当花了一些时间适应后，使用 NServiceBus 编写代码是相当简单的，代码将比以前更加简短，当然也更加容易进行单元测试。一个金融服务领域的架构师这样说：

虽然熟悉关于消息传递的思想需要花费数个星期，但是我们的开发人员只需要一个星期就可以完成一个发布/订阅的解决方案，这确实的证明了 NServiceBus 让编码变的多么简单。我们才刚开始 NServiceBus 的旅程，但已经因为它所能提供的而感到兴奋了。——Charlie Barker

英文原文：http://docs.particular.net/nservicebus/overview