310 lines
9.7 KiB
Markdown
310 lines
9.7 KiB
Markdown
# RWADurian 2.0 系统部署与运维成本方案
|
||
|
||
**版本：** 1.0
|
||
**日期：** 2026年1月22日
|
||
**编制：** 技术部
|
||
|
||
---
|
||
|
||
## 一、项目概述
|
||
|
||
### 1.1 系统简介
|
||
|
||
RWADurian 2.0 是一套基于微服务架构的数字资产挖矿与交易系统。用户通过贡献算力参与挖矿，系统按秒计算并分配资产份额，同时支持资产交易、销毁等功能。
|
||
|
||
### 1.2 业务场景
|
||
|
||
#### 场景一：实时挖矿与资产展示
|
||
|
||
用户通过安卓 App 参与挖矿，系统需要：
|
||
|
||
- **按秒计算挖矿收益**：根据用户算力占比，每秒计算并分配资产份额
|
||
- **实时推送资产变化**：用户在 App 上能实时看到资产数量和价值的变化
|
||
- **长连接保持**：用户打开 App 期间，通过 WebSocket 长连接保持数据同步
|
||
- **不间断运行**：挖矿服务全年 7×24 小时不中断
|
||
|
||
#### 场景二：资产交易与K线行情
|
||
|
||
用户可在平台内进行资产买卖：
|
||
|
||
- **实时K线行情**：展示分钟/小时/日K线图表
|
||
- **销毁记录实时更新**：每笔交易产生的销毁量实时显示
|
||
- **价格实时刷新**：资产价格随交易实时变动
|
||
|
||
### 1.3 需部署服务清单
|
||
|
||
| 服务名称 | 路径 | 功能描述 | 端口 |
|
||
|----------|------|----------|------|
|
||
| mining-admin-web | frontend/mining-admin-web | 管理后台前端 | 3100 |
|
||
| auth-service | backend/services/auth-service | 用户认证与授权 | 3024 |
|
||
| contribution-service | backend/services/contribution-service | 算力/贡献值管理 | 3020 |
|
||
| mining-service | backend/services/mining-service | 挖矿核心服务 | 3021 |
|
||
| trading-service | backend/services/trading-service | 交易与行情服务 | 3022 |
|
||
| mining-admin-service | backend/services/mining-admin-service | 管理后台API | 3023 |
|
||
|
||
### 1.4 技术栈
|
||
|
||
| 组件 | 技术 |
|
||
|------|------|
|
||
| 前端 | Next.js 14 + React 18 + Tailwind CSS + ECharts |
|
||
| 后端 | NestJS 10 (全部5个服务) |
|
||
| 数据库 | PostgreSQL 15 |
|
||
| 缓存 | Redis 7 |
|
||
| 消息队列 | Kafka |
|
||
| 实时通信 | Socket.io (WebSocket) |
|
||
|
||
---
|
||
|
||
## 二、数据存储与带宽需求分析
|
||
|
||
### 2.1 数据存储需求
|
||
|
||
#### 核心数据结构
|
||
|
||
| 数据类型 | 单条大小 | 产生频率 | 说明 |
|
||
|----------|----------|----------|------|
|
||
| MiningRecord | 152 bytes | 每用户每分钟1条 | 挖矿记录 |
|
||
| MiningTransaction | 320 bytes | 每笔交易1条 | 资产流水 |
|
||
| BurnRecord | 216 bytes | 每分钟1条 | 销毁记录 |
|
||
| MinuteKLine | 152 bytes | 每分钟1条 | K线数据 |
|
||
|
||
#### 存储量估算（按 10,000 活跃用户计算）
|
||
|
||
| 时间范围 | 原始数据量 | 含索引 (×1.5) |
|
||
|----------|------------|---------------|
|
||
| 每日 | ~1.1 GB | ~1.7 GB |
|
||
| 每月 | ~33 GB | ~50 GB |
|
||
|
||
### 2.2 带宽需求
|
||
|
||
#### 实时推送数据量（单用户）
|
||
|
||
| 推送类型 | 数据大小 | 推送频率 | 带宽占用 |
|
||
|----------|----------|----------|----------|
|
||
| 价格更新 | 200 bytes | 每秒1次 | 1.6 kbps |
|
||
| 余额更新 | 495 bytes | 每秒1次 | 3.96 kbps |
|
||
| 销毁/K线 | 425 bytes | 每分钟1次 | 0.1 kbps |
|
||
| **单用户合计** | | | **5.7 kbps** |
|
||
|
||
#### 带宽承载能力
|
||
|
||
| 带宽规格 | 理论承载 | 实际承载（预留30%） |
|
||
|----------|----------|---------------------|
|
||
| 10 Mbps | 1,754 用户 | ~1,200 用户 |
|
||
| 50 Mbps | 8,771 用户 | ~6,000 用户 |
|
||
| 100 Mbps | 17,543 用户 | ~12,000 用户 |
|
||
|
||
---
|
||
|
||
## 三、方案一：高可用架构
|
||
|
||
### 3.1 适用场景
|
||
|
||
**要求全年每一秒钟都不中断挖矿与销毁记录，用户通过安卓手机实时长连接，按秒显示资产数量与价值。**
|
||
|
||
- 挖矿服务 7×24 不间断运行
|
||
- 用户 App 实时展示资产变化
|
||
- 主备自动切换，故障无感知
|
||
|
||
### 3.2 架构设计
|
||
|
||
```
|
||
┌─────────────┐
|
||
│ 用户请求 │
|
||
└──────┬──────┘
|
||
│
|
||
┌──────▼──────┐
|
||
│ Nginx VIP │ (Keepalived 漂移)
|
||
└──────┬──────┘
|
||
┌────────────┼────────────┐
|
||
│ │
|
||
┌──────▼──────┐ ┌──────▼──────┐
|
||
│ Server 1 │◄────────►│ Server 2 │
|
||
│ (主节点) │ 心跳检测 │ (备节点) │
|
||
│ │ │ │
|
||
│ - 6个服务 │ │ - 6个服务 │
|
||
│ - Nginx │ │ - Kafka │
|
||
│ - Redis主 │ │ - Redis从 │
|
||
└──────┬──────┘ └──────┬──────┘
|
||
│ │
|
||
└────────────┬────────────┘
|
||
│
|
||
┌──────▼──────┐
|
||
│ Server 3 │
|
||
│ (数据库) │
|
||
│ │
|
||
│ - PG 主实例 │
|
||
│ - PG 从实例 │
|
||
└─────────────┘
|
||
```
|
||
|
||
### 3.3 服务器配置
|
||
|
||
| 服务器 | 角色 | 部署内容 |
|
||
|--------|------|----------|
|
||
| Server 1 | 应用主节点 | 6个服务 + Nginx + Redis主 |
|
||
| Server 2 | 应用备节点 | 6个服务(热备) + Kafka + Redis从 |
|
||
| Server 3 | 数据库节点 | PostgreSQL 主从复制 |
|
||
|
||
### 3.4 高可用机制
|
||
|
||
| 故障场景 | 恢复策略 | 恢复时间 |
|
||
|----------|----------|----------|
|
||
| Server 1 宕机 | Keepalived 自动切换至 Server 2 | < 30 秒 |
|
||
| Server 2 宕机 | Server 1 继续服务 | 无影响 |
|
||
| Server 3 宕机 | 从实例提升为主 | < 5 分钟 |
|
||
| 单服务崩溃 | PM2/Systemd 自动重启 | < 10 秒 |
|
||
|
||
### 3.5 月度成本
|
||
|
||
| 费用项目 | 规格 | 月租金 |
|
||
|----------|------|--------|
|
||
| 应用服务器 ×2 | 主备双活 | ¥7,000 |
|
||
| 数据库服务器 ×1 | PostgreSQL 主从 | ¥3,500 |
|
||
| 带宽 | 100 Mbps × ¥100/M | ¥10,000 |
|
||
| 公网 IP | 3 个 | ¥150 |
|
||
| 备份 + 监控 | - | ¥300 |
|
||
| **合计** | | **¥20,950/月** |
|
||
|
||
### 3.6 支撑能力
|
||
|
||
| 指标 | 数值 |
|
||
|------|------|
|
||
| 同时在线用户 | ~12,000 |
|
||
| 实时推送频率 | 每秒 |
|
||
| 可用性 | 99.9%+ |
|
||
|
||
---
|
||
|
||
## 四、方案二：标准架构
|
||
|
||
### 4.1 适用场景
|
||
|
||
**不考虑挖矿是否中断，中断后重启继续即可；不要求按秒实时显示，但销毁记录和K线需要实时刷新。**
|
||
|
||
- 允许短暂服务中断
|
||
- K线行情、销毁记录实时更新
|
||
- 资产余额可通过轮询刷新
|
||
|
||
### 4.2 架构设计
|
||
|
||
```
|
||
┌─────────────┐
|
||
│ 用户请求 │
|
||
└──────┬──────┘
|
||
│
|
||
┌──────▼──────┐
|
||
│ Server 1 │
|
||
│ (单节点) │
|
||
│ │
|
||
│ - 6个服务 │
|
||
│ - Nginx │
|
||
│ - Redis │
|
||
│ - Kafka │
|
||
│ - PostgreSQL│
|
||
└─────────────┘
|
||
```
|
||
|
||
### 4.3 服务器配置
|
||
|
||
| 服务器 | 角色 | 部署内容 |
|
||
|--------|------|----------|
|
||
| Server 1 | 全功能节点 | 6个服务 + 全部中间件 + 数据库 |
|
||
|
||
### 4.4 月度成本
|
||
|
||
| 费用项目 | 规格 | 月租金 |
|
||
|----------|------|--------|
|
||
| 服务器 ×1 | 应用 + 数据库 | ¥3,500 |
|
||
| 带宽 | 10 Mbps × ¥100/M | ¥1,000 |
|
||
| 公网 IP | 1 个 | ¥50 |
|
||
| 机柜托管 | 2U | ¥400 |
|
||
| 备份 + 监控 | - | ¥200 |
|
||
| **合计** | | **¥5,150/月** |
|
||
|
||
### 4.5 支撑能力
|
||
|
||
| 指标 | 数值 |
|
||
|------|------|
|
||
| 同时在线用户 | ~1,200 |
|
||
| K线/销毁刷新 | 实时 |
|
||
| 可用性 | 99%+ |
|
||
|
||
---
|
||
|
||
## 五、方案对比
|
||
|
||
| 维度 | 方案一（高可用） | 方案二（标准） |
|
||
|------|-----------------|---------------|
|
||
| **适用场景** | 秒级实时推送，不中断 | K线/销毁实时，允许中断 |
|
||
| **月成本** | ¥20,950 | ¥5,150 |
|
||
| **服务器数量** | 3 台 | 1 台 |
|
||
| **带宽** | 100 Mbps | 10 Mbps |
|
||
| **同时在线用户** | ~12,000 | ~1,200 |
|
||
| **实时性** | 秒级推送 | 分钟级/轮询 |
|
||
| **可用性** | 99.9% | 99% |
|
||
| **挖矿中断处理** | 自动切换，不中断 | 需手动重启 |
|
||
|
||
---
|
||
|
||
## 六、成本汇总
|
||
|
||
| 方案 | 月成本 |
|
||
|------|--------|
|
||
| 方案一（高可用） | ¥20,950 |
|
||
| 方案二（标准） | ¥5,150 |
|
||
| **差额** | ¥15,800 |
|
||
|
||
---
|
||
|
||
## 七、建议
|
||
|
||
### 7.1 初期阶段
|
||
|
||
建议采用 **方案二（标准架构）**：
|
||
|
||
- 月成本仅 ¥5,150，降低初期投入
|
||
- 满足初期用户规模需求（~1,200 在线）
|
||
- 快速上线验证业务模式
|
||
- K线和销毁记录仍可实时刷新
|
||
|
||
### 7.2 扩展阶段
|
||
|
||
当满足以下条件时，升级至 **方案一（高可用架构）**：
|
||
|
||
- 同时在线用户超过 1,000
|
||
- 用户对实时性要求提高
|
||
- 业务模式验证成功，进入增长期
|
||
|
||
---
|
||
|
||
## 八、附录
|
||
|
||
### 8.1 服务端口分配
|
||
|
||
| 服务 | 端口 |
|
||
|------|------|
|
||
| mining-admin-web | 3100 |
|
||
| contribution-service | 3020 |
|
||
| mining-service | 3021 |
|
||
| trading-service | 3022 |
|
||
| mining-admin-service | 3023 |
|
||
| auth-service | 3024 |
|
||
| PostgreSQL | 5432 |
|
||
| Redis | 6379 |
|
||
| Kafka | 9092 |
|
||
|
||
### 8.2 数据库分配
|
||
|
||
| 服务 | 数据库名 | Redis DB |
|
||
|------|----------|----------|
|
||
| auth-service | rwa_auth | 14 |
|
||
| contribution-service | rwa_contribution | 0 |
|
||
| mining-service | mining_db | 1 |
|
||
| trading-service | trading_db | 2 |
|
||
| mining-admin-service | mining_admin_db | 3 |
|
||
|
||
---
|
||
|
||
**文档结束**
|