也该学习基于常见组件的微服务场景实战，全链路日志的注意事项了

注意事项

在使用SkyWalking之前，还需要考虑以下5个注意事项。

 SkyWalking的数据收集机制

中间件在收集日志的时候，不可能是同步的。为什么呢？如果每次记录日志都要发一个请求到中间件，等中间件返回结果以后，才算日志记录完成，进入下一个动作，那么这个请求的响应时间肯定变慢。而且这种情况下，业务系统和日志系统是耦合的，业务系统要保证绝对高可用，而日志系统只是用来为研发人员调研问题提供方便的，对可用性的要求没有那么高。也不可能让高可用的系统依赖中可用的系统。

所以这个日志收集的过程必须是异步的，和业务流程解耦。

SkyWalking的数据收集机制是这样的：服务中有一个本地缓存，把收集的所有日志数据先存放在这个缓存中，然后后台线程通过异步的方式将缓存中的日志发送给SkyWalking服务端。这种机制使得在日志埋点的地方无须等待服务端接收数据，也就不影响系统性能。

如果SkyWalking服务端宕机了，会出现什么情况

如果服务端宕机了，理论上日志缓存中的数据会出现没人消费的情况，这样会不会导致数据越积越多，最终超出内存呢？

在SkyWalking中会设置缓存的大小，如果这部分数据超出了缓存大小，Trace不会保存，也就不会超出内存了。

 流量较大时，如何控制日志的数据量

流量大时，不可能收集每个请求的日志，否则数据量会过大。那SkyWalking如何控制采样比例呢？

SkyWalking会在每个服务器上配置采样比例，比如设置为100，代表1%的请求数据会被收集，代码如下所示。

这样就可以通过sampleRate来控制采样比例了。一般而言，流量越大，采样比例越小。

不过，这里有两点需要特别注意。

1）一旦启用forceSampleErrorSegment，出现错误时就会收集所有的数据，此时sampleRate对出错的请求不再适用。

2）所有相关联服务的sampleRate最好保持一致，如果A调用B，然后A、B的采样比例不一样，就会出现一个Trace串不起来的情况。

日志的保存时间

一般来说，日志不需要永久保存，通常是保存3个月的数据，关于这一点大家结合公司的实际情况进行配置即可。

按照以前的设计方案，需要自己设计一个工具将数据进行定时清理，不过此时可以直接使用SkyWalking进行配置，代码如下所示。

集群配置：如何确保高可用

先来看看SkyWalking官方文档给出的SkyWalking架构，如图9-7所示。

在此架构中，需要关注SkyWalking的收集服务（Receiver）和聚合服务（Aggregator），它们支持集群模式。同时，在集群服务里，多个服务节点又需要一些协调服务来协调服务间的关系，它们支持Kubernetes、ZooKeeper、Consul、etcd、Nacos（开源的协调服务基本都支持）。

• 图9-7 SkyWalking的架构

前面多次提及ZooKeeper，此时大家应该猜得到项目组最终的选型。

小结

在方案中使用SkyWalking后，对于问题排查帮助非常大。比如再碰到类似登录失败的问题时，根据关键字查到TraceID以后，基于TraceID调出所有的请求日志，到底发生了什么就会一目了然。

这个全链路日志系统上线以后，团队优化了很多慢请求，因为每个调用环节和耗时都列出来了，很容易就能找到瓶颈点并加以解决。基于这个系统，团队完成了多个可以汇报的亮点工作。

但是SkyWalking也存在不足，比如一开始使用的版本存在很多兼容性问题。不过现在它改善不少，只要使用最新版，基本上问题不大。

这次的架构经历不涉及太多的架构设计，主要是技术选型和一些注意事项。希望通过上面的讲解，帮助大家快速理解全链路日志，并针对技术选型问题快速做出决策。

本文给大家讲解的内容是基于常见组件的微服务场景实战，全链路日志的注意事项