E2B 核心架构 - 精简版E2B 核心架构 - 精简版 1. 核心架构图 2. 组件职责矩阵组件端口部署方式核

E2B 核心架构 - 精简版

只包含4个核心组件，去除所有外部依赖和辅助服务

1. 核心架构图

graph TB
    subgraph "客户端"
        SDK[Client SDK<br/>JS/Python/Go]
    end

    subgraph "API层"
        API[API Server<br/>:3000<br/>━━━━━━━━━<br/>沙箱CRUD<br/>鉴权管理<br/>配额控制]
        Proxy[Client Proxy<br/>:443<br/>━━━━━━━━━<br/>流量代理<br/>WebSocket<br/>文件传输]
    end

    subgraph "宿主机 (每台1个进程)"
        Orch[Orchestrator<br/>:8080<br/>━━━━━━━━━<br/>VM生命周期<br/>资源管理<br/>Firecracker控制]
    end

    subgraph "虚拟机层"
        VM1[Firecracker VM 1<br/>Envd进程<br/>用户代码]
        VM2[Firecracker VM 2<br/>Envd进程<br/>用户代码]
        VM3[Firecracker VM N<br/>Envd进程<br/>用户代码]
    end

    SDK -->|1. 创建沙箱<br/>POST /sandboxes| API
    SDK -->|2. 访问沙箱<br/>wss://xxx.e2b.dev| Proxy

    API -->|gRPC<br/>CreateSandbox| Orch
    Proxy -->|HTTP/WS<br/>转发流量| Orch

    Orch -->|启动/管理| VM1
    Orch -->|启动/管理| VM2
    Orch -->|启动/管理| VM3

    style SDK fill:#e1f5ff
    style API fill:#fff4e1
    style Proxy fill:#ffe1f5
    style Orch fill:#e1ffe1
    style VM1 fill:#f0f0f0
    style VM2 fill:#f0f0f0
    style VM3 fill:#f0f0f0

2. 组件职责矩阵

组件	端口	部署方式	核心职责	通信协议
Client SDK	N/A	客户端库	封装API调用、WebSocket连接	HTTP/WebSocket
API Server	3000	多实例(3+)	沙箱CRUD、鉴权、配额管理	REST API + gRPC
Client Proxy	443	多实例(10+)	流量代理、子域名路由	HTTP/WebSocket
Orchestrator	8080	每宿主机1个	VM生命周期、Firecracker管理	gRPC

3. 两条核心请求链路

3.1 控制平面：创建沙箱

sequenceDiagram
    participant SDK as Client SDK
    participant API as API Server
    participant Orch as Orchestrator
    participant FC as Firecracker

    SDK->>API: POST /sandboxes<br/>{template: "base"}
    activate API
    
    Note over API: 1. 验证API Key
    Note over API: 2. 检查配额
    Note over API: 3. 分配沙箱ID
    
    API->>Orch: gRPC: CreateSandbox<br/>{sandboxID, template}
    activate Orch
    
    Note over Orch: 4. 准备VM配置
    Orch->>FC: 启动Firecracker VM
    activate FC
    Note over FC: 5. 启动VM<br/>6. 启动Envd
    FC-->>Orch: VM Ready
    deactivate FC
    
    Orch-->>API: SandboxInfo<br/>{id, ip, status}
    deactivate Orch
    
    API-->>SDK: 200 OK<br/>{sandboxID, url}
    deactivate API
    
    Note over SDK: 沙箱创建完成<br/>可以开始访问

3.2 数据平面：访问沙箱

