本篇要回答的问题：把上一讲的需求分析方法论用到两个真实产品上——“互联网"和"对象存储”，它们的根源需求、子系统拆分、市场策略各是怎样的？不同市场的差异有多大？
上一讲讲了需求分析的方法论（三步法、变化点/稳定点、产品定义）。本讲是它的实战篇，选了两个标志性案例：一个是无历史包袱的全新基础设施（互联网），一个是有既有市场、要面对搬迁问题（对象存储），通过对比看清"不存在大一统的产品定义"。
案例一：打造"互联网"
根源需求的原点：这不是某巨头的网，也不是政府的网，而是一张开放的网——不存在能主宰一切的"造物主"。
关键判断：忽略这一点就会做成微信网（WechatNet）或中国网（ChinaNet）——可能是巨网，但都不是"互联网"。
"开放"的两个层次：
| 层次 | 含义 | 对应设计 |
|---|---|---|
| 对网络设备/运营商开放 | 定义跨网数据交换标准 | IP 协议 |
| 对应用软件开放 | 提供屏蔽网络复杂性的高层协议 + 杀手级应用引流 | TCP/UDP + Email/WWW |
关键洞见：安全被阶段性放弃——加密传输没作为互联网内建特性，极大降低了实施难度。深层原因：物理网络一旦存在就极难改变（想想 IPv4→IPv6 用了多少年），而安全方案的长期有效性存疑，所以把它留给更经得起变更的软件层（操作系统和应用），这是极明智的选择。
最终 MVP 版 Internet 项目要做的事：
| 子系统 | 职责 |
|---|---|
| IP 协议 | 连接所有既有网络的协议标准 |
| 骨干网络 | 至少两个城市互联试点 |
| 路由器 | 打通骨干网与企业专用网 |
| 高阶网络协议 | 工作在 IP 之上，方便应用开发 |
| 基础协议栈源码/包 | 方便操作系统、网络设备厂商集成 |
| 典型应用 | Email、WWW 等杀手级应用 |
| 安全协议（远期） | 安全传输方案及其源码/包 |
物理网络的三种构件抽象：
| 构件 | 抽象 | 图示 |
|---|---|---|
| 骨干路由器 | 路由算法计算机 + 若干网络端口 |  |
| 交换机 | 路由算法计算机 + 若干网络端口（连局域网设备） |  |
| 路由器 | 本地端口（连局域网）+ 远程端口（接入互联网），负责协议转换 |  |
应用层引入域名（DNS）：物理网络认 IP，人类记不住，故用域名作交流地址，DNS 负责域名→IP 解析。
案例二：存储新兵"对象存储"
是什么需求满足方式的变化催生了它？三大趋势：
| 趋势 | 含义 |
|---|---|
| 数据跟随账号 | 互联网应用第一大特征，数据不再跟随设备 |
| 交互方式变化 | 从纯文本转向照片/视频/语音，移动化加剧 |
| 体验诉求提升 | 显示精度提升 → 单张照片从 100K 到几十兆 |
对存储系统的四大挑战：规模、可靠、成本、并发吞吐。
文件型存储的备选方案对比：
| 方案 | 接口/特征 | 为何不适合大规模文件型存储 |
|---|---|---|
| 本地文件系统 | 文件系统 | 单机，无规模 |
| NAS（NFS/FTP/Samba/WebDAV） | 文件系统 | 出现早，没考虑大规模挑战 |
| 数据库 | 结构化数据 | 极少作文件型存储 |
| SAN | 块存储（模拟硬盘） | 太底层，应用很少直接用 |
| GFS/HDFS | 文件系统 | 为大文件/日志设计，元数据单机可放，不解决海量小文件 |
关键洞见：除数据库和 SAN 外，其余共同特征都是接口为文件系统（FileSystem）——而文件系统是一棵树，除单文件操作外，任何树节点修改（如移动节点）都是需锁住整棵树的事务操作，对规模和并发吞吐都是伤害。
对象存储打破了"文件型存储接口一定是文件系统"的惯例，改用键值存储（Key-Value）：
| 概念 | 含义 |
|---|---|
| 桶 Bucket | 类似数据库的表，逻辑划分手段 |
| 键 Key | 选定桶 + Key 即可存取文件 |
| 无关联 | 文件间不存在树型关联，可按算法把元信息分散到不同机器 |
关键判断：文件型存储为何不必考虑文件间关联？因为关系都在数据库里，文件型存储只负责内容存储，有个 Key 找到内容即可。本质上服务端（高并发）与桌面（单用户）面临的场景完全不同——文件系统是桌面单用户产物，数据库的出现早已证明文件系统不适合服务端。
对象存储的市场影响：支持万亿级文件（NAS 的 POC 一般只要求 1-2 亿）；并逐步侵蚀 Hadoop 生态——HDFS 只是对象存储的一个特例，大数据生态正过渡到以对象存储为基石。
两案例对比
| 维度 | 互联网 | 对象存储 |
|---|---|---|
| 与既有方案关系 | 不替换，而是连接既有方案 | 替换/补充既有存储方案 |
| 历史包袱 | 很少 | 重，需面对老存储搬迁 |
| 关键决策 | 开放、安全后置 | 用 K-V 替代文件系统 |
| 搬迁方案 | 不需要 | 存储网关：把对象存储包装成 NAS（NFS/FTP/Samba/WebDAV） |
关键洞见：云服务的诞生让存储有了新交付形态（不再扛硬件上门），打开了空白市场；但空白市场之外仍要解决既有方案搬迁，于是存储网关应运而生。
总结
两个案例印证：不同市场差异极大，不存在大一统的产品定义和市场策略。互联网是无历史包袱的"连接者"，关键决策是开放、把安全后置到软件层；对象存储是有历史包袱的"替换者"，关键决策是用 K-V 打破文件系统惯例以应对海量并发，并用存储网关解决搬迁。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 互联网的根源需求 | 一张开放、无造物主的网 |
| 安全后置 | 安全留给可变更的软件层而非物理网络 |
| 对象存储 | 用 Key-Value 替代文件系统的文件型存储 |
| 文件系统是树 | 树节点修改需锁整棵树，伤害规模与并发 |
| 存储网关 | 把对象存储包装成 NAS 供老用户迁移 |
一句话速记
互联网靠"开放 + 安全后置"做连接者无包袱，对象存储靠"K-V 替代文件系统树"做替换者解海量并发——市场不同，打法迥异。
几条值得记住的判断
- 重要但不可持续的需求（如安全）可阶段性后置，放到更经得起变更的层。
- 文件系统是桌面单用户产物，服务端高并发场景应警惕"树锁"。
- 不存在大一统的产品定义，连接者与替换者的策略完全不同。
思考题
互联网把"安全"这个重要却不可持续的需求阶段性地放到了软件层。回到你的系统：有没有某个你"内建"进底层、却其实演化速度很快的能力？它是不是该被上移到更容易变更的层，给未来留出迭代空间？
