基于WebRTC构建应用的可复用模块

WebRTC基础设施在PCDN客户端中的使用策略

在基于WebRTC开发P2P CDN客户端时，对于WebRTC基础设施组件的使用策略需要根据具体情况权衡。

决策流程图

是 否 小修改 大修改 是 否 组件评估 是否直接满足需求 直接使用 是否需要修改 封装适配层 是否核心组件 复制并修改 寻找替代方案

详细策略分析

1. 直接使用WebRTC基础设施（推荐）

classDiagram class PCDNClient { +rtc::Thread worker_thread_ +rtc::Event shutdown_event_ +rtc::Buffer packet_buffer_ } PCDNClient --> rtc::Thread PCDNClient --> rtc::Event PCDNClient --> rtc::Buffer

适用组件：

• 线程管理（rtc::Thread, TaskQueue）

• 事件通知（rtc::Event）

• 内存管理（rtc::Buffer, CopyOnWriteBuffer）

• 日志系统（RTC_LOG）

• 时间管理（rtc::TimeMillis, Timestamp）

优势：

• 减少重复开发

• 保证稳定性和性能

• 跨平台兼容性

• 持续获得WebRTC社区更新

实现方式：

#include "rtc_base/thread.h"
#include "rtc_base/event.h"

class PCDNClient {
public:
    PCDNClient() : worker_thread_(rtc::Thread::Create()) {
        worker_thread_->Start();
    }
    
    void Process() {
        worker_thread_->PostTask([this] {
            // 在工作线程处理任务
            shutdown_event_.Wait(rtc::Event::kForever);
        });
    }

private:
    std::unique_ptr<rtc::Thread> worker_thread_;
    rtc::Event shutdown_event_;
};

2. 封装适配层（中等修改需求）

PCDN客户端 适配层 WebRTC基础设施

适用场景：

• 需要扩展功能

• 需要统一接口

• 需要隔离变化

实现示例：

// network_adapter.h
class NetworkAdapter {
public:
    virtual bool SendPacket(const rtc::Buffer& packet) = 0;
    virtual ~NetworkAdapter() = default;
};

// webrtc_network_adapter.h
#include "rtc_base/socket.h"

class WebRTCNetworkAdapter : public NetworkAdapter {
public:
    WebRTCNetworkAdapter() {
        socket_.reset(rtc::Thread::Current()->socketserver()
            ->CreateSocket(AF_INET, SOCK_DGRAM));
    }
    
    bool SendPacket(const rtc::Buffer& packet) override {
        return socket_->Send(packet.data(), packet.size()) > 0;
    }

private:
    std::unique_ptr<rtc::Socket> socket_;
};

3. 复制并修改（特殊需求）

PCDN客户端 定制组件 修改的WebRTC组件

适用场景：

• 需要深度优化（如内存池）

• 需要特殊行为（如自定义调度策略）

• 许可证冲突

• WebRTC组件无法满足极端性能需求

实现方式：

1. 复制相关源文件到项目目录
2. 重命名命名空间（避免冲突）
3. 进行必要修改
4. 添加项目特定优化

示例目录结构：

pcdn_project/
├── src/
│   ├── pcdn_core/
│   └── webrtc_forked/
│       ├── rtc_base/
│       │   ├── event.h
│       │   └── event.cc
│       └── BUILD.gn
└── third_party/
    └── webrtc/  # 原始WebRTC

各组件具体建议

1. 线程模型

建议：直接使用rtc::Thread和TaskQueueBase

2. 网络I/O

建议：封装PhysicalSocketServer和AsyncSocket

3. 事件通知

建议：直接使用rtc::Event

4. 内存管理

建议：直接使用rtc::Buffer，特殊场景可自定义内存池

风险与挑战

1. 版本升级问题

WebRTC升级 API变化 适配层失效 客户端故障

解决方案：

• 使用稳定的WebRTC分支（如M系列）

• 封装稳定接口层

• 编写兼容性测试

2. 性能问题

WebRTC通用设计 可能包含额外开销 额外开销 影响PCDN性能

解决方案：

• 性能关键路径绕过抽象层

• 选择性重写热点组件

• 使用轻量级替代方案

3. 依赖管理

大依赖树 构建复杂 开发效率低

解决方案：

• 使用Bazel管理依赖

• 仅包含必要组件

• 使用WebRTC子模块

最佳实践建议

1. 分层架构设计

应用层 业务逻辑层 适配层 WebRTC基础设施 操作系统

2. 组件选择矩阵

组件	推荐策略	理由	风险控制
线程管理	直接使用	成熟稳定	保持版本一致
网络I/O	封装适配	需要定制超时	保留原始接口
事件通知	直接使用	高效可靠	无
内存管理	直接使用	优化充分	特殊场景测试
日志系统	封装适配	需要统一格式	兼容原始日志
时间管理	直接使用	高精度计时	无

3. 代码组织建议

pcdn_project/
├── src/
│   ├── core/              # PCDN核心逻辑
│   ├── adapters/          # WebRTC适配层
│   │   ├── thread_adapter.cc
│   │   ├── network_adapter.cc
│   ├── third_party/
│   │   └── webrtc/        # WebRTC源码（只读）
│   └── main.cc
├── include/
│   └── pcdn/
│       ├── core/
│       └── adapters/
└── BUILD.bazel            # 构建配置

4. 构建系统集成

# BUILD.bazel 示例
cc_library(
    name = "webrtc_infra",
    srcs = [
        "//third_party/webrtc/rtc_base/thread.cc",
        "//third_party/webrtc/rtc_base/event.cc",
    ],
    hdrs = [
        "//third_party/webrtc/rtc_base/thread.h",
        "//third_party/webrtc/rtc_base/event.h",
    ],
    defines = ["WEBRTC_POSIX"],
)

cc_library(
    name = "network_adapter",
    srcs = ["src/adapters/network_adapter.cc"],
    deps = [":webrtc_infra"],
)

总结

1. 优先直接使用：对于成熟稳定的基础设施（线程、事件、时间），直接使用WebRTC实现

2. 封装适配层：对于需要定制或可能变化的组件（网络I/O、日志），创建适配层

   PCDN业务代码 适配接口 WebRTC实现 自定义实现

3. 谨慎复制修改：仅在极端性能需求或特殊场景下复制修改WebRTC组件，并注意：

   • 保持与原组件的兼容性

   • 添加详细修改注释

   • 定期同步上游更新

4. 统一基础设施：建立项目级的公共基础设施库，封装WebRTC组件：

   namespace pcdn {
   namespace infra {
       using Thread = rtc::Thread;
       using Event = rtc::Event;
       
       class NetworkSocket {
           // 封装WebRTC网络接口
       };
   } // namespace infra
   } // namespace pcdn

5. 性能监控：对基础设施组件进行持续性能监控：

最终建议采用混合策略：

• 80%直接使用WebRTC基础设施

• 15%通过适配层使用

• 5%自定义实现（仅限性能关键路径）

这样既能利用WebRTC的成熟基础设施，又能保持项目的灵活性和性能优化空间。