认识达内从这里开始

微服务架构开发随着互联网的不断发展而被广泛应用到不同行业之中，今天合肥达内培训就带大家通过案例分析来简单了解一下，微服务架构应用注意事项分享。

从单体架构迁移到微服务后，复杂性加剧的表现之一是依赖项增加。单体应用中包含了系统的所有业务逻辑，而迁移到微服务后则会变成多项服务依赖共存。您的微服务还可能依赖其他外部服务，例如来自云提供商的API，或用作基础架构一部分的SaaS服务。

当这些外部或内部依赖项出现故障时会发生什么?您在代码中实施的保护措施能否缓解这些故障?超时和重试等逻辑是否针对系统在生产环境中的实际运行方式进行了调优?

黑洞攻击是测试您能否处理好故障依赖项的好方法。黑洞攻击会拦截主机或容器对特定主机名、IP地址和/或端口的访问，模拟资源不可用时会发生的情形。这种方法能够有效模拟网络或防火墙相关中断以及网络分区。

在存在外部依赖项的情况下，假设我们正在运行一个使用TwilioAPI向客户发送短消息的服务。我们知道，我们与Twilio的通信随时都有可能中断，因此我们将微服务设计为读取队列中的消息，并且只在这些消息通过TwilioAPI成功发送到Twilio后才将它们从队列中删除。

如果TwilioAPI不可用，消息将在我们这一端排队等候(比如使用Kafka或ActiveMQ等消息总线)，当与Twilio的通信一旦恢复，它们将被立即发送。听起来很不错吧?

但在实际测试之前，我们如何知道在与Twilio的网络连接中断时，服务的实际表现如何呢?我们如何知道，它在生产环境中的实际运行方式是否同我们在白板上设计的一样?

我们可通过运行黑洞攻击，拦截该服务访问TwilioAPI，观察它的实际表现。这可以解答我们的很多问题，例如：消息队列是否正确?我们设定的超时时间是否合理?随着消息队列的增长，服务是否继续正常运行?我们不再查看代码和推断这些问题的答案，而是实际注入故障，观察会发生什么。

在这种情况下，我们可以假设“网络连接断开时消息队列正确，并且在网络恢复后消息传递正常”。我们可通过运行黑洞攻击，检验这个假设是否正确。如果终证明假设有误，我们可能会获取一些有用的信息，帮助我们提高系统弹性。

黑洞攻击也可以用来验证内部依赖项发生故障时会出现什么状况，以及发现隐藏的依赖项。隐藏依赖项是个十分常见的问题，好能在它们引发事件之前发现它们。在服务中添加新的依赖项时会引入隐藏依赖项，但这些依赖项在组织内并无相关记录或传达。

举例来说：服务A更新后，现在依赖于服务B，但运行服务B的团队并不知道这一点。他们中止服务B以进行维护，突然服务A意外中断。如果服务A是关键服务(例如登录服务)，或者是支持客户购买商品的服务，那么这种中断的代价将非常高昂。对于团队来说，这种问题并不罕见，因为服务依赖项的映射和可视化通常比较困难。

通过定期对服务运行黑洞攻击，可暴露这些隐藏的依赖项，从而让相关团队知道它们的存在。如能清楚地了解外部依赖项，您还可以获得其他好处。比如某项服务在其依赖的服务无法访问时会如何响应?超时和重试配置是否正确?基于微服务的分布式系统如何处理网络分区?这些问题都可通过黑洞攻击予以解答。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。