在不同领域工作的组织机构正在独立发现构建相同软件的模式。这些系统更强大、更有弹性、更灵活，能够更好地满足现代需求。
之所以会发生这些变化，是因为近年来应用需求发生了巨大变化。仅在几年前，一个大型应用程序需要数十台服务器、数秒的响应时间、数小时的离线维护和数千兆字节的数据。如今，应用程序部署在从移动设备到运行数千个多核处理器的云计算集群等各种设备上。用户期望毫秒级的响应时间和 100% 的正常运行时间。数据的单位是 Petabytes。昨天的软件架构根本无法满足今天的需求。
我们认为需要一种连贯一致的系统架构方法，而且我们相信所有必要的方面都已得到单独认可：我们希望系统具有响应性、复原性、弹性和消息驱动性。我们称之为反应式系统。
作为反应式系统构建的系统更加灵活、松散耦合和可扩展。这使它们更易于开发和变更。它们对故障的容忍度更高，当故障发生时，它们会以优雅而非灾难的方式应对。反应式系统反应灵敏，能为用户提供有效的互动反馈。
Reactive Systems #
Responsive：如果可能，系统应及时作出反应。响应性是可用性和实用性的基石，但不仅如此，响应性还意味着可以快速发现问题并有效处理。响应式系统的重点是提供快速、一致的响应时间，建立可靠的上限，从而提供一致的服务质量。这种一致的行为反过来又简化了错误处理，建立了终端用户的信心，并鼓励了进一步的互动。
Resilient： 面对故障，系统仍能保持响应。这不仅适用于高可用性的关键任务系统，任何不具备弹性的系统在发生故障后都会反应迟钝。弹性是通过复制、遏制、隔离和授权来实现的。故障被控制在每个组件内，组件之间相互隔离，从而确保系统的部分组件可以在不影响整个系统的情况下发生故障并恢复。每个组件的恢复都委托给另一个（外部）组件，并在必要时通过复制确保高可用性。一个组件的客户端不承担处理其故障的负担。
Elastic：系统在不同的工作量下保持响应。反应型系统可以通过增加或减少分配用于服务这些输入的资源，对输入率的变化做出反应。这意味着设计不存在争用点或中心瓶颈，从而能够分片或复制组件，并在它们之间分配输入。反应式系统通过提供相关的实时性能测量，支持预测式和反应式扩展算法。它们在商品硬件和软件平台上以具有成本效益的方式实现了弹性。
Message Driven：反应式系统依靠异步消息传递来建立组件之间的边界，以确保松散耦合、隔离和位置透明。这种边界还提供了将故障作为消息委派的方法。采用显式消息传递可通过塑造和监控系统中的消息队列，并在必要时施加反向压力，实现负载管理、弹性和流量控制。将透明消息传递作为一种通信手段，可使故障管理在整个集群或单个主机内使用相同的结构和语义。无阻塞通信允许接收方仅在活动时消耗资源，从而减少系统开销。
大型系统由较小的系统组成，因此依赖于其组成部分的反应特性。这意味着，反应式系统采用的设计原则使这些特性适用于所有规模的系统，从而使它们具有可组合性。世界上最大的系统都依赖于基于这些特性的架构，每天满足数十亿人的需求。现在是时候从一开始就有意识地应用这些设计原则了，而不是每次都要重新发现它们。