标签：
自主性和松散耦合在设计时和运行时都是没有的事，任何技术都可以给你。
面向服务的架构（SOA）和事件驱动的体系结构提供了依据识别使用nservicebus。
战略领域驱动设计有助于弥合业务/IT鸿沟和驱动业务事件选择使用nservicebus发表。
在本文中，Udi Dahan解释经典的Web服务思想，在下面的用户界面层和业务逻辑的地方服务上的缺点。相反，他描述了一种方法，跨越应用程序的所有层，勾勒出松与紧耦合固有的线。最后，UDI说明这些垂直服务之间的协作，利用事件以带来灵活高效的业务流程。
一个与分布式系统的建立现在的问题是他们是脆弱的。作为系统的一部分的速度慢了下来，效果往往会影响整个系统的瘫痪。nservicebus的主要设计目标是消除，指导开发人员编写，在生产环境中的健壮的代码。这可以防止数据丢失故障的情况下的鲁棒性。
使nservicebus有效使用，你需要了解分布式系统架构，它的目的是支持。换句话说，如果你设计你的系统，根据下面所列的原则，nservicebus会使你的生活更方便。另一方面，如果你不遵循这些原则，可能会让它更难nservicebus。
在nservicebus扩展功能让你调整自己的行为以满足您的特定需要，但他们是分开记录。
通信模式，使鲁棒性是单向的信息传递，也被称为“消防和忘记”。这是在更详细的讨论。
因为它可以跨网络和另一台机器沟通的时间是未知的，无限的，通信是基于存储转发模式，如下图所示。
在这个模型中，当客户端进程调用一个API将消息发送到服务器进程，该API将控制返回给调用线程发送消息前。在这一点上，整个网络的信息传递成为信息技术的责任。可能有各种各样的通信干扰，服务器可能会下降，或防火墙可能减缓转移。同时，尽管该消息可能已达到目标机，目标进程目前可能下降。
而这一切是怎么回事，客户端进程是不经意。像线程关键资源（和它的内存分配）不持有等待调用完成。这可以防止客户端进程失去稳定性由于具有多线程和所有内存用完后等待来自其它机器或过程的反应。
请求/响应的一般规律，这是更准确地描述为同步远程过程调用，是不同的处理一个消息时使用。而不是让调用线程的堆栈管理的通信交互的状态，它是明确的。从网络的角度来看，请求/响应就只不过是两个单向的相互作用，如下图所示。
这是特别重要的通信服务器背后有问题的网络连接客户现在对服务器的稳定性影响不大。如果客户端崩溃的时间，它发送请求到服务器发送一个响应，服务器没有资源捆绑起来等待几分钟直到连接超时。
当使用持久消息的演唱会，全系统的鲁棒性，更增加。
持久消息不同于常规的存储和转发消息，消息保存到本地磁盘后再发送。这意味着，如果在调用线程控制返回，进程崩溃和发送的消息不会丢失。在服务器到服务器的情况下，一个服务器可以完成本地事务但可能崩溃后，单向持久消息更容易产生不可靠甚至在面对积木全面强大的系统。
不同的沟通方式是一对多的通信。
在这种方式下，消息的发送者往往不知道那些希望接收消息的细节。这种额外的松散耦合是在用户明确地选择接收消息的成本，如下图所示。
用户需要知道哪些端点负责某个消息。这些信息通常是由可作为合同的一部分，指定端点用户发送请求。为订阅消息的一部分，用户通过其 “返回地址”，终点在它想要接收的消息。
记住，出版商可以选择存储有关用户感兴趣的是，在一个高度可用的方式的信息。这允许多个进程在多台机器上发布消息给所有用户，不管收到订阅消息或不。
用户不需要订阅自己。通过对返回地址模式的使用，一个中央配置站可以发送多条短信的每一个出版商，指定哪些用户终端订阅的消息。
另一个选项，可用于使自己显示为一个单一的逻辑用户的多个物理用户。这使得有可能不在出版社或任何一个用户的部分的任何显式协调负载平衡的多个物理用户之间的消息处理。所有需要的是所有用户的订阅消息指定相同的返回地址。
发布一个消息包括消息到达终点以前订阅该消息类型。
已公布的经常代表事件或事物发生的信息；例如，取消订单，产品脱销，运输延迟。有时，一个事件的原因是前一个命令消息的处理，例如取消订单。出版商不需要发布一个消息处理命令消息虽然是最简单的解决方案的一部分。
由于许多命令消息可以在很短的时间内收到，发布消息的每一个命令消息的所有用户将输入的荷载，因此，是不是最佳的解决方案。较好的解决了出版商卷起所有的变化发生在一个给定的时间为一个单一的发布消息。适当的时期内依赖于发布服务器和数据的新鲜度其承诺的服务水平协议。例如，在金融领域的出版周期是10ms，而在消费者的电子商务业务，一分钟是可以接受的。
另一个优点是发布信息的一个计时器，活动可以卸载从终端/服务器处理命令消息，有效地扩大了更多的服务器。
许多系统为用户提供搜索，过滤和排序数据的能力。而单向的信息传递和发布/订阅了这些功能的实现的核心部件，它们结合的方式是不是像一个普通的客户端-服务器的请求/响应。
在常规的客户服务器开发，服务器向客户端提供所有的CRUD（创建，读取，更新，删除）的能力。然而，当用户看到的数据不经常需要更新到第二（因为他们往往看同一屏幕几秒到几分钟）。因此，检索数据从同一个表中，用于高度一致的事务处理带来了竞争，导致较差的性能在高负载下的所有的CRUD操作。
一个解决方案，避免了这个问题，将命令和查询在系统级，甚至以上，客户端和服务器端。在这个解决方案中有两个“服务”，跨客户端和服务器：一个负责命令（创建，更新，删除），并负责查询其他（阅读）。这些服务只能通过消息进行通信；一个无法访问的其他数据库，如下图所示：
命令服务发布信息的变化数据，该查询服务订阅。当查询服务接收到这样的通知，它保存在其自己的数据存储，可能有不同的模式的数据（如星型模式的查询优化）。查询服务也将所有内存中的数据如果数据是足够小。
标签：
原文地址：http://www.cnblogs.com/powerxu/p/4294265.html
