服务调用链的主要因素有哪些？

服务调用链主要因素如下

1、数据收集部分

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

2、数据分析部分

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

3、监控报警

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

4、实现方式分析

服务调用链根据收集方式可分为日志收集方式和程序实现方式

5、日志收集方式

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

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

6、手动埋点方式

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

为了支持易用性，需要较多的开发工作和可用性设计不会因为Trace组件或者Kafka的不可用造成服务的不可用。此种方式的主要坏处是，功能是以jar包方式提供的，如有重大bug或者改动，所有服务都必须重新发布。