微服务是当今的热门话题。关于它们的文章很多，并且许多人和公司已经开始建造它们。有人说这个概念并不新鲜，我还没有找到一个明确的、被广泛接受的微服务定义。我喜欢的是在 Jonas Bonér 写的一本书中发现的（链接）：
“基于微服务的架构是一个简单的概念：它主张从一组小型、独立的 反应式微服务 服务创建一个系统，每个服务都拥有自己的数据，并且独立隔离、可扩展且具有故障恢复能力。
我并不是说这个定义是完美的
但是我喜欢它，因为它注重可扩展性和弹性。我最近构 加密货币数据 建的几个服务必须能够处理高负载。这意味着该服务必须具有可扩展性和弹性。我们使用 apache camel（Fuse）作为框架在 Openshift 平台上构建 API。由于无状 反应式微服务 态的实现和 Openshift 轻松提升容器的能力，它可以完美地扩展。然而，高负载下的可扩展性和响应性问题让我寻找构建类似界面的其他方法。在进行研究时，我发现了“反应式微服务”和“反应式编程”这两个术语。
响应式编程
什么是反应式编程？我找到了一个不错的页面，按照我的喜好解释了“反应式编程”：链接
简而言之，它指出：
“反应式编程是使用异步数据流进行的编程。”
这并不是什么新鲜事，可以通过 JMS 中的 Hub and Spoke 系统来实现。您订阅一个队列，一旦有消息放入队列，您就会“做出反应”。然而，反应式编程远不止于此。它将一切事物 克莉调查了国民革命联盟领导人的第三次 视为数据流。从调用数据库到从属性文件中简单地检索值。一切都以数据流的形式进行处理。这种编程方式有其优点和缺点。在这篇文章中我试图让你了解为什么它对微服务有益。
当我寻找反应式编程的良好定义/解释时
我遇到的第一个热门话题就是反应式宣言。尽管我 西班牙比特币数据库 发现它更针对反应式系统，但当第一次研究“反应式”时，它是一个很好的起点，因为宣言简化了概念，从而大大简化了解释。
反应性宣言
根据反应宣言，反应系统具有响应性、弹性、消息驱动和有弹性。反应式服务本质上是一种反应式系统，它必须遵循相同的原则。