在不同的领域深耕的各个组织都独立地发现了一种如出一辙的软件构建模式。这些系统更加的健壮、更加弹性、更加灵活并能够更好地满足现代化的需求。
这些变化方兴未艾，因为近几年应用程序需求已经发生了显著地变化。仅在几年以前，一个大型应用程序拥有数十台服务器、数秒的响应时间、数小时的维护时间以及GB级别的数据。而现在的应用程序被部署到了所有形态上，从移动设备到运行着数以千计的多核心处理器的云端集群。用户期望毫秒级的响应时间以及100%的正常运行时间。数据则是PB级别的。以前的软件架构已经根本无法满足现代化的需求了。
我们相信需要一种同调的系统架构方法，而且我们相信所有必要的方面都已经被独立地认识到了：我们需要具有即时响应性、弹性、适应性以及消息驱动的系统。我们称之为反应式系统。
被构建为反应式的系统更加的灵活、松散耦合并是可伸缩的。这使得他们可以更加容易地被开发以及适应改变。他们对系统的失败更加地包容，而当失败着实发生时，他们将用优雅而不是灾难性的方式来应对。反应式系统具有极高的即时响应性，给予用户有效的交互反馈。
反应式系统具有：
- 即时响应性：只要有可能，系统就会及时地做出响应。响应能力是可用性和实用性的基石，但是更加重要的是，响应能力意味着可以快速地检测到问题并且行之有效地解决它。即时响应的系统专注于提供快速而一致的响应时间，确立可靠的上界，从而提供一致地服务质量。这种一致的行为反过来简化了错误处理、建立了最终用户的信任、并鼓励他们进行进一步的交互。
- 弹性：系统在出现失败时依然保持即时响应性。这不仅适用于高可用的、任务关键型系统 —— 任何不具备弹性的系统都将会在失败之后丢失即时响应性。弹性是通过复制、遏制、隔离以及委派来实现的。失败被包含在了每个组件内部，和其他组件相互隔离，从而确保了系统的各个部分能够在不危及整个系统的情况下失败和恢复。每个组件的恢复都被委派给了另一个外部的组件，并在必要时通过复制来实现了高可用。因此组件的客户端也就没有了处理组件失败的负担。
- 适应性：系统在变化的工作负载之下依保持着即时响应性。反应式系统可以通过增加或者减少分配给服务于输入负载的资源，来响应输入负载的速率的变化。这意味着设计上并没有争用点和中心化的瓶颈，从而可以分片或者复制组件，并在他们之间分发输入的负载能力。通过提供相关的实时性能测量信息，反应式系统都支持预测式以及反应式伸缩算法。他们在日常的硬件以及软件平台上实现了成本高效的适应性。
- 消息驱动：反应式系统依赖异步的消息传递来确立组件之间的边界，以确保松散耦合、隔离以及位置透明性。这一边界还提供了将失败作为消息委派出去的手段。使用显式的消息传递，通过在系统中形成并监视消息流队列，并在必要的时候应用回压，从而实现了负载管理、适应性以及流控制。使用位置透明性的消息传递作为通信的手段，使得跨集群或者在单个主机中使用相同的构造和语义管理失败成为了可能。非阻塞的通信使得接收者可以只在活动的时候消耗资源，从而带来更少的系统开销。
大型系统是由较小的系统所构成的，因此依赖于他们的构成部分的反应式特性。这意味着，反应式系统应用了一些设计原则，因此这些属性也适用于所有级别的伸缩，使得他们可以组合。世界上最大型的系统都依赖于基于这些属性的架构，并每日服务于数十亿的人们的需求。现在是时候从一开始就有意识地应用这些设计原则，而不是每次都重新发现他们了。