- Implement 5 core API endpoints (create task, get progress, get results, update decision, export Excel) - Add FulltextScreeningController with Zod validation (652 lines) - Implement ExcelExporter service with 4-sheet report generation (352 lines) - Register routes under /api/v1/asl/fulltext-screening - Create 31 REST Client test cases - Add automated integration test script - Fix PDF extraction fallback mechanism in LLM12FieldsService - Update API design documentation to v3.0 - Update development plan to v1.2 - Create Day 5 development record - Clean up temporary test files
660 lines
17 KiB
Markdown
660 lines
17 KiB
Markdown
# MSE与ARMS采购决策分析
|
||
|
||
> **分析日期:** 2025-11-18
|
||
> **项目阶段:** 创业初期,ASL模块待开发
|
||
> **问题:** 是否需要购买阿里云MSE(微服务引擎)和ARMS(应用监控)?
|
||
> **结论:** **创业初期不需要,现有基础设施足够** ✅
|
||
|
||
---
|
||
|
||
## 📊 功能对比分析
|
||
|
||
### 1️⃣ 阿里云MSE vs 我们的基础设施
|
||
|
||
| MSE功能 | 我们的实现 | 是否需要MSE | 理由 |
|
||
|---------|-----------|------------|------|
|
||
| **注册配置中心** (Nacos/ZooKeeper) | `config/env.ts` 环境变量 | ❌ **不需要** | 我们是**单体Serverless应用**,不是微服务架构,不需要服务注册 |
|
||
| **微服务治理** (Spring Cloud/Dubbo) | 不适用 | ❌ **不需要** | 我们是Node.js单体应用,不使用Spring Cloud或Dubbo |
|
||
| **云原生网关** (Ingress) | SAE自带网关 | ❌ **不需要** | SAE已提供HTTP路由和负载均衡 |
|
||
| **分布式任务调度** (XXL-JOB) | `common/jobs/` (MemoryQueue/DatabaseQueue) | ⚠️ **暂不需要** | 创业初期我们的jobQueue够用,后续可升级 |
|
||
|
||
**核心差异:**
|
||
```
|
||
MSE适用场景:
|
||
┌─────────┐ ┌─────────┐ ┌─────────┐
|
||
│ 服务A │───│ 服务B │───│ 服务C │ ← 需要注册中心
|
||
└─────────┘ └─────────┘ └─────────┘
|
||
|
||
我们的架构:
|
||
┌───────────────────────────────────────┐
|
||
│ 单体Serverless应用(Fastify) │ ← 不需要注册中心
|
||
│ - legacy模块(AIA/PKB/RVW) │
|
||
│ - ASL模块(待开发) │
|
||
│ - 平台基础设施(8个内部模块) │
|
||
└───────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
### 2️⃣ 阿里云ARMS vs 我们的监控方案
|
||
|
||
| ARMS功能 | 我们的实现 | 是否需要ARMS | 理由 |
|
||
|---------|-----------|-------------|------|
|
||
| **应用监控** | `common/monitoring/metrics.ts` | ⚠️ **暂不需要** | 我们有基础监控,创业初期够用 |
|
||
| **接口调用监控** | `common/logging/logger.ts` | ⚠️ **暂不需要** | Winston结构化日志可追踪 |
|
||
| **性能分析** | `/health` + Metrics | ⚠️ **暂不需要** | 简单场景够用 |
|
||
| **错误诊断** | 结构化日志 + SLS | ⚠️ **暂不需要** | 日志系统可追踪错误 |
|
||
| **调用链追踪** | 无 | ⚠️ **初期不需要** | 单体应用调用链简单 |
|
||
|
||
**核心差异:**
|
||
```
|
||
ARMS适用场景:
|
||
- 复杂的微服务调用链
|
||
- 需要深度性能分析
|
||
- 大规模生产环境(日活>10万)
|
||
|
||
我们的场景:
|
||
- 单体应用,调用链清晰
|
||
- 创业初期,流量小
|
||
- 基础监控 + 日志足够
|
||
```
|
||
|
||
---
|
||
|
||
## 💰 成本效益分析
|
||
|
||
### MSE成本(估算)
|
||
|
||
| 项目 | 配置 | 价格/月 | 说明 |
|
||
|------|------|--------|------|
|
||
| 注册配置中心 | 最小规格 | ~¥200 | Nacos专业版 |
|
||
| 云原生网关 | 最小规格 | ~¥300 | 不需要(SAE已提供) |
|
||
| **总计** | - | **~¥500** | 创业初期不必要 |
|
||
|
||
### ARMS成本(估算)
|
||
|
||
| 项目 | 配置 | 价格/月 | 说明 |
|
||
|------|------|--------|------|
|
||
| 应用监控 | 按调用量 | ~¥300-1000 | 取决于调用量 |
|
||
| **总计** | - | **~¥300-1000** | 有免费额度,但有限 |
|
||
|
||
### 我们的监控成本
|
||
|
||
| 项目 | 配置 | 价格/月 | 说明 |
|
||
|------|------|--------|------|
|
||
| 结构化日志 | Winston → stdout | ¥0 | 免费 |
|
||
| 日志存储 | 阿里云SLS | ¥0-50 | 小流量免费额度内 |
|
||
| 健康检查 | 自实现 | ¥0 | 免费 |
|
||
| **总计** | - | **¥0-50** | 创业初期够用 |
|
||
|
||
**成本对比:**
|
||
```
|
||
购买MSE + ARMS:~¥800-1500/月
|
||
我们的方案: ~¥0-50/月
|
||
|
||
节省成本:~¥800-1500/月 = ~¥10,000-18,000/年
|
||
```
|
||
|
||
---
|
||
|
||
## ✅ 我们的基础设施 vs MSE/ARMS
|
||
|
||
### 我们已经有的能力
|
||
|
||
#### 1. 配置管理(替代MSE配置中心)
|
||
|
||
**我们的方案:**
|
||
```typescript
|
||
// config/env.ts - 统一配置管理
|
||
export const config = {
|
||
storageType: process.env.STORAGE_TYPE || 'local',
|
||
cacheType: process.env.CACHE_TYPE || 'memory',
|
||
queueType: process.env.QUEUE_TYPE || 'memory',
|
||
// ... 40+个配置项
|
||
}
|
||
|
||
// SAE环境变量(云端配置)
|
||
STORAGE_TYPE=oss
|
||
CACHE_TYPE=redis
|
||
QUEUE_TYPE=database
|
||
```
|
||
|
||
**优势:**
|
||
- ✅ 零成本
|
||
- ✅ 简单直接
|
||
- ✅ 适合单体应用
|
||
- ✅ SAE原生支持
|
||
|
||
**MSE配置中心的优势(我们暂不需要):**
|
||
- 动态配置更新(我们重启即可)
|
||
- 多应用配置共享(我们只有1个应用)
|
||
- 版本管理(我们用Git + 环境变量)
|
||
|
||
---
|
||
|
||
#### 2. 任务调度(替代MSE分布式任务调度)
|
||
|
||
**我们的方案:**
|
||
```typescript
|
||
// common/jobs/ - 简单任务队列
|
||
import { jobQueue } from '@/common/jobs'
|
||
|
||
const job = await jobQueue.push('asl:screening', data)
|
||
// 当前实现:MemoryQueue(本地)
|
||
// 后续升级:DatabaseQueue(云端)
|
||
```
|
||
|
||
**优势:**
|
||
- ✅ 零成本
|
||
- ✅ 代码简单
|
||
- ✅ 满足基本需求
|
||
- ✅ 可后续升级
|
||
|
||
**MSE任务调度的优势(我们暂不需要):**
|
||
- 复杂的Cron表达式(我们用简单队列)
|
||
- 任务分片(我们流量小,不需要)
|
||
- 可视化管理(我们代码管理即可)
|
||
- 任务失败重试(我们可以简单实现)
|
||
|
||
**对比:**
|
||
```
|
||
MSE XXL-JOB: ¥200+/月,复杂配置,适合大规模
|
||
我们的jobQueue: ¥0,简单直接,创业阶段够用
|
||
```
|
||
|
||
---
|
||
|
||
#### 3. 应用监控(替代ARMS)
|
||
|
||
**我们的方案:**
|
||
```typescript
|
||
// common/logging/logger.ts - 结构化日志
|
||
import { logger } from '@/common/logging'
|
||
logger.info('API called', {
|
||
path, method, latencyMs, statusCode, userId
|
||
})
|
||
|
||
// common/monitoring/metrics.ts - 关键指标
|
||
Metrics.recordDBConnectionCount()
|
||
Metrics.recordMemoryUsage()
|
||
Metrics.recordApiLatency(path, method, latency, statusCode)
|
||
|
||
// common/health/ - 健康检查
|
||
GET /health/liveness - SAE存活检查
|
||
GET /health/readiness - 就绪检查(含数据库/内存/缓存)
|
||
```
|
||
|
||
**日志输出到阿里云SLS(免费额度内):**
|
||
```
|
||
Winston(stdout,JSON格式)→ SAE采集 → 阿里云SLS存储
|
||
小流量场景:免费额度够用(每月500MB日志)
|
||
```
|
||
|
||
**优势:**
|
||
- ✅ 基本监控能力完整
|
||
- ✅ 日志可追溯
|
||
- ✅ 健康检查完善
|
||
- ✅ 成本极低(SLS免费额度)
|
||
|
||
**ARMS的优势(我们暂不需要):**
|
||
- 可视化Dashboard(我们可以查日志)
|
||
- 调用链追踪(单体应用不需要)
|
||
- 自动告警(我们可以简单实现)
|
||
- 深度性能分析(创业初期不需要)
|
||
|
||
---
|
||
|
||
## 📈 什么时候需要MSE和ARMS?
|
||
|
||
### 升级触发条件
|
||
|
||
#### 考虑购买MSE的时机:
|
||
|
||
1. **架构演进为微服务**
|
||
- 当前:单体Serverless应用
|
||
- 未来:拆分为5+个独立服务
|
||
- 触发条件:模块独立部署、团队>10人
|
||
|
||
2. **任务调度复杂化**
|
||
- 当前:简单队列(<1000个任务/天)
|
||
- 未来:复杂定时任务、任务分片
|
||
- 触发条件:任务量>10,000/天
|
||
|
||
3. **配置管理复杂化**
|
||
- 当前:环境变量(<50个配置项)
|
||
- 未来:动态配置、A/B测试
|
||
- 触发条件:配置项>200个,需要动态更新
|
||
|
||
**估算时间:** 1-2年后(年收入>1000万,用户>10万)
|
||
|
||
---
|
||
|
||
#### 考虑购买ARMS的时机:
|
||
|
||
1. **流量规模变大**
|
||
- 当前:预估日活<1000,并发<100
|
||
- 未来:日活>10万,并发>1000
|
||
- 触发条件:性能瓶颈频繁出现
|
||
|
||
2. **故障定位困难**
|
||
- 当前:日志可追踪,调用链简单
|
||
- 未来:复杂调用链,难以定位问题
|
||
- 触发条件:故障排查耗时>1小时
|
||
|
||
3. **需要深度性能优化**
|
||
- 当前:基础监控够用
|
||
- 未来:需要细粒度性能分析
|
||
- 触发条件:用户反馈性能问题
|
||
|
||
**估算时间:** 6个月-1年后(流量快速增长期)
|
||
|
||
---
|
||
|
||
## 💡 决策建议(创业初期)
|
||
|
||
### ✅ 推荐方案:不购买MSE和ARMS
|
||
|
||
**理由(5条):**
|
||
|
||
#### 1. **架构不匹配**
|
||
```
|
||
MSE适用:微服务架构(多个独立服务)
|
||
我们架构:单体Serverless应用(一个Fastify应用)
|
||
结论:不需要MSE
|
||
```
|
||
|
||
#### 2. **我们的基础设施已足够**
|
||
```
|
||
✅ 配置管理:env.ts + SAE环境变量
|
||
✅ 任务调度:jobQueue(简单队列)
|
||
✅ 日志监控:Winston + 阿里云SLS(免费)
|
||
✅ 健康检查:/health 端点
|
||
✅ 性能监控:Metrics类
|
||
```
|
||
|
||
#### 3. **成本节省显著**
|
||
```
|
||
不购买:¥0-50/月(只用SLS免费额度)
|
||
购买: ¥800-1500/月
|
||
|
||
年节省:~¥10,000-18,000
|
||
```
|
||
|
||
#### 4. **流量规模小**
|
||
```
|
||
预估:
|
||
- 初期日活:<1000人
|
||
- 并发请求:<100
|
||
- 日志量:<100MB/天
|
||
|
||
免费额度足够:
|
||
- SLS:500MB/月免费
|
||
- SAE:自带基础监控
|
||
```
|
||
|
||
#### 5. **可后续升级**
|
||
```
|
||
现在:使用免费方案
|
||
6个月后:流量增长,评估是否需要
|
||
1年后:根据实际情况决定
|
||
```
|
||
|
||
---
|
||
|
||
## 🎯 当前推荐方案(零额外成本)
|
||
|
||
### 方案1:日志监控(已实现)✅
|
||
|
||
```typescript
|
||
// Winston结构化日志 → stdout → SAE采集 → 阿里云SLS
|
||
|
||
// 1. 配置Winston输出JSON(已实现)
|
||
logger.info('API called', {
|
||
path: '/api/v1/asl/screening',
|
||
method: 'POST',
|
||
latencyMs: 120,
|
||
statusCode: 200,
|
||
userId: 123,
|
||
projectId: 456
|
||
})
|
||
|
||
// 2. SAE自动采集stdout日志
|
||
|
||
// 3. 阿里云SLS查询日志(免费额度)
|
||
// 可以按userId、path、statusCode等字段查询
|
||
```
|
||
|
||
**成本:** ¥0(SLS免费额度内)
|
||
|
||
**能力:**
|
||
- ✅ 所有API调用记录
|
||
- ✅ 性能指标(响应时间)
|
||
- ✅ 错误追踪(error日志)
|
||
- ✅ 用户行为追踪
|
||
|
||
---
|
||
|
||
### 方案2:健康检查与监控(已实现)✅
|
||
|
||
```typescript
|
||
// 1. SAE健康检查端点(已实现)
|
||
GET /health/liveness - 存活检查(<10ms)
|
||
GET /health/readiness - 就绪检查(含DB/内存/缓存)
|
||
|
||
// 2. 关键指标监控(已实现)
|
||
Metrics.recordDBConnectionCount() // 数据库连接数
|
||
Metrics.recordMemoryUsage() // 内存使用
|
||
Metrics.recordApiLatency(...) // API延迟
|
||
|
||
// 3. SAE控制台查看
|
||
- CPU使用率
|
||
- 内存使用率
|
||
- 实例数量
|
||
- HTTP请求统计
|
||
```
|
||
|
||
**成本:** ¥0(SAE自带)
|
||
|
||
**能力:**
|
||
- ✅ 实时监控CPU/内存
|
||
- ✅ 实例健康状态
|
||
- ✅ HTTP请求统计
|
||
- ✅ 自动重启故障实例
|
||
|
||
---
|
||
|
||
### 方案3:任务调度(已实现,可升级)✅
|
||
|
||
**当前实现(Phase 1):**
|
||
```typescript
|
||
// MemoryQueue - 本地开发
|
||
QUEUE_TYPE=memory
|
||
|
||
// 功能:
|
||
- ✅ 创建任务
|
||
- ✅ 查询任务状态
|
||
- ✅ 进度跟踪
|
||
```
|
||
|
||
**后续升级(Phase 2):**
|
||
```typescript
|
||
// DatabaseQueue - 生产环境
|
||
QUEUE_TYPE=database
|
||
|
||
// 升级内容:
|
||
- ✅ 任务持久化(存储到PostgreSQL)
|
||
- ✅ 多实例共享(SAE多实例环境)
|
||
- ✅ 失败重试(3次重试机制)
|
||
- ✅ 定时任务(简单Cron支持)
|
||
```
|
||
|
||
**成本:** ¥0(使用现有PostgreSQL)
|
||
|
||
**什么时候需要MSE XXL-JOB:**
|
||
- 任务量 > 10,000/天
|
||
- 需要复杂的任务分片
|
||
- 需要可视化管理界面
|
||
- 需要跨服务任务编排
|
||
|
||
---
|
||
|
||
### 方案4:错误告警(补充实现,30分钟)
|
||
|
||
**简单告警方案(可选实现):**
|
||
|
||
```typescript
|
||
// common/monitoring/alerting.ts(新增)
|
||
|
||
import { logger } from '../logging/logger.js'
|
||
|
||
export class Alerting {
|
||
/**
|
||
* 发送钉钉告警(创业初期推荐)
|
||
*/
|
||
static async sendDingTalkAlert(message: string, level: 'info' | 'warn' | 'error') {
|
||
if (process.env.NODE_ENV !== 'production') return
|
||
|
||
const webhook = process.env.DINGTALK_WEBHOOK_URL
|
||
if (!webhook) return
|
||
|
||
// 发送到钉钉群
|
||
await fetch(webhook, {
|
||
method: 'POST',
|
||
headers: { 'Content-Type': 'application/json' },
|
||
body: JSON.stringify({
|
||
msgtype: 'text',
|
||
text: { content: `[${level.toUpperCase()}] ${message}` }
|
||
})
|
||
})
|
||
}
|
||
|
||
/**
|
||
* 数据库连接告警(80%阈值)
|
||
*/
|
||
static async checkAndAlertDBConnection() {
|
||
const current = await getDatabaseConnectionCount()
|
||
const max = config.dbMaxConnections
|
||
const usage = (current / max) * 100
|
||
|
||
if (usage > 80) {
|
||
await this.sendDingTalkAlert(
|
||
`⚠️ 数据库连接数告警:${current}/${max} (${usage.toFixed(1)}%)`,
|
||
'warn'
|
||
)
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
**成本:** ¥0(钉钉免费)
|
||
|
||
---
|
||
|
||
## 📋 创业初期推荐方案(总结)
|
||
|
||
### ✅ 使用(零成本)
|
||
|
||
| 服务 | 实现方式 | 成本 | 状态 |
|
||
|------|---------|------|------|
|
||
| **日志监控** | Winston + 阿里云SLS(免费额度) | ¥0 | ✅ 已实现 |
|
||
| **健康检查** | /health 端点 + SAE自带监控 | ¥0 | ✅ 已实现 |
|
||
| **任务队列** | MemoryQueue(本地)/DatabaseQueue(云端) | ¥0 | ✅ 已实现 |
|
||
| **配置管理** | env.ts + SAE环境变量 | ¥0 | ✅ 已实现 |
|
||
| **错误告警** | 钉钉Webhook(可选) | ¥0 | 📋 可选实现 |
|
||
|
||
**总成本:** ¥0-50/月
|
||
|
||
---
|
||
|
||
### ❌ 暂不购买
|
||
|
||
| 服务 | 原因 | 何时需要 |
|
||
|------|------|---------|
|
||
| **阿里云MSE** | 我们是单体应用,不是微服务 | 1-2年后(架构升级为微服务) |
|
||
| **阿里云ARMS** | 基础监控足够,流量小 | 6个月-1年后(流量>10万/天) |
|
||
|
||
---
|
||
|
||
## 🔄 升级路径规划
|
||
|
||
### Phase 1:当前阶段(0-6个月)⭐ 现在
|
||
|
||
**流量规模:** 日活<1000,并发<100
|
||
|
||
**推荐方案:**
|
||
```
|
||
✅ Winston日志 + 阿里云SLS(免费额度)
|
||
✅ /health健康检查
|
||
✅ MemoryQueue任务队列
|
||
✅ 简单的Metrics监控
|
||
✅ 钉钉告警(可选)
|
||
```
|
||
|
||
**成本:** ¥0-50/月
|
||
|
||
---
|
||
|
||
### Phase 2:快速增长期(6个月-1年)
|
||
|
||
**流量规模:** 日活1000-10000,并发100-500
|
||
|
||
**升级建议:**
|
||
```
|
||
✅ 升级到DatabaseQueue(任务持久化)
|
||
⚠️ 考虑ARMS基础版(按量付费)
|
||
⚠️ 增加Redis缓存(降低DB压力)
|
||
⚠️ 增加CDN(加速静态资源)
|
||
```
|
||
|
||
**成本:** ¥500-1000/月
|
||
|
||
---
|
||
|
||
### Phase 3:成熟期(1年+)
|
||
|
||
**流量规模:** 日活>10万,并发>1000
|
||
|
||
**升级建议:**
|
||
```
|
||
⚠️ 考虑MSE(如果拆分为微服务)
|
||
✅ 购买ARMS专业版(深度性能分析)
|
||
✅ 增加Redis集群(高可用)
|
||
✅ 增加RDS只读实例(读写分离)
|
||
```
|
||
|
||
**成本:** ¥2000-5000/月
|
||
|
||
---
|
||
|
||
## 🎯 最终建议
|
||
|
||
### ✅ 创业初期(现在)
|
||
|
||
**不需要购买MSE和ARMS,原因:**
|
||
|
||
1. **架构不匹配**
|
||
- MSE面向微服务,我们是单体应用
|
||
- ARMS面向大流量,我们流量小
|
||
|
||
2. **成本优先**
|
||
- 节省:¥800-1500/月
|
||
- 累计:¥10,000-18,000/年
|
||
|
||
3. **现有方案足够**
|
||
- 我们的8个基础设施模块
|
||
- Winston日志 + SLS
|
||
- 健康检查 + 简单监控
|
||
|
||
4. **可后续升级**
|
||
- 随着流量增长再评估
|
||
- 架构升级时再考虑
|
||
|
||
---
|
||
|
||
### 🔄 替代方案(推荐)
|
||
|
||
#### 立即使用(免费):
|
||
|
||
1. **阿里云SLS(日志服务)** - 免费额度内
|
||
- 收集Winston日志
|
||
- 日志查询和分析
|
||
- 简单的告警规则
|
||
|
||
2. **SAE自带监控** - 免费
|
||
- CPU/内存监控
|
||
- HTTP请求统计
|
||
- 实例健康状态
|
||
|
||
3. **钉钉告警(可选)** - 免费
|
||
- 关键错误通知
|
||
- 数据库连接告警
|
||
- 任务失败通知
|
||
|
||
#### 6个月后评估:
|
||
|
||
1. **如果流量>1万/天**
|
||
- 考虑ARMS基础版(按量付费)
|
||
|
||
2. **如果需要拆分微服务**
|
||
- 考虑MSE注册中心
|
||
|
||
---
|
||
|
||
## 📊 对比总结表
|
||
|
||
| 维度 | 我们的方案 | MSE + ARMS | 结论 |
|
||
|------|-----------|-----------|------|
|
||
| **架构匹配度** | ✅ 完美(单体应用) | ❌ 不匹配(微服务) | 我们胜出 |
|
||
| **功能完整性** | ✅ 基础完整 | ✅ 功能强大 | 基础够用 |
|
||
| **成本** | ✅ ¥0-50/月 | ❌ ¥800-1500/月 | 我们胜出 |
|
||
| **实施难度** | ✅ 简单 | ⚠️ 需要学习 | 我们胜出 |
|
||
| **可扩展性** | ✅ 可升级 | ✅ 强 | 平手 |
|
||
| **创业初期适用** | ✅ 完美 | ❌ 不适合 | **我们胜出** |
|
||
|
||
---
|
||
|
||
## 🎬 行动建议
|
||
|
||
### ✅ 立即执行(免费优化)
|
||
|
||
1. **配置阿里云SLS日志服务**(30分钟)
|
||
- SAE控制台开启日志采集
|
||
- 配置日志查询
|
||
- 设置简单告警(如错误数>10/分钟)
|
||
|
||
2. **添加钉钉告警(可选,30分钟)**
|
||
- 创建钉钉群机器人
|
||
- 添加 `common/monitoring/alerting.ts`
|
||
- 关键错误发送到钉钉
|
||
|
||
3. **优化监控指标(30分钟)**
|
||
- 完善 `Metrics.recordApiLatency()`
|
||
- 定期记录关键指标
|
||
- 日志输出便于SLS分析
|
||
|
||
### ❌ 暂不执行(节省成本)
|
||
|
||
1. ❌ 购买阿里云MSE(节省¥500/月)
|
||
2. ❌ 购买阿里云ARMS(节省¥300-1000/月)
|
||
|
||
### 📅 6个月后复评
|
||
|
||
- 评估流量增长情况
|
||
- 评估监控需求变化
|
||
- 决定是否购买ARMS
|
||
- 评估是否需要微服务架构(MSE)
|
||
|
||
---
|
||
|
||
## 💼 给决策者的一句话
|
||
|
||
**创业初期,不需要购买MSE和ARMS。**
|
||
|
||
**理由:**
|
||
1. 我们的基础设施已经覆盖了核心需求
|
||
2. 节省¥10,000-18,000/年的成本
|
||
3. 流量规模不需要企业级监控
|
||
4. 可以在成长后再升级
|
||
|
||
**风险:** 极低(我们有完整的监控和日志体系)
|
||
|
||
**建议:** 把节省的费用投入到LLM调用成本和市场推广
|
||
|
||
---
|
||
|
||
**文档路径:** `docs/08-项目管理/04-技术决策/2025-11-18-MSE与ARMS采购决策分析.md`
|
||
**决策结论:** 创业初期不购买MSE和ARMS,使用现有免费方案
|
||
**复评时间:** 6个月后(2025年5月)或流量突破1万/天时
|
||
**维护者:** 技术团队
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|