当前移动版架构

仅展示移动版行情功能涉及的上下游结构，不涉及交易模块

Front 上游是上证或券商提供的行情数据接口，部分外盘数据可能来自新浪公开的接口

FSServer 部署在公司，Memcache 由公司服务定时远程写入数据

主要业务流程

用户登录流程

用户登录区分匿名/实名，首次/非首次

Fee 验证通过后，LB 返回一个相对空闲的 DS URL （实际就是 IP：PORT 拼合）返回给客户端

所有 DS 的 服务端口要暴露在公网中

用户信息查询修改流程

DS 转发客户请求给 Fee

用户行情数据获取

缺陷分析

共同缺陷

• 功能定义混子不明确
• 稳定性差
• 接口复杂不明晰且文档缺位
• 缺少热备，自动恢复方案
• Debug困难

各部分缺陷

1. 数据上游 Front 没有好的高可用方案
2. DM DS 冗余
   • 重复的数据下发，驻存
3. DM DS 职责不明 (明确的设计是区分计算节点和分发节点)
   • 有些指标 DS 也承担计算任务
   • 操盘线 DS 引入 CalcCPX.o
4. LB DS 分工不明 （缺少 API 网关）
   • 用户登录由 LB 转发到 Fee
   • 用户改密等由 DS 转发到 Fee
5. DM DS 存储不健壮
   • 本地文件数据库
     • IO 其实更频繁，内存态占用也大
     • Debug 不容易
     • 存储结构更改麻烦
   • 内存落地文件
     • 定时任务强杀时容易损坏，出错时需手动删除重启
     • Debug 不容易
     • 存储结构更改麻烦
6. DM DS 数据存储布局不合理
   • 瀑布分流的结构，上游一个节点出错，下游10处需要手动修改
   • 应该有中心化，热备方案
7. DS 接口暴露公网
   • 伪负载均衡
   • 登录鉴权可以被绕过
8. Fee 承担业务多
   • 登录鉴权
   • 用户行为
   • 用户信息查询
   • 用户信息修改
   • 特殊活动
   • 交易信息
   • …
9. Fee 和 DB 的 Redis 缓存做的不够好