作为一名用户，如果你在新推出的、令人眼花缭乱的酒店预订网站上请求一个报价，却需要很长时间才能做出回应，你会有何感受?相信我，并不是所有的罪魁祸首都是网络或基础设施-----应用程序的体系结构也与它有很大的关系。也许领域模型对底层资源的调用太多了，比如数据库或消息服务器，这些资源已经抑制了应用程序的吞吐量。
我们都希望我们的应用程序能够在一个可接受的时间段内响应用户的请求。而这个事件我们称之为latency（延迟），它更正式地定义为：您所请求的请求和从服务器返回的响应之间的时间周期。如果我们将延迟绑定在一个用户可接受的范围之内，那么你就实现了软件系统的responsiveness（响应性）。响应性是你的模型reactive的主要标准。但如何处理失败呢?一个卡住的系统也是不具有响应的。解决这个问题的关键是围绕故障设计您的系统，您将在1.6.2中看到更多这方面的内容。
响应式模型的主要特点是什么呢？？表1.4总结了主要的标准
表1.4
| 标准 | 介绍 |
|---|---|
| 对用户的交互具可响应 | 否则，没人会用你的系统 |
| 弹性的 | 这意味着可以回应失败的情况。如果您的系统在失败的情况下陷入了一个不确定的状态，那么您就无法交付一个稳定的模型。它必须通过重新启动部分应用程序模型或者向用户提供关于下一步行动的适当反馈。 |
| 伸缩性 | 这意味着要对不同的负载进行响应。系统可以面对负载峰值，即使在高负载的情况下，也应该能够保持延迟在一定的范围。 |
| 消息驱动 | 为了保持响应性和弹性，系统必须松散耦合，并通过使用异步消息传递来最小化阻塞 |