架构演进与趋势

中间件架构演进历程

第一阶段：单体时代（2000s）

单体应用
  └── 直连数据库
  └── 本地文件存储
  └── 同步调用

痛点：扩展性差、部署耦合、单点故障

第二阶段：SOA 时代（2008~2015）

ESB（企业服务总线）
  ├── 服务注册（Zookeeper）
  ├── 消息队列（ActiveMQ / RabbitMQ）
  └── 数据库连接池（Druid / C3P0）

痛点：ESB 成为瓶颈，中心化治理复杂

第三阶段：微服务时代（2015~2020）

微服务架构
  ├── 服务注册发现（Eureka / Consul / Nacos）
  ├── API 网关（Zuul / Spring Cloud Gateway）
  ├── 配置中心（Apollo / Nacos）
  ├── 消息队列（Kafka / RocketMQ）
  ├── 分布式缓存（Redis Cluster）
  └── 分布式追踪（Zipkin / Jaeger）

第四阶段：云原生时代（2020~至今）

云原生架构
  ├── 容器编排（Kubernetes）
  ├── 服务网格（Istio + Envoy）
  ├── GitOps（Argo CD）
  ├── 可观测性（OpenTelemetry）
  ├── Serverless 消息（Pulsar / EventBridge）
  └── 存算分离（MinIO / Ceph）

当前核心趋势

1. 存算分离

传统中间件将计算和存储耦合在同一节点，扩展时必须同步扩容。

传统模式：
  Broker 节点 = 计算 + 存储（本地磁盘）
  扩容时：计算和存储必须同步扩

存算分离模式（Pulsar）：
  Broker（无状态计算层）← 独立扩容
  BookKeeper（存储层）  ← 独立扩容

影响：Pulsar、TiDB、ClickHouse 等新一代中间件均采用此架构。

2. 服务网格下沉

将服务治理能力从 SDK 下沉到基础设施层（Sidecar）。

传统 SDK 模式：
  应用代码 + 治理 SDK（侵入性强，多语言困难）

Sidecar 模式（Istio + Envoy）：
  应用代码（纯业务）
  Envoy Sidecar（流量治理，语言无关）

3. eBPF 革命

eBPF 允许在内核层面安全地执行自定义程序，正在重塑网络和可观测性中间件。

• Cilium：基于 eBPF 的 K8s 网络插件，替代 iptables
• Pixie：无需插桩的自动可观测性
• Falco：基于 eBPF 的运行时安全

4. WebAssembly 插件

APISIX、Envoy 等网关/代理开始支持 WASM 插件，实现：

• 多语言插件开发（Rust/Go/C++）
• 沙箱隔离，插件崩溃不影响主进程
• 热加载，无需重启

5. 向量数据库崛起

AI 时代的新型中间件需求：

产品	定位
Milvus	开源向量数据库
Qdrant	Rust 实现，高性能
Weaviate	多模态向量存储
pgvector	PostgreSQL 扩展

6. 统一可观测性标准（OpenTelemetry）

OTEL 正在成为可观测性数据的事实标准：

应用 SDK（OTEL）
  └── OTEL Collector
        ├── Prometheus（Metrics）
        ├── Jaeger（Traces）
        └── Loki / ES（Logs）

一次接入，多后端输出，避免厂商锁定。

未来展望

方向	预期变化
AI Infra	向量数据库、特征存储、模型服务网关成为标配
边缘计算	轻量级中间件（NATS、Dapr）向边缘下沉
无服务器	消息队列与 FaaS 深度集成，事件驱动架构普及
安全左移	mTLS、零信任网络成为默认配置
平台工程	Internal Developer Platform 整合中间件能力