实现流程

业务系统--->MQ(Kafka)--->第三方短信平台

现有架构

● 客户端,只有对接业务系统的 REST 接口,没有平台展示层,如运营管理、数据大屏等。
● 负载均衡层没有,客户端直接对接到服务层。
● 服务层,单点部署没有高可用,很容易出现单点故障。
● 短信异步推送,但是 “单消费者单线程” 造成处理效率极低;使用消息队列,但是没有进行消息一致性处理,可能造成消息丢失。
● 没有流量管控能力,不能按需控制流量。
● 基础设施,单点部署没有高可用,很容易出现单点故障;没有灾备,有风险。
● 缺少监控。

优化方案

● 短信处理效率:短信异步推送,但是 “单消费者单线程” 造成处理效率极低,需要改造为 “多消费者多线程” 处理模式,并发处理从而提高效率。
压测,使得平台并发量达到三方短信网关峰值。
● 消息一致性:使用消息队列异步推送短信,但是没有进行消息一致性处理,可能造成消息丢失。增加消息一致性处理,确保消息不丢失,保障可靠性。
● 流量管控:没有流量管控能力,不能按需控制流量。平台需要控制各应用的消息数量(包括总量和当前流量),需要对各应用进行管控。
● 展示层:客户端,只有对接业务系统的 REST 接口,没有平台展示层。增加平台展示层,如管理后台、运维后台、监控后台、数据大屏等。
● 负载均衡:没有负载均衡层,客户端直接对接到服务层。添加负载均衡层,负载均衡、反向代理,避免服务层直接对外暴露。
● 服务集群高可用:服务层,单点部署没有高可用,很容易出现单点故障。服务层部署改造为集群部署,包括 “集群部署方案” 和 “服务适配集群部署”。
●集群部署也是一种应用分片方案,避免高并发情况下单点压力过大。
● 基础设施,单点部署没有高可用,很容易出现单点故障。基础设施进行集群部署,高可用,避免单点故障。没有灾备,有风险。基础设施进行异地备份或异机备份,降低风险。
● 数据分片:数据分片非常好理解,把要处理的数据分成 N 份并行进行处理。将数据库分库分表,可以充分利用计算机的 CPU 或者内存等资源,不再把数据库压力集中在单个点上。
● 监控:缺少监控,不能及时发现故障。添加监控报警,对服务和基础设施都进行监控,及时发现及时处理。
● 三方供应商:对接多个三方短信供应商,监控第三方短信网关的健康状态,如果出现异常,要切换到备用短信网关。
● 信息安全:加强信息安全,防止短信滥用。

测试方案

模拟项目批量下发短信业务压力,查看批量发送短信条数是否与消费短信条数一致,统计短信全部消费时间,验证消费能力。
● 批量下发 1w 短信场景(单次 100 条)
● 批量下发 10w 短信场景(单次 200 条)

讨论

除此外还需要关注哪些测试点?如何保证测试场景覆盖度?


↙↙↙阅读原文可查看相关链接,并与作者交流