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

注意事项

在使用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也存在不足，比如一开始使用的版本存在很多兼容性问题。不过现在它改善不少，只要使用最新版，基本上问题不大。

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

本文给大家讲解的内容是基于常见组件的微服务场景实战，全链路日志的注意事项下篇文章给大家讲解的内容是基于常见组件的微服务场景实战大数据架构图，熔断，业务场景：如何预防一个服务故障影响整个系统觉得文章不错的朋友可以转发此文关注小编；感谢大家的支持！

（编辑：淮北站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!