Enable javascript in your browser for better experience. Need to know to enable it? Go here.

Reactive architectures

本页面中的信息并不完全以您的首选语言展示,我们正在完善其他语言版本。想要以您的首选语言了解相关信息,可以点击这里下载PDF。
更新于 : Nov 07, 2016
不在本期内容中
这一条目不在当前版本的技术雷达中。如果它出现在最近几期中,那么它很有可能仍然具有相关参考价值。如果这一条目出现在更早的雷达中,那么它很有可能已经不再具有相关性,我们的评估将不再适用于当下。很遗憾我们没有足够的带宽来持续评估以往的雷达内容。 了解更多
Nov 2016
试验 ?

We see continued adoption and success of reactive architectures , with reactive language extensions and reactive frameworks being very popular (we added several such blips in this edition of the Radar). User interfaces, in particular, benefit greatly from a reactive style of programming. Our caveats last time still hold true: Architectures based on asynchronous message passing introduce complexity and make the overall system harder to understand—it's no longer possible to simply read the program code and understand what the system does. We recommend assessing the performance and scalability needs of your system before committing to this architectural style.

Apr 2016
试验 ?
Nov 2015
评估 ?

The techniques of functional reactive programming have steadily gained in popularity over recent years, and we’re seeing increased interest in extending this concept to distributed systems architectures. Partly inspired by “The Reactive Manifesto”, these reactive architectures are based on a one-way, asynchronous flow of immutable events through a network of independent processes (perhaps implemented as microservices). In the right setting, these systems are scalable and resilient and decrease the coupling between individual processing units. However, architectures based entirely on asynchronous message passing introduce complexity and often rely on proprietary frameworks. We recommend assessing the performance and scalability needs of your system before committing to this as a default architectural style.

May 2015
评估 ?
发布于 : May 05, 2015

下载 PDF

 

English | Español | Português | 中文

订阅技术雷达简报

 

立即订阅

查看存档并阅读往期内容