科技推荐：现代系统必须能够处理混乱以避免停机

科技改变生活，也在一定的程度上科改善生活！那么现如今生活条件越来越好以后大家更多的关注点都不同，但是近来有很大一部分了却同时关注到了现代系统必须能够处理混乱以幸免停机的消息！

尽管我们尽最大努力幸免它们，但IT事件是这项工作不可幸免的一部分 - 并且试图保持领先于业务影响的停机时间只会变得更加棘手。今天的系统密切耦合，越来越复杂，更多的移动部件带来更多出错的机会。

这就是为什么越来越多的组织转向微服务以提高服务可用性和更好地恢复故障的原因之一。虽然这些是破坏单片应用程序的重要前提，但它们也可能增加失败的风险 - 除非明确考虑到弹性设计。

准备失败

鉴于分布式系统固有的混乱特性，应该开辟服务，不仅要预测故障，还要在发生故障时自动恢复。这意味着定期发生故障，以确保您的系统能够处理混乱而不会中断对最终客户的服务。为了实现这一目标，您需要能够在测试环境中模拟类似生产的流量。

固然，在更改生产之前测试弹性是个好主意。如果您不这样做，您将无法验证您的服务是否支持平均和峰值负载。事实上，最安全的选择是确保您的产品能够处理峰值量的两倍而无需扩大规模。

在弹性测试方面，正确的工具不应过于关注请求的处理方式，只要他们最终能够产生正确的影响。请记住，在某些情况下，输入服务可能无法将请求移交给系统的其余部分，但不会报告失败。通过确保实际上正在进行端到端验证，不要冒险在监控雷达下飞行的问题。

下一步

在了解服务如何在负载下运行之后，是时候开始介绍故障事件了。与所有软件测试一样，最好使用自动化工具，以便您轻松快速地重现场景，以便您可以协调影响不同基础架构技术的复杂事件。除了验证修复和服务更改的能力之外，这还同意 您在任何环境和计划中运行随机故障方案。

故意义的失败事件在很大程度上取决于您的服务布局，您可以通过询问与您相关的特定问题来制定它们。例如，当数据库在一段时间内无法访问时，使用前端的人员会受到什么影响?这些用户是否仍可以在Web UI中导航?他们是否仍然可以对其信息进行更新，并且当数据库再次可以访问时，是否可以正确处理这些更新?

如果您运行多个微服务，则可以询问是否存在全局中断，如果任何单个服务崩溃。或者，如果您有一个缓冲服务之间通信的排队机制，当消费者服务(或服务)停止工作时会发生什么?用户是否仍然可以使用您的应用程序?并且考虑到平均负载，在队列溢出并开始丢失消息之前你有多长时间?

一旦定义了有关基础架构的几个关键问题，就可以开始列出模拟这些失败的不同方法。停止特定服务或数据库服务器可能就足够了。您可能希翼阻挠服务的主线程来模拟死锁，而其容器仍然响应并运行。您可能决定在网络中引入规则以阻挠特定服务之间的流量。在Linux环境中，您可以使用“tc”等工具来模拟网络情况，如高延迟，丢失，损坏或重复的数据包。

通过演练学习和提高

创建故障场景最有价值的方面之一是它们可以暴露系统可能失败的所有潜在方式，从而为自我修复逻辑奠定了基础。您的团队将完成手动恢复服务的步骤 - 顺便说一下，确保他们能够在SLA中执行此操作。可以使用此恢复过程的自动化，但与此同时，您可以轻松了解您的团队已经完成了使服务重回正轨的过程。通过使故障情景随机且有规律并且不公开运行的完整细节，您还可以包括对演习的发现和诊断 - 毕竟这是SLA的关键部分。

混沌工程的核心是将系统的复杂性作为给定，通过模拟新的和古怪的条件来测试它，并观察系统如何响应。这是数据工程团队需要重新设计和重新配置系统以实现更高的弹性。学习新的实用的东西有很多机会。例如，您可能会发现下游服务发生更改时服务未获得更新的实例，或者完全缺少监视的区域。有一些令人兴奋的方法可以让您的产品更具弹性和稳健性!