Reactive宣言的思考

这篇博文是关于著名的Rective宣言的再思考,或者可以认为是简单总结拓展。

Reactive反应式编程是软件发展的一个新趋势,在过去几年中聚集了很多的技术鉴赏家的热情。按照Reactice宣言,有下面Reactvie之道:

1. 反应到事件react to events – 事件驱动event-driven的自然特性激活了其随后的各种特性。

2.反应到加载react to load – 通过避免金多线程对共享资源的竞争锁争夺实现可扩展性。

2.反应到失败react to failure – 弹性系统能够在任何级别满血复活。

3.反应到用户react to users – 无论负载多高,都有傲人的响应时间。

事件驱动
事件驱动的应用程序由发送和接收事件进行通信的组件组成。事件是异步传递,通常使用一个基于推送的通信模型,事件不会发生阻塞。一个关键目标是要能够有效地利用系统资源,不能占用不必要的资源,最大限度地提高资源共享。

反应的应用是建立在分布式架构中,消息传递提供了节点间通信层和组件位置透明性。这也使部件和子系统之间的接口是基于松耦合的设计,从而使系统更容易随时间的变化。

系统设计依赖于共享可变状态,数据访问和操作是通过使用并发控制机制,以避免数据完整性发生问题。并发控制机制是并行系统某种限制版。 Amdahl定律制定明确降低程序代码的并行会限制系统的可扩展性。避免共享可变状态允许更高的并行度,从而达到更高程度的可扩展性和资源共享(如数据库资源等)。


Scala可扩展性
系统架构需要小心地设计成横向扩展或者向上扩展,以便能够利用节点的并行的硬件趋势(CPU和nb的数目增加。nb是一个CPU内的物理和逻辑核心)和系统级并行(节点的数目)。垂直和水平缩放应该是双向的,所以弹性系统也能够在双向扩展,从而优化运营成本。

弹性构建的关键是通过由消息传递提供的分布式架构和节点到节点的通信机制,允许子系统进行配置,无需修改代码在同一个节点上或在不同的节点上运行(也就是位置透明性实现)。


弹性Resilient
一个弹性系统在系统的一个或多个部分发生故障的情况下将继续发挥作用,包括不可预测的的条件(如意外的负载)。该系统需要精心设计,包含明确和安全的封装故障,防止故障进一步升级和级联失控。

响应Responsive
响应由韦氏定义为“快速回应或作出适当的反应。”
应用程序使用可观察的模型,事件流和有态客户端。
当状态变化,观察的模型让其他系统接收事件。
..


评论
如果你在过去几年能积极了解软件的发展趋势,那么该宣言说的想法似乎很熟悉。这是因为宣言总结了软件开发社区在建设网络规模的系统见解。

很多教训源于分布式系统进行集中存储状态。在分布式系统中的一致性模型权衡已经被CAP定理解释。CAP的见解让开发人员在一致性、可用性和分区容忍性之间进行权衡考虑。近年来宽松的一致性模型已经得到普及,特别是NoSQL数据库不同的品种。

而相对数据库,应用程序的一致性模型对系统的可伸缩性和可用性同样产生重大影响,宣言更明确地解决了这一问题。一致性模型应该是一个纵向方面,应该在系统的所有的层面都必须被考虑设计。

事件驱动是一种广泛使用在编程中的术语,有许多不同的含义,并有多种变化。可以用不同的异步通信方法来实现。在反应宣言“异步通信”是使用消息传递,如在消息系统或Actor模型,而不是异步函数或异步方法调用。

反应宣言中采用并结合的思想从CAP理论, NoSQL,事件驱动的多种架构。它总结了开发社区在建设网络规模应用的经验教训。该宣言有很大的意义,但是该宣言可能比较晦涩。如果没有在可扩展性问题方面拥有丰富经验的开发人员可能难以理解,这样就可能错过或误解这一伟大思想。

相关参考:
使用Akka实现Reactive DDD