一.skywalking的简单介绍
skywalking是一个开源的观测平台, 用于从服务和云原生基础设施收集, 分析, 聚合以及可视化数据，它提供了一种简便的方式来清晰地观测分布式系统, 甚至可以观测横跨不同云的系统
二.名词解释
服务(Service)：表示对请求提供相同行为的一系列或一组工作负载. 在使用打点代理或 SDK 的时候, 你可以定义服务的名字. 如果不定义的话, SkyWalking 将会使用你平台上定义的名字
服务实例(Service Instance)：上述的一组工作负载中的每一个工作负载称为一个实例. 就像 Kubernetes 中的 pods 一样, 服务实例未必就是操作系统上的一个进程. 但当你在使用打点代理的时候, 一个服务实例实际就是操作系统上的一个真实进程
端点(Endpoint)：对于特定服务所接收的请求路径, 如 HTTP 的 URI 路径和 gRPC 服务的类名 + 方法签名.
三.架构（6.0架构图）
平台后端是一个支持集群模式运行的后台, 用于数据聚合, 数据分析以及驱动数据流从探针到用户界面的流程. 平台后端还提供了各种可插拔的能力, 如不同来源数据(如来自 Zipkin)格式化, 不同存储系统以及集群管理. 你甚至还可以使用观测分析语言来进行自定义聚合分析
存储是开放式的. 你可以选择一个既有的存储系统, 如 ElasticSearch, H2 或 MySQL 集群(Sharding-Sphere 管理), 也可以选择自己实现一个存储系统. 当然, 我们非常欢迎你贡献新的存储系统实现
用户界面对于 SkyWalking 的最终用户来说非常炫酷且强大. 同样它也是可定制以匹配你已存在的后端的
架构简单说明：SkyWalking 的核心是数据分析和度量结果的存储平台，通过 HTTP 或 gRPC 方式向 SkyWalking Collecter 提交分析和度量数据，SkyWalking Collecter 对数据进行分析和聚合，存储到 Elasticsearch、H2、MySQL、TiDB 等其一即可，最后我们可以通过 SkyWalking UI 的可视化界面对最终的结果进行查看。Skywalking 支持从多个来源和多种格式收集数据：多种语言的 Skywalking Agent 、Zipkin v1/v2 、Istio 勘测、Envoy 度量等数据格式。
整体架构看似模块有点多，但在实际上还是比较清晰的，主要就是通过收集各种格式的数据进行存储，然后展示。所以搭建 Skywalking 服务我们需要关注的是 SkyWalking Collecter、SkyWalking UI 和 存储设备，SkyWalking Collecter、SkyWalking UI 官方下载安装包内已包含，最终我们只需考虑存储设备即可
四.限制
那么skywalking是否真的就天下无敌呢？成也探针，败也探针，限制就在它身上。
1.进程内传播在大多数情况下成为可能。许多高级编程语言(如 Java, .NET)都是用于构建业务系统. 大部分业务逻辑代码对于每一个请求来说都运行在同一个线程内, 这使得传播是基于线程 ID 的, 以确保上下文是安全的.
2.仅仅对某些框架和库奏效。因为是代理来在运行时修改代码的, 这也意味着代理插件开发者事先就要知道 所要修改的代码是怎么样的. 因此, 在这种探针下通常会有一个已支持的列表清单.支持服务列表：
https://github.com/apache/skywalking/blob/master/docs/en/setup/service-agent/java-agent/Supported-list.md
3.跨线程可能并非总是奏效 如上所述, 每个请求的代码大都运行在一个线程之内, 对于业务代码来说尤其如此. 但是在其他一些场景下, 它们也会在不同线程下工作, 比如指派任务到其他线程, 任务池, 以及批处理. 对于一些语言, 可能还提供了协程或类似的概念如 Goroutine, 使得开发者可以低开销地来执行异步操作, 在这些场景下, 自动打点可能会遇到一些问题
补充知识：
五.什么是APM系统
1.APM系统概述
APM (Application Performance Management) 即应用性能管理系统，是对企业系统即时监控以实现
对应用程序性能管理和故障管理的系统化的解决方案。应用性能管理，主要指对企业的关键业务应用进行监测、优化，提高企业应用的可靠性和质量，保证用户得到良好的服务，降低IT总拥有成本。
APM系统是可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。
2 分布式链路追踪
随着分布式系统和微服务架构的出现，一次用户的请求会经过多个系统，不同服务之间的调用关系十分复杂，任何一个系统出错都可能影响整个请求的处理结果。以往的监控系统往往只能知道单个系统的健康状况、一次请求的成功失败，无法快速定位失败的根本原因
简单服务调用图
除此之外，复杂的分布式系统也面临这下面这些问题：
性能分析：一个服务依赖很多服务，被依赖的服务也依赖了其他服务。如果某个接口耗时突然变长
了，那未必是直接调用的下游服务慢了，也可能是下游的下游慢了造成的，如何快速定位耗时变长
的根本原因呢？
链路梳理：需求迭代很快，系统之间调用关系变化频繁，靠人工很难梳理清楚系统链路拓扑 (系统
之间的调用关系)。
为了解决这些问题，Google 推出了一个分布式链路跟踪系统 Dapper ，之后各个互联网公司都参照
Dapper 的思想推出了自己的分布式链路跟踪系统，而这些系统就是分布式系统下的APM系统
3 什么是OpenTracing
分布式链路跟踪最先由Google在Dapper论文中提出，而OpenTracing通过提供平台无关、厂商无关
的API，使得开发人员能够方便的添加（或更换）追踪系统的实现。
下图是一个分布式调用的例子，客户端发起请求，请求首先到达负载均衡器，接着经过认证服务，订单服务，然后请求资源，最后返回结果
分布式调用
虽然这种图对于看清各组件的组合关系是很有用的，但是存在下面两个问题：
1）.它不能很好显示组件的调用时间，是串行调用还是并行调用，如果展现更复杂的调用关系，会更加复杂，甚至无法画出这样的图。
2）这种图也无法显示调用间的时间间隔以及是否通过定时调用来启动调用
一种更有效的展现一个调用过程的图：
调用时间图
基于OpenTracing我们就可以很轻松的构建出上面这幅图
网友评论