摘要：本文记录一个元器件供应链数字化平台Arieslink在架构设计与工程落地中的完整实践：双数据源隔离设计、基于 WebSocket 的实时行情推送、低代码框架与传统开发的分工边界，以及数据采集、安全体系、多语言等横切能力的实现思路。文章不涉及具体代码细节，重点分享每个技术决策背后的取舍，欢迎同行交流指正。
一、项目背景与技术挑战
项目要解决的是元器件流通环节的信息结构化问题：把分散的制造商、产品规格、替代关系、市场行情数据组织成可检索、可对比、可持续更新的数据资产。对技术团队来说，这个项目有几个典型挑战：
- 数据来源杂：行情数据（金属价格、汇率、航运指数、宏观指标等 9 大类）来自多个外部源，格式、单位、发布周期各异；
- 时效要求高：行情数据需要分钟级更新，且要与用户端的展示、订阅逻辑联动；
- 管理端与用户端诉求分裂：内部运营需要快速录入、维护海量产品数据；外部用户需要流畅的检索、详情、对比体验——两者对系统的要求完全不同；
- 安全与合规：涉及企业用户信息与交易数据，传输、接口、会话三个层面都要有防护。
这些挑战决定了技术选型不能"一套方案打天下"，而要在不同子系统采用不同的策略。
二、整体架构：分层的模块化设计
系统采用前后端分离架构，整体分为四层：
| 层次 | 选型 | 职责 |
|---|---|---|
| 前端 | Vue 3 + Vite + Element Plus | 用户端页面、移动端适配、状态管理 |
| 后端 | Java + Spring Boot 3 | 业务 API、认证授权、数据服务 |
| 数据层 | PostgreSQL（主业务）+ MySQL（数据采集）+ Redis（会话缓存） | 业务数据、采集数据、分布式会话 |
| 存储与中间件 | 对象存储 + WebSocket | 文档/图片存储、实时推送 |
前端基于组合式 API 组织业务逻辑，按业务模块拆分页面组件；响应式采用移动优先策略，以 768px、480px 为断点，Flexbox + Grid 自适应布局，配合图片懒加载——移动端访问是高频场景，移动体验被放在第一优先级。
三、关键技术实践
1. 双数据源：业务数据与采集数据物理隔离
系统承载两类性质完全不同的数据：一类是用户、产品、订单等核心业务数据，对一致性、事务性要求高；另一类是外部采集的市场行情数据，特点是量大、时效强、来源杂乱、与业务无强事务关联。
我们的方案是双数据源物理隔离：主业务库承载核心业务，采集库独立承载行情数据。收益有三点：
- 采集任务的批量写入压力不会影响主业务库的查询性能；
- 采集数据出问题时可以独立清洗、重建，不影响业务连续性；
- 两个库的备份、扩容、生命周期管理互不干扰。
实践中的额外收获：数据源隔离后，采集模块可以独立演进——比如更换数据源、调整采集频率，都不需要动业务代码。
2. 实时行情推送：WebSocket 与"推送面"控制
行情展示模块要求用户无需刷新即可看到最新价格。我们采用 WebSocket 长连接方案，行情数据按固定周期（约 30 秒）批量推送，同时承载站内消息、订单状态通知等场景。
这里最值得分享的取舍是推送面控制：早期设计是连接建立后全量广播行情，简单直接，但用户量和订阅频道增长后，带宽和客户端解析压力都会线性上涨。最终改为按订阅维度推送——用户关注什么才推什么，配合连接级别的频道管理，把无效流量降到最低。对实时系统，推送的"面"和推送的"频率"同样需要设计，只调频率不控面，迟早会出问题。
3. 低代码与原生开发的边界：注解生成管理端，手写实现用户端
管理后台（产品录入、分类维护、数据管理）使用低代码框架，通过注解即可生成完整的 CRUD 管理界面，后台开发效率提升非常显著。但用户端（检索、详情、行情展示）全部采用原生开发。
为什么这样分工？我们的判断是：低代码框架解决"标准管理需求"非常高效，但一旦涉及复杂交互、多表联动、定制校验，在框架内硬实现反而比原生开发更慢、更难维护。低代码管后台、原生管前台的分工，让两类工作都在各自的舒适区，这是本项目性价比最高的一个决策。
4. 数据采集与清洗：采集是开始，清洗才是工作量的主体
9 大类外部数据源的采集链路，踩过最深的坑是：数据的"脏"是常态。同一指标在不同源的单位、口径、发布时间都不一样，定时抓取只是第一步，归一化清洗、异常值识别、时区对齐才占工作量的主体。
最终沉淀的实践：把"采集"和"清洗入库"拆成独立作业，互不阻塞；清洗规则集中管理，每个数据源一套适配器；对异常值做标记而不是直接丢弃，便于回溯。数据质量是行情类产品的生命线，这块投入不能省。
5. 安全体系：传输、接口、会话三层防护
- 传输层：敏感字段（如密码）前端加密后再传输，避免明文暴露；
- 接口层：所有 API 请求带签名校验，防止请求被篡改与重放；
- 会话层：JWT + 分布式会话（Redis 存储），支持多实例部署与集中式会话管理；登录侧配置图形验证码与防刷机制，短信验证码对接云短信服务。
安全设计的原则是"纵深防御"：任何单层被突破，其他层仍然有效。
6. 多语言与搜索可见性：容易被低估的两个横切能力
多语言：平台面向全球供应链，从第一天就做了中英繁三语。经验是：多语言不是"翻译几个按钮"，产品规格参数、分类名称、富文本内容都要有对应方案，语言标识前后端统一、请求层自动注入——架构要提前设计，后期补的成本极高。
搜索可见性：面向公网的产品，"被找到"是增长前提。做了两层优化：传统 SEO（静态 Meta、动态页面级配置、站点地图自动生成、预渲染）和面向 AI 搜索引擎的适配（结构化数据、站点说明文件、爬虫白名单等）。后者是我们认为值得所有公网产品关注的新方向——未来用户的第一入口可能不是搜索结果页，而是 AI 的答案，提前让 AI"读懂"你的站点，会形成先发优势。
四、经验与反思
外部数据源的稳定性不可控，采集链路要设计"降级"路径：某个数据源临时不可用是常态，要有重试、降级、告警机制，不能让采集失败影响主流程。
低代码框架的边界要在项目初期划定：哪些模块用低代码、哪些原生实现，最好在架构评审时定下来。运行期反复"从框架里搬出来重写"的成本，远高于一开始的谨慎评估。
实时推送的收益要量化：推送频率不是越快越好，要结合业务场景评估——行情类 30 秒级别足够，过度追求"实时"只会放大服务器与流量成本。
文档与资料分发是 B 端平台的高频痛点：产品文档在线预览（支持常见办公文档格式）、文件对象存储与权限控制，看似是"小功能"，实际是用户粘性的重要来源。
五、结语
这个项目的核心体会是：供应链数字化的难点不在技术本身，而在"数据治理"与"架构取舍"——数据要持续清洗、架构要为两类完全不同的数据流分别设计、工具选型要敢于划边界。希望以上的实践与踩坑记录对正在做同类平台的团队有帮助，也欢迎在评论区交流不同方案。
（本文为项目技术复盘，仅代表个人实践观点。）
