CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章微服务故障排除方面的优秀实践由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.

人们听到“微服务”时，常常想到Kubernetes，这是一种声明式容器编排系统。由于具有声明性，Kubernetes将微服务视作实体，这在故障排除方面带来了一些难题。不妨看看为什么在Kubernetes环境下为微服务排除故障可能具有挑战性，以及一些相应的最佳实践.

想了解为什么为微服务排除故障可能具有挑战性，不妨看一个例子.

如果您在Kubernetes中有一个应用程序，就可以将它部署为pod，利用Kubernetes对其进行扩展。该实体是您可以监控的pod。若使用微服务，您不应该监控pod;相反，应该监控服务。所以您可能拥有整体式工作负载(部署为pod的单个容器)并对其进行监控，但如果您的服务由几个不同的pod组成，就需要了解这些pod之间的相互关系，才能明白服务是如何运行的，以及进行监控，如果不这么做，您认为的事件可能不是真正的事件(即可能对服务的运作并不重要).

说到监控微服务，您需要在服务层面、而不是在pod层面进行监控。如果您尝试在pod层面进行监控，将与编排系统发生冲突，并且可能出岔子.

1、为微服务排除故障时常见问题的根源

为微服务排除故障时，网络、基础架构和应用程序等问题都很常见.

网络

网络层面的问题最难调试。如果问题出在网络上，您需要查看套接字层统计信息。底层网络拥有将A点连接到B点的套接字，因此您需要在网络层面查看往返时间，看看数据包是否在传输、是否存在路由问题等.

基础架构

pod重新启动时，基础架构问题会显露出来(Kubernetes中的崩溃循环)。发生这种情况的原因有很多。比如说，如果您的服务中有一个pod无法访问Kubernetes数据存储，Kubernetes会重新启动它。您需要跟踪支持该服务的那些pod的状态。如果您看到数次或频繁的pod重新启动，这就成了问题.

另一个常见的基础架构问题是Kubernetes API服务器过载，需要很长的时间才能响应。每当需要执行某个操作，pod都要与API服务器通信——因此，如果API服务器过载，这就成了问题.

第三个基础架构问题与域名系统(DNS)有关。在Kubernetes中，您的服务由名称来标识，名称则由DNS服务器来解析。如果这些解析很慢，您会开始看到问题.

应用程序

有几个常见的应用程序问题可能导致重新启动和错误。比如说，如果您的服务负载均衡未起作用，比如说由于您的URL发生了变化或者负载均衡系统没有执行正确的操作，就可能会导致某一个pod过载，从而导致它重新启动.

如果您的URL构建不正确，您会收到响应代码“404页面未找到”。如果服务器过载，您会收到500错误。这些是应用程序问题，只不过表现为基础架构问题.

2、微服务故障排除方面的最佳实践

以下是有效识别和排除微服务问题的两个最佳实践.

在服务层面聚合数据

您需要使用一款工具来提供在服务层面聚合的数据(即日志)，以便可以查看出现了多少次pod重新启动和错误代码等。这与当今大多数DevOps工程师使用的方法不同;在后一种方法中，每次pod重新启动都是单独的警报，导致工程师陷入到可能只是正常操作或Kubernetes自我纠正的警报中.

一些DevOps工程师可能想知道是否可以使用服务网格来聚合数据。虽然服务网格内置了可观察性工具，但您要小心：由于涉及大量数据，许多服务网格会采样数据;它们为您提供了原始数据，并提供了标签，以便您自行聚合数据。您真正需要的是一种工具，为您仅提供服务所需的数据以及服务层面的报告机制.

使用机器学习

在试图识别和解决微服务问题时，您需要监控属于服务的每个pod在如何运行。这意味着监控延迟、进程重启次数和网络连接错误等度量指标。有两种方法可以做到这一点:

• 设置阈值——比如说，如果有20多个错误，就设置警报。在像Kubernetes这样的动态系统中，这种方法有点原始，尤其是在使用微服务的情况下。
• 确立基准——使用机器学习来研究度量指标随时间的推移而如何变化，构建机器学习模型，以预测该指标在未来有怎样的表现。如果指标偏离基准，您会收到一则警报，指明哪些参数导致机器学习算法认为存在问题。
• 我建议别尝试设置阈值——你会被大量警报所淹没，这会导致警报疲劳。相反，应使用机器学习。久而久之，机器学习算法可以在问题出现之前发出警报。

参考：https://www.kubernetes.org.cn/9812.html 。

最后此篇关于微服务故障排除方面的优秀实践的文章就讲到这里了,如果你想了解更多关于微服务故障排除方面的优秀实践的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。