（01）SkyWalking简介
SkyWalking专为微服务，云原生架构和基于容器（Docker，k8s，Mesos等）的架构设计的应用程序性能监控工具，用于收集、分析、聚合和可视化来自服务和云原生基础设施的数据。提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。SkyWalking主要由以下四大部分构成：
（02）Agent代理程序
探针收集数据并根据SkyWalking的要求对数据进行重新格式化，Agent运行在各个服务实例中，负责采集服务实例的Trace、Metrics等数据，然后通过gRPC方式上报给SkyWalking后端，供OAP服务器进行分析。
（03）OAP服务器
SkyWalking的OAP（Observability Analysis Platform，观测分析平台）是一个用于分析链路采样数据的分析计算系统。在OAP服务主要需要计算以下三类数据：
1）Record数据，记录的链路数据，如Trace、访问日志等数据，由RecordStreamProcessor进行处理。
2）Metrics数据，记录的指标数据，绝大部分的OAL（Observability Analysis Language）指标都将生成这类数据，由MetricsStreamProcessor进行处理。
3）TopN数据，记录的周期性的采样数据，如慢SQL的周期性采集，由TopNStreamProcessor进行处理。

Trace、访问日志等这类的明细数据，数据量比较大，不需要归并处理，在OAP节点内部即可处理完成，采用缓存、异步批量处理和流式写入的方式将它们写入到外部存储器中。

绝大部分由OAL（Observability Analysis Language）定义的指标数据是需要微服务聚合计算的，在OAP集群计算流中将其分为了两个步骤。

步骤一，接收和解析Agent代理程序发送的数据，并执行当前OAP服务节点内的数据聚合，使用OAL或其他聚合模式。对于不需要聚合的数据，直接将其写入到外部存储器中；如果是需要微服务聚合的数据，根据一定的路由规则发送给指定的OAP服务节点。

步骤二，接收和解析经步骤一处理的数据，之后进行二次聚合计算，并将结果数据写入到外部存储器中。

针对以上两个步骤，OAP服务节点被分为Receiver（处理步骤一）和Aggregator（处理步骤二）两种角色。

默认情况下，所有OAP服务节点均为Mixed混合角色，其既可以执行步骤一的操作，也可以执行步骤二的操作。在大规模系统部署SkyWalking的场景下，可根据网络流量进行角色分离的两级部署。

配置文件application.yml：
core:
selector: ${SW_CORE:default}
default:
# Mixed: Receive agent data, Level 1 aggregate, Level 2 aggregate
# Receiver: Receive agent data, Level 1 aggregate
# Aggregator: Level 2 aggregate
role: ${SW_CORE_ROLE:Mixed} # Mixed/Receiver/Aggregator

OAP服务器还服务响应SkyWalking UI界面发送来的查询请求，将前面持久化的数据查询出来，组成正确的响应结果返回给UI界面进行展示。

（04）Storage数据库存储
作为OAP服务的外部存储设备，负责数据的存储，支持多种存储类型，可以使用既有的存储系统，如ElasticSearch，Mysql等，也可以自定义实现存储系统。SkyWalking数据可以选择存储在已实现的ElasticSearch,Mysql,TiDB,InfluxDB，H2的持久化系统，其中H2是内存数据库，重启SkyWalking服务会导致数据丢失，是默认的存储方式，一般线上使用ElasticSearch集群作为其后端存储（MySQL小数据量）。

（05）UI界面
负责可视化和管理SkyWalking数据，前后端分离，该UI界面负责将用户的查询操作封装为GraphQL请求提交给OAP后端触发后续的查询操作，待拿到查询结果之后会在前端负责展示并可以查看链路调用关系，查看各种监控指标，性能指标等等。

（06）说明
Log: 日志，Skywalking中需要进行特殊的配置才能显示日志信息，无侵入的性能监控不能显示日志。
Trace: 链路追踪，能够反映输出接口的调用链，比如这个接口调用其他的接口，调用了哪个数据库等等。
Metrics: 度量信息，Skywalking中的所有的图表展示的数据信息统称为metric。

（07）Trace概念

（08）系统架构

（09）模块通讯
RPC与Http协议：RPC中可以使用HTTP作为通讯协议。RPC是一种设计、实现框架，通讯协议只是其中一部分。
RPC：提供了一种轻量无感知的跨进程通信的方式，在分布式机器上调用其他方法与本地调用无异（远程调用的过程是透明的，并不知道这个调用的方法是部署在哪里，通过PRC能够解耦服务）。RPC是根据语言的API来定义的，而不是基于网络的应用来定义的，调用更方便，协议私密更安全、内容更小效率更高。
Http：在接口不多、系统与系统交互较少的情况下，解决信息孤岛初期常使用的一种通信手段；优点是简单、直接、开发方便。利用现成的http协议进行传输。但如果是一个大型的网站，内部子系统较多、接口非常多的情况下，RPC框架的好处就显示出来了，首先（基于TCP协议的情况下）就是长链接，不必每次通信都要像http 一样去3次握手，减少了网络开销；其次就是RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。第三个来说就是安全性。最后就是流行的服务化架构、服务化治理，RPC框架是一个强力的支撑。

RPC要做的三个事情
建立通信：在客户端与服务端建立起数据传输通道，大都是TCP连接（gRPC使用了HTTP2）。
寻址：A服务器上的应用需要告诉RPC框架：B服务器地址、端口，调用函数名称。必须实现待调用方法到call ID的映射。
序列化与反序列化：由于网络协议都是二进制的，所以调用方法的参数在进行传递时首先要序列化成二进制，B服务器收到请求后要再对参数进行反序列化。恢复为内存中的表达方式，找到对应的方法进行本地调用，得到返回值。返回值从B到A的传输仍要经过序列化与反序列化的过程。
Skywalking中的通信模型如下：

其中探针与服务端使用了Grpc通信，如果使用Kafka来替代Grpc，可以防止数据服务挂掉的时候数据丢失。但引入了一层缓存，直接影响了数据的时效性，还要维护额外的中间件，性能可能会存在额外的开销。
官方目前仅支持kafka与Grpc。