实现流程

业务系统--->MQ（Kafka）--->第三方短信平台

现有架构

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

优化方案

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

测试方案

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

讨论

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