通过混沌工程，我们为开发人员和基础设施人员提供了准备实时生产的机会，现在他们将成为经验丰富的玩家，可以毫无顾虑地处理生产错误。这是所有组织都需要采用的未来思维方式，因为我们正在快速发展，每天都有新框架，每个组织都在创建工具以摆脱旧系统，它在扩展性，弹性方面为组织提供了足够的灵活性一方面，它使架构复杂化，因此如果没有混沌工程，您将无法持续。
微服务架构本质上是分布式的，它由可以独立扩展和部署的小型服务套件组成。
如果我们推导出上面的陈述，我们会发现三件重要的事情。
由于微服务是分布式的，它是通过网络进行通信的，而网络是不可靠的，那么你的微服务怎么会可靠呢？
通过网络，微服务相互通信，因此它们相互依赖，因此如果它们的依赖服务失败，它们可能会失败。
微服务在基础设施上进行扩展和部署，因此如果基础设施出现故障，您的微服务也会失败。
这些观点证明了“失败是不可避免的，我们必须为此做好准备”的说法。
但问题是我们如何准备呢？
答案是混沌工程。
什么是混沌工程
混沌工程是一种可以衡量架构弹性的技术。通过混沌工程，我们将注入故障（增加负载，注入延迟），然后我们将检查服务如何反应，服务的弹性如何？我们称之为 FIT（故障注入测试）如果服务没有弹性，我们将识别它并使服务具有弹性，以便它可以处理生产中的实时错误。
混沌工程注意点
尽管混沌工程是一个引人注目的想法，它可以让您的开发人员准备好处理实时生产事件，但混沌工程不是免费的午餐，它需要适当的 DevOps 管道、自动扩展架构、弹性系统才能使其成功。
因此，在采用它之前，您需要在基础设施、DevOps 和构建可扩展架构上花钱。
以下是在您的系统中采用混沌工程时需要考虑的一些建议。
- 你必须有一个精心设计的 DevOps 管道，你可以在其中测试混沌工程大约 1% 的负载流到混沌工程路径来测试你的系统如何反应。
- 您需要拥有精心设计的容器编排技术，您可以在其中管理容器、自动缩放、故障转移、网络规则等
- 混沌工程适用于复杂的业务系统，如果您的系统足够简单，请不要采用混沌工程，它会增加您的业务开销和成本。
- 采用混沌工程后，您必须执行 Gameday 概念，即在生产中进行混沌测试的那一天，并且必须定期进行。
- 您需要拥有自动化平台并实施混沌质量门，它可以执行所有类型的故障测试。如果您的团队必须手动完成，那么从长远来看，团队将失去兴趣并且失控。
- 如果您在混沌工程期间发现生产中出现新故障，您需要终止测试并将其重新路由到原始路由，这样用户就不会遇到任何错误。
- 如果在混沌测试中发现新错误，团队必须对其进行 RCA 并尝试解决它，然后找到一种方法使其自动化并将其同化在混沌质量门中。
- 组织必须有一个混沌检查表，每个服务都需要通过该检查表，然后才能将其提升到生产环境。
- 如果您的团队不够熟练，生产中的混沌工程是有风险的，最好从较低的环境开始，一旦团队掌握了技能，然后尝试在生产中进行。
- 在生产中测试时尽量减少爆炸半径很重要，不必要的给客户带来痛苦并不是尝试混沌的好方法，因此混沌工程团队必须确保保持最小爆炸半径的体验并退回到原始路线如果出现问题。
工具
- 网络
由于微服务通过网络进行通信，因此我们可能会遇到许多类型的故障，例如网络不稳定、网络负载、DDoS 攻击。通话中的延迟等。Hystrix 是一个合适的工具。通过 hystrix，我们可以确保如果一个服务关闭而不是重击该服务，我们可以采用默认路由，并给该服务时间恢复。
我们可以在生产中使用 Netflix FIT 框架时引入负载/拥塞或网络延迟来检查服务的反应，请注意，在 FIT 中，我们必须有一个单独的 Canary 路径进行 FIT 测试，我们可以在其中进行大约 1% 的实际测试——时间用户负载，如果服务没有弹性，我们将在那里终止测试并重新路由到真实路径，以便用户不会遇到任何错误。
- 依赖
微服务相互调用以实现业务能力，因此微服务依赖是一个主要因素，我们可以预测多种类型的故障，例如，依赖的服务不可用，服务未处于接收请求的状态，一个服务失败作为级联影响整个微服务服务链失败和崩溃、分布式缓存不可用、缓存内存崩溃、单点故障。
Hystrix 是一个 Netflix OSS 工具，我们可以通过它在服务中实现断路器模式，所以如果一个依赖的服务因多个请求而失败，最好不要调用它并采用默认路由，这样整个微服务调用链，而不是中断和用户体验不会停止。
另一种弹性技术是识别作为业务核心的关键服务，并确保如果其他服务失败，这些服务可以运行，并且可以为用户提供最少的体验，而不是停止整个用户体验。
在实时架构中，我们并不总是调用持久层，它会造成延迟，而且所有业务功能都不是无状态的，我们需要跨多个微服务共享数据，因此我们使用缓存技术并在我们的代码中进行某种编排，如果请求然后我们首先检查缓存然后数据不可用我们调用持久层并将结果添加到缓存以供进一步请求
如果缓存失败或作为单点故障，我们的服务将失败，为了避免同样的情况，我们使用分布式缓存和复制，并且数据必须复制到不同的可用区域，因此如果一个区域失败，可以检索数据另一个可用区域。
我们需要为持久层和微服务采用多区域策略，如果您的业务分布在地理上，那么根据架构风格，我们必须在地理上拥有不同的数据中心，例如美国北部、美国东部、亚太地区、欧洲等.
有趣的是，如果您的一个数据中心服务于一个地区，比如说亚太地区服务于亚洲，那么现在如果该数据中心宕机，您的所有亚太地区用户都会受到影响，所以我们必须制定多地区和故障转移策略，因此如果一个地区宕机，那就是用户请求可以由另一个区域共享以拥有弹性系统。
- 扩展
在微服务中，我们一般采用 XYZ 轴缩放。我们可以面对多种类型的问题，例如区域不可用、服务器关联、粘性会话、缓存不可用等。
通常，当我们构建微服务/分布式架构时，虽然我们说要构建无状态微服务，但由于购物车功能等业务需求，我们并不总是需要维护状态，因此我们采用了许多技术，如服务器关联或粘性会话，一旦请求到达节点负载均衡器，确保用户进一步的请求将仅由该节点处理，但这种技术有一些缺点，尽管您的系统是分布式的，但如果该特定节点出现故障，则您有多个实例该节点将遇到错误，这是意料之中的。
所以我们需要确保我们的服务不应该有任何服务器关联。我们可以使用分布式缓存来存储有状态数据或会话，也可以使用请求有效负载来附加状态，以便数据在整个请求周期中可用，这些数据已由不同的微服务填充。
检查您的服务是否有服务器亲和性，您可以通过 Chaos Monkey 和 Chaos 工具包随机杀死节点来查看结果。
- 基础设施
在采用微服务时，您必须拥有强大的基础设施支持，大多数组织要么使用云提供商，要么拥有自己的内部云或自己的数据中心，无论如何，如果基础设施出现故障，您的微服务架构取决于基础设施，您的微服务也会失败。因此，我们必须考虑基础设施故障，并以可以减轻故障的方式设计我们的架构。
对于基础设施，我们必须要有一个多区域策略和故障转移机制，这样如果一个区域的基础设施出现故障，另一个区域可以为该区域的用户提供服务。
另外，我们需要明智地选择数据中心，这样两个数据中心的物理距离不会太大，如果网络希望时间增加，响应时间增加，但它们物理上必须相距较远，以免发生自然灾害，发生恐怖袭击。不会影响两个数据中心。
使用 Chaos Kong，我们可以关闭整个区域，看看故障转移是如何工作的。