企业官网建设流程全解析

• 后端
• 音视频
• 即时通讯
• AI Agent

LiveKit 是一个开源（Apache License v2.0）的实时音视频基础设施项目，本仓库（livekit-server）是其核心服务器：一个用 Go 编写、基于 [Pion WebRTC] 实现的可扩展分布式 WebRTC SFU（Selective Forwarding Unit，选择性转发单元）。它让真实用户、设备与 AI Agent 以"参与者"的身份进入同一个房间，实时流动音频、视频与数据。阅读本文后，你将掌握 LiveKit 服务器的安装方式、开发模式启动流程、JWT 访问令牌生成、模拟推流验证、核心配置文件解读，以及从源码构建与生产部署的完整路径。

项目定位：连接人类与 AI 的端到端实时栈

LiveKit 官方的定位是"用于语音、视频和物理 AI Agent 的开源平台"，而本仓库正是这套体系中最关键的一环——媒体服务器。它承担的任务包括：

• 在人员、设备与 AI 模型之间转发实时音频、视频和数据流；
• 让参与方以统一方式加入房间，并支持 [Agent Dispatch] 自动或按需将 AI Agent 路由进房间；
• 为 Web、移动端、桌面端、嵌入式设备和服务器端提供完整 SDK 生态（浏览器、Swift、Android、Flutter、React Native、Rust、Node.js、Python、Unity、ESP32、C++ 等均有对应客户端 SDK）。

从源码结构看，服务器主体分布在cmd/server（可执行入口）、pkg/rtc（房间/参与者/传输管理）、pkg/sfu（媒体转发引擎）、pkg/service（房间分配、认证、Twirp API 等）与pkg/routing（节点路由）等包中，整体呈现典型的"单机可跑、多节点可扩"的分层设计。

核心特性一览

根据仓库 README，LiveKit 服务器的关键能力包括：

• 可扩展、分布式的 WebRTC SFU：媒体在服务器侧选择性转发，而非在客户端之间直连；
• 人、设备与 AI Agent 同房间协作：Agent 与浏览器/手机一样以参与者身份加入，支持 agent dispatch 自动路由；
• 现代化、功能完整的多端 SDK；
• 生产级设计，内置 JWT 认证；
• 健壮的网络与连接性：支持 UDP / TCP / TURN 多种传输路径；
• 部署简单：单个二进制、Docker 或 Kubernetes 均可；
• 高级媒体特性：speaker detection（说话人检测）、simulcast（联播）、selective subscription（选择性订阅）、moderation APIs（管理 API）、端到端加密、SVC 编码（VP9、AV1）、data tracks（低延迟遥测与远程操控数据通道）、SIP 电话接入、webhooks 事件通知、分布式与多区域部署。

其中"单二进制部署"在代码中可以得到印证：cmd/server/main.go将整个服务器编译为livekit-server单一可执行文件，Dockerfile 也只拷贝这一个产物作为最终镜像入口。

安装 LiveKit 服务器

README 推荐在安装服务器之外同时安装 [LiveKit CLI]，以便访问服务器 API、创建令牌、生成测试流量以及脚手架/部署 Agent。媒体服务器的安装方式按平台分为三种：

macOS

brew install livekit

Linux

curl -sSL https://get.livekit.io | bash

该安装脚本对应仓库根目录的 install-livekit.sh：脚本会自动从 GitHub Releases 查询最新版本（要求符合 SemVer 语义化版本号），识别架构（aarch64映射为arm64，x86_64映射为amd64），默认安装到/usr/local/bin（可通过环境变量INSTALL_PATH覆盖），并在目录无写权限时自动使用sudo。脚本仅支持 Linux；macOS 用户需走 Homebrew。

Windows

直接从 GitHub Releases 页面下载最新版本的可执行文件即可。

快速开始：开发模式启动与验证

启动服务器

进入开发模式只需一条命令：

livekit-server --dev

--dev标志在 cmd/server/main.go 中定义为"将日志级别设为 debug、使用控制台格式化输出，并开启 /debug/pprof（生产环境不安全）"。结合getConfig的实现细节可以看到，开发模式下若未显式配置密钥，服务器会使用占位密钥对：

API Key: devkey API Secret: secret

同时会默认只绑定到回环地址127.0.0.1与::1，避免开发实例意外暴露到公网。若要为生产环境定制，需参考部署文档与 config-sample.yaml 配置文件。

