Laravel + go-micro + grpc 实践基于 Zipkin 的分布式链路追踪系统 摘自https://mp.weixin.qq.com/s/JkLMNabnYbod-b4syMB3Hw?

分布式调用链跟踪系统,属于监控系统的一类。系统架构逐步演进时,后期形态往往是一个平台由很多不同的服务、组件构成,用户请求过来后,可能会经过其中多个服务,如图

不过,出问题时往往很难排查,如整个请求变慢、偶尔报错、不可用等,我们很难得知具体是由哪一个或哪些服务引起的,通常开发同学都会互相甩锅,最后不得不花大量时间人肉 tracing

项目初期时,可以简单处理,通过生成唯一 request_id ,在各个方法记录日志,方便排查问题。中后期系统拆分为各个子服务时,要么继续推进原有的 request_id 方式到各个服务,要么换用成熟的追踪系统,如zipkin

zipkin 是什么

zipkin 是 twitter 开源的产品,类似于 Google 的 Dapper,淘宝也有类似的系统叫 鹰眼。社区有一个开源项目叫 opentracing,定义了此类系统的统一标准,各个开源项目也基本都对其兼容, 如 zipkin jaeger appdash 等。

两个核心概念

TraceId:

用于标识一次完整请求 trace,会从头到尾贯穿在各个服务中,通常在请求入口时生成。

SpanId:

用于标识某个调用跨度 span,一个 span 可以有多个 子span, 通常一个完整的 trace 由很多个 span 组成。

如图

基本流程

请求入口生成 trace

在方法(或服务)调用前,生成 span,记录时间

调用时,携带 TraceId SpanId (如,在 http header 或 grpc meta data 里)

调用完后关联到 trace

统一上报到 zipkin 存储

最后,在 zipkin 可查看完整调用链

实践准备工作

关键词: php7、grpc、protobuf、go-micro、consul、zipkin

先配置本机环境, 以 Mac 系统为例: 安装 protobuf、consul、zipkin、php-grpc 扩展

brew install protobuf
brew instlal consul
brew install php71-grpc
wget -O zipkin.jar ‘https://search.maven.org/remote_content?g=io.zipkin.java&a=zipkin-server&v=LATEST&c=exec‘

 

启动服务

本机调试时可以用下面的命令快速启动 consul 和 zipkin ,不建议用在生产环境

consul agent -dev
java -jar zipkin.jar

此时可以打开 http://localhost:8500/ui 看到 consule 界面

打开 http://localhost:9411/ 可看到 zipkin 主界面

PHP 演示基于 Laravel 框架,已经在 Github 上

git clone https://github.com/henter/php-zipkin-demo
cd php-zipkin-demo
composer install
php artisan serve

此时可打开 http://localhost:8000/ 看到 laravel 首页

Go 服务基于 go-micro 微服务框架,请确保本机已安装 Go

go get github.com/henter/go-zipkin-demo
启动服务
go-zipkin-demo

准备工具已就绪,打开浏览器访问 http://localhost:8000/test

这个请求会记录 4 条span,分别是 root、一次 http 请求、一次 grpc 请求、go 服务内方法调用

此时刷新 zipkin 页面,左侧选择 php-zipkin-demo, 点击 Find Traces 可看到追踪记录,如图

点进去即可看到整个链路耗时12.4 ms以及各个 span 耗时

点击每个 span 可查看更详细信息

需继续完善

演示程序仅仅实现了从 php 通过 grpc 请求 go 服务时的场景,如果用在生产,需继续实现以下场景:

PHP 接收 http 请求,并作为子span

Go 发起 grpc 请求

Go 发起 http 请求

Go 接收 http 请求,并作为子span

这些不是本文重点,在示例程序上稍加改造即可。 各场景相互结合串联到一起,基本能覆盖绝大部分业务。

另外,可以将 zipkin trace 数据推到 prometheus 监控系统,通过 grafana 可视化。或者,将 zipkin 数据存储换成 elasticsearch,结合 kibana 生成图表。

最后

具体代码都在 Github 了,仅演示用,这里不深入具体细节,大家有兴趣可以看代码,欢迎 start

https://github.com/henter/php-zipkin-demo

https://github.com/henter/go-zipkin-demo

有任何问题欢迎交流,可加我个人微信 henter

注:本文示意图来自 Google Dapper 论文 
https://research.google.com/pubs/pub36356.html

原文地址:https://www.cnblogs.com/si812cn/p/9951209.html

时间: 2024-12-09 17:37:51

Laravel + go-micro + grpc 实践基于 Zipkin 的分布式链路追踪系统 摘自https://mp.weixin.qq.com/s/JkLMNabnYbod-b4syMB3Hw?的相关文章

个推基于 Zipkin 的分布式链路追踪实践

作者:个推应用平台基础架构高级研发工程师 阿飞 01业务背景 随着微服务架构的流行,系统变得越来越复杂,单体的系统被拆成很多个模块,各个模块通过轻量级的通信协议进行通讯,相互协作,共同实现系统功能. 单体架构时,一个请求的调用链路很清晰,一般由负载均衡器将用户请求转发到后端服务,由后端服务进行业务处理,需要的数据从外部的存储中获取,处理完请求后,再经由负载均衡器返回给用户. 而在微服务架构中,一个请求往往需要多个模块共同协作处理,不同模块可能还依赖于不同的外部存储,各个模块的实现技术还不尽相同,

