全链路追踪!微服务运维人员终于解放了 - Go语言中文社区

全链路追踪!微服务运维人员终于解放了


一个人身体不舒服才想起没有定期体检
显然已经晚了
微服务架构也是一样
只有实时监控、定期体检
系统中各服务的运行状态才会健康
那么,如何为“微服务”体检呢?
全链路追踪 就是微服务的“体检中心”
在这里插入图片描述

微服务的“身体构造”

当我们进行微服务架构开发时,通常会根据业务来划分微服务,各业务之间通过网络通信进行调用。一个用户操作,可能需要很多微服务的协同才能完成。在业务调用链路上,任何一个微服务出现问题或者网络超时,都会导致功能失败。随着业务越来越多,对于微服务之间的调用链的分析会越来越复杂。
在这里插入图片描述
在拥有众多服务的微服务应用中,如何知道一次请求调用的是哪条链路?当请求调用失败时,如何知道是哪个服务出现了问题导致调用失败?一次请求响应时间长,到底是哪些服务耗时长的?……
你可能会说,可以通过查看每个服务的日志来分析这些信息。但是应用的服务有可能部署到了上百个节点上,人工查找显然是不现实的。
为了查看微服务应用在实际运行中各个服务的运行状态,每次调用各个环节执行情况,我们需要一个微服务应用的体检中心,这就是全链路追踪。

为微服务“全身检查”

在这里插入图片描述
SaCa ACAP 在微服务领域积累了大量的技术实践,打造了一套独有的全链路追踪组件。
通过服务调用日志我们能够分析出整个微服务应用的调用情况。为了解决服务日志分散在各个节点上,首先需要将日志统一进行收集,然后将收集的数据进行过滤汇总,之后对汇总的数据进行链路分析,形成链路调用的数据,最后将数据用友好清晰的方式展现出来,这就是链路追踪的全过程。

你可能会说“这个过程听起来好像日志分析系统啊”,没错,我们的链路追踪就是基于 ELK 日志分析系统方案实现的。使用 Filebeat 收集各个服务的日志、使用 Logstash 完成日志数据的过滤, Elasticsearch 负责日志的存储于分析。

但是不要以为这就是链路追踪的全部,SaCa ACAP 还能解决更多问题。

点击,阅读详细内容

版权声明:本文来源CSDN,感谢博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
原文链接:https://blog.csdn.net/yuxliang007/article/details/88690926
站方申明:本站部分内容来自社区用户分享,若涉及侵权,请联系站方删除。
  • 发表于 2020-04-19 11:07:48
  • 阅读 ( 1688 )
  • 分类:运维

0 条评论

请先 登录 后评论

官方社群

GO教程

猜你喜欢