服务调用链的主要因素和简要对比

调用链主要因素

数据收集部分

主要用于多样化的数据收集，为数据分析作准备。要求易用好用侵入尽可能小（开发工做量），而且在极端状况下（如收集组件不可用）不能对业务有任何影响。能够看到此部分的开发量是巨大的，尤为是须要集成Nginx上下游、基础组件多样、技术栈多样的状况下。

数据分析部分

主要有实时分析与线下分析。通常，实时分析的价值更大一些，主要产出如秒级别的调用量、平均响应时间、TP值等。另外，调用链（Trace)须要存储全量数据，一些高并发大埋点的请求，会有性能问题。

监控报警

此部分利用数据分析的产出，经过短信邮件等形式，通知订阅人关注。监控报警平台应尽可能向devops平台靠拢，包括自主化服务平台。

实现方式分析

根据收集方式可分为日志收集方式和程序实现方式

日志收集方式

日志收集方式与传统的ELK链路差很少。主要经过日志组件，打印出符合规范的日志格式。Flume守护进程会读取、过滤这些日志，将数据Sink到kafka集群中。会接收一份全量数据（调用链须要）到ES中供查询分析；同时接收一份日志使用Spark或Strom方式分析出须要的数据，存结果。

主要开发量集中在日志组件和各个模块的组合调试中。另外，因为须要在每台宿主机上安装配置flume-agent，此模式依赖完善的运维体系，可以使用jenkens或者ansible集成支持。

手动埋点方式

这种方式采用业务端直推的方法，将数据直接聚集到kafka中。客户端通常会开一个堆上的缓冲区，将有单独的线程定时上报缓冲区数据。数据落地到kafka后，后续的处理相似。

为了支持易用性，须要较多的开发工做和可用性设计不会由于Trace组件或者Kafka的不可用形成服务的不可用。

此种方式的主要坏处是，功能是以jar包方式提供的，若有重大bug或者改动，全部服务都必须从新发布。

监控报警

• 通常的，grafana等组件便可知足需求，够用，并可以快速实现。但其方式，仅仅能展现数据，须要肉眼盯盘，若是有更灵活的监控需求，不支持。
• 监控曲线，应该可以发现系统性能瓶颈，为扩容、缩容提供决策依据。

• 同比、环比、斜率，包括报警，须要进行开发（报警和历史走势），功能不复杂，但须要考虑如下问题：

  • 报警接收人变动，是否能及时支持
  • 报警阈值调整，是否须要走工单等复杂流程
  • 是否能查看历史报警和处理的报警，并依此评价响应速度

对比

咱们大致对比了不一样封装层次的三个表明，以便对调用链产品有个大致理解

总结

cat

优势：功能强大，监控全面，并且数据展现全面，更便于之后问题分析。
缺点：须要在代码中埋点，对代码侵入性很大。对于美团内部框架依赖严重。

sleuth + zipkin

优势：是spring cloud的组件，基于spring boot框架，接入简单，不须要埋点，分析的方式是经过日志分析，并且能够对接多种第三方存储进行存储和分析。
缺点：功能单一，只经过进行http调用的跟踪。页面数据展现比较简单，只有调用链路的相关信息， 没有总体数据的对比。sleuth只对restTemplate，zuul转发，spring cloud stream的消息中间件这三种调用方式进行添加监控信息，其余方式不支持，因此更适用于spring cloud环境。

pinpoint

优势：采用javaagent字节码加强技术，对业务代码入侵极少，业务只须要在启动时增长javaagent参数便可
缺点：
1.功能限于链路跟踪，对于其余业务监控指标支持不足
2.维护技术难度较高，内部是字节码加强技术，问题排查须要较高的技术水平
3.同第二点，自定义扩展开发难度也较高。

来源：http://sayhiai.com/index.php/archives/23/