Open ImHype opened 6 years ago
随着考拉服务化进程的推进,我们的应用架构逐步由集中式向分布式演进。这个时代的服务化调用往往带有以下特点:
在这种场景下,对于我们服务调用的性能监控和异常监控显得尤为重要。
出于对服务调用的性能监控和异常监控的根本性诉求,Trace 便应运而生了,细化以后的目标大概有这些:
我们对以上调用关系进行分析,可以得到以下结论:
我们可以有一个基础的 trace 设计思路了
Trace 想要正常运转,需要以下步骤:
完成以上的流程,通常来说,需要三个角色
在分布式系统中,用户的一次URL请求在各个系统中调用,这个调用关系会呈现成树形调用链。 Span记录了调用信息,Trace客户端会把Span记录在日志中。散落在各个系统的Span按唯一标识组装起来变形成了一颗树。
Trace 代表一个完整的调用链,对应到如图的 0 节点,往往是面向用户的顶层应用,具有唯一的 traceId,生成 Span 时需要用到。
Span记录了调用信息,散落在各个系统的Span按唯一标识组装起来变形成了一颗树。Span中主要信息包含:
值得注意的是:
有了以上知识作为基础后,我们来思考如何用 nodejs 来实现这个 trace 的客户端。
上图可以理解为一个 koa 的 middleware:
实际在生产环境,我们并不需要统计所有的服务调用,这会带来较高的统计成本,所以我们支持使用「采样率」来对一定比例的请求做跟踪。
比较优雅的方式是,你可能需要将这个「采样率」托管在 disconf 或者其他数据管理平台上
Trace 期望监测的是线上的真实调用情况,所以对于压测场景,期望能做区分以排除此类数据,所以较为通用的方式是如果在 cookie 上传入某个字段,则表示为压测数据。
以上阐述的 Trace 方案其实最终灵感都是来自于 Google Dapper。
而如何更为优雅的统计应用的服务调用,可能还需要不断地探索
为什么没有选择开源的 APM,类似于 Zipkin Jaeger 之类支持多语言很全面的库。
背景
随着考拉服务化进程的推进,我们的应用架构逐步由集中式向分布式演进。这个时代的服务化调用往往带有以下特点:
在这种场景下,对于我们服务调用的性能监控和异常监控显得尤为重要。
Trace 的目标
出于对服务调用的性能监控和异常监控的根本性诉求,Trace 便应运而生了,细化以后的目标大概有这些:
Trace 架构及流程
我们对以上调用关系进行分析,可以得到以下结论:
我们可以有一个基础的 trace 设计思路了
流程
Trace 想要正常运转,需要以下步骤:
架构
完成以上的流程,通常来说,需要三个角色
数据结构
在分布式系统中,用户的一次URL请求在各个系统中调用,这个调用关系会呈现成树形调用链。 Span记录了调用信息,Trace客户端会把Span记录在日志中。散落在各个系统的Span按唯一标识组装起来变形成了一颗树。
Trace
Trace 代表一个完整的调用链,对应到如图的 0 节点,往往是面向用户的顶层应用,具有唯一的 traceId,生成 Span 时需要用到。
Span
Span记录了调用信息,散落在各个系统的Span按唯一标识组装起来变形成了一颗树。Span中主要信息包含:
值得注意的是:
使用 node 实现 trace 客户端
有了以上知识作为基础后,我们来思考如何用 nodejs 来实现这个 trace 的客户端。
上图可以理解为一个 koa 的 middleware:
接入 Trace 后需要了解的
采样率
实际在生产环境,我们并不需要统计所有的服务调用,这会带来较高的统计成本,所以我们支持使用「采样率」来对一定比例的请求做跟踪。
比较优雅的方式是,你可能需要将这个「采样率」托管在 disconf 或者其他数据管理平台上
压测标识
Trace 期望监测的是线上的真实调用情况,所以对于压测场景,期望能做区分以排除此类数据,所以较为通用的方式是如果在 cookie 上传入某个字段,则表示为压测数据。
总结
以上阐述的 Trace 方案其实最终灵感都是来自于 Google Dapper。
而如何更为优雅的统计应用的服务调用,可能还需要不断地探索