PaaS与Reaction宣言

“Reaction宣言”文档在2013年发布，它聚焦于：如何在互联网场景中构建健壮可用的应用系统，如何在各种形式的外部访问（事件、关联调用、负载、错误异常）中保证系统的稳定性。

人们在各自不同的业务领域从事软件构建工作，总结出了一套开发设计模式，它们看起来是如此相似，遵循这些模式的应用系统更加健壮、坚韧与灵活，更适应于现代要求。然而系统需求在近几年发生了戏剧性变化，这些模式也正随之发生改变。几年前，一个大型系统由数十台服务器构成，秒级的响应时间，小时级的离线维护以及GB级的数据量，到了如今，系统将被部署到任何地方，从终端用户的移动设备到上千颗多核处理器的云端集群服务器。用户期望的响应时间变为毫秒级，要求100%在线运行时间，而数据则开始以PaaS实现与运维管理：基于Mesos+Docker+ELK的实战指南PB级衡量。之前的软件架构已不能再简单的适应于今天的需求。一套清晰的系统架构方法是必要的，这些必要的架构方面已被逐一地识别出来，宣言将其称之为“ReactionSystem”，它们是：响应（Responsive）、韧性（Resilient）、弹性（Elastic）、消息驱动（MessageDriven）。

1

响应（Responsive）

系统应尽可能地及时地响应。响应是可用性与有效性的基石，除此之外，响应意味着问题被尽早发现、及时处理。响应系统聚焦在保证快速而一致的响应时间，建立可靠的时间上限，从而交付一致的服务质量。这种一致性反过来又简化了错误处理，建立终端用户信心，并鼓励进一步互动。

2

韧性（Resilient）

系统在遭遇故障（failure）时依然要保持响应。这不仅适用于高可用、业务关键类系统，所有不具备韧性的系统在故障后都将无法提供响应。

故障特指非预期的阻碍持续服务的事件，一般来说其会阻碍当前以及随后的所有用户请求。这与错误（error）截然相反，一个错误是预期的、代码逻辑可处理的，例如在用户表单输入内容校验时引发的错误。较之故障让整个系统的处理能力下降，错误却并不是致命的。错误是常规操作的可预知部分，能被及时处理，错误之后系统能继续在相同能力水平下提供服务。故障的例子有硬件宕机、进程因重要资源耗尽而退出，程序缺陷引发内部瘫痪等。

韧性通过复制、封闭、隔离和委派来实现。故障存在于每一个组件中，组件之间的相互隔离可保证局部故障及其恢复不会影响到整体。节点的恢复被委派到另一个（外部）组件负责。高可用通过节点间的复制实现。客户端组件不参与到异常处理中。

组件在不同位置同时运行被称之为复制。它可以是在不同线程或线程池、进程、网络节点或数据中心。复制提供伸缩性，进来的负载被分发到组件的多个实例（例如一般服务的负载均衡）。复制也提供健壮性，进来的负载被克隆到多个实例并行处理（例如大数据的并行计算）。

隔离（或封闭）能被定义为在时间和空间上的解耦。在时间上的解耦，意味着发送方与接收方能拥有相互独立的生命周期，它们并不需要为了相互通信而同时存在。通过在组件间引入异步的边界，采用消息传递的通信方式实现。在空间上的解耦（定义为位置透明）意味着发送方与接收方并不需要运行在相同的进程中，而是由运营部门或者程序本身所决定的最优效率的任何地方，并可以在应用生命周期中改变。

PaaS模型与特征委派的目的在于将一个任务的执行保证交由另一个组件负责。这个组件可以执行其他工作，或随意地观察委托任务的进展情况，如果进一步动作（如故障处理或进展报告）需要的话。

3

弹性（Elastic）

系统在变化的工作负载下保持响应。ReactiveSystems能够感知外部输入请求速率的变化，通过减少与增加资源来做出反应。这意味着没有中心瓶颈、临界区的设计，对组件进行复制或分片，将输入请求分发到其上。ReactiveSystems支持预测，并可及时反应，伸缩算法建立在相关的实时性能数据指标上。他们在商业硬件和软件平台上实现性价比高的资源弹性。这种弹性意味着系统的吞吐量随着资源成比例的增加或减少而自动伸缩，从而适应外部请求的变化。

组件用于执行任务所依赖的任何东西都称为资源，它们必须按照组件需要而分配，包括CPU、主存、存储、网络带宽、任务调度、时钟、输入输出以及类似于数据库、网络文件系统等外部服务。这些资源的可靠性以及可伸缩性必须考虑，因为缺少必要资源将影响到组件某些功能的执行。

4

消息驱动（MessageDriven）

ReactiveSystems依赖于异步消息传送，以在组件之间建立起边界，从而实现松耦合、隔离、位置透明，以及提供将错误委派给消息处理的手段。明确的消息传送机制通过创建、监控消息队列，并在必要时应用背压（backpressure)使负载处理、弹性伸缩、流量控制得以实现。位置透明消息作为一种通信手段，使得故障的管理可以在一个集群或一个主机上以相同语义结构工作。非阻塞（nonblocking）通信允许接收者只在活动时消耗资源，导致系统开销更少。

背压是应对压力负载的一种反馈机制，它使系统能够优雅的响应负载，而不是突然的故障或者性能急剧下降。当压力负载达到一定程度即将无法应付时，他们会将情况反馈给上游系统，采取减少负载、重分发负载以及弹性扩容等方法规避异常。