创建访问令牌

连接 LiveKit 房间的用户必须持有访问令牌。访问令牌（JWT）编码了用户身份以及被授予的房间权限。README 推荐使用 CLI 生成：

lk token create \ --api-key devkey --api-secret secret \ --join --room my-first-room --identity user1 \ --valid-for 24h

令牌机制在服务端有对应实现：pkg/service中的认证逻辑负责校验 JWT，而cmd/server/commands.go中还保留了一个已隐藏的create-join-token子命令（createToken函数），它构造auth.VideoGrant（RoomJoin: true与指定房间名），通过auth.NewAccessToken(apiKey, apiSecret)签发默认有效期 30 天的令牌，并支持--recorder选项生成"隐藏的、只能订阅"的录制参与者。该子命令已被标记为 deprecated，令牌生成统一交给 LiveKit CLI。

用示例应用测试

访问官方示例应用，输入生成的令牌即可连接到你的 LiveKit 服务器。连接成功后，你的音视频就开始发布到这台新实例上了。

模拟一个测试推流者

在没有真实摄像头/麦克风的情况下，可以用 CLI 模拟推流：

lk room join \ --url ws://localhost:7880 \ --api-key devkey --api-secret secret \ --identity bot-user1 \ --publish-demo \ my-first-room

该命令向房间发布一段循环演示视频。README 特别提醒：由于演示视频编码方式（每 3 秒一个关键帧）的限制，浏览器需要先缓冲足够数据才能开始渲染画面，会出现轻微延迟——这是模拟推流的固有现象，并非服务器故障。

加入一个 AI Agent

Agent 与浏览器或手机一样，以参与者身份加入房间。按照 Voice AI 快速入门构建一个 Agent 后，它连接自托管服务器的方式与连接 LiveKit Cloud 完全相同；在没有 Cloud 的环境下运行时，使用模型插件（model plugins）替代 LiveKit Inference 即可。

配置深入：从 config-sample.yaml 读懂生产参数

仓库根目录的 config-sample.yaml 是官方随仓库维护的完整配置示例，其中的核心参数与默认值如下（生产部署可直接以此为蓝本）。

主端口与 Redis 分布式模式

port: 7880

port是 RoomService 与 RTC 端点的主 TCP 端口，生产环境应置于带 TLS 的负载均衡器之后（对应pkg/config/config.go中Config.Port字段）。当配置了redis后，LiveKit 会自动以全分布式方式运行，客户端可连接任意节点并被路由到同一房间：

redis: address: redis.host:6379 # db: 0 # username: myuser # password: mypassword

配置示例中还覆盖了 Redis Sentinel（sentinel_master_name+sentinel_addresses）、Redis TLS（tls.enabled、insecure、server_name、ca_cert_file等）以及 Redis Cluster（cluster_addresses）三种高级形态。分布式路由由pkg/routing/redisrouter.go实现。

WebRTC 传输配置

rtc: port_range_start: 50000 port_range_end: 60000 tcp_port: 7881 use_external_ip: true

• port_range_start/port_range_end：客户端 UDP 流量使用的端口区间，需在防火墙开放入站；
• tcp_port：UDP 不可用时启用 WebRTC ICE over TCP 的端口。该端口不能放在负载均衡器或 TLS 之后，必须直接暴露在节点上（WebRTC 传输本身已加密，无需额外加密层）；
• use_external_ip：通过 STUN 探测宿主机公网 IP，适用于 AWS、Google 云这类内网 IP 映射到外网 IP 的云环境。

示例中还给出了大量可选配置：advertise_internal_ip（同时通告内外网 IP）、node_ip（手动指定公网 IP）、udp_port（UDP mux，建议端口数不少于 vCPU 数）、use_ice_lite（lite ICE 加速建连）、stun_servers/turn_servers（客户端使用的 STUN/TURN）、congestion_control（默认开启的拥塞控制，allow_pause控制是否可暂停部分轨道）、allow_tcp_fallback（UDP 不稳定时自动回退 TCP/TURN）、packet_buffer_size_video（默认 500）/packet_buffer_size_audio（默认 200）、pli_throttle（PLI/FIR 限流）、interfaces/ips的 include/exclude 过滤、batch_io（合并网络写系统调用降低 CPU）等。这些参数分别对应pkg/config/config.go中的RTCConfig与 SFU 侧实现。

