全链路追踪！微服务运维人员终于解放了

一个人身体不舒服才想起没有定期体检
显然已经晚了
微服务架构也是一样
只有实时监控、定期体检
系统中各服务的运行状态才会健康
那么，如何为“微服务”体检呢？
全链路追踪 就是微服务的“体检中心”

微服务的“身体构造”
当我们进行微服务架构开发时，通常会根据业务来划分微服务，各业务之间通过网络通信进行调用。一个用户操作，可能需要很多微服务的协同才能完成。在业务调用链路上，任何一个微服务出现问题或者网络超时，都会导致功能失败。随着业务越来越多，对于微服务之间的调用链的分析会越来越复杂。

在拥有众多服务的微服务应用中，如何知道一次请求调用的是哪条链路？当请求调用失败时，如何知道是哪个服务出现了问题导致调用失败？一次请求响应时间长，到底是哪些服务耗时长的？……
你可能会说，可以通过查看每个服务的日志来分析这些信息。但是应用的服务有可能部署到了上百个节点上，人工查找显然是不现实的。
为了查看微服务应用在实际运行中各个服务的运行状态，每次调用各个环节执行情况，我们需要一个微服务应用的体检中心，这就是全链路追踪。
为微服务“全身检查”

SaCa ACAP 在微服务领域积累了大量的技术实践，打造了一套独有的全链路追踪组件。
通过服务调用日志我们能够分析出整个微服务应用的调用情况。为了解决服务日志分散在各个节点上，首先需要将日志统一进行收集，然后将收集的数据进行过滤汇总，之后对汇总的数据进行链路分析，形成链路调用的数据，最后将数据用友好清晰的方式展现出来，这就是链路追踪的全过程。
你可能会说“这个过程听起来好像日志分析系统啊”，没错，我们的链路追踪就是基于 ELK 日志分析系统方案实现的。使用 Filebeat 收集各个服务的日志、使用 Logstash 完成日志数据的过滤， Elasticsearch 负责日志的存储于分析。

但是不要以为这就是链路追踪的全部，SaCa ACAP 还能解决更多问题。
代码入侵性
作为支撑业务组件，应当尽可能少入侵或者无入侵其他业务系统，对于使用方透明，减少开发人员的负担。
对于应用的程序员来说，是不需要知道有追踪系统这回事的。如果一个追踪系统想生效，就必须需要依赖应用的开发者主动配合，那么这个追踪系统也太脆弱了，往往由于追踪系统在应用中植入代码的 bug 或疏忽导致应用出问题，这样才是无法满足对追踪系统“无所不在的部署”这个需求。
为此 SaCa ACAP 采用了应用采用了应用监控组件 SkyWalking。它基于 Javaagent 技术，对代码无入侵。将应用和探针一起部署，就能实现对服务的监控。服务每次调用都会产生相应的日志信息。
探针的性能消耗
APM 组件服务的影响应该做到足够小。服务调用埋点本身会带来性能损耗，这就需要调用追踪的低损耗，在一些高度优化过的服务，即使一点点损耗也会很容易察觉到，而且有可能迫使在线服务的部署团队不得不将追踪系统关停。
性能的损耗很大一部分来自于将日志同步写入到文件当中。同步文件 IO 操作会产生阻塞，造成线程等待和线程上线文切换。
解决办法就是采用异步方法，异步方法先在堆内存中存储日志，然后批量写入到文件中。
但是异步写入会占用一部分用于处理业务的堆内存，为了尽可能的减少对业务运行的影响，我们首先将日志写入到堆外内存中，然后在写入到文件中。减少 IO 阻塞的同时也降低了对业务运行的影响。
分布式追踪 ID
业务系统中，涉及到各种各样的 ID ，如在支付系统中就会有支付 ID 、退款 ID 等。
一般来说有下面几点要素：
唯一性：确保生成的 ID 是全网唯一的
有序递增性：确保生成的 ID 是对于某个用户或者业务是按一定的数字有序递增的
高可用性：确保任何时候都能正确的生成 ID
带时间： ID 里面包含时间
5
我们的 ID 生成算法是基于 Twitter 的 snowflake 算法。
41 位的时间序列，精确到毫秒，可以使用 69 年
10 位的机器标识，最多支持部署 1024 个节点
12 位的序列号，支持每个节点每毫秒产生 4096 个 ID 序号，最高位是符号位始终为 0
同时我们对算法进行了优化，解决了分布式环境下会出现的 ID 非全局递增的情况。
体检报告实时展现
如何快速发现问题？如何判断故障影响范围？如何梳理服务依赖以及依赖的合理性？如何分析链路性能问题以及实时容量规划？等等这些问题除了需要一个优质的后端追踪组件外，还需要一个用户体验友好的交互界面。
SaCa ACAP 全链路追踪组件就是一套包含交互界面的完整方案。
应用拓扑追踪

直观展现整个应用的服务调用关系，服务间调用流量，服务部署主机信息，服务内组件类型，监控整个应用各个服务真实运行情况。