写在前面的话
限于本文作者水平，仅仅以node为web server和后端，数据库采用mongodb，来展示全链路的可视化。如果您感觉文章还可以，欢迎点赞，如果有疑问欢迎评论。也可以加我微信一起讨论768838557。
全链路可视化的必要性
微服务架构越来越流行，技术中台部，基础架构部等部门的分工也越来越精细化，原本一次请求可能只涉及前后端数据库一两个服务，同时随着高可用甚至服务上云后的应用场景，可能需要在多个务、中间件、之间进行流转，甚至可能是跨越了不同的机房和服务器，系统高可靠高可用的需求，以及一旦出现性能瓶颈或者故障需要跟因分析等场景，这就需要能够帮助快速定位的全链路可视化。基本能看到全链路的作用有：
- 故障定位，根因分析
- 性能分析（能耗分析、依赖分析）
- 数据分析，业务分析（产品分析）
前端服务的全链路是如何做的，这里自己本地采用node的koa框架，做了一个node的server，数据库使用mongodb（安装在一台机器上）。
一个简单的服务拓扑图
这里的例子能看到node做了静态服务器和后端的工作，背后支撑的数据库和文件读写服务。
这里针对不同的服务分别列出了
- 请求数量
- 错误率
- 平均响应时间
查看特定服务的访问情况
1.服务端的性能和访问情况
详见下图，这里能看到服务的整体趋势，比如node server的访问情况
2.数据库的访问情况
支持下钻的性能分析
针对特定的资源请求，支持下钻查看详情，探究背后的服务关系
1.node
这里看出node server和mongo两个服务，耗时占比差不多。
数据库查询情况
按照span进行排列，能够看出数据库查询了三张表
再看另一个接口，见下图，这张图node server处理时间占比较大，可以看出node 采用的koa的框架，这里的洋葱模型表现得很明显。
node某次查询的分析
这里能看到最后一步执行占比最长，高达88%，如果上传了source map基本可以定位到代码执行。
整体来看，以上这个例子能清晰看清楚服务之间的拓扑关系，对于服务的吞吐量，响应时间以及错误略都能从整体到局部展示出来数据。
往期文章（包含部分掘金上榜文章）
《谷歌教你如何说服老板为用户体验掏钱(1)- 电商品牌的最佳实践》
作者：Yestodorrow
链接：juejin.cn/post/712988…
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
