认识达内从这里开始

随着互联网的不断发展，越来越多的企业都引入了微服务等互联网技术，而本文我们就通过案例分析来简单了解一下，微服务洞察的概念与应用分析。

设想这样一个问题现场，线上系统出现了一个奇怪的问题，某一个接口偶现错误，频率不高，出现时间毫无规律，但是没有发现任何有效的错误日志。这时，在通常的实践中，除非具备脑内debug的神力，不然我们往往需要在代码中增加日志逻辑，然后重启应用，静静等待问题复现后查询日志，如果定位了问题范围需要更多的信息，就需要我们不断循环编写日志逻辑->重启应用->静静等待的步骤直到解决bug。但这还不是令人头疼的，如果给这个问题加上问题触发伴随应用重启、pod内日志丢失、重启后问题无法复现等debuff，排查的难度将会进一步上升。

而由于微服务洞察具备任意位置类粒度的动态信息采集的核心能力，能够帮助我们解决上述场景中的一些痛点。先在一次发现这个问题后，我们可以直接在线上环境中通过配置一条微服务洞察的规则，来收集一些初步信息来帮助我们判断可能的问题原因。由于收集的信息会以调用链的形式组织，我们可以从中获取问题出现的频率、时间、参数分布、上下游调用信息等。同时由于信息会直接上报并集中存储到远端系统，因此不受应用重启的影响，我们也不需要一台一台实例去查询日志。

在对问题有了初步的判断之后，我们往往能够将问题定位到一个范围之内，这时我们可以进一步锁定某些方法，通过配置规则，打印它们的入参、返回值、调用堆栈等信息来判断其执行是否符合预期。

通过上述的举例可以发现，借助微服务洞察的能力，我们能够轻松地探知标准的可观测系统难以触达的角落，从而满足我们对一些微服务场景的观测需求。

洞察微服务场景

无损下线

无损下线是微服务治理中的一个功能，主要是为了解决在发布过程中的微服务在下线的过程中可能存在的流量损失。其大致流程如下图所示。

通过一系列的策略和措施，能够做到服务的完全无损下线。但这样就导致无损下线的流程比较复杂，同时还涉及到多个节点之间的通知机制，特别是在大规模之下，下线流程的完整性以及可靠性的确认变得非常复杂与繁琐。这就是前文所提到的难以触达的角落，我们可以通过微服务洞察的能力帮助我们观测这个场景。

针对无损下线的场景，微服务洞察提供了场景化的规则，简单配置一键开启。

在开启了规则之后，微服务洞察会收集无损下线流程中值得关心的信息，组织成调用链的形式展示。如下图场景，我们对108节点进行缩容操作，我们就可以得到一条Tracing链路，其中包含主动通知、服务注销、应用停止等几个步骤，并且我们可以在每个步骤中看到所需的信息。

我们也可以看到SpringCloud向Nacos(注册中心)执行服务下线的调用结果，注销成功。

微服务洞察通过将无损下线的workflow抽象成Tracing结构的策略，可以帮助我们降低大规模场景、复杂链路下无损下线问题的排查成本。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。