当前移动版架构

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

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

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

主要业务流程

用户登录流程

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

Fee 验证通过后,LB 返回一个相对空闲的 DS URL (实际就是 IPPORT 拼合)返回给客户端

所有 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 缓存做的不够好

- lostsummer


Comments

comments powered by Disqus