软件弹性工程与设计

这是一个基于Figma 工程团队的博客文章构建的简单速率限制器。有关实际算法的

这是 T20 世界杯赛季，我们想为我们的用户建立一个测验系统，用于短期预言预测。在比赛开始时要求用户预测场景，最后，主持人将提交所有预测场景中实际发生的情况。评分将根据谁回答正确以及回答所花费的时间进行。鉴于我们系统的规模，我们估计可能有 5 万人参与测验。所以我们的目标是为100

您的公司拥有一支才华横溢的站点可靠性工程师 (SRE) 团队来创建可扩展且高度可靠的软件系统，以最大限度地减少错误的影响。他们将处理客户问题，花时间随叫随到，并通过人工干预提供帮助。在与客户端错误作斗争时，它们是您的前线防御系统。但重要的是要记住，无论您的 SRE 多么出色，在开发过

我们生活在一个不完美的世界里，失败是不可避免的。我们依赖的系统迟早会失败。我们无法采取任何措施来阻止它，但我们有能力减轻级联故障。我们只需要在我们的工具箱中添加一些工具。 超时必须了解任何资源池都可能耗尽，我们的责任是防止这种情况发生

在分布式系统领域，回退策略是最难应对的挑战之一，对于时间敏感的服务来说尤其如此。更糟糕的是，不良的回退策略可能需要很长时间（甚至数年）才能产生影响，而优质策略与不良策略之间的差异并不明显。本文将重点讲述回退策略如何导致更多问题，且问题的出现速度比修复速度更快。我们将提供一些示例，说明回退策略

顾名思义，Sentinel是微服务的强大后卫。它提供了流量控制，并发限制，电路中断和自适应系统保护等功能，以确保其可靠性。这是阿里巴巴集团积极维护的开

软件架构师的当务之急之一是保护API和服务端点免受有害事件（例如拒绝服务攻击，级联故障或资源过度使用）的危害。速率限制是一种用于控制使用API​​或服务的速率的技术，它反过来可以保护您免受可能导致服务突然停止的这些事件的侵害。在分布式系统中，没有比集中配置和管理使用者与API交互的速率更好的

在这个微服务世界中，我们总是强调通过 API/服务网关层传递任何 HTTP 请求，该层连接多个微服务，并有一个最低要求，即记录每个服务的所有请求和响应以获得更清晰的可见性。我们可以考虑在以下场景中编写我们的反向代理层。 1.假设具有API服务像“PHP”或“Pytho

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

使用resilience4j的库和Spring Boot设计高弹性的微服务。微服务本质上是分布式的。当您使用分布式系统时，请始终记住这一第一法则- 网络中可能发生任何事情。处理任何此类意外故障可能很难解决。故障可能是任何东西-应用程序，硬件或网络等。系统从故障中恢复并保持正常

系统弹性是组织、硬件和软件系统减轻故障或损失的严重性和可能性、适应不断变化的条件并在事后做出适当响应的能力。在这篇文章中，我将介绍以下系统弹性模式： 自适应响应 卓越的监控 协调弹性 异构系统 动态重新定位 必要的可用性

重试功能是 Spring Batch 模块的一部分。从 2.2.0 开始，此功能从 Spring Batch 中提取出来并作为一个单独的模块进行维护。要在 Spring 应用程序中启用此功能，请将此依赖项包含到您的 maven pom.xml 中。

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

随着我们逐渐利用云计算，这变得越来越具有挑战性。由于各个组件都面临着被称为“灰色失败”的新挑战，因此我们创建强大解决方案的方法仍然面临压力 。在出现灰色故障时，服务器或网络的一部分不会快速失败，而是开始缓慢运行。慢跑比快跑更糟。慢速组件有时以低于正常速度1％的速度运行，可能很健康，可以说“我

本文介绍了fail-fast 原理、它的优点、如何应用它以及我的个人经验。尽管看起来违反直觉，但快速失败会使您的应用程序更加健壮。使用快速失败原则，错误和故障会更快出现，这使得它们更容易修复。如果本文启发您在代码库中应用快速失败原则，您可以立即开始使用它。即使您将该原则应用于单个文件

大约一年前，我们GitHub迁移了一个旧的速率限制器，以提供更多的流量并适应更具弹性的平台体系结构。我们采用了带有客户端分片的复制Redis后端。最终，效果很好，但是我们在此过程中吸取了一些教训。 Memcached问题<