我的回答来自《Spring微服务实战》
1、使用Spring Cloud可以很方便的集成Zipkin，详见“第9章 使用Spring Cloud Sleuth 和 Zipkin进行分布式跟踪》
2、从功能角度来看，不管使用HTTP、RabbitMQ、Kafka，Zipkin的行为没有任何差异。通过使用HTTP追踪，Zipkin使用异步线程发送性能数据。另外使用RabbitMQ或Kafka来收集跟踪数据的主要优势是，如果Zipkin服务器关闭，任何发送给Zipkin的跟踪信息都将”排队“，直到Zipkin能够收集数据。（238页）

跟大众点评的cat区别呢

在项目中我们也对比过zipkin和pinpoint，个人认为还要考虑以下几方面：
1、定制成本 两者都需要对中间件进行定制化的开发，zipkin开源社区更活跃些，遇到的问题也比较容易解决。pinpoint自身支持了很多的plugin,如果想要二次开发，需要了解它的扩展机制，代码上来说会稍微复杂。
2、维护成本 pinpoint需要维护单独的hbase集群（当然hdfs也少不了）
3、规范 pinpoint是自己走的一套，没有遵守opentracing标准规范，zipkin已有相应实现

pinpoint支持cloud吗

基于不同场景选择不一样。本来刚看到问题，本人觉得第一想法就是MQ比较适合。但是使用MQ 需要搭建相应的消息系统。这就相对引入一些复杂度。对于前期项目刚开始，可以使用http，能快速对接上追踪系统。而随着后期项目渐入稳定，然后 http 的调用相对而言，效率偏低，如果并发十分大，可能会影响项目原本的稳定性。这个时候就可以考虑使用MQ，提高吞吐量。
 哈哈 说个题外话，总感觉要在代合耦合这种代码，就感觉十分不舒服。：（

我是做Android音视频开发的 现在想往后台和微服务方向转 想问问作者有什么看法呢

留言支持mq但我觉得可能http侵入更低，http层后面可以接入kafka等.
我们内部其实也做了类似dapper做参考的链路系统，有个问题1如何考虑采样率的实现，2pinpoint每个层都trace一下会不会有性能问题？

美团的OCTO 很不错

消息队列更合适一些，原因1 服务某一段时间耗时增加不至于影响现有服务的调用。2 采用消息队列可以有效控制消费舒服，对于缓解存储端压力是个不错的选择。3 消息队列吞吐量更强

kafka合适些，它原本定位于日志领域，为了解决数据一致性不那么高，而并发量，可扩展性要求高的场景，现在已聚焦与分布式的流式平台，监控类的业务合适。

对于微服务架构模式下，主业务应用和后端子业务应用通过nginx网关代理，这种情况下 如何在nginx上对接pinpoint链路追踪呢？

感谢，没直接用过，涨涨见识，感觉开源对于软件技术的发展不可限量。

异步mq更好，不会对原来对被追踪的业务请求产生多余影响

还是没明白服务b如何拿到服务a生成的trance id

老师，看了本章后，我有一个地方不理解；假设场景，微服务A调用微服务B，那么服务B是怎么知道服务A生成的id呢？如果是调用服务时当参数传过去的，那岂不是等于侵入了业务代码了吗？有没有不侵入业务代码的方法？

pinpoint 性能是个硬伤

我觉得采用异步通信的方式好一些。
1、同步http发送方式对业务代码性能影响大。
2、消息队列的消息可以被不同的消费组处理。数据处理更灵活。
3、消息队列本身也有一定的消息存储和缓冲的能力。当采集进程短时间有问题时，不会导致数据的丢失，等恢复正常后可以继续消费。

pinpoint支持dubbo、thrift这类非http的调用吗

openzipkin应该就是集成在springcloud中的吧？