zipkin集成后项⽬⽆法启动踩坑实践
⼀、背景
近些年微服务⼤⾏其道，这就不得不说下它带来的好处。微服务可独⽴开发，独⽴部署，每个微服务都是⼀个完整的王国，不同业务对应不同的微服务，保证了业务的解耦，甚⾄可以根据业务特点选⽤最合适最⾼效的技术栈实现相应服务，实现微服务体系下采⽤多种语⾔等。但是凡事都有两⾯性，微服务带来好处的同时，也会引⼊⼀些其他问题，⽐如今天要探讨的微服务的链路追踪问题。
通常⼀个微服务架构的项⽬，由于服务数量众多，再加上业务的复杂性，通常⼀个请求会涉及到多个微服务的调⽤，这中间任何⼀个服务出现调⽤失败或者发⽣异常，会导致整个调⽤的失败，⽽这种错误很难去定位。所以微服务中必须实现链路追踪，这样可以跟进⼀个请求会涉及到哪些服务调⽤，服务调⽤的顺序是怎样的。从⽽可以保证每个请求步骤清晰可见，出现问题快速定位。
⽬前⽐较流⾏的链路追踪相关的技术有Cat、Zipkin、Pinpoint、SkyWalking等，这⾥主要探讨Zipkin。Zipkin是⼀款开源的分布式实时数据追踪系统（Distributed Tracking System），基于 Google Dapper的论⽂设计⽽来，由 Twitter 公司开发贡献。其主要功能是聚集来⾃各个异构系统的实时监控数据。
⼆、项⽬集成⽅案介绍
最近因项⽬需求，需要对现有SpringCloud项⽬进⾏链路追踪的集成，最后确定的技术⽅案为使⽤zipkin实现。通过对Zipkin官⽅⽂档的调研，了解到zipkin的落地⽅案⼤致可以概括为以下⼏种：
thread技术
从上图可以看到，业务服务和zipkin传输链路数据可以基于直连的http或gRPC，或者也可以通过消息队列activemq、kafka或者rabbitmq；对于链路数据的存储，zipkin⽀持内存、cassandra、elasticsearch及mysql等。这⾥我们根据项⽬具体情况以及⽬前项⽬已经具有的资源，最终选⽤kafka作为连接业务服务和zipkinserver的通道，对链路数据使⽤elasticsearch存储。另外这⾥需要特别说明⼀点，基于内存存储的zipkinserver可以直接通过ui界⾯查看全局调⽤链情况；但是若存储使⽤其他⽅式，则全局调⽤链必须
借助ZipkinDependency对存储的数据进⾏分析才能⽣成全局调⽤链，ZipkinDependency是⼀个sparkjob。
三、发现问题
确定了最终技术⽅案，开始着⼿对⽬前的所有服务进⾏集成。因为需要使⽤zipkin和kafka相关依赖及配置，这⾥为了集成⽅便，最终采⽤将这两者封装成SDK的⽅式，⽽业务服务只需要集成封装好的SDK即可。SDK封装完毕后使⽤⾃⼰编写的最简单的demo⼩项⽬完成了测试。
但接下来对业务项⽬的集成却没有那么顺利。
⾸先对业务⽹关进⾏了集成，集成完毕后部署测试，发现了⼀个奇怪的现象：在服务器上启动项⽬后，通过命令能够查看到相应的java进程，但是在尝试调⽤服务时原先没有问题的接⼝显⽰⽆法调⽤，进⼀步确认发现该服务对应的端⼝并没有被监听。
问题出现：添加了封装好的SDK后项⽬启动可以看到相应的java进程，但是相应接⼝并没有被监听。
四、 定位问题

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。