原文作者：Rich Burroughs of F5

原文链接：利用混沌工程进步微服务的弹性

转载起源：NGINX 官方网站

NGINX 惟一中文官网社区 ，尽在 http://nginx.org.cn/

微服务备受服务开发和部署团队的欢送。在微服务架构下，开发人员能够应用更小、更具针对性的代码库，并且在服务部署的工夫和形式上领有更大的独立性。与单体架构相比，这些劣势很显著。

然而，世上没有收费的午餐。随着从单体架构过渡到微服务，复杂性并不会隐没，只是地位稍有转移。较小的代码库有助于更轻松地开发单个微服务，然而在生产中来操作微服务的时候复杂性会成倍的减少。

在应用微服务构建的零碎中，可能运行着更多的主机和/或容器——更多的负载均衡器、更多的防火墙规定等。您可能会依据不同的微服务将 NGINX 用于不同的目标（Web 服务、反向代理、负载平衡）。随着服务数量从数十扩大到数百甚至数千，理解零碎和预测零碎行为变得愈发艰难。此外，这些服务都通过网络互相通信，而不是通过单体架构外部的模块间调用。

咱们如何验证基于微服务的零碎不仅可能在失常条件下按设计运行，而且还可能应答环境中的意外故障或性能降落问题呢？混沌工程是一种不错的验证办法。混沌工程实际可帮忙团队更好地治理生产环境中运行的利用并进步零碎弹性。

什么是混沌工程？

咱们将混沌工程定义为三思而行、计划周密的试验，旨在发现零碎缺点。咱们常常将混沌工程比作疫苗接种，疫苗接种是将潜在的有害物质注射到体内，以防将来产生感化。在混沌工程试验中，咱们被动将“故障”注入零碎，以测试零碎的弹性。咱们采纳迷信无效的试验办法：提出假如，发展试验，而后察看是否验证了假如。

可注入零碎的故障类型包含敞开主机或删除容器、减少 CPU 负载或内存压力，以及减少网络提早或丢包等。这些只是举例说明，当然还有其余可注入的故障类型。

提出假如

混沌工程试验的第一步是提出假如。依据注入的故障，咱们会对系统可能产生的影响做出一个预期，这个就是假如。请记住，咱们的目标是测试零碎的弹性。一般来说，咱们假如零碎可能应答咱们注入的故障类型。但有时咱们会发现假如有误，这时咱们能够利用取得的信息来改善零碎的弹性。

举例来说，假如有一个无状态 HTTP 服务在 NGINX 上运行，后者将一个 REST API 裸露给了其余一些服务。该服务的一个实例同时在生产环境中的 10 台主机上运行，能够确保在以后业务负载下，不会耗尽每台主机的 CPU 资源。咱们可通过被动敞开一台主机，测试咱们的零碎是否足够强壮。

在这种状况下，咱们的假如是“零碎可能应答一台主机的故障，不会对其余服务或应用该零碎的人员产生影响。”接下来咱们就能够通过试验，来确认咱们的假如是否正确。

爆炸半径、量级和停止条件

在布局试验时要牢记三个重要概念：爆炸半径、量级和停止条件。上面咱们来具体理解一下这三个概念。

  • 爆炸半径—— 是咱们试验所用主机（或容器）的占比。这是一个十分重要的概念，即便在非生产环境中，咱们也须要最大限度缩小试验对用户的潜在影响。咱们先从较小的爆炸半径开始（比方一台主机或一个容器），而后随着对试验的理解及掌控水平越来越深，逐步减少爆炸半径。
  • 量级—— 是咱们给各个主机（或容器）施加的压力大小或故障水平。举例来说，如果咱们要测试一个 CPU 攻打对 NGINX Web 服务器的影响，咱们可能会在试验一开始多施加 20% 的 CPU 负载（量级），之后随着工夫的推移一直减少。咱们能够察看减少 CPU 负载对响应工夫等服务指标的影响，从而确定零碎在性能解体之前能够接受多大的攻打。
  • 停止条件—— 是导致咱们中断试验的条件。最好能提前晓得当零碎承受不住试验无奈持续时，会呈现哪种类型（或水平）的影响。可能是错误率或提早的减少，也可能是监控软件生成的某个警报。您能够依据须要定义停止条件，能够依据理论的试验环境而不同。

爆炸半径、量级和停止条件可能让咱们平安地进行混沌工程试验。在制订混沌工程试验打算时，务必将零碎用户始终牢记在心，防止对系统用户造成负面影响。咱们必须着眼于用户，努力提高零碎弹性并改善用户体验。

