SkyWalking的OAP（Observability Analysis Platform，观测分析平台）是一个用于链路数据的分布式计算系统。
因为它巧妙的设计，使得在链路数据计算和聚合过程中，不需要考虑数据的一致性，也没有事务、分布式锁等概念。
在极端情况下，可能出现链路数据的丢失,但会最大限度保障OAP集群的可用性。咱们来看一下，它是如何设计的，为以后的系统设计和架构提供一些思路。
数据类型
在介绍分布式计算之前，咱们先了解一下需要计算的数据都有哪些类型：
- Record数据，即明细数据，如Trace、访问日志等数据，由
RecordStreamProcessor进行处理。 - Metrisc数据，即指标数据，绝大部分的OAL指标都会生成这种数据，由
MetricsStreamProcessor进行处理。 - TopN数据，即周期性采样数据，如慢SQL的周期性采集，由
TopNStreamProcessor进行处理。
分布式计算
像Trace、访问日志等这样的明细数据，数据量比较大，但是不需要归并处理，所以在OAP节点内部处理即可完成。明细数据采用缓存、异步批量处理和流式写入的方式写入到存储中。
绝大部分由OAL（Observability Analysis Language，观测分析语言）定义的指标数据是需要分布式聚合计算的，所以在OAP集群计算流中分成了两种步骤。
步骤一：接收和解析探针发送的数据，并进行当前OAP节点内的数据聚合，使用OAL或者其他聚合模式。如果是不需要分布式聚合的数据，直接写入到存储中；如果是需要分布式聚合的数据，根据一定的路由规则发送给指定的OAP节点。
步骤二：接收和解析经步骤一处理过的数据，然后进行二次聚合计算，并写入到存储中。
因为上面两个步骤极有可能不在同一个OAP节点上，所以OAP节点被分为Receiver（步骤一）和Aggregator（步骤二）两种角色。
为了减少部署难度，所有OAP节点在默认情况下都会使用Mixed角色（既可以进行步骤一的操作，也可以进行步骤二的操作）。在大规模部署的时候，可以根据网络流量进行角色分离的两级部署。
指标数据是计算资源消耗最大的分布式计算，也是整套分布式计算要支持的核心计算类型。在此计算过程中，使用哈希路由策略，根据计算的实体，如服务ID、端点ID等的哈希值来选择对应的OAP节点。
OAP节点之间的通信采用的是 gRPC stream 模式，传输过程中不包含业务字段名称，按照数据类型和字段定义顺序进行序列化，减少非数据字段的传输。
注：本文以SkyWalking的8.2.0版本为例进行介绍，如果版本不同会略有差异。
最后，感谢你的点赞、推荐和关注，帅气又美丽。
随时随地看视频
