国标平台不是「一个程序」，是信令、媒体、存储、前端、数据库五块拼起来的一套东西。 判断一个平台能不能做大，只看一件事：媒体服务能不能独立部署、独立扩容。
第十章把协议讲完了。从这一章开始看真实的软件。 先别急着装——先搞清楚一个平台由哪几块组成，配置项才有地方安放。
一、五块的职责
信令服务管「谁来、要什么」：注册、目录、点播、控制，全走它。 它是最先必须起来的，也是排障的第一站。 媒体服务管「数据怎么走」：收流、转发、转协议、录像。 它最吃资源，也是唯一需要横向加机器的一块。 存储服务管「留下来」，前端和接口管「给人看、给系统调」，数据库管「记住」。 五块里只有信令是「必须有」的，其余在小型项目里常常合并进同一个进程。 所以「平台有几个进程」不是架构好坏的标准，「能不能拆」才是。
二、为什么媒体要单独拆
信令是轻负载、媒体是重负载，两者差着两个数量级： 一台机器能扛几万路信令，但一路 1080p 的转发就可能吃掉一个核。 绑在一起扩，就只能按媒体的需要去扩信令，结果是「信令那边闲着、媒体这边刚够」，浪费得厉害。 拆开之后还有一个好处是「故障隔离」：媒体进程崩了，信令还在，注册和目录都不受影响， 用户看到的是「点播失败」而不是「整个平台打不开」。 这就是为什么看一个平台「能不能做大」，第一眼看的就是它有没有独立的媒体服务。
三、会话表放在哪
会话表是「哪个用户在看哪一路」的记录，它的位置决定了重启之后会发生什么。 放内存最快，但进程一重启全丢，正在看的流全部断，而且平台不知道它们断过。 放 Redis 能共享、能扛重启，代价是每次查多一次网络往返。 这个代价到底有多大，算一下就清楚：内存查一次零点几微秒，Redis 一次一百微秒上下，差一千倍。 但相对两百毫秒的控制预算，两者都可以忽略。 所以「放 Redis 会拖慢」这个担心站不住——真正该担心的是「Redis 挂了怎么办」。
四、动手 Demo：一个国标平台由哪几块拼起来
列五块的端口和职责，再看「会话表放内存还是放 Redis」这笔账。
rows = [("信令服务", "SIP 5060", "注册、点播、控制"),
("媒体服务", "UDP 30000 起", "收流、转发、转协议"),
("存储服务", "磁盘", "录像、回放索引"),
("前端接口", "HTTP 10000 起", "网页、开放接口"),
("数据库", "3306/6379", "设备表、会话表")]
print("内存查一次约 0.1 微秒，Redis 约 100 微秒")
print("差 1000 倍，但相对 200 毫秒预算都可忽略")
实跑输出：
--------------------------------------------------------------------
一个国标平台由哪几块拼起来
--------------------------------------------------------------------
**国标平台不是「一个程序」**，**是「信令、媒体、存储、前端」四块拼起来的一套东西。**
**这一节把四块的职责和它们之间的接口摆清楚**——**看懂这张表，后面两章的配置项就好理解了。**
模块 典型端口 负责什么
-----------------------------------------------------------------------
**信令服务** **SIP 5060 或自定义** **注册、点播、控制**
**媒体服务** **UDP 30000 起** **收流、转发、转协议**
**存储服务** **磁盘** **录像、回放索引**
**前端／接口** **HTTP 10000 起** **网页、开放接口**
**数据库** **3306 或 6379** **设备表、会话表**
**五块里只有信令服务是「必须有」的**，**其余可以合并在一个进程里。**
**小型项目常常是一个程序全包，大型项目才会拆开。**
**拆开的理由不是「架构好看」，是「能扩容」**：
**信令是轻负载，一台能扛几万路；媒体是重负载，一路一千兆的流就要一个核。**
**两者绑在一起，就只能按媒体的需要去扩信令，浪费得厉害。**
**所以判断一个平台「能不能做大」，看一个指标就够了**：**媒体服务能不能独立部署、独立扩容。**
**不能的话，路数一上去就卡在单机上。**
**再说一个容易被忽略的模块：**
**「会话表」到底放在哪。**
**放内存最快，但重启全丢；放 Redis 能共享，但多一次网络往返。**
按每次点播查三次会话算
内存查一次约 0.1 微秒，Redis 一次约 100 微秒
差 1000 倍，但相对 200 毫秒的控制预算都可以忽略
**这个算式的结论有点反直觉**：**「放 Redis 会拖慢」这个担心，在毫秒预算面前是站不住的。**
**真正该担心的是「Redis 挂了怎么办」，不是「它慢不慢」。**
五行的端口分布很说明问题：信令一个端口、前端一个端口，媒体却是一整段。 因为媒体要「一路一对端口」，路数越多占得越多。 这也解释了「平台装好了但点播黑屏」这个经典问题：信令端口放行了，媒体端口段没放。 一个端口和一段端口，是两种工作量。 会话表那两行是本节最实用的结论：一千倍的性能差距，在毫秒预算面前不重要。 所以选型的依据不是「谁快」，是「谁能扛重启」。 顺带说一句「几万路信令」这个说法： 它不是实测值，是量级判断——每个心跳两百字节、六十秒一次，几万路也就是每秒几百个包。
30 秒实验
- 算一下：五块里哪一块需要横向加机器？（媒体）
- 想一下：为什么「一个端口」和「一段端口」是两种工作量？
- 想一下：会话表放 Redis 的真正理由是什么？（扛重启）
常见误区
- 以为「国标平台是一个程序」。 至少是信令加媒体两块，大型项目还会继续拆。
- 以为「进程越少越先进」。 能不能拆才是关键，拆不动就扩不了。
- 以为「会话表放内存最好」。 内存快，但重启就丢。
自测三问（点开对答案）
1. 国标平台的五块分别是什么？ —— **信令、媒体、存储、前端接口、数据库**。 2. 为什么媒体服务要单独拆？ —— **它是重负载**，**和轻负载的信令绑在一起就只能按它扩，浪费。** 3. 会话表放 Redis 的代价和收益各是什么？ —— **代价是每次查多一百微秒，收益是重启不丢、多机共享。**下一节看组网：四种搭法，故障时会发生什么完全不同。
- ☐ （本节完，下一节 11.01.02 国标平台的组网及特点）