应用黑洞攻打验证依赖项

从单体架构迁徙到微服务后，复杂性加剧的体现之一是依赖项减少。单体利用中蕴含了零碎的所有业务逻辑，而迁徙到微服务后则会变成多项服务依赖共存。您的微服务还可能依赖其余内部服务，例如来自云提供商的 API，或用作基础架构一部分的 SaaS 服务。

当这些内部或外部依赖项呈现故障时会产生什么？您在代码中施行的保护措施是否缓解这些故障？超时和重试等逻辑是否针对零碎在生产环境中的理论运行形式进行了调优？

黑洞攻打是测试您是否解决好故障依赖项的好办法。黑洞攻打会拦挡主机或容器对特定主机名、IP 地址和/或端口的拜访，模仿资源不可用时会产生的情景。这种办法可能无效模仿网络或防火墙相干中断以及网络分区。

在存在内部依赖项的状况下，假如咱们正在运行一个应用 Twilio API 向客户发送短消息的服务。咱们晓得，咱们与 Twilio 的通信随时都有可能中断，因而咱们将微服务设计为读取队列中的音讯，并且只在这些音讯通过 Twilio API 胜利发送到 Twilio 后才将它们从队列中删除。

如果 Twilio API 不可用，音讯将在咱们这一端排队等待（比方应用 Kafka 或 ActiveMQ 等音讯总线），当与 Twilio 的通信一旦复原，它们将被立刻发送。听起来很不错吧？

但在理论测试之前，咱们如何晓得在与 Twilio 的网络连接中断时，服务的理论体现如何呢？咱们如何晓得，它在生产环境中的理论运行形式是否同咱们在白板上设计的一样？

咱们可通过运行黑洞攻打，拦挡该服务拜访 Twilio API，察看它的理论体现。这能够解答咱们的很多问题，例如：音讯队列是否正确？咱们设定的超时工夫是否正当？随着音讯队列的增长，服务是否持续失常运行？咱们不再查看代码和推断这些问题的答案，而是理论注入故障，察看会产生什么。

在这种状况下，咱们能够假如“网络连接断开时音讯队列正确，并且在网络复原后消息传递失常”。咱们可通过运行黑洞攻打，测验这个假如是否正确。如果最终证实假如有误，咱们可能会获取一些有用的信息，帮忙咱们进步零碎弹性。

黑洞攻打也能够用来验证外部依赖项产生故障时会呈现什么情况，以及发现暗藏的依赖项。暗藏依赖项是个非常常见的问题，最好能在它们引发事件之前发现它们。在服务中增加新的依赖项时会引入暗藏依赖项，但这些依赖项在组织内并无相干记录或传播。

举例来说：服务 A 更新后，当初依赖于服务 B，但运行服务 B 的团队并不知道这一点。他们停止服务 B 以进行保护，忽然服务 A 意外中断。如果服务 A 是要害服务（例如登录服务），或者是反对客户购买商品的服务，那么这种中断的代价将十分昂扬。对于团队来说，这种问题并不常见，因为服务依赖项的映射和可视化通常比拟艰难。

通过定期对服务运行黑洞攻打，可裸露这些暗藏的依赖项，从而让相干团队晓得它们的存在。如能分明地理解内部依赖项，您还能够取得其余益处。比方某项服务在其依赖的服务无法访问时会如何响应？超时和重试配置是否正确？基于微服务的分布式系统如何解决网络分区？这些问题都可通过黑洞攻打予以解答。

结语

咱们定义了混沌工程，并介绍了混沌工程如何帮忙构建更具弹性的微服务架构。咱们还探讨了如何利用黑洞攻打来理解服务如何响应内部和外部依赖项的故障。

黑洞攻打能够很好地帮忙咱们理解到服务在应答依赖项故障时的弹性，然而在微服务环境中，还有其余相干试验能够实用。比方敞开主机、减少网络提早或丢包、毁坏 DNS 解析以及减少 CPU 或内存压力都是不错的微服务弹性测试方法。

想要通过 NGINX Plus 试用混沌工程？立刻点击下载 30 天收费试用版，或与咱们分割以探讨您的用例。

NGINX 惟一中文官网社区 ，尽在 http://nginx.org.cn/

更多 NGINX 相干的技术干货、互动问答、系列课程、流动资源：

开源社区官网：https://www.nginx.org.cn/

微信公众号：https://mp.weixin.qq.com/s/XVE5yvDbmJtpV2alsIFwJg