交易系统架构图
交易系统架构
请求流程:
- 请求首先到SLB(阿里云)经过负载均衡后, 到Nginx
- Nginx做简单负载均衡后发给交易API系统, 4C8G * 5 ECS(阿里云)
- 交易会根据请求参数, 路由到各个子系统, 使用dubbo
- 子系统收到请求, 请求风控系统校验风控
- 请求应用中心获取应用参数 (appId, appKey等)
- 拼装报文,请求渠道系统
- 返回信息
日志报送流程
- 交易成功报送清结算, 报送数据中心
- filebeat拉取日志, 报送kafka, 因filebeat升级 同时存在5.x和6.x 需要加中间一层, 之前是直接报logstash
- logstash对数据进行过滤然后根据type 分别保送到 elasticsearch和redis
- 监控系统监控redis队列数据, 满足规则, 报警(发消息到通知系统)
- 监控系统对es数据进行过滤, 放到mysql, 用来展示商户, 渠道的交易变化等信息
- kibana(直接用的kibana)提供给技术支持查询日志. es数据会定期删除, 保留15-30天的数据, 仅仅技术支持用, 不需要效率很高, 所以机器配置相对较差.
扩容方案
公司体量较小, QPS高峰期也就500左右, TPS高峰期在100~200, 所以基本没有遇到问题.
之前有过一段时间公众号支付交易量较大, 主要做法是增加公众号机器, 同时增加API系统机器.
假如交易量提高, 一般应对就是增加机器, 和提高机器配置, 基本上都可以应对.
存在问题
定时系统是仅仅通过dubbo发送调用请求, 没有业务逻辑. 所以单体基本没有遇到挂掉. 也在考虑分布式定时任务.
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 程序员小航!
评论