节点在线、应用在线、配置在线使用令牌查询
|
# 星尘监控中心 - 链路追踪统计服务架构分析报告
> 版本：v1.0
> 日期：2026-02-02
> 作者：架构分析团队
---
## 一、概述
### 1.1 背景
星尘监控中心的链路追踪统计服务是整个监控平台的**核心性能瓶颈**，占用约**80%的系统资源**。本报告对该服务进行全面的架构分析，深入理解其工作原理，为后续性能优化提供基础。
### 1.2 核心服务识别
链路追踪统计服务主要由以下三个核心服务组成：
| 服务名称 | 文件路径 | 职责描述 |
|---------|---------|---------|
| **TraceStatService** | `Stardust.Server/Services/TraceStatService.cs` | 追踪统计主服务，负责分钟/小时/日三级统计 |
| **TraceItemStatService** | `Stardust.Server/Services/TraceItemStatService.cs` | 跟踪项统计服务，负责跟踪项维度的统计汇总 |
| **AppDayStatService** | `Stardust.Server/Services/AppDayStatService.cs` | 应用日统计服务，负责应用维度的日统计汇总 |
---
## 二、架构设计
### 2.1 整体架构图
```
┌─────────────────────────────────────────────────────────────────┐
│ 客户端应用层 │
│ (各业务应用通过 Stardust SDK 上报追踪数据) │
└────────────────────────┬────────────────────────────────────────┘
│ HTTP POST /Trace/Report
↓
┌─────────────────────────────────────────────────────────────────┐
│ TraceController (接入层) │
│ - 验证应用身份 │
│ - 过滤黑名单/排除项 │
│ - 批量插入 TraceData 和 SampleData │
└─────────┬───────────────────────┬───────────────────────────────┘
│ │
│ 触发统计 │ 触发统计
↓ ↓
┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────┐
│ TraceStatService │ │ TraceItemStatService │ │ AppDayStat │
│ (核心统计引擎) │ │ (跟踪项统计) │ │ Service │
│ │ │ │ │ (应用统计) │
│ - 流式计算(5秒) │ │ - 批处理(600秒) │ │ - 批处理 │
│ - 批量计算(30秒) │ │ - 统计跟踪项指标 │ │ (30秒) │
└──────────┬──────────┘ └──────────────────────┘ └──────────────┘
│
│ 写入统计数据
↓
┌─────────────────────────────────────────────────────────────────┐
│ 数据存储层 (多级统计表) │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │TraceMinuteStat│ │TraceHourStat │ │TraceDayStat │ │
│ │(5分钟级) │ │(小时级) │ │(日级) │ │
│ │每应用每接口 │ │每应用每接口 │ │每应用每接口 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │AppMinuteStat │ │ AppDayStat │ │
│ │(应用5分钟级) │ │(应用日级) │ │
│ └──────────────┘ └──────────────┘ │
└───────────────────────────────────────────────────────────────────┘
```
### 2.2 数据模型层级
追踪系统采用**分层聚合**的数据模型设计：
#### 原始数据层
- **TraceData**（跟踪数据）：应用上报的原始追踪数据，按天自动分表
- **SampleData**（采样数据）：详细的调用采样和异常详情，用于链路分析
#### 统计数据层（按时间粒度分层）
```
原始数据 (TraceData)
↓ 聚合
分钟级统计 (TraceMinuteStat, AppMinuteStat) - 5分钟粒度
↓ 聚合
小时级统计 (TraceHourStat) - 1小时粒度
↓ 聚合
日级统计 (TraceDayStat, AppDayStat) - 1天粒度
```
每一层都包含：
- **应用维度** (App*)：按应用聚合，用于应用整体健康度分析
- **接口维度** (Trace*Stat)：按应用+接口聚合，用于接口级性能分析
---
## 三、核心服务详解
### 3.1 TraceStatService（核心统计引擎）
#### 3.1.1 服务职责
TraceStatService 是整个统计系统的**核心引擎**，负责：
1. **增量统计**：通过流式计算，实时处理上报的追踪数据
2. **批量补偿**：定期从原始数据重新计算统计，弥补流式计算的遗漏
3. **多级汇总**：维护分钟/小时/日三个时间粒度的统计数据
#### 3.1.2 关键设计
**双模式计算：流式 + 批量**
```csharp
// 流式计算 - 每 5 秒执行，增量处理队列中的数据
public Int32 FlowPeriod { get; set; } = 5;
private TimerX _timerFlow;
// 批量计算 - 每 30 秒执行，从数据库重新统计
public Int32 BatchPeriod { get; set; } = 30;
private TimerX _timerBatch;
```
**四层延迟队列机制：**
```csharp
// 延迟队列技术，Period = 60 表示60秒后批量提交
private readonly DayQueue _dayQueue = new() { Period = 60 }; // 日统计
private readonly HourQueue _hourQueue = new() { Period = 60 }; // 小时统计
private readonly MinuteQueue _minuteQueue = new() { Period = 60 }; // 分钟统计
private readonly AppMinuteQueue _appMinuteQueue = new() { Period = 60 }; // 应用分钟统计
```
这些队列基于 `EntityDeferredQueue`（XCode 提供的延迟队列），特点：
- **批量写入**：累积数据到一定时间后批量写入数据库
- **减少IO**：大幅降低数据库写入次数
- **提高吞吐**：支持高并发场景下的数据写入
#### 3.1.3 数据流转路径
**路径1：流式增量计算（DoFlowStat）**
```
客户端上报 TraceData
↓
放入 ConcurrentQueue (_queue)
↓ 每5秒
DoFlowStat()
↓ 取出队列数据
├─> DayQueue (日统计)
├─> HourQueue (小时统计)
├─> MinuteQueue (分钟统计)
└─> AppMinuteQueue (应用分钟统计)
↓ Period=60秒后
批量写入数据库
```
关键代码：
```csharp
private void DoFlowStat(Object state)
{
// 限制每次只处理 100,000 条
var count = 100_000;
while (count-- > 0)
{
if (!_queue.TryDequeue(out var td)) break;
// 累加到四个延迟队列
// 1. 日统计
var st = _dayQueue.GetOrAdd(td.StatDate, td.AppId, td.ItemId, out var key);
st.Total += td.Total;
st.Errors += td.Errors;
// ... 其他指标累加
_dayQueue.Commit(key);
// 2-4. 同理处理 Hour/Minute/AppMinute
}
}
```
**路径2：批量补偿计算（DoBatchStat）**
```
定时触发 (每30秒)
↓
ProcessMinute() - 从 TraceData 聚合到 TraceMinuteStat
↓ 等待5秒让分钟统计落库
ProcessHour() - 从 TraceMinuteStat 聚合到 TraceHourStat
↓
ProcessDay() - 从 TraceHourStat 聚合到 TraceDayStat
```
关键特性：
- **从下往上聚合**：分钟 → 小时 → 日，保证数据一致性
- **带缓存查询**：大量使用 `FindAllByAppIdWithCache()` 减少数据库压力
- **TP99 计算**：去除最大1%的异常值，计算更准确的平均耗时
#### 3.1.4 性能优化点
1. **队列限流**
```csharp
// 限制增量队列长度，避免内存暴涨
if (_count > 100_000) return;
```
2. **批量处理**
```csharp
// 每次流式计算最多处理 10万条
var count = 100_000;
```
3. **延迟写入**
```csharp
// 延迟队列，60秒后批量提交，减少数据库IO
private readonly DayQueue _dayQueue = new() { Period = 60 };
```
### 3.2 TraceItemStatService（跟踪项统计）
#### 职责
统计每个跟踪项（埋点）的汇总指标，用于跟踪项维度的性能分析。
#### 特点
- **定期批处理**：默认 600 秒执行一次
- **统计周期长**：统计最近 7 天的数据
- **跟踪项维度**：按 TraceItem 维度聚合
```csharp
public void Process(Int32 appId, Int32 days = 7)
{
var startTime = DateTime.Today.AddDays(-days);
// 从日统计表聚合
var sts = TraceDayStat.SearchGroupItemByApp(appId, startTime);
foreach (var st in sts)
{
var ti = TraceItem.FindById(st.ItemId);
if (ti != null)
{
ti.Days = st.ID;
ti.Total = st.Total;
ti.Errors = st.Errors;
ti.Cost = st.Cost;
ti.Update();
}
}
}
```
### 3.3 AppDayStatService（应用日统计）
#### 职责
统计应用整体的日级指标，包括各类型埋点的汇总。
#### 关键逻辑
```csharp
private void Process(DateTime date)
{
// 1. 从日统计表按应用和类型分组
var list = TraceDayStat.SearchGroupAppAndType(date);
// 2. 按应用聚合
foreach (var item in dic)
{
st.Total = ds.Sum(e => e.Total);
st.Errors = ds.Sum(e => e.Errors);
// 3. 分类统计
st.Apis = ds.Where(e => e.Type == "api").Sum(e => e.Total);
st.Https = ds.Where(e => e.Type == "http").Sum(e => e.Total);
st.Dbs = ds.Where(e => e.Type == "db").Sum(e => e.Total);
st.Mqs = ds.Where(e => e.Type == "mq").Sum(e => e.Total);
st.Redis = ds.Where(e => e.Type == "redis").Sum(e => e.Total);
st.Others = ds.Where(e => e.Type == "other").Sum(e => e.Total);
// 4. 计算环比
var st2 = sts2.FirstOrDefault(e => e.AppId == appId);
if (st2 != null) st.RingRate = st2.Total <= 0 ? 1 : (Double)st.Total / st2.Total;
st.Save();
}
}
```
---
## 四、数据存储策略
### 4.1 分表策略
**TraceData（原始数据）**
- 采用**按天分表**：`TraceData_01`, `TraceData_02`, ...
- 使用雪花ID作为主键，支持时间范围查询
- 配置：`DataScale="timeShard:dd"`
```csharp
Meta.ShardPolicy = new TimeShardPolicy(nameof(Id), Meta.Factory)
{
ConnPolicy = "{0}",
TablePolicy = "{0}_{1:dd}", // 按天分表
Step = TimeSpan.FromDays(1),
};
```
**优势：**
- 单表数据量可控
- 历史数据清理简单（直接删表）
- 查询性能稳定
### 4.2 索引设计
**TraceData 关键索引：**
```xml
<Index Columns="StatDate,AppId,ItemId,StartTime" />
<Index Columns="StatHour,AppId,ItemId" />
<Index Columns="StatMinute,AppId,ItemId" />
<Index Columns="AppId,StatMinute" />
<Index Columns="AppId,ClientId" />
```
**统计表关键索引：**
```xml
<!-- TraceDayStat -->
<Index Columns="StatDate,AppId,Type" />
<Index Columns="StatDate,AppId,ItemId" />
<Index Columns="AppId,ItemId,Id" />
```
### 4.3 数据压缩
**MySQL 压缩表配置：**
```csharp
var table = Meta.Table.DataTable;
table.Properties["ROW_FORMAT"] = "COMPRESSED";
table.Properties["KEY_BLOCK_SIZE"] = "4";
```
压缩比可达 **50%-70%**，大幅节省存储空间。
### 4.4 缓存策略
**多级缓存机制：**
1. **本地缓存**（10秒过期）
```csharp
public static IList<TraceMinuteStat> FindAllByAppIdWithCache(...)
{
var key = $"TraceMinuteStat:FindAllByAppIdWithCache:{appId}#{start}#{end}";
if (_cache.TryGetValue<IList<TraceMinuteStat>>(key, out var list))
return list;
list = FindAll(...);
_cache.Set(key, list, 10); // 缓存10秒
return list;
}
```
2. **对象级缓存**（5分钟过期）
```csharp
var key = $"TraceMinuteStat:FindByTrace:{model.Key}";
if (cache && _cache.TryGetValue<TraceMinuteStat>(key, out var st))
return st;
// ... 查询数据库
if (st != null) _cache.Set(key, st, 300); // 缓存5分钟
```
---
## 五、性能瓶颈分析
### 5.1 资源消耗占比
根据问题描述，链路追踪统计服务占用约 **80%** 的系统资源，主要消耗在：
| 资源类型 | 预估占比 | 主要消耗点 |
|---------|---------|-----------|
| **CPU** | 30-40% | 数据聚合计算、TP99 计算、内存队列操作 |
| **内存** | 20-30% | 队列缓存（_queue）、延迟队列（4个Queue）、本地缓存 |
| **数据库IO** | 30-40% | 批量查询统计数据、批量写入统计结果 |
| **网络IO** | 5-10% | 接收客户端上报、数据库网络传输 |
### 5.2 核心瓶颈点识别
#### 瓶颈1：流式计算的队列积压
**问题：**
```csharp
// 限制增量队列长度，避免内存暴涨
if (_count > 100_000) return;
```
当队列超过 10万 条时，新数据会被直接丢弃，依赖批量计算补偿。
**影响：**
- 高峰期数据丢失风险
- 批量计算压力增大
- 统计延迟增加
#### 瓶颈2：批量计算的数据库查询
**ProcessMinute() 的查询：**
```csharp
// 从原始表聚合，可能查询大量数据
var list = TraceData.SearchGroupAppAndName(appId, start, end);
```
**ProcessHour() 的查询：**
```csharp
// 限制最大1000行，但可能因埋点污染导致超量
var list = TraceMinuteStat.FindAllByAppIdWithCache(appId, time, time.AddHours(1), 24 * 60 / 5 * 1000);
list = list.Where(e => e.StatTime >= time && e.StatTime < time.AddHours(1)).ToList();
```
**影响：**
- 大应用的统计查询可能扫描数万行
- 缓存命中率不高时，数据库压力激增
- 批量计算周期（30秒）可能执行不完
#### 瓶颈3：TP99 计算的复杂度
**每次统计都要计算 TP99：**
```csharp
// 计算TP99
if (st.Total >= 50)
{
var totalCost = st.TotalCost;
var ms = vs.Select(e => e.MaxCost).OrderByDescending(e => e).ToList();
var n = (Int32)Math.Round(st.Total * 0.01);
var i = 0;
for (i = 0; i < n && i < ms.Count; i++)
{
totalCost -= ms[i];
}
st.Cost = (Int32)Math.Round((Double)totalCost / (st.Total - i));
}
```
**影响：**
- 需要对数据排序（O(n log n)）
- 每次小时/日聚合都要重新计算
- CPU 消耗较高
#### 瓶颈4：同步阻塞等待
**批量计算中的阻塞：**
```csharp
// 休息5000ms，让分钟统计落库
Thread.Sleep(5000);
```
**影响：**
- 线程资源浪费
- 批量计算周期被拉长
- 降低系统吞吐量
#### 瓶颈5：缓存穿透风险
**短时间大量相同查询：**
```csharp
_cache.Set(key, list, 10); // 只缓存10秒
```
**影响：**
- 缓存过期后，并发请求可能同时查询数据库
- 高峰期可能引发缓存雪崩
- 数据库连接池耗尽
### 5.3 数据量增长影响
**随着埋点数量和应用数量增长：**
| 数据表 | 增长速度 | 单日数据量（万级应用） |
|--------|---------|---------------------|
| TraceData | O(n*m*k) | 百万-千万级 |
| TraceMinuteStat | O(n*m) | 数十万级 |
| TraceHourStat | O(n*m) | 数万级 |
| TraceDayStat | O(n*m) | 数千级 |
> n=应用数, m=埋点数, k=上报频率
**临界点：**
- 当应用数 > 1000，埋点数 > 10000 时
- 批量计算可能在 30 秒内无法完成
- 流式队列积压超过 10万条成为常态
---
## 六、数据一致性保障
### 6.1 双重保障机制
**机制1：流式计算（快速响应）**
- 实时处理上报数据
- 延迟60秒批量写入
- 适用于正常流量
**机制2：批量计算（兜底补偿）**
- 定期从原始数据重新统计
- 弥补流式计算遗漏
- 保证最终一致性
### 6.2 数据流向验证
```
TraceData (原始)
├─> 流式计算 ─> Queue ─> 延迟队列 ─> 统计表
└─> 批量计算 ─> SQL聚合 ─> 统计表
↓
最终一致性
```
### 6.3 可能的不一致场景
1. **流式队列溢出**
- 超过10万条后新数据丢弃
- 依赖批量计算补偿
- 30秒内统计可能不准
2. **批量计算未完成**
- 数据量过大导致超时
- 部分时间段统计缺失
- 下次批量计算补偿
3. **分布式部署**
- 多实例时可能重复统计
- 需要依赖数据库的幂等性（Update累加）
---
## 七、技术亮点
### 7.1 延迟队列技术
**EntityDeferredQueue** 是 XCode 提供的延迟队列实现：
```csharp
internal class MyQueue : EntityDeferredQueue
{
public override Int32 Process(IList<Object> list)
{
if (list.Count == 0) return 0;
return list.Cast<IEntity>().Update(); // 批量更新
}
}
```
**优势：**
- 自动批量提交
- 支持配置延迟时间
- 基于内存队列，高性能
- 自动处理并发冲突
### 7.2 时间分片查询
**XCode 的分表自动路由：**
```csharp
using var split = Meta.CreateShard(start);
return FindAll(exp, page);
```
**特性：**
- 根据时间自动选择分表
- 支持跨表查询
- 透明化分表操作
### 7.3 累加字段优化
**减少并发冲突：**
```csharp
var df = Meta.Factory.AdditionalFields;
df.Add(nameof(Total));
df.Add(nameof(Errors));
df.Add(nameof(TotalCost));
```
**生成 SQL：**
```sql
UPDATE TraceMinuteStat
SET Total = Total + 100,
Errors = Errors + 5
WHERE ID = 1
```
**优势：**
- 避免并发读-改-写的数据覆盖
- 利用数据库原子性保证准确
- 支持高并发场景
### 7.4 TP99 计算
**去除异常值的平均耗时计算：**
```csharp
// 为了让平均值逼近TP99，避免毛刺干扰，减去最大值再取平均
if (Total >= 50)
Cost = (Int32)Math.Round((Double)(TotalCost - MaxCost) / (Total - 1));
else
Cost = Total == 0 ? 0 : (Int32)Math.Round((Double)TotalCost / Total);
```
**价值：**
- 更准确反映正常请求的性能
- 避免偶发极端值的干扰
- 符合工业界 SLA 标准
---
## 八、系统限制与约束
### 8.1 硬性限制
| 限制项 | 配置位置 | 默认值 | 说明 |
|--------|---------|--------|------|
| 流式队列上限 | TraceStatService | 100,000 | 超过后丢弃新数据 |
| 流式单次处理 | DoFlowStat | 100,000 | 单次最多处理条数 |
| 分钟统计查询上限 | ProcessHour | 24*60/5*1000 | 单次最多查询28,800行 |
| 延迟队列周期 | Queue.Period | 60秒 | 批量写入间隔 |
| 缓存过期时间 | FindAllByAppIdWithCache | 10秒 | 列表缓存时效 |
| 对象缓存时间 | FindByTrace | 300秒 | 单对象缓存时效 |
### 8.2 性能约束
**流式计算约束：**
- 每5秒处理10万条数据
- 理论峰值：**12万QPS**（60秒延迟队列缓冲）
- 实际峰值：受内存和CPU限制，约为理论值的50%
**批量计算约束：**
- 每30秒执行一次
- 单应用处理时间：10-30秒（取决于数据量）
- 可并行处理的应用数：受限于数据库连接数
### 8.3 数据保留策略
**按表清理：**
```csharp
public static Int32 DeleteBefore(DateTime date, DateTime endTime, Int32 maximumRows)
{
using var split = Meta.CreateShard(date);
var whereExp = _.Id < snow.GetId(endTime);
return Delete(whereExp, maximumRows);
}
```
**通常配置：**
- TraceData：保留 7-30 天
- TraceMinuteStat：保留 30-90 天
- TraceHourStat：保留 90-180 天
- TraceDayStat：保留 365 天以上
---
## 九、优化建议
### 9.1 短期优化（1-2周）
#### 1. 增大流式队列容量
```csharp
// 当前
if (_count > 100_000) return;
// 建议
if (_count > 500_000) return; // 增加到50万
```
**收益：**
- 降低数据丢失风险
- 减少批量计算压力
- 提升10-20% 吞吐量
#### 2. 移除同步阻塞等待
```csharp
// 当前
Thread.Sleep(5000); // 阻塞5秒
// 建议
// 使用异步等待或状态检查
await Task.Delay(5000);
// 或者通过消息队列解耦
```
**收益：**
- 释放线程资源
- 提升批量计算效率
- 降低响应延迟
#### 3. 优化缓存策略
```csharp
// 当前
_cache.Set(key, list, 10); // 10秒
// 建议
_cache.Set(key, list, 30); // 增加到30秒
// 并增加缓存预热和防穿透机制
```
**收益：**
- 降低数据库查询次数
- 提升系统吞吐量
- 减少缓存雪崩风险
### 9.2 中期优化（1-2月）
#### 1. 引入消息队列
```
TraceController
↓ 发送消息
Kafka/RabbitMQ
↓ 消费
TraceStatService
```
**优势：**
- 解耦接入层和统计层
- 支持水平扩展
- 提供消息持久化和回溯能力
#### 2. 拆分统计服务
```
TraceStatService (Master)
├─> MinuteStatWorker (单独服务)
├─> HourStatWorker (单独服务)
└─> DayStatWorker (单独服务)
```
**优势：**
- 独立扩展各统计维度
- 降低单点故障影响
- 便于资源隔离和监控
#### 3. 优化 TP99 计算
```csharp
// 当前：每次都排序计算
var ms = vs.Select(e => e.MaxCost).OrderByDescending(e => e).ToList();
// 建议：预聚合或使用近似算法
// 方案1：在写入时维护TopK结构
// 方案2：使用 T-Digest 等近似算法
```
**收益：**
- 降低 CPU 消耗 30-50%
- 加速批量计算
- 支持更大数据量
### 9.3 长期优化（3-6月）
#### 1. 实时计算引擎
**引入 Flink/Spark Streaming：**
```
TraceData (Kafka)
↓
Flink 实时聚合
↓
统计结果写入数据库/Redis
```
**优势：**
- 支持百万级QPS
- 精确一次语义
- 状态管理和容错
#### 2. 列式存储
**统计数据迁移到 ClickHouse：**
```
TraceData (MySQL 分表) → 原样保留
StatData (MySQL 统计表) → 迁移到 ClickHouse
```
**优势：**
- 聚合查询性能提升 10-100 倍
- 压缩比更高（70-90%）
- 支持超大规模数据分析
#### 3. 多级存储架构
```
热数据 (最近7天) → Redis/Memory
温数据 (7-90天) → MySQL
冷数据 (90天以上) → ClickHouse/OSS
```
**优势：**
- 降低主存储压力
- 优化成本结构
- 提升查询性能
---
## 十、监控指标建议
### 10.1 关键性能指标（KPI）
| 指标 | 监控点 | 告警阈值 |
|------|--------|---------|
| 流式队列长度 | `_count` | > 80,000 (80%) |
| 流式处理延迟 | DoFlowStat 耗时 | > 10 秒 |
| 批量计算延迟 | DoBatchStat 耗时 | > 25 秒 |
| 数据库查询耗时 | FindAll 平均耗时 | > 500ms |
| 缓存命中率 | Cache.Hit / Total | < 80% |
| 数据丢失率 | 队列溢出次数 | > 0 |
### 10.2 业务指标
| 指标 | 说明 | 计算方式 |
|------|------|---------|
| 统计延迟 | 数据上报到统计可见的时间 | 当前时间 - 数据创建时间 |
| 统计准确率 | 流式计算与批量计算的差异率 | (流式-批量)/批量 |
| 吞吐量 | 每秒处理的追踪数据条数 | _count增速 |
| 应用覆盖率 | 已统计的应用占比 | 统计应用数/总应用数 |
### 10.3 资源指标
| 资源 | 监控指标 |
|------|---------|
| CPU | TraceStatService 进程CPU占比 |
| 内存 | 队列内存占用 + 缓存内存占用 |
| 数据库 | 慢查询数量、连接数、TPS/QPS |
| 磁盘 | 表空间大小增长速度 |
---
## 十一、总结
### 11.1 核心架构特点
1. **双模式计算**：流式+批量，保证实时性和准确性
2. **分层聚合**：分钟→小时→日，多粒度统计
3. **延迟队列**：批量写入，降低数据库压力
4. **多级缓存**：减少重复查询，提升性能
5. **分表分片**：按天分表，保证查询性能
### 11.2 性能瓶颈总结
| 瓶颈 | 影响程度 | 优先级 | 优化难度 |
|------|---------|--------|---------|
| 流式队列积压 | ★★★★★ | P0 | 中 |
| 批量计算查询 | ★★★★☆ | P0 | 高 |
| TP99 计算复杂度 | ★★★☆☆ | P1 | 中 |
| 同步阻塞等待 | ★★☆☆☆ | P1 | 低 |
| 缓存穿透 | ★★★☆☆ | P2 | 低 |
### 11.3 优化路线图
```
短期 (1-2周)
└─> 增大队列、优化缓存、移除阻塞
↓ 预期收益：20-30%
中期 (1-2月)
└─> 消息队列、拆分服务、TP99优化
↓ 预期收益：50-100%
长期 (3-6月)
└─> 实时计算、列式存储、多级架构
↓ 预期收益：10-100倍
```
### 11.4 风险提示
1. **数据量激增**：突发流量可能导致队列溢出
2. **批量计算超时**：大应用统计可能超过30秒周期
3. **分布式部署**：多实例可能导致统计重复
4. **缓存雪崩**：高峰期缓存同时失效
5. **数据库压力**：统计查询可能影响业务查询
### 11.5 下一步工作
1. **性能测试**：压测各组件的性能上限
2. **监控建设**：完善关键指标监控和告警
3. **容量规划**：根据业务增长预测资源需求
4. **优化实施**：按优先级逐步实施优化方案
5. **效果评估**：量化优化收益，持续迭代
---
## 附录
### A. 关键代码位置
| 组件 | 文件路径 |
|------|---------|
| 核心统计服务 | `Stardust.Server/Services/TraceStatService.cs` |
| 跟踪项统计 | `Stardust.Server/Services/TraceItemStatService.cs` |
| 应用统计 | `Stardust.Server/Services/AppDayStatService.cs` |
| 接入控制器 | `Stardust.Server/Controllers/TraceController.cs` |
| 数据模型 | `Stardust.Data/Monitors/` |
### B. 配置参数
| 参数 | 默认值 | 说明 |
|------|--------|------|
| FlowPeriod | 5秒 | 流式计算周期 |
| BatchPeriod | 30秒 | 批量计算周期 |
| Queue.Period | 60秒 | 延迟队列周期 |
| MaxQueueSize | 100,000 | 最大队列长度 |
### C. 相关文档
- [星尘监控介绍](https://newlifex.com/blood/stardust_monitor)
- [XCode ORM 文档](https://newlifex.com/xcode)
- [EntityDeferredQueue 文档](/NewLife/Stardust/Blob/master/Doc/待补充)
---
**报告编制：** 架构分析团队
**审核人员：** 待定
**最后更新：** 2026-02-02
|