AuraBoot
免费开始
English简体中文

集群模式

集群基础设施视图

单节点 AuraBoot 适合开发与小规模部署。集群模式面向生产工作负载，重点是可用性、吞吐与滚动升级。平台在应用层是无状态的，所以默认的扩容路径就是横向扩展。

拓扑

                  +-----------------+
                  |   Load Balancer |
                  +--------+--------+
                           |
        +------------------+------------------+
        |                  |                  |
   +----v----+        +----v----+        +----v----+
   |  app-1  |        |  app-2  |        |  app-3  |   (stateless JVMs)
   +----+----+        +----+----+        +----+----+
        |                  |                  |
   +----+------------------+------------------+----+
   |                                               |
+--v-----+   +---------+   +---------+   +---------v-+
| Redis  |   |  Kafka  |   |  MinIO  |   | Postgres   |
| (lock+ |   | (event  |   | (files) |   | primary +  |
| cache) |   |  bus)   |   |         |   | standby)   |
+--------+   +---------+   +---------+   +-----------+

应用节点不持有任何持久状态。所有共享状态都落在 Redis、Kafka、PostgreSQL 与 MinIO。

共享基础设施

组件角色说明
Redis分布式锁（SET NX EX，默认 3 分钟租约）、缓存、限流多节点部署需要 Redis；不可用时回落到 JVM 本地锁（仅单实例安全）
Kafka消息队列（aura.mq.type 之一：领域事件、webhook 投递、crawler 等后台任务）多节点可选 Kafka / Redis / RabbitMQ（默认 memory 仅单节点）
PostgreSQL主写节点 + 一个或多个流复制 standby应用面向 primary；standby 用于读多的分析
MinIOS3 兼容对象存储生产环境为耐久性跑 4 节点集群

何时使用

  • 生产流量超出单个 JVM 能承载的上限。
  • 高可用要求（零停机滚动升级）。
  • 必须在节点重启后继续的长期后台工作（crawler、automation）。
  • 同一物理部署上的租户需要隔离；见 多租户。

工作原理

无状态的应用节点通过消息队列共享任务，通过 Redis 锁协调互斥操作。PostgreSQL 主库是唯一的写权威；只读副本仅用于报表。/actuator/health 健康探针接入负载均衡器；下线节点时先把它从负载均衡器摘除、等待在飞请求排空后再关停。

会话亲和性是可选的。Token 是无状态 JWT，请求可以落到任意节点。SSE / WebSocket 连接确实会受益于粘性路由，因为 chokepoint ConversationTurnService 会把 ResponseSink 注册在持有该开放流的节点上。

配置

spring:
  # Redis 可选 —— 设置 SPRING_DATA_REDIS_HOST 环境变量即启用（多节点必需）。
  # 不设置时，应用以本地锁 + 进程内数据同步运行（仅单实例安全）。
  data:
    redis:
      host: "${REDIS_HOST:localhost}"
      port: "${REDIS_PORT:6379}"
  datasource:
    url: "jdbc:postgresql://${PG_PRIMARY}:5432/aura_boot"
    hikari:
      maximum-pool-size: "${HIKARI_MAX_POOL_SIZE:30}"

aura:
  mq:
    type: kafka                  # memory | redis | kafka | rabbitmq
    kafka:
      bootstrap-servers: "${KAFKA_BOOTSTRAP:localhost:9092}"
      consumer-group: aura-group
  scheduler:
    engine: "${AURA_SCHEDULER_ENGINE:local}"   # local（数据库支撑的 TaskScheduler）| xxl

横向扩展拨杆：

拨杆默认值何时调大
应用副本数1负载下 p95 延迟攀升
每节点 HikariCP maximum-pool-size30DB pg_stat_activity 出现排队
每个 topic 的 Kafka 分区数6消费者 lag 增长
Crawler worker 数1Frontier 准入速率超过抓取吞吐
Redis maxmemory2 GB出现 eviction 事件

滚动升级

# 对每个节点按顺序执行：
# 1) 先把节点从负载均衡器后端池摘除（具体命令取决于你的 LB）
sleep 20                                                  # 排空 SSE / commands
ssh "$NODE" 'systemctl restart auraboot'
curl -sS "https://$NODE/actuator/health" | jq -e '.status == "UP"'  # 健康后再放回 LB

与负载均衡器协调，确保同一时刻只下线一个节点。

验证

  • 所有 app 节点 /actuator/health 返回 UP 并对外提供流量。
  • 同一个受锁保护的资源在任一时刻只有一个节点持有 Redis 锁（没有重复执行）。
  • webhook 投递与 crawler 等后台消费者的消息队列 lag 是有界的。
  • 杀掉一个 app 节点后，过了排空窗口不再产生用户可见的错误。
  • 正常负载下 PostgreSQL standby 的复制滞后保持在 1 秒以内。

相关