微服务体系结构是一种体系结构风格，其中应用程序被分解为能够提供特定服务的独立组件。当调用这些组件链时，应用程序的业务逻辑将得到服务。

不管是哪种体系结构风格，软件的质量对于提供完美和值得信任的服务都是至关重要的。密集的测试是发布高质量软件的关键。软件工程师执行多个级别的测试，以确保微服务、业务逻辑以及最终整个应用程序在任何情况下都不会出现错误行为。其中一个测试过程称为FMEA．

FMEA代表失效模式和影响分析。这是一个涉及质量测试的过程，其中有意关闭应用程序的一个或多个组件(或)模拟连接失败，以研究依赖于失败的被调用微服务的微服务的行为。这个过程对于确保业务逻辑中涉及的微服务之间不会出现级联故障至关重要。不执行FMEA可能使应用程序漂移到不稳定状态，或者更糟糕的是，显示服务器错误，其中可能包含终端用户的敏感信息。

嗯，在测试阶段放下一个自拥有的微服务来研究测试阶段中依赖的微服务的行为是相对容易的。依赖于第三方API的微服务的FMEA如何呢?我们无法控制第三方API的运行状态。因此，这可以缩小到模拟第三方api的故障。

接下来，如何模拟无法控制的API端点的故障?

方法

回顾或观察微服务的典型实现。有一部分代码执行对API端点的HTTP(S)请求(或任何其他协议)。API端点在实现中以域名的形式表示为常量。你发现前面的陈述有什么有趣的地方吗?

API端点以a的形式表示域名而且不的形式IP地址．

利用在实现中看到的这种模式，如果可以将API端点域名指向没有运行服务的IP地址会怎样?它不是模拟API调用失败吗?

例如，考虑一个第三方API端点api.example.com这解决了为1.2.3.4并提供端口443上查询位置的天气信息。被分析的微观服务应该相信这一点api.example.com解析为127.0.0.1，其中端口443上没有运行服务。因此，当微服务运行时，它尝试对api.example.com最终失败了127.0.0.1没有在端口443上运行天气信息服务。

我们怎么做呢?

DNS缓存中毒!

让我们分析一下域名的DNS解析是如何在主机中发生的。主机为域名制作一个DNS请求，并将其传递给网络驱动程序。此时，主机试图通过在本地DNS缓存中查找域名来解析查询。如果没有找到，则递归地向检查其本地DNS缓存(能够解析DNS)的网关查询，然后向ISP网关查询，以此类推到实际的DNS服务器。观察,我们做可以控制主机，所以让我们尝试篡改主机的DNS缓存，将第三方API域名指向一个不运行指定服务的IP地址，例如，api.example.com来127.0.0.1．

有一个特殊的文本文件设置在基于*nix的系统和C:\Windows\System32\Drivers\etc\hosts在windows系统中，它是本地DNS缓存的扩展。这是主机解析DNS查询时查找的第一个地方。牛眼灯!

中添加新行设置文件中的第三方API端点指向的IP地址没有运行指定的服务，就可以模拟第三方API失败。

别说话，给我看看代码

考虑一个检查输入字符串是否是pokemon和/或python模块的微服务。例如,

请求：
GET / tensorflow响应：
｛
“is_python_module”:没错,
“is_pokemon”:假的
｝

发展

下面的代码展示了微服务的实现。观察使用的两个第三方api，即:

• pypi.org:识别输入字符串是否为python模块
• pokeapi.co:识别输入字符串是否为口袋妖怪

它查询两个API端点以获得与输入字符串相关的详细信息。使用获得的信息，微服务相应地更新响应并返回结果。

测试

下面的代码显示了三种场景(基于*nix的系统)的FMEA测试自动化:

• pokeapi.co是下来,而pypi.org是健康的
• pokeapi.co是健康的,而pypi.org是下来
• pokeapi.co是下来,pypi.org是下来

请注意:有意跳过两个api都正常时的测试用例。

以允许进行编辑的用户(例如root)运行测试设置文件。

耶!三个测试都通过了。保持了软件的质量!