【免费下载链接】Node-Media-ServerA Node.js implementation of RTMP/HTTP-FLV Media Server项目地址https://gitcode.com/gh_mirrors/no/Node-Media-Server点击查看免费下载Node-Media-Server 是一个基于 Node.js 的高性能实时流媒体服务器支持 RTMP/RTMPS、HTTP-FLV、WebSocket-FLV 推流与播放并在 v4 中通过增强 RTMP FLV v1 原生支持 HEVC、VP9、AV1 等现代编解码器。本文以仓库中的 架构总览文档 为骨架结合 src 下的真实源码实现从系统分层、核心组件、会话与协议、四条核心工作流程、配置系统、事件系统到性能优化设计完整拆解这台媒体服务器的内部构造。读完本文你将掌握它的模块职责划分、数据从推流端到播放端的完整传递路径以及如何通过配置与事件钩子对服务器进行定制与监控。一、系统分层架构总览架构文档开篇给出了一个五层结构图从顶层的应用形态RTMP 推流/播放、HTTP-FLV 播放、WebSocket-FLV 播放到底层的全局状态与日志基础每一层都对应仓库中真实的模块目录┌─────────────────────────────────────────────────────────────┐ │ 应用层 (Application Layer) │ ├─────────────────┬─────────────────┬─────────────────────────┤ │ RTMP推流/播放 │ HTTP-FLV播放 │ WebSocket-FLV播放 │ │ (OBS/FFmpeg) │ (Web播放器) │ (Web播放器) │ └─────────────────┴─────────────────┴─────────────────────────┘ ┌─────────────────────────────────────────────────────────────┐ │ 协议层 (Protocol Layer) │ ├─────────────────┬─────────────────┬─────────────────────────┤ │ RTMP协议 │ FLV协议 │ WebSocket协议 │ │ (握手/分块) │ (标签格式) │ (帧格式) │ └─────────────────┴─────────────────┴─────────────────────────┘ ┌─────────────────────────────────────────────────────────────┐ │ 会话层 (Session Layer) │ ├─────────────────┬─────────────────┬─────────────────────────┤ │ RTMP Session │ FLV Session │ API Session │ │ (推流/播放) │ (HTTP/WS播放) │ (REST API) │ └─────────────────┴─────────────────┴─────────────────────────┘ ┌─────────────────────────────────────────────────────────────┐ │ 服务层 (Service Layer) │ ├─────────────────┬─────────────────┬─────────────────────────┤ │ RTMP Server │ HTTP Server │ Broadcast Server │ │ (TCP监听) │ (HTTP/WS监听) │ (流分发) │ └─────────────────┴─────────────────┴─────────────────────────┘ ┌─────────────────────────────────────────────────────────────┐ │ 核心层 (Core Layer) │ ├─────────────────┬─────────────────┬─────────────────────────┤ │ Context │ Logger │ Event System │ │ (全局状态) │ (日志系统) │ (事件管理) │ └─────────────────┴─────────────────┴─────────────────────────┘这五层在目录结构上有着一一对应的映射层次职责仓库目录协议层RTMP/FLV/AMF 编解码、RTSP/RTP 客户端协议src/protocol会话层单个连接的协议状态机与生命周期src/session服务层端口监听、连接接纳、流分发与录制/通知src/server核心层全局状态、日志、数据包抽象、速率采样src/coreAPI 层REST 管理接口与认证中间件v4.2 新增src/api值得强调的是架构文档中的「应用层」由外部客户端OBS、FFmpeg、浏览器播放器构成服务端不感知客户端的具体形态只通过统一会话抽象与之交互——这正是后续「一推多播、多协议共存」能成立的前提。二、核心组件全局状态、日志与媒体数据包2.1 Context —— 全局共享状态管理器Context 是整个服务器的大脑它以单例对象的形式持有以下关键状态sessions所有活跃连接RTMP、HTTP-FLV、WS-FLV、录制、中继客户端按会话 id 索引的 Mapbroadcasts按流路径如/live/stream索引的活跃广播服务器 Map每个推流方在此注册自己的 BroadcastServereventEmitterNode.js 原生EventEmitter实例承担全生命周期事件分发store/relayServer/recordServer由 NodeMediaServer 构造函数 注入的持久化存储、中继与录制管理器供 API 层访问networkStats进程累计的入/出流量字节计数inBytes/outBytes被所有推流/播放会话累加用于网络级带宽统计。从源码结构看Context 本质上是服务层与会话层之间的依赖注入容器各 Server 组件在构造时读取Context.config决定是否创建监听器会话在建立时从Context.broadcasts查找或新建广播对象事件通过Context.eventEmitter解耦各模块。2.2 Logger —— 统一结构化日志系统Logger 实现了五级日志体系trace、debug、info、warn、error输出格式为[时间] [级别] 消息。日志级别在 NodeMediaServer 构造函数 中被设为debug构造函数内部——也就是说启动阶段会输出最详细的调试日志便于排查握手与协议问题。2.3 AVPacket —— 统一媒体数据包抽象AVPacket 是跨协议传递媒体的通用货币。它的字段设计决定了系统能做协议无关的转发字段含义典型取值codec_type媒体轨道类型8音频、9视频、18脚本数据codec_id编解码器标识H.2647、AAC10增强 FLV 下为 FOURCC 值pts/dts显示/解码时间戳由各协议解析器换算flags帧语义标志0音频头、1音频帧、2视频头、3关键帧、4普通帧、5元数据、6视频元数据HDRdata原始媒体负载Buffer这个抽象是整套架构的基石BroadcastServer.broadcastMessage 对同一个AVPacket同时调用Flv.createMessage(packet)和Rtmp.createMessage(packet)分别产出 FLV 标签和 RTMP 消息分发给不同协议的订阅者实现一次解析、多协议输出。2.4 RateSampler —— 滑动窗口速率采样器架构文档提到的实时统计能力在 RateSampler 中落地。它以 1 秒为间隔、保留 5 个采样点通过字节增量 / 窗口时间跨度计算每个流与整个网络的入/出带宽inBps/outBps。当推流会话被替换导致计数器回退时它会自动重置基准rebase而不会产生负速率。rateSampler.start()在 NodeMediaServer 构造函数 中启动供/api/v1/streams、/api/v1/stats等 REST 接口实时读取。三、服务器组件端口监听与能力装配3.1 NodeRtmpServer —— RTMP/RTMPS 双监听NodeRtmpServer 在构造阶段根据配置决定是否创建监听器存在rtmp.port则用net.createServer创建明文 TCP 服务器存在rtmps.port则用tls.createServer加载key/cert创建 TLS 服务器——对应架构文档中的标准 1935 端口和安全 1936 端口。run()阶段两个监听器绑定到Context.config.bind地址。每个新连接都会被包装为一个 RtmpSession 并注册进Context.sessions。监听失败如端口被占用EADDRINUSE会打印友好错误并退出进程。stop()则关闭监听器并销毁所有存活的 socket。3.2 NodeHttpServer —— HTTP/HTTPS WebSocket 一体化NodeHttpServer 的能力远超静态文件服务它同时承载了 FLV 拉流、FLV 推流、WebSocket-FLV、REST API 和 WebAdmin 控制台若配置了static.router与static.root通过 Express 挂载静态目录默认在/admin挂载webadmin/dist构建产物可通过webadmin.enable: false关闭若配置了auth.jwt则启用/api/v1REST 路由先为/api/v1/login挂登录限流中间件再为其余 API 挂 JWT 认证app.all(/:app/:name.flv, handleFlv)兜底所有 FLV 请求——请求体走 HTTP 长连接GET 播放 / POST 推流升级为 WebSocket 后同样由handleFlv处理HTTP 明文服务器挂载wsWebSocket 服务HTTPS 使用http2.createSecureServerallowHTTP1: true兼容 HTTP/1.1并挂载 WSS 服务对应架构文档中HTTP 服务器: 8000/8443 端口。每个 FLV/WS 连接都会被包装为 FlvSession会话在构造时通过req.methodPOST 即推流或 WebSocket 子协议post/publisher判断自己是发布者还是播放者。3.3 NodeRecordServer —— FLV 录制与录制元数据NodeRecordServer 实现了架构文档中的流录制run()时校验record.path可写然后监听postPublish事件当record.auto ! false时为每个新推流创建 NodeRecordSession输出文件为{record.path}/{streamPath}/{unix_time}.flvrecord.auto: false时录制服务仍然可用但只通过手动 APIWebAdmin 录制按钮或POST /api/v1/streams/{app}/{name}/record触发录制元数据文件路径、时长、大小、状态持久化到 store 的records集合重启后_recoverStaleRecords()会把上次异常退出遗留的recording状态记录按文件实际大小与 mtime 修正为done推流在 30 秒宽限期内由同一客户端重连时会继续追加到同一个录制文件而不是新建对应 README 的 Record Session Resume 特性。3.4 NodeNotifyServer —— HTTP 回调通知NodeNotifyServer 是架构文档事件通知机制的具体实现。当配置了notify.url后它会监听prePlay、postPlay、donePlay、prePublish、postPublish、donePublish、postRecord、doneRecord共 8 个事件把会话信息id、ip、app、name、query、protocol、字节统计、action等以 JSON POST 到回调 URL。一个值得注意的行为如果回调响应状态码不是 200服务器会主动关闭该会话——回调方可以用非 200 响应来拒绝非法连接。3.5 补充BroadcastServer / RelayServer / HistoryServer架构文档的服务层主要列出了 RTMP、HTTP、Broadcast 三类实际仓库还包含另外三个管理型服务它们在架构图里共同构成完整的服务面BroadcastServer流分发核心见下一节工作流程详述NodeRelayServerRTSP 拉流 / RTMP 拉-推中继任务管理任务持久化在 store 的relay_tasks集合并在重启后自动恢复按任务类型实例化 RtspClientSession 或 RtmpClientSessionNodeHistoryServer监听donePublish把结束的推流会话含协议、路径、IP、起止时间、字节、播放次数写入 store 的stream_history集合条目数由store.maxHistory限制默认 10000。四、会话组件连接级状态机4.1 BaseSession —— 统一会话抽象BaseSession 定义了所有会话的公共骨架随机会话 id时间戳 8 个随机字符、IP、协议类型、流路径三元组streamHost/streamApp/streamName、创建/结束时间、编解码参数视频宽高、帧率、码率音频声道、采样率、流量计数inBytes/outBytes/playCount以及sendBuffer/close两个抽象方法。所有字段为 RTMP、FLV、录制、中继等会话共享这也是Context.sessions能统一管理异构连接的原因。4.2 RtmpSession —— RTMP 协议会话RtmpSession 在run()阶段把协议回调注入 Rtmp 解析器onConnect解析 app/name/query 得到流路径并校验非法字符、onPlay、onPush、onOutput、onPacket。收到data时累加inBytes并喂给解析器关闭时根据isPublisher调用donePublish或donePlay。一个关键的实现细节连接建立后即创建占位BroadcastServer()直到onConnect解析出合法流路径才从Context.broadcasts取回或新建真正的广播对象——非法路径非[a-zA-Z0-9_-]会被直接断开。4.3 FlvSession —— HTTP / WebSocket FLV 会话FlvSession 与 RtmpSession 共享同一套生命周期逻辑onPlay/onPush/onClose的语义完全一致差异仅在数据通道HTTP 模式下监听req的data事件WebSocket 模式下监听ws的message事件FLV 推流数据交给 Flv 解析器转成 AVPacket再走broadcastMessage。播放端sendBuffer会区分 WebSocketws.send与 HTTPres.write两种写出路径。五、协议组件RTMP、FLV 与 AMF5.1 Rtmp —— 完整 RTMP 实现src/protocol/rtmp.js 是一份相对完整的 RTMP 协议栈包含握手calcHmac使用HmacSHA256架构文档提到的 HMAC-SHA256 握手验证支持简单握手格式 0与复杂握手格式 1/2基于 Genuine FMS 常量计算 digest分块四种 chunk 头类型Type 0/1/2/3长度分别为 11/7/3/0 字节、扩展时间戳、默认 chunk size 128、最大 chunk size 0xffff消息类型协议控制消息Set Chunk Size、Abort、Ack、Window Ack Size、Set Peer Bandwidth、用户控制事件、音频8/视频9消息、AMF0/AMF3 数据与命令消息、聚合消息等通道划分协议控制2、调用命令3、音频4、视频5、数据6连接保活RTMP_PING_TIME60000ms 周期 Ping、RTMP_PING_TIMEOUT30000ms 超时判定。5.2 Flv —— FLV 标签解析与增强 RTMP v1src/protocol/flv.js 负责 FLV 头的解析FLV 版本 1、hasAudio/hasVideo标志位与标签的生成/解析。它完整实现了Enhanced RTMP FLV v1详见仓库 增强 RTMP 规范文档视频标签头解析时检测isExHeader帧类型高 4 位的第 4 位若为增强格式则读取 4 字节 FOURCC识别av01AV1、vp09VP9、hvc1HEVC并把序列开始SequenceStart、编码帧CodedFrames/CodedFramesX、元数据Metadata承载 HDR 信息映射为对应的flags音频同样支持增强头通过AudioPacketTypeSequenceStart识别序列头FOURCC 覆盖Opus、mp4aAAC、.mp3、fLaC、ac-3、ec-3等传统 H.264codecID 7与 AACcodecID 10路径继续兼容旧式 Sequence Header 判定。5.3 Amf —— AMF0 数据格式Amf 实现 AMF0 的序列化/反序列化用于解析 RTMP 命令与onMetaData脚本数据。在 BroadcastServer.broadcastMessage 中元数据包flags 5会被解码并回填到发布者会话的编解码参数上audiocodecid、width、height、framerate、videodatarate等这些字段随后出现在 REST API 的流信息与历史记录中。六、工作流程四条核心链路6.1 服务器启动流程启动入口为 bin/app.jsnode bin/app.js对照源码启动顺序的实际实现是NodeMediaServer.run() 依次执行httpServer.run()→rtmpServer.run()→notifyServer.run()随后打开持久化 store成功后才启动recordServer、relayServer、historyServer若 store 打开失败如目录无写权限录制/中继/历史服务会被禁用但主服务继续运行。需要补充的是bin/app.js中的首启安全流程若 admin 用户的密码为空或为默认值会生成 16 位随机密码并以 scrypt 哈希写入配置同时打印到控制台auth.secret与jwt.secret为空时也会自动生成随机密钥并回写 bin/config.json。CLI 参数见下文配置系统在回写之后应用因此命令行覆盖值永远不会被持久化。6.2 RTMP 推流流程这条链路在源码中的真实映射为RtmpSession.onConnectconnect 解析→onPushpublish 命令→BroadcastServer.postPublish身份验证 注册发布者→RtmpSession.onPacket→broadcast.broadcastMessage(packet)转换、分发、缓存。其中身份验证当auth.publish: true时调用verifyAuth校验流地址签名见下文安全特性幂等保护若该流路径已有发布者postPublish返回already has a publisher并断开新连接发布宽限期发布者断开后不会立即销毁广播而是进入 30 秒reconnecting状态同一 IP 的客户端重连可继承累计统计createTime、字节数、播放数、编解码参数并继续时间轴通过_dtsOffset平移时间戳这正是录制续写与历史记录连续的底层机制。6.3 多协议播放流程播放侧的实现集中在BroadcastServer.postPlaysrc/server/broadcast_server.js验证通过后按播放者协议flv或rtmp依次发送 FLV 头Flv.createHeader(true, true)、元数据、音频头、视频头、GOP 缓存然后注册为订阅者。此后broadcastMessage每收到一个 AVPacket都会同时向所有订阅者写出对应协议的编码消息——一个发布者、任意数量播放者、多种输出协议的架构即由此实现。6.4 API 请求处理流程REST 路由定义在 ApiRouter 中覆盖认证login/change password、健康检查、流管理、会话管理、统计、SSE 事件流、中继任务、录制元数据、历史记录与配置管理。JWT 中间件 src/api/middleware/auth.js 默认放行/health与/login其余路由要求Authorization: Bearer token或?token查询参数令牌校验失败统一返回 401UNAUTHORIZED。登录接口还叠加了 login_rate_limit 限流中间件。七、关键特性从文档到代码的印证7.1 多协议支持协议用途源码落点RTMP/RTMPS标准推流协议SSL 加密rtmp_server.js 的 TCP/TLS 双监听HTTP-FLV长连接低延迟播放FlvSession HTTP 分支WebSocket-FLV浏览器兼容性最佳FlvSession WS 分支7.2 现代编解码器支持视频支持 H.264、HEVC、VP9、AV1音频支持 AAC、MP3、Opus——这是 v4 的核心设计目标README 明确说明 v4 为增强 RTMP FLV v1 原生支持 HEVC/VP9/AV1 而设计且不再兼容旧flv_265扩展与 FlashPlayer 的 RTMP。四字节编解码器标识FOURCC的识别逻辑在 flv.js 与标签解析代码中直接体现。7.3 安全特性HMAC-SHA256 握手rtmp.js 的calcHmacTLS/SSLrtmps与https配置段加载 PEM 密钥证书JWT 认证管理 API 的 Bearer Token 校验流认证MD5 签名verifyAuthbroadcast_server.js的实现规则为推流/播放地址携带sign查询参数格式为exp-md5hex其中md5hex MD5(streamPath - exp - authSecret)exp为 Unix 秒级过期时间戳过期或签名不符即拒绝。这是 OBS/FFmpeg 等客户端拼接带签名 RTMP/HTTP-FLV 地址的标准用法。7.4 监控与管理REST API 提供流、会话、录制、历史、中继、配置的全量管理接口/stats与每个流的带宽数据由 RateSampler 实时计算全生命周期事件与结构化日志贯穿始终。7.5 高性能设计事件驱动全程基于 Node.js 事件循环与异步 I/O无阻塞操作GOP 缓存管理关键帧flags 3到达时清空重建 GOP 缓存缓存上限 4096 帧broadcast_server.js防止长时间直播内存膨胀协议实时转换同一 AVPacket 双路编码为 FLV 与 RTMP 输出。八、配置系统参数详解与 CLI 覆盖8.1 配置文件架构文档给出的示例是精简版仅含rtmp/http/auth/jwt仓库实际的默认配置 bin/config.json 更为完整以下逐段对照说明{ bind: 0.0.0.0, notify: { url: }, store: { path: ./data, maxHistory: 10000 }, auth: { play: false, publish: false, secret: , jwt: { secret: , expiresIn: 24h, refreshExpiresIn: 7d, algorithm: HS256, users: [ { username: admin, password: , role: admin } ] } }, rtmp: { port: 1935 }, rtmps: { port: 1936, key: ./key.pem, cert: ./cert.pem }, http: { port: 8000 }, https: { port: 8443, key: ./key.pem, cert: ./cert.pem }, webadmin: { enable: true }, record: { auto: false, path: ./record } }各配置段的字段语义类型定义见 context.js 的 JSDoc typedef配置段字段说明默认行为bind—所有监听器的绑定地址0.0.0.0rtmp/rtmpsport/key/cert明文 RTMP 与 TLS RTMPS 监听缺省端口即不创建对应监听器http/httpsport/key/certHTTP-FLV/WS-FLV 与 HTTPS/WSS 监听同上recordpath/auto录制根目录 / 是否自动录制所有推流默认auto: false仅手动 API 录制storepath/maxHistory等持久化目录与历史条数上限默认./data、10000 条authplay/publish/secret播放/推流签名认证开关与共享密钥默认关闭secret 首启自动生成auth.jwtsecret/expiresIn/refreshExpiresIn/algorithm/users管理 API 的 JWT 配置与账户密码为 scrypt 哈希存在该段即启用 APIsecret 首启自动生成webadminenable是否在/admin提供内置控制台默认truenotifyurl事件回调 Webhook 地址为空则不启用通知补充说明来自 bin/app.js配置中的store.path、record.path会相对配置文件所在目录解析rtmps/https的key/cert若相对路径在当前工作目录找不到也会回退到配置文件目录下查找。仓库自带了示例证书 bin/cert.pem 与 bin/key.pem。8.2 命令行覆盖除了配置文件启动时可用的 CLI 参数node bin/app.js --help包括-c, --config path Path to the config file (default: bin/config.json) -b, --bind addr Bind address, overrides the bind config value --rtmp-port n RTMP port, overrides rtmp.port --rtmps-port n RTMPS port, overrides rtmps.port --http-port n HTTP/WebSocket port, overrides http.port --https-port n HTTPS/WSS port, overrides https.port --data-path path Runtime data directory, overrides store.path --record-path p Record output directory, overrides record.path --record-auto Enable auto recording, forces record.auto on --notify-url url Event webhook URL, overrides notify.url --auth-play Enable play authentication, forces auth.play on --auth-publish Enable publish authentication, forces auth.publish on --no-admin Disable the webadmin console (/admin), media only -h, --help Show this help端口参数会经过 1~65535 的整数校验--notify-url会校验必须是绝对 URL命令行值优先于配置文件且永不回写配置文件。例如快速起一个关闭控制台、开启自动录制的实例node bin/app.js --no-admin --record-auto --record-path ./html/record九、事件系统全生命周期钩子9.1 生命周期事件架构文档列出的 8 个事件在源码中均有真实的Context.eventEmitter.emit落点事件触发时机源码触发点preConnect/postConnect连接建立前/后连接处理入口prePublish/postPublish推流开始前/后broadcast_server.js 的postPublishprePlay/postPlay播放开始前/后postPlaybroadcast_server.jsdonePublish/donePlay推流/播放结束_finishPublish与donePlay此外实际代码中还存在postRecord/doneRecord录制开始/结束供录制元数据与通知使用。9.2 事件使用示例NodeMediaServer实例通过on(eventName, listener)src/index.js暴露事件订阅可直接用于业务联动const NodeMediaServer require(node-media-server); const nms new NodeMediaServer(require(./bin/config.json)); nms.on(prePublish, (session) { console.log(Stream ${session.streamPath} starting to publish); }); nms.on(donePlay, (session) { console.log(Player ${session.id} stopped playing); }); nms.run();session对象即 BaseSession 及其子类实例携带id、ip、streamPath、inBytes、outBytes等字段可据此实现鉴权、限流、统计等自定义逻辑。同时NotifyServer 正是这套事件系统的官方消费者——把事件转发为 HTTP Webhook。十、性能优化设计架构文档的优化清单对应到源码的落点如下10.1 内存管理GOP 缓存上限FLV 与 RTMP 两套 GOP 缓存各自超过 4096 帧即整体清空broadcast_server.js将新播放者的秒开缓存控制在有界内存内广播自动销毁_destroyIfEmpty在发布者与订阅者都清空时把广播对象从Context.broadcasts移除避免流路径泄漏会话及时清理连接关闭时从Context.sessions删除配合close/stop的全量关闭流程index.js 的幂等stop()实现优雅退出。10.2 网络优化架构文档提到的 TCP_NODELAY 与缓冲区优化、零拷贝从当前源码结构看主要依赖 Node.js 底层 socket 的默认行为与异步写模型sendBuffer直接socket.write/res.write未做额外用户态拷贝。这里需要以实际部署观测为准不宜将文档描述等同于已验证的基准测试结论。10.3 编解码优化系统的编解码优化本质上不是转码而是协议级快速格式转换媒体负载以 AVPacket 为载体原样透传仅 FLV/RTMP 容器头按需生成因此 CPU 开销极低、延迟可控H.265 的 CTScomposition time offset换算在 flv.js 中专门处理保证增强格式下的音画同步。结语架构设计的核心脉络纵观全局Node-Media-Server 的架构可以概括为三句话统一抽象消除协议差异——AVPacket与BaseSession让 RTMP、HTTP-FLV、WS-FLV、录制、中继、REST 六类连接共用同一套生命周期与数据通路广播服务器是流的心脏——BroadcastServer承担鉴权、GOP 缓存、双协议编码、订阅者分发是一推多播与秒开体验的实现核心事件系统与持久化 store 撑起管理面——生命周期事件驱动通知、录制、历史统计与 REST API轻量 JSON store 让中继任务、录制元数据、历史记录在进程重启后依然可恢复。这套分层设计让流媒体核心逻辑与外围管理能力解耦推流、播放、录制、通知各自演进而互不干扰。若想进一步深入可以继续阅读仓库内的 API 文档、数据流分析、时序图 与 增强 RTMP 规范并结合 test/broadcast.test.js 等测试用例验证各模块的行为边界。赞分享【免费下载链接】Node-Media-ServerA Node.js implementation of RTMP/HTTP-FLV Media Server项目地址https://gitcode.com/gh_mirrors/no/Node-Media-Server点击查看免费下载相关推荐Flowy流程图引擎深度解析掌握事件生命周期与交互状态管理Flowy流程图引擎深度解析掌握事件生命周期与交互状态管理 在现代Web应用中流程图工具已成为构建自动化系统、业务流程管理和思维导图的核心组件。Flowy作前端图表库node-restify 请求生命周期终结事件 restifyDone 深度解析node restify 请求生命周期终结事件 restifyDone 深度解析 当一个请求被完全服务完毕时node restify 会在请求对象Reque后端Nginx UI 集群环境配置指南通过 cluster 分区预定义多节点Node环境Nginx UI 集群环境配置指南通过 cluster 分区预定义多节点Node环境 Nginx UI 自 v2.0.0 beta.23 起支持在配置文件开发工具上一篇使用 Ent 与 elk 扩展从 Schema 生成 OpenAPI 规范与 RESTful 服务下一篇Math.NET Numerics随机数生成器从Mersenne Twister到Xoshiro256**创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考