当前企业级分布式微服务集群架构图，服务链路追踪已成为不可或缺的一环。
skywalking 是一个优秀的国产开源框架，2015年由个人吴晟（华为开发者）开源 ，2017年加入 apache 孵化器。
skywalking 是分布式系统的应用程序性能监视工具，专为微服务、云原生架构和基于容器化技术 （docker、K8s、Mesos）架构而设计，它是一款优秀的 APM（Application Performance Management）工具。skywalking是观察性分析平台和系统。提供分布 式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。
SkyWalking通过加载探针的方式收集应用调用链路信息，并对采集的调用链路信息进行分析，生成应用间关系和服务间关系以及服务指标。Apache SkyWalking (Incubating)目前支持多种语言，其中包括Java，.Net Core ，Node.js和Go语言。
总览视图是应用和组件的全局视图，其中包括组件应用数量，应用的告警波动，慢服务列表以及应用吞吐量；拓扑图从应用依赖关系出发，展现整个应用的拓扑关系；应用视图则是从单个应用的角度，展现应用的上下游关系，TopN的服务和服务器，JVM的相关信息以及对应的主机信息。服务视图关注单个服务入口的运行情况以及此服务的上下游依赖关系，依赖度，帮助用户针对单个服务的优化和监控；调用链展现了调用的单次请求经过的所有埋点以及每个埋点的执行时长；告警视图根据配置阈值针对应用、服务器、服务进行实时告警。
SkyWalking中默认使用的端口有8080、11800、12800，请保证这些端口未被占用。
性能对比
模拟了三种并发用户：500，750，1000。使用jmeter测试，每个线程发送30个请求，设置思考时间为10ms。使用的采样率为1，即 100%，这边与生产可能有差别。pinpoint默认的采样率为20，即50%，通过设置agent的配置文件改为100%。zipkin默认也是1。组合 起来，一共有12种。下面看下汇总表：
从上表可以看出，在三种链路监控组件中，skywalking的探针对吞吐量的影响最小，zipkin的吞吐量居中。pinpoint的探针对吞吐量的 影响较为明显，在500并发用户时，测试服务的吞吐量从1385降低到774，影响很大。然后再看下CPU和memory的影响，在内部服务器 进行的压测，对CPU和memory的影响都差不多在10%之内。
捋清业务
我们都知道，在一般场景下，我们很难直观的了解系统的运行、业务的流程，因为传统的都是文字需求说明和枯燥的代码。通过链路追踪，可以根据调用链路来捋清楚服务间的调用关系，如果 API 设计符合规范，甚至可以直观的了解调用的服务作用。这对于刚刚接触系统的开发人员十分重要。
分析耗时
链路的基本功能，服务间的调用耗时记录，如果服务耗时过长，会影响整体的用户体验，甚至会抛出超时异常等，这样的情况在微服务架构中也是时有发生。
可视化错误
微服务调用链路发生错误，可以直观的显示查看，定位到被调用服务的接口，及时排查微服务中错误原因。
优化链路
显示完整的调用链路，根据业务分析合理性、可读性、健壮性，是否重复调用某一个服务，是否链路过长，有没有可以优化的，链路是否清晰。有些场景比较复杂，比如数据中心比较分散，服务分布在不同的数据中心，但是服务中心之间因为地域原因，距离远，延迟高，这可能不符合设计要求，因此就要根据链路来找到最近的数据中心，然后配置调用最近的数据中心的服务。
生成网络拓扑
通过服务追踪系统中记录的链路信息，可以生成一张系统的网络调用拓扑图，它可以反映系统都依赖了哪些服务，以及服务之间的调用关系是什么样的，可以一目了然。除此之外，在网络拓扑图上还可以把服务调用的详细信息也标出来，也能起到服务监控的作用。
查看官网版本
我们使用es作为存储最好是使用明确存储了方式的版本 8.7.0。
拉取镜像
####### 尝鲜版
稳定版
备份镜像
docker-compose 启动SkyWalking
docker-compose的安装
编写SkyWalking的docker-compose文件
这里使用最新版本的Skywalking镜像。
启动服务
查看启动
测试SkyWalking的UI界面
在浏览器输入 例如：
skywalking 就介绍到这里，本章节仅仅只是入门，简单使用skywalking，实际上里面还有很多功能没有介绍，有兴趣的同学可以按照上面的教程安装部署，然后自己探索一下。在现在微服务架构比较流行的环境下，如果没有一个调用链追踪框架，会导致很难排查线上服务调用的问题。skywalking是目前发展势头最快的技术框架的技术框架，因为对代码是无侵入性的，所以目前很多公司都采用skywalking。