基于zipkin分布式链路追踪系统预研第一篇

分布式服务追踪系统起源于Google的论文“Dapper, a Large-Scale Distributed Systems Tracing Infrastructure”(译文可参考此处),Twitter的zipkin是基于此论文上线较早的分布式链路追踪系统了,而且由于开源快速被各社区所研究,也诞生了很多的版本. 在这里也是对zipkin进行研究,先贴出Twitter zipkin结构图. 结构比较简单,大概流程为: Trace数据的收集至Scribe(Facebook开源的日志传输通路)或

zipkin分布式链路追踪系统

基于zipkin分布式链路追踪系统预研第一篇 分布式服务追踪系统起源于Google的论文“Dapper, a Large-Scale Distributed Systems Tracing Infrastructure”(译文可参考此处),Twitter的zipkin是基于此论文上线较早的分布式链路追踪系统了,而且由于开源快速被各社区所研究,也诞生了很多的版本. 在这里也是对zipkin进行研究,先贴出Twitter zipkin结构图. 结构比较简单,大概流程为: Trace数据的收集至Scr

spring cloud 入门系列八:使用spring cloud sleuth整合zipkin进行服务链路追踪

好久没有写博客了,主要是最近有些忙,今天忙里偷闲来一篇. =======我是华丽的分割线========== 微服务架构是一种分布式架构,微服务系统按照业务划分服务单元,一个微服务往往会有很多个服务单元,一个请求往往会有很多个单元参与,一旦请求出现异常,想要去定位问题点真心不容易,因此需要有个东西去跟踪请求链路,记录一个请求都调用了哪些服务单元,调用顺序是怎么样的以及在各个服务单元处理的时间长短.常见的服务链路追踪组件有google的dapper.twitter的zipkin.阿里的鹰眼等,它们

分布式链路追踪(Sleuth、Zipkin)

技术背景 在微服务架构中,随着业务发展,系统拆分导致系统调用链路愈发复杂,一个看似简单的前端请求可能最终需要调用很多次后端服务才能完成,那么当整个请求出现问题时,我们很难得知到底是哪个服务出了问题导致的,这时就需要解决一个问题,如何快速定位服务故障点,于是,分布式系统调用链追踪技术就此诞生了. ZipKin Zipkin 是一个由Twitter公司提供并开放源代码分布式的跟踪系统,它可以帮助收集服务的时间数据,以解决微服务架构中的延迟问题,包括数据的收集.存储.查找和展现. 每个服务向zipki

跟我学SpringCloud | 第十一篇:使用Spring Cloud Sleuth和Zipkin进行分布式链路跟踪

SpringCloud系列教程 | 第十一篇:使用Spring Cloud Sleuth和Zipkin进行分布式链路跟踪 Springboot: 2.1.6.RELEASE SpringCloud: Greenwich.SR1 如无特殊说明,本系列教程全采用以上版本 在分布式服务架构中,需要对分布式服务进行治理--在分布式服务协同向用户提供服务时,每个请求都被哪些服务处理?在遇到问题时,在调用哪个服务上发生了问题?在分析性能时,调用各个服务都花了多长时间?哪些调用可以并行执行?-- 为此,分布式

基于 SkyWalking 实现服务链路追踪

SkyWalking简介 SkyWalking是一个开源的观测平台,用于从服务和云原生等基础设施中收集.分析.聚合以及可视化数据.SkyWalking 提供了一种简便的方式来清晰地观测分布式系统,甚至可以观测横跨不同云的系统.SkyWalking 更像是一种现代的应用程序性能监控(Application Performance Monitoring,即APM)工具,专为云原生,基于容器以及分布式系统而设计 SkyWalking 在逻辑上分为四部分:探针.平台后端.存储和用户界面.其架构图如下:

[转帖]Greenplum: 基于PostgreSQL的分布式数据库内核揭秘(下篇)

Greenplum: 基于PostgreSQL的分布式数据库内核揭秘(下篇) http://www.postgres.cn/v2/news/viewone/1/454 原作者:姚延栋 创作时间:2019-05-08 17:25:25+08   采编:wangliyun 发布时间:2019-05-09 08:25:28 欢迎大家踊跃投稿,投稿信箱:[email protected] 评论:0    浏览:1620 作者介绍 姚延栋,山东大学本科,中科院软件所研究生.PostgreSQL中文社区委员

[转帖]Greenplum :基于 PostgreSQL 的分布式数据库内核揭秘 (上篇)

Greenplum :基于 PostgreSQL 的分布式数据库内核揭秘 (上篇) https://www.infoq.cn/article/3IJ7L8HVR2MXhqaqI2RA 学长的文章.. 姚延栋 阅读数:7142019 年 9 月 15 日 17:11 本文经授权转载自公众号 PostgreSQL 中文社区,主要介绍了 Greenplum 集群概述.分布式数据存储和分布式查询优化. 一.数据库内核揭秘 Greenplum 是最成熟的开源分布式分析型数据库(今年 6 月份预计发布的 G