​

架构总览

​

多服务设计

​

元数据服务

​

可集成或独立部署

• 进程内集成：把多个服务放进同一个 blockdb 进程，本地共享依赖，便于开发和中小规模部署。
• 独立部署：按读写等资源特征把服务拆成独立进程，各自水平扩展、独立运维。

​

推荐部署拓扑

                  ┌──────────────┐
                  │ meta-service │  表元数据管理（独立）
                  └──────────────┘

  读服务（一个 binary）         写服务（一个 binary）
  ┌──────────────┐            ┌──────────────┐
  │ read         │            │ write        │
  │ block-read   │            │              │
  └──────────────┘            └──────────────┘

  独立部署                         独立部署
  ┌──────────────┐  ┌───────────┐ ┌──────────────┐
  │ scan         │  │ subscribe │ │ batch-worker │
  └──────────────┘  └───────────┘ └──────────────┘

• 所有读 API（scan 除外）集成在同一个 binary：read + block-read。
• 所有写 API 集成在同一个服务：write。
• scan 与 subscribe 各自独立部署：避免大扫描拖累读服务、长连接订阅影响其它服务。
• 批量写入 worker 独立部署：batch-worker 独立扩缩容，与实时读写隔离。

​

底层依赖

• 物理数据库：遵循 MySQL 协议的物理在线数据库，BlockDB 通过标准 SQL 完成实际读写。
• Redis：作为缓存使用（如区块读取缓存）。
• Kafka：作为事件总线，分发区块写入事件并支撑订阅。
• 对象存储：用于大批量写入的数据中转，以及区块 bundle 等文件的存取。

​

设计要点

• 无状态：核心服务进程不持有本地状态，可自由组合、水平扩展。
• 元数据与计算分离：meta-service 管理表元数据，核心读写服务保持无状态。
• 按资源特征拆分：读 / 写 / 扫描 / 订阅按资源消耗与并发模型拆分为不同服务，便于独立调优与扩缩容。