整体架构

本文介绍 Bingo 的整体架构设计和服务组成。

架构图

┌─────────────────────────────────────────────────────────────┐
│                        客户端层                              │
│  Web Browser / Mobile App / Third-party Services            │
└────────────────────┬────────────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────────────┐
│                      API 网关层(可选)                       │
│                   Nginx / Traefik / Kong                     │
└────────────────────┬────────────────────────────────────────┘
                     │
         ┌───────────┼───────────┬────────────┐
         ▼           ▼           ▼            ▼
    ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
    │   API   │ │  Admin  │ │Scheduler│ │   Bot   │
    │ Server  │ │ Server  │ │ Service │ │ Service │
    └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘
         │           │           │            │
         └───────────┼───────────┴────────────┘
                     ▼
         ┌───────────────────────┐
         │   基础设施层            │
         ├───────────────────────┤
         │  MySQL / PostgreSQL   │
         │  Redis                │
         │  Message Queue        │
         └───────────────────────┘

服务说明

1. API Server (bingo-apiserver)

端口:

• 8080 (HTTP)
• 8081 (gRPC)
• 8082 (WebSocket)

职责:

• 对外提供 RESTful API 服务
• WebSocket 实时通信
• 面向 C 端用户

特点:

• 高并发场景
• 可水平扩展
• 无状态设计

典型场景:

• 用户注册登录
• 业务数据查询
• 实时消息推送

2. Admin Server (bingo-admserver)

端口:

• 18080 (HTTP)
• 18081 (gRPC)

职责:

• 管理后台 API 服务
• 内部管理功能
• 数据统计分析

特点:

• 面向内部管理
• 权限控制严格
• 操作审计完整

典型场景:

• 用户管理
• 权限配置
• 系统监控

3. Scheduler (bingo-scheduler)

端口:

• 8080 (Web UI)

职责:

• 定时任务调度
• 异步任务处理
• 任务监控管理

特点:

• 基于 Asynq
• 支持任务重试
• 可视化监控

典型场景:

• 定时数据同步
• 批量消息发送
• 数据清理归档

4. Bot Service (bingo-bot)

职责:

• 第三方平台集成
• Discord/Telegram Bot
• 事件处理

特点:

• 事件驱动
• 异步处理
• 可扩展架构

典型场景:

• Discord 命令处理
• Telegram 消息处理
• 第三方回调

5. CLI Tool (bingoctl)

职责:

• 数据库迁移
• 代码生成
• 运维工具

特点:

• 命令行操作
• 提升开发效率
• 自动化任务

典型场景:

• 执行数据库迁移
• 生成 CRUD 代码
• 数据初始化

微服务架构优势

1. 独立部署

每个服务独立部署,互不影响。可以针对不同服务选择不同的部署策略。

2. 水平扩展

根据负载情况独立扩展服务实例:

• API Server 高并发场景可以多实例部署
• Admin Server 内部使用,单实例即可
• Scheduler 根据任务量调整

3. 技术异构

不同服务可以使用不同技术栈(虽然当前都是 Go):

• Bot Service 可以用 Node.js
• Scheduler 可以用 Python

4. 故障隔离

单个服务故障不影响其他服务:

• Bot 服务异常不影响 API 服务
• Scheduler 问题不影响用户访问

5. 团队协作

不同团队可以负责不同服务,并行开发。

服务间通信

gRPC 通信

服务间使用 gRPC 进行高性能通信:

API Server  ──gRPC──→  Admin Server
     │
     └──────gRPC──→  Scheduler

优势:

• 高性能(基于 HTTP/2)
• 类型安全(Protocol Buffers)
• 双向流式通信

共享数据库

当前服务共享同一个数据库,简化事务处理:

API Server  ──┐
Admin Server──┼──→  MySQL
Scheduler   ──┘

注意: 随着业务发展,可以拆分为独立数据库。

基础设施层

MySQL/PostgreSQL

• 主数据库
• 业务数据持久化
• 支持事务

Redis

• 分布式缓存
• Session 存储
• 消息队列(Asynq 后端)

Message Queue

• 基于 Asynq(Redis)
• 异步任务处理
• 定时任务调度

部署方式

开发环境

# 使用 Docker Compose 一键启动
docker-compose up -d

生产环境

┌─────────────┐
│   Nginx     │  负载均衡
└──────┬──────┘
       │
   ┌───┴────┬────────┬────────┐
   ▼        ▼        ▼        ▼
API-1    API-2    API-3    API-N   多实例
   │        │        │        │
   └────────┴────────┴────────┘
            │
         MySQL + Redis

下一步

• 分层架构详解 - 理解单个服务的内部架构