软件弹性工程与设计

事件驱动架构是一个分布式系统，而分布式系统是天生网络不可靠。这需要在发生故障时计划进行重试，但是重试会导致重复记录，某人帐户中支付两次付款是不可原谅的。为了避免多次处理事件，我们需要应用Exactly-once语义。如果消息处理系统和消息消费者之间没有某种合作，就不可能保证完全一次处

当你你写了一个bash脚本，但是由于错误而运行一半退出了，当您修复了系统中的错误并再次运行这个脚本。但是脚本中的一半步骤会立即失败，因为它们已经作用于您的系统了。要构建弹性系统，您需要编写幂等的软件。（幂等在分布式环境同样重要，这样才能保证重试等正确实现）

断路器中的回退是通过一些预先配置的响应来替换发生的故障，从而使故障的范围受到限制并且对最终用户隐藏。然而，在现实生活中，简单的回退往往过于简单，我建议采用更强大的方法来处理故障，补偿发生的故障。 什么是断路器？

不可否认的是，在Dev（和Ops最近）领域出现的数千项创新中，讨论最多的主题之一是反应式编程。新的FW框架不断推出，例如ReactiveX（RxJava）的Java语言的实现，最近推出的带有反应式编程的Spring 5，甚至是Java 8中的lambdas和流的推出（自2014年起），很明显

在此示例中，使用spring web提供REST API访问，使用apache camel集成对数据库（内存中）的调用。 为了限制多余的端点调用或速率限制器，使用apache camel throttler，它会检查请求计数和已用时间。 试图找到一个简单的解决方案来

将负载平衡建模为约束满足问题，以生成最佳的动态路由表基于社交哈希的动态，可感知连接的路由产品使用时间超过4年 点击标题见论文

场景：在与多个支付提供商进行通信的应用程序上工作场景中，每个提供商对我们都有自己的速率限制。我们不想用任何提供商的费率限制，同时也要充分利用我们允许的限制。我们可以承受将付款请求延迟一小段时间的麻烦，因为批量付款是作为异步作业离线处理的。在平均结算日，我们会在很短的时间内执行大量付款

托马斯·里德（Thomas Reid）曾经写道：“整个一条链并不比链条中最薄弱的节点更强大。” 这对于任何具有相互依赖的链接的系统都是如此，无论是文字链还是软件应用程序中的依赖链。如果一个链接断开，负载就会崩溃。对于SaaS，PaaS，IaaS和其他服务提供商，此概念可以成就或破坏业

在Kafka的场景下毒丸是：针对Kafka主题生产推入的记录，无论尝试多少次，消费者使用都会失败。因此，毒丸可以有不同的形式： 记录已损坏（我自己从未使用Kafka遇到过此问题） 反序列化失败 主题的消费者应配置正确的反序列化器，以能够反序列化生产者

在本教程中，我们将学习如何使用  Bucket4j对Spring REST API进行速率限制。我们将探索API速率限制，了

在外部系统之一不可用的情况下进行事件重新处理是我们业务流程的重要组成部分。希望有这样一个重试机制：如果任何外部系统暂时不可用，该应用程序可以让我们重新处理消息。 卡夫卡之前在项目的早期，我们使用IBM MQ

当服务的多个实例可以调用指定的外部服务，在这些服务实例中都要定制断路策略很浪费，比如调用外部服务一段时间后进行关闭处理逻辑等。他们可以统一共享调用同一个外部服务的统计信息，这样一个调用失败以后，其他服务实例就不要再重试一遍，这是使用分布式断路器的地方。由于找不到现有解决方案，我们决定

构建微服务很容易，难点是：-找到微服务之间适当的界限-集成服务（消息传递与RPC）-错误处理（弹性）-Sociotechno社会技术的关注（团队划分界限，组织变更）  

该文介绍如何利用Spring Cloud网关将resilience4j断路器与网关后面的后端服务结合使用，方法如下： Resilience4j 

RSocket可以彻底改变分布式系统中的机器到机器通信。在以下段落中，我们将讨论云中的负载平衡问题以及我们将介绍有助于处理网络问题的可恢复性功能，尤其是在物联网系统中。

断路器是一种模式，可以防止整个架构中单个微服务的故障级联，从而确保系统具有弹性。该模式可以通过像Hystrix或Resilience4j这样的代码库实现，或者通过底层基础设施来实现，例如使用Istio。 Hystrix vs. Re