23、skywalking地址和服务名的映射分析-解释一次拓扑依

一、现象概述：

1. 应用状态：

A 应用 实际是调用了 B（未接skywalking），并没有调用 C(接入skywalking)。

2. 现象：

2.1 trace信息

A只有调用B的链路信息

2.2 拓扑信息

A没有依赖B ，却依赖了C

3. 原因总结：

• 3.1 B没有接skywalking，所以其IP bb 信息没有映射到 应用B

• C 接入了skywalking，所以其IP cc 信息会映射到C

若应用出现过漂移，即应用C 使用过 IP bb ，那么就会存在一个IP bb 到应用 C的映射记录。

后来IP bb 又被应用B使用，但是应用B没有接入skywalking，所以不会有一个IP bb 到应用B的映射记录，即IP bb 始终在应用C的名下。

所以拓扑信息中A对 B应用 IP bb的调用，从服务名称中显示为 A对C的调用。

二、 源码分析

1. PEER 地址 映射为 服务名概述

EntrySpan 会接收到 ExitSpan 的 ref信息

• exitSpan 所创建的 ref 里的peer（ip\域名 地址信息) 就关联到了 EntrySpan所在Service 和 其实例
• exitSpan 的startTime 作为 NetworkAddressAliasSetup 的MinuteTimeBucket

2. 存储

NetworkAddressAliasMappingListener#parseEntry 根据entry中的ref 构建NetworkAddressAliasSetup
Source -> StorageData : NetworkAddressAliasSetup 转换为 NetworkAddressAlias
NetworkAddressAliasEsDAO 将 NetworkAddressAlias 存储到索引network_address_alias中
内容形如下：

{
    "_index":"sw_network_address_alias-20211105",
    "_type":"_doc",
    "_id":"xxxx",
    "_version":1,
    "_score":1,
    "_source":{
        "address":"1.74.11.60:20880",
        "last_update_time_bucket":202111051035,
        "represent_service_instance_id":"xxxx",
        "represent_service_id":"yyyyy",
        "time_bucket":202111051035
    }
}

2. 使用

CacheUpdateTimer 定时 将 地址和 服务的映射关系 加载到进程缓存中，之后尝试以peer地址为key从缓存中获取服务名称。

if (addressInventoryCache.currentSize() == 0) {
    loadStartTime = TimeBucket.getMinuteTimeBucket(System.currentTimeMillis() - 60_000L * 60 * 24 * ttl); //初始状态下，全量更新： 近10 天的数据
} else {
    loadStartTime = TimeBucket.getMinuteTimeBucket(System.currentTimeMillis() - 60_000L * 10);//差异更新：近10分钟的数据
}