架构怎么定的？一半需求推的，一半顺手的，还有一个是 AI 推荐的
yoker:
上期说，把 Excel 翻译成系统的第一步，是梳理指标这张网：两层指标，触发式重算。
今天聊第二步：这张网要跑起来，系统怎么搭。
动手前我先想清楚这系统到底要干啥——就三件事：
1. 数据要能自动进来（行情抓取）
2. 指标要能算、能改（计算引擎）
3. 结果要能看（图表看板）
后面所有技术选型，都是围着这三件事转的。
## 语言：Python
数据要自动进来、指标要算，这套系统本质是个数据处理系统——行情、指标、图表，全是数据在流动。Python 在数据处理这条路上的生态最全：抓数据、算指标、存库、出接口，一套工具链都是现成的。我当时又正好在做 AI 开发，手边全是 Python 的东西。语言这关没纠结。
## 后端框架：FastAPI
理由有两层。一层是顺手：当时公司项目正好在用，坑踩过、路径熟。另一层是它确实对路：系统里行情抓取是 IO 密集的，FastAPI 是异步的，async/await 写并发抓取很自然——一个循环里同时挂十几个抓取任务，谁先回来先处理谁。又是顺手、又是对路，没纠结。
## 前端：React + antd
原因有点私心：我一直想练手 React——写前端这么多年，Vue 用得滚瓜烂熟，React 一直没正经写过。这次正好有个真项目，AI 写代码又很能打，代码可以让 AI 写，我只负责看它对不对，学习成本被 AI 摊薄了。那就上 React 练练手。组件库呢？我了解的 React UI 框架不多，antd 名气最大、例子最多，遇到问题好搜。就它了。
## 数据库：PostgreSQL
两条需求逼的：第一，指标、行情是结构化数据，该用关系型存；第二，图表组合是 JSON 存的（今天想看 A ，明天想看 B ，组合存成 JSON ），PostgreSQL 原生支持 JSON 查询，前端要 "给我看这套组合"，数据库直接查 JSON 字段就行。关系型 + JSON 查询，一个库全干了。
还有个配套的：数据库结构会跟着指标走，得有个版本管理工具盯着。alembic ，数据库迁移工具——这个也是 Claude 推荐的。
## 定时任务：APScheduler
前期的需求就一个：定时把行情抓下来。APScheduler 够简单、够轻，没一上来就上重家伙。
## 计算队列：taskiq（这个得感谢 Claude）
指标是级联的，一个指标变了，下游一串要跟着重算。重算不能全堆在请求里干等，得有个异步任务队列。
我第一反应是 Celery——行业标准，名气最大。然后我干了件现在看起来有点 "偷懒" 的事：把需求丢给 Claude ，问它这个场景用什么合适。
Claude 没推荐 Celery ，推荐了个我没听过的：taskiq 。理由：轻量、异步、配置简单，这种量级的重算任务用 Celery 是杀鸡用牛刀。
我一看——有道理，那就它了。
这事搁两年前不会发生：技术选型要么自己拍脑袋，要么翻社区帖子比半天。现在直接问 AI ，它把方案、理由、备选一次给全，我只需要判断 "说得对不对"。说实话，taskiq 用下来确实没坑，轻量、够用，还挺顺手。
## 回头看
这套技术栈：Python + FastAPI + React/antd + PostgreSQL + APScheduler + taskiq 。单看任何一个都平平无奇，都是主流常见选项。但组合起来你会发现，每个选择都有它自己的来路：
- 数据处理系统 → Python ，生态最全
- IO 密集的行情抓取 → 顺手 + 对路的 FastAPI
- 想练手的前端 → React + antd （想试试 + AI 摊薄学习成本）
- 结构化指标 + JSON 图表 → PostgreSQL
- 定时抓取 → 轻量的 APScheduler
- 级联重算 → AI 推荐的 taskiq
- 数据库版本管理 → AI 推荐的 alembic
一半是需求推着走，一半是手边的顺手，还有几个是 AI 推荐的，外加一个 "想试试" 的。
我觉得这才是 AI 时代真实的选型方式：**需求想清楚，技术选型自己就浮出来了；拿不准的，问 AI ，它给方案，你判断。**
架构不是设计出来的，是一道道选择攒出来的。
不过技术选型只是第一步。真正让系统跑起来的，是后面那些 "没想到" 的坑。比如：行情数据来自各个市场，各市场有自己的交易时间——美股是美东时间，A 股是北京时间，还有期货夜盘、外汇 24 小时。可老伙计看盘是按北京时间的。
这个坑，下期讲行情抓取的时候细说。
下期聊：行情抓取实战——数据源那些坑，还有时间、时区、各市场交易时间怎么对齐。
---
原文链接：[点击查看](https://www.v2ex.com/t/1235724)
上期说，把 Excel 翻译成系统的第一步，是梳理指标这张网：两层指标，触发式重算。
今天聊第二步：这张网要跑起来，系统怎么搭。
动手前我先想清楚这系统到底要干啥——就三件事：
1. 数据要能自动进来（行情抓取）
2. 指标要能算、能改（计算引擎）
3. 结果要能看（图表看板）
后面所有技术选型，都是围着这三件事转的。
## 语言：Python
数据要自动进来、指标要算，这套系统本质是个数据处理系统——行情、指标、图表，全是数据在流动。Python 在数据处理这条路上的生态最全：抓数据、算指标、存库、出接口，一套工具链都是现成的。我当时又正好在做 AI 开发，手边全是 Python 的东西。语言这关没纠结。
## 后端框架：FastAPI
理由有两层。一层是顺手：当时公司项目正好在用，坑踩过、路径熟。另一层是它确实对路：系统里行情抓取是 IO 密集的，FastAPI 是异步的，async/await 写并发抓取很自然——一个循环里同时挂十几个抓取任务，谁先回来先处理谁。又是顺手、又是对路，没纠结。
## 前端：React + antd
原因有点私心：我一直想练手 React——写前端这么多年，Vue 用得滚瓜烂熟，React 一直没正经写过。这次正好有个真项目，AI 写代码又很能打，代码可以让 AI 写，我只负责看它对不对，学习成本被 AI 摊薄了。那就上 React 练练手。组件库呢？我了解的 React UI 框架不多，antd 名气最大、例子最多，遇到问题好搜。就它了。
## 数据库：PostgreSQL
两条需求逼的：第一，指标、行情是结构化数据，该用关系型存；第二，图表组合是 JSON 存的（今天想看 A ，明天想看 B ，组合存成 JSON ），PostgreSQL 原生支持 JSON 查询，前端要 "给我看这套组合"，数据库直接查 JSON 字段就行。关系型 + JSON 查询，一个库全干了。
还有个配套的：数据库结构会跟着指标走，得有个版本管理工具盯着。alembic ，数据库迁移工具——这个也是 Claude 推荐的。
## 定时任务：APScheduler
前期的需求就一个：定时把行情抓下来。APScheduler 够简单、够轻，没一上来就上重家伙。
## 计算队列：taskiq（这个得感谢 Claude）
指标是级联的，一个指标变了，下游一串要跟着重算。重算不能全堆在请求里干等，得有个异步任务队列。
我第一反应是 Celery——行业标准，名气最大。然后我干了件现在看起来有点 "偷懒" 的事：把需求丢给 Claude ，问它这个场景用什么合适。
Claude 没推荐 Celery ，推荐了个我没听过的：taskiq 。理由：轻量、异步、配置简单，这种量级的重算任务用 Celery 是杀鸡用牛刀。
我一看——有道理，那就它了。
这事搁两年前不会发生：技术选型要么自己拍脑袋，要么翻社区帖子比半天。现在直接问 AI ，它把方案、理由、备选一次给全，我只需要判断 "说得对不对"。说实话，taskiq 用下来确实没坑，轻量、够用，还挺顺手。
## 回头看
这套技术栈：Python + FastAPI + React/antd + PostgreSQL + APScheduler + taskiq 。单看任何一个都平平无奇，都是主流常见选项。但组合起来你会发现，每个选择都有它自己的来路：
- 数据处理系统 → Python ，生态最全
- IO 密集的行情抓取 → 顺手 + 对路的 FastAPI
- 想练手的前端 → React + antd （想试试 + AI 摊薄学习成本）
- 结构化指标 + JSON 图表 → PostgreSQL
- 定时抓取 → 轻量的 APScheduler
- 级联重算 → AI 推荐的 taskiq
- 数据库版本管理 → AI 推荐的 alembic
一半是需求推着走，一半是手边的顺手，还有几个是 AI 推荐的，外加一个 "想试试" 的。
我觉得这才是 AI 时代真实的选型方式：**需求想清楚，技术选型自己就浮出来了；拿不准的，问 AI ，它给方案，你判断。**
架构不是设计出来的，是一道道选择攒出来的。
不过技术选型只是第一步。真正让系统跑起来的，是后面那些 "没想到" 的坑。比如：行情数据来自各个市场，各市场有自己的交易时间——美股是美东时间，A 股是北京时间，还有期货夜盘、外汇 24 小时。可老伙计看盘是按北京时间的。
这个坑，下期讲行情抓取的时候细说。
下期聊：行情抓取实战——数据源那些坑，还有时间、时区、各市场交易时间怎么对齐。
---
原文链接：[点击查看](https://www.v2ex.com/t/1235724)
评论
暂无评论。