sequenceDiagram
    participant SDK as Client SDK
    participant CProxy as Client Proxy
    participant OProxy as Orchestrator Proxy<br/>(5007端口)
    participant Envd as Envd (VM内)
    participant App as 用户进程

    SDK->>CProxy: GET https://sbx_abc123.e2b.dev/api/data
    activate CProxy
    
    Note over CProxy: 1. 解析subdomain<br/>提取sandboxID
    Note over CProxy: 2. 从Catalog查询<br/>Orchestrator IP
    
    CProxy->>OProxy: HTTP转发到<br/>Orchestrator:5007
    activate OProxy
    
    Note over OProxy: 3. 查找沙箱<br/>获取VM IP
    
    OProxy->>Envd: HTTP转发到VM
    activate Envd
    
    Envd->>App: 转发到用户进程
    activate App
    App-->>Envd: 响应数据
    deactivate App
    
    Envd-->>OProxy: 响应
    deactivate Envd
    
    OProxy-->>CProxy: 响应
    deactivate OProxy
    
    CProxy-->>SDK: 200 OK + 数据
    deactivate CProxy
    
    Note over SDK,App: 两层代理：Client Proxy → Orchestrator Proxy → VM

4. 关键设计决策

4.1 为什么分离API Server和Client Proxy？

维度	API Server	Client Proxy
请求频率	低频 (创建/删除)	高频 (每次访问)
延迟要求	500ms-2s	10-50ms
业务复杂度	高 (数据库、鉴权、配额)	低 (纯转发)
扩展策略	3-5实例	10+实例
故障影响	无法创建新沙箱	无法访问沙箱

结论: 控制平面和数据平面分离，独立扩展、互不影响。

4.2 为什么Orchestrator是System Job？

原因1: 需要访问宿主机的/dev/kvm设备
原因2: 每台宿主机只能有1个Orchestrator管理本机VM
原因3: 与宿主机硬件资源强绑定

4.3 核心通信协议选择

Client SDK ──REST/WebSocket──> API Server/Proxy
API Server ──gRPC──> Orchestrator  (低延迟、强类型)
Orchestrator ──gRPC──> Envd       (VM内通信)

6. 部署拓扑（精简版）

graph TB
    subgraph "负载均衡层"
        LB[Load Balancer]
    end

    subgraph "API节点池 (3实例)"
        API1[API Server 1]
        API2[API Server 2]
        API3[API Server 3]
    end

    subgraph "Proxy节点池 (10实例)"
        P1[Client Proxy 1]
        P2[Client Proxy 2]
        P3[Client Proxy ...]
    end

    subgraph "宿主机1"
        O1[Orchestrator 1]
        VM1[VM Pool]
    end

    subgraph "宿主机2"
        O2[Orchestrator 2]
        VM2[VM Pool]
    end

    subgraph "宿主机N"
        O3[Orchestrator N]
        VM3[VM Pool]
    end

    LB --> API1
    LB --> API2
    LB --> API3
    LB --> P1
    LB --> P2
    LB --> P3

    API1 -.gRPC.-> O1
    API2 -.gRPC.-> O2
    API3 -.gRPC.-> O3

    P1 -.HTTP.-> O1
    P2 -.HTTP.-> O2
    P3 -.HTTP.-> O3

    O1 --> VM1
    O2 --> VM2
    O3 --> VM3

7. 核心代码入口

组件	代码路径	启动入口
API Server	`packages/api/`	`main.go` → `server.Start()`
Client Proxy	`packages/client-proxy/`	`main.go` → `proxy.Start()`
Orchestrator	`packages/orchestrator/`	`main.go` → `server.NewGRPCServer()`
Envd (VM内)	`packages/envd/`	`main.go` → `api.Start()`

8. 最小可运行配置

要运行E2B核心功能，最少需要：

# 1个API Server实例
./api-server --port 3000

# 1个Client Proxy实例  
./client-proxy --port 443

# 1个Orchestrator实例 (在宿主机上)
./orchestrator --port 8080

就这3个进程 + Firecracker，即可提供完整的沙箱服务！

总结

4个核心组件：

Client SDK - 用户接口层
API Server - 控制平面 (管理+鉴权)
Client Proxy - 数据平面 (流量代理)
Orchestrator - 执行平面 (VM管理)

2条核心链路：

控制链路: SDK → API → Orchestrator → VM (低频)
数据链路: SDK → Proxy → Orchestrator → VM (高频)

关键设计: 控制平面和数据平面分离，实现高性能和高可用！