密钥与认证

keys: key1: secret1 key2: secret2

密钥对用于 JWT 认证：服务器 API 需要密钥对来生成访问令牌并调用服务器。生产环境建议通过key_file指向权限为仅本人可读（others 权限为 0）的密钥文件，pkg/config/config.go中定义了ErrKeyFileIncorrectPermission等校验错误。

房间默认配置

# room: # auto_create: false # empty_timeout: 300 # departure_timeout: 20 # max_participants: 0 # enabled_codecs: # - mime: audio/opus # - mime: video/vp8 # enable_remote_unmute: true # playout_delay: # enabled: true # min: 100 # max: 2000 # sync_streams: true

每个房间默认继承这些设置；若通过 CreateRoom 显式创建房间，则显式设置优先。empty_timeout控制无人加入时房间保留秒数（默认 300），departure_timeout控制所有人离开后房间保留秒数（默认 20），enabled_codecs可限制房间接受的编码（还支持video/h264、video/vp9、video/av1、audio/red），playout_delay控制视频轨道播放延迟（配合sync_streams改善音画同步）。

Webhook、信号中继与 PSRPC

• webhook：配置api_key与urls列表后，LiveKit 会向你的 URL 处理器推送房间事件，api_key必须匹配服务器配置的某个密钥用于签名校验（对应pkg/service中的 webhook 发送逻辑）；
• signal_relay：自 v1.4.0 起基于 psrpc 的可靠信号中继，retry_timeout（默认 30s）、min_retry_interval（500ms）、max_retry_interval（5s）、stream_buffer_size（1000）；
• psrpc：自 v1.5.1 起更可靠的内部 RPC，max_attempts（3）、timeout（500ms）、backoff（500ms）、buffer_size（1000），可选 gzip 压缩（compression.quality1-9、threshold1024 字节）。

音频、TURN、Ingress 与节点限制

• audio：active_level（默认 30，0-127，0 最响）、min_percentile（默认 40）、update_interval（默认 500ms）、smooth_intervals（默认 4）、active_red_encoding，控制说话人检测灵敏度；
• turn：内置 TURN 服务器，udp_port默认 3478（推荐 443）、tls_port默认 5349（无负载均衡时必须设为 443）、domain需匹配 TLS 证书域名、cert_file/key_file或LIVEKIT_TURN_CERT/LIVEKIT_TURN_KEY环境变量提供证书、ttl_seconds默认 300、per_user_relay_allocation_limit默认 12（防止单个参与者耗尽共享中继端口配额）。pkg/config/config.go还定义了TURNMaxTTLSeconds（24 小时）与DefaultTURNTTLSeconds（300s）等常量约束；
• ingress：rtmp_base_url与whip_base_url用于生成 RTMP/WHIP 拉流地址，enable_udp_url_pull默认关闭（存在安全风险）；
• limit：节点级限流，num_tracks（默认每 CPU 400 路进出轨、上限 8000）、bytes_per_sec（默认 1 GB/s）、subscription_limit_video/audio（单参与者订阅数限制）、max_metadata_size、signal_message_size_limit（默认 2 MiB）、max_api_request_body_size（默认 10 MiB）等，设为 -1/0 可禁用对应限制；
• node_selector：节点选择策略，kind可选any、sysload、cpuload、regionaware，配合sort_by、algorithm（lowest/twochoice）、sysload_limit（默认 0.7）与regions经纬度坐标，用于多节点负载分配。

部署选项

使用 LiveKit Cloud

LiveKit Cloud 是官方托管方案，在 19+ 区域运行并提供 99.99% 可用性，在服务器之上叠加 Agent 托管、模型推理、电话接入与可观测性。Build 计划免费且无需信用卡。

自托管

自托管部署可参考部署文档，官方提供 Docker 镜像与 Helm chart 两种途径。仓库内的 Dockerfile 展示了镜像构建方式：以golang:1.26.7-alpine作为构建阶段镜像（GOTOOLCHAIN=local强制使用镜像内工具链以保证可复现构建），CGO_ENABLED=0静态编译./cmd/server，最终以精简的alpine作为运行镜像，并先执行apk upgrade拉取最新安全补丁。多平台构建（linux/amd64、linux/arm64）由 magefile.go 中的PublishDocker目标使用docker buildx完成。

从源码构建

