技术架构的轮回：从 Azure Direct Drive 看“云端帝国”的 Shared Nothing 反击战

在文章创一代与富二代在 Shared Nothing 和 Shared Disk 上的抉择里，我们发现一个规律，分布式系统的江湖里，一直存在着两条截然不同的路线, shared nothing 和 shared disk。

开源社区和独角兽们的成名作——ScyllaDB、Cassandra、TiKV、Ceph，以及最近大火的 DeepSeek 3FS，它们几乎清一色地选择了 Shared Nothing 架构。每个节点既是计算也是存储，守土有责，互不干涉，像是一个个占山为王的诸侯。

由于垄断资源而建立起的“云端帝国”——Google Bigtable、Azure Storage (Blob/File)、Alibaba Cloud (OSS/EBS)，你会发现它们更倾向于 Shared Storage（或存算分离）架构。计算层是无状态的“打工人”，数据统一存放在底层的存储池里，通过一层又一层的网关和负载均衡器来访问数据，像是一个中央集权的帝国。

为什么会有这种“小团队偏爱 Shared Nothing，大公司偏爱 Shared Disk”的规律？这背后，其实是创一代（技术突围者）与创二代（资源继承者）在面对不同约束条件时的最优解。

“创一代”资源匮乏，唯有压榨每一分硬件性能（Performance）才能生存，所以他们拒绝中间商，拒绝中心化；“创二代”资源富足，更看重规模化管理（Manageability）和多租户隔离，所以他们喜欢建立层级，喜欢统一调度。

但是，微软 Azure 的最新块存储架构——Direct Drive，却打破了这个规律。 这位典型的“云端皇帝”，竟然在最新的核心存储产品中，拆掉了层层宫墙，搞起了 Shared Nothing 风格的“直连”。

这究竟是架构的倒退，还是更高维度的螺旋上升？

1. 传统的云存储架构：中央集权的代价

在 Azure 传统的块存储（以及大多数云厂商的 EBS 类产品）中，I/O 路径通常是这样的：

VM (Client) -> Load Balancer -> Front End (Gateway) -> Partition Server -> Storage Node

这是一个典型的“帝国式”架构。所有的请求都要经过“皇宫大门”（Front End）。这样做的好处显而易见：

• 统一管理：Gateway 可以做鉴权、流控、计费、快照。
• 屏蔽复杂：客户端不需要知道数据具体在哪块盘上，只需要向 Gateway 要数据。
• 故障隔离：底层的变动对上层透明。

但代价也很沉重：延迟（Latency）和 抖动（Jitter）。每一次跳转（Hop）都是一次性能损耗。当 IOPS 需求飙升到 10万、20万甚至更高时，那个曾经带来便利的“中央网关”，就变成了最大的性能瓶颈。

2. Azure Direct Drive：皇帝也开始“摆地摊”

微软在 Direct Drive 架构（Direct Drive 是 Azure 内部代号，对应公有云产品 Ultra Disk）中，做了一个惊人的决定：砍掉中间层。

根据 Azure 官方在 SDC (Storage Developer Conference) 上的披露，Direct Drive 的核心设计理念是：

• Simplify the I/O path（简化 I/O 路径）
• Clients should be able to access data directly（客户端应能直接访问数据）
• Avoiding load-balancers, front ends, partitioning layers（避开负载均衡、前端和分区层）

架构细节中的“反模式”

在 Direct Drive 中，计算节点上的虚拟机客户端（VDC - Virtual Disk Client）变得极度“聪明”。它不再是傻傻地发请求给网关，而是手里握着一张“地图”（Map）。

1. 直连数据节点（Shared Nothing 的精髓）：
   客户端知道每一个数据分片（Slice）具体位于后端的哪几个 Block Storage Service (BSS) 节点上。
2. 胖客户端（Smart Client）：
   读写请求不再经过 Load Balancer，而是由客户端通过 DDX 协议（基于 RDMA/TCP 的私有协议）直接发给存储节点。
3. 拓扑感知：
   客户端甚至参与到数据的一致性维护中，它知道 Replica Set（副本集）的存在，能够处理分片层面的路由。

这不就是 Ceph 客户端做的事情吗？这不就是 TiKV SDK 做的事情吗？

没错。微软在架构上抛弃了 Shared Storage 标志性的“统一入口”，转而采用了 Shared Nothing 标志性的“全对等、端到端直连”。

3. 为什么“创二代”要学“创一代”？

为什么微软这种拥有无限资源的“创二代”，要退回到这种看起来管理更复杂、客户端更重的架构？

答案只有一个：被性能逼的。

在云原生时代，数据库（如 ScyllaDB）和 AI 训练任务对 I/O 的吞吐和延迟要求已经达到了物理极限。云厂商发现，如果不拆掉中间那层厚厚的“官僚机构”（Gateway），无论后端堆多少 SSD，性能都卡在网络转发上。

这给我们揭示了一个关于技术架构选择的深层逻辑：

阶段一：资源匮乏期（创一代）

架构特征： Shared Nothing, P2P, Kernel Bypass.

目标： 活下去。

手段： 消除一切中间商，能直连就直连，复杂性留给代码，性能留给用户。

阶段二：资源爆发期（创二代 - 早期）

架构特征： Shared Storage, Disaggregated, Layered.

目标： 管得好。

手段： 引入中间层，解耦，通过堆硬件来掩盖软件的低效，用延迟换取灵活性和多租户隔离。

阶段三：资源内卷期（创二代 - 觉醒）

架构特征： Direct Drive, RDMA, Smart Client.

目标： 赢下去。

手段： 架构的“返祖”。当竞争维度回到硬核的性能指标（IOPS/Latency）时，云厂商发现，“中央集权”的效率天花板太低了。他们不得不重新捡起“创一代”的武器——Shared Nothing 的直连思想，利用 RDMA 等新网络技术，把“云”做得像“物理机”一样快。

4. 结语：反模式才是进化的阶梯

Azure Direct Drive 的出现，打破了“云原生就得是全虚拟化、全网关化”的迷信。它告诉我们，架构没有绝对的“先进”与“落后”。

• 当你的瓶颈是管理成本时，Shared Storage 是真理，把复杂性藏在网关后面。
• 当你的瓶颈是极致性能时，Shared Nothing 是真理，把复杂性推向边缘（客户端），换取直线距离的最短路径。

微软的这次转身，表面上是架构的轮回，实际上是螺旋上升。它不再是简单的“各管一摊”的 Shared Nothing，而是基于高速网络（RDMA）和智能控制面（Control Plane）重新定义的 Direct Access。

对于我们技术人来说，这或许是一个信号：在盲目追求“云原生解耦”的今天，有时候，拆掉网关，回归直连，反而是通向下一代高性能架构的“捷径”。

最后打个广告，想看"不正经但更有趣的技术"请移步《文件系统演义》