交易系统架构图

Java进阶训练营学习笔记
课程: Java进阶训练营
老师: 中华石杉
邀请码: 二维码

交易系统架构

交易系统架构

请求流程:

  1. 请求首先到SLB(阿里云)经过负载均衡后, 到Nginx
  2. Nginx做简单负载均衡后发给交易API系统, 4C8G * 5 ECS(阿里云)
  3. 交易会根据请求参数, 路由到各个子系统, 使用dubbo
  4. 子系统收到请求, 请求风控系统校验风控
  5. 请求应用中心获取应用参数 (appId, appKey等)
  6. 拼装报文,请求渠道系统
  7. 返回信息

日志报送流程

  1. 交易成功报送清结算, 报送数据中心
  2. filebeat拉取日志, 报送kafka, 因filebeat升级 同时存在5.x和6.x 需要加中间一层, 之前是直接报logstash
  3. logstash对数据进行过滤然后根据type 分别保送到 elasticsearch和redis
  4. 监控系统监控redis队列数据, 满足规则, 报警(发消息到通知系统)
  5. 监控系统对es数据进行过滤, 放到mysql, 用来展示商户, 渠道的交易变化等信息
  6. kibana(直接用的kibana)提供给技术支持查询日志. es数据会定期删除, 保留15-30天的数据, 仅仅技术支持用, 不需要效率很高, 所以机器配置相对较差.

扩容方案

公司体量较小, QPS高峰期也就500左右, TPS高峰期在100~200, 所以基本没有遇到问题.
之前有过一段时间公众号支付交易量较大, 主要做法是增加公众号机器, 同时增加API系统机器.
假如交易量提高, 一般应对就是增加机器, 和提高机器配置, 基本上都可以应对.

存在问题

定时系统是仅仅通过dubbo发送调用请求, 没有业务逻辑. 所以单体基本没有遇到挂掉. 也在考虑分布式定时任务.


   版权声明

文章作者: liuzhihang
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源!

评论
  目录