构建前置条件：

• 已安装 Go 1.26+（当前仓库版本号见 version/version.go，为1.13.7；Dockerfile 锁定工具链为 Go 1.26.7）；
• GOPATH/bin已加入PATH。

然后依次执行：

git clone <本仓库地址> cd livekit ./bootstrap.sh mage

• bootstrap.sh 负责在系统缺失 mage 时从源码安装 mage 构建工具，并执行go mod download拉取依赖；
• mage默认执行Build目标（magefile.go），它会先运行 wire 代码生成，再在cmd/server目录执行go build -o ../../bin/livekit-server，产物位于bin/livekit-server。

magefile.go 还提供了其他常用目标：mage BuildLinux（交叉编译 Linux 二进制）、mage Test（跳过集成的单元测试）、mage TestAll（含集成测试的全量测试）、mage TestServer（前台运行 SDK 测试服务器）、mage Lint（golangci-lint）、mage Generate（重新生成代码）、mage Clean（清理构建产物）。

服务器命令行与运维子命令

启动入口 cmd/server/main.go 基于 urfave/cli v3 实现，除默认启动动作外还注册了若干运维子命令：

• livekit-server generate-keys：生成一对 API Key 与 Secret（generateKeys函数）；
• livekit-server ports：打印服务器当前配置将使用的 TCP/UDP 端口清单（printPorts函数，涵盖 HTTP 服务、ICE/UDP、ICE/TCP、TURN/TLS、TURN/UDP）；
• livekit-server list-nodes：以表格形式列出集群所有节点及其 CPU/内存/房间/客户端/流量/NACK/重传等实时统计（listNodes函数，数据来自pkg/routing的节点状态）；
• livekit-server help-verbose：打印全部帮助信息，包括由配置自动生成的 CLI 标志；
• livekit-server --version：输出版本号。

全局标志方面，--bind（监听 IP，可多次指定）、--config（配置文件路径）、--config-body/环境变量LIVEKIT_CONFIG（直接以 YAML 字符串传配置，适合容器场景）、--key-file、--keys/LIVEKIT_KEYS、--region/LIVEKIT_REGION、--node-ip/NODE_IP、--udp-port/UDP_PORT、--redis-host/REDIS_HOST、--redis-password、--turn-cert/LIVEKIT_TURN_CERT、--turn-key/LIVEKIT_TURN_KEY、--cpuprofile、--memprofile等均有定义，且大部分支持环境变量注入，便于容器化部署。

仓库源码结构导读

若想深入源码学习，可按以下路径阅读：

• cmd/server/main.go：进程入口、CLI 定义、开发模式逻辑与优雅停机（监听 SIGINT/SIGTERM/SIGQUIT，首次触发优雅停止、第二次强制停止）；
• cmd/server/commands.go：各运维子命令的实现；
• pkg/config/config.go：全部配置结构体与校验逻辑；
• config-sample.yaml：官方维护的完整配置样例；
• pkg/rtc：房间、参与者、媒体轨道、订阅管理与传输协商；
• pkg/sfu：SFU 媒体转发引擎，含拥塞控制（pkg/sfu/bwe）、码率分配（pkg/sfu/streamallocator）、RTP 统计（pkg/sfu/rtpstats）等；
• pkg/routing：单机路由（localrouter.go）与 Redis 分布式路由（redisrouter.go）及节点选择策略（pkg/routing/selector）；
• pkg/service：RoomService、认证、webhook、TURN、Ingress/SIP 等服务端能力；
• pkg/telemetry/prometheus：Prometheus 指标（默认prometheus_port: 6789的/metrics端点）；
• test：集成测试与多节点场景测试（multinode_test.go、singlenode_test.go等）。

结语

从一条livekit-server --dev命令到生产级的多节点分布式部署，LiveKit 服务器提供了完整、清晰且可自托管的实时音视频基础设施路径。配合 LiveKit Agents 与各端 SDK，你可以用同一套房间模型把人、设备和 AI Agent 编织进同一实时场景——这正是"连接人类与 AI 的端到端实时栈"在工程上的落点。本文涉及的安装、令牌、配置与构建细节均以当前仓库（版本 1.13.7）为准，更多生态组件（Agents SDK、Egress、Ingress、SIP 等）可沿仓库 README 中的生态表格继续探索。

• 后端
• 音视频
• 即时通讯
• AI Agent