服务调用链的主要因素和简要对比
调用链主要因素
数据收集部分
主要用于多样化的数据收集，为数据分析做准备。要求易用好用侵入尽量小（开发工作量），并且在极端情况下（如收集组件不可用）不能对业务有任何影响。可以看到此部分的开发量是巨大的，尤其是需要集成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.同第二点，自定义扩展开发难度也较高。
