软件弹性工程与设计

当使用微服务架构来构建我们的应用程序时，在服务中最终会得到一个非常复杂的依赖树。如果依赖关系树中的服务遇到导致其开始缓慢响应的问题，则最终会形成一系列问题，这些问题会使依赖关系树级联起来。随着越来越多的请求进入应用程序，等待慢速服务响应可能会消耗越来越多的资源。更糟糕的是，对慢速服务施加的额

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

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

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

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

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

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

现在流行的是Spring Cloud基于NetFlix解决方案提供的

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

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

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

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

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

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

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

我们需要几乎瞬时的资源弹性，而不必预先分配资源或支付超出需要的资源。我们还希望将所有运行最佳实践融入运行时，以免我们担心代码运行得几乎是低级自动化，低操作性和低健壮性，这是近十年来云计算最基本的两项追求，无服务器是实现这些机遇的最接近的。 然而，当