背景及系统简介：
Kafka是一种高吞吐量的分布式架构的发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。通常由于高吞吐量的要求而选择通过处理日志数据和日志聚合来解决。
本文涉及的分布式系统(简称C系统)已初具规模，而随着系统建设的建设推进和功能的逐步完善，外围系统对C系统的日志消费需求逐步增加。为了满足日志消费需求，决定在C系统的网关系统中增加日志发送功能实现对外消息的发送。
C系统的网关系统主要负责分布式系统的接入验证，对接受请求进行必要的合法性、安全性等内容的校验。将消息发送功能放到网关系统中主要有2方面考虑：
- 网关系统日志记录了上送请求的原始信息，能够完整描述交易请求发生的场景及请求内容;
- 便于制定统一的消息报文格式和规范，避免多系统发送消息时标准不一致，给后续的消息消费带来困难。
联机消息发送测试
网关系统设置了消息控制表，控制是否发送消息。同时可以根据需要从不同维度控制哪些消息需要发送,而不是所有日志数据全部发送，避免系统资源的浪费，提高消息的使用效率。
1. 正常交易消息发送
即发送服务的基本功能测试。当上送交易请求在后台执行成功后，触发网关系统消息发送功能，将该上送请求相关的日志信息封装消息发送出去。消息控制数据缓存在应用服务器，以提高读取速度，通过POSTMAN工具查询、验证。
消息发送无显性展示，因此测试对消息是否正常、发送规则是否符合消息控制表配置规则、发送内容的正确性和完整性、topic使用是否正确、总线系统是否正常、正确接收到消息等内容的验证，通过查询log的方式完成。
2. 查证交易消息发送
查证功能是网关系统提供的查证上送交易执行结果(成功/失败)的功能。由于网络等原因未收到被查交易返回结果时，如果该交易配置了消息发送功能，则在查证交易成功后将被查交易的原始交易信息封装消息并发送，保证该交易所有使用场景都能正确发送消息。
3. 异常消息处理
异常场景主要验证Kafka不能正常发送消息的情况，我们通过修改Kafka服务器IP地址方式和配置错误的topic等方式模拟Kafka消息发送失败的场景，进而验证网关系统是否能将消息正确、完整的记录到异常消息表中。
4. 熔断场景测试
熔断是指Kafka异常或消息服务压力过大，进而影响网关系统其他正常功能，需要临时关闭消息服务已保证网关系统本身对外服务正常。关闭消息服务是通过将要发送的消息记录到异常消息表中，后续通过批量补发方式补发消息。
批量消息处理测试
通过定时轮询的方式，对记录到异常消息表里的消息进行补发。同时设置消息熔断机制，当Kafka异常时，将消息发送完全切换到记录消息表，避免造成Kafka完全失效的同时也保证了本系统对外服务正常。
消息补发功能
当日消息补发定时轮询，每5分钟扫描一次异常消息表，对于未发送成功的消息重新补发，在发送三次失败后更新消息状态为“异常”。测试主要验证内容：
- 补发消息的筛选;
- 错误的消息(如空消息)等处理;
- 补发线程冲突处理机制，等
上日消息补发对上一日未发送的异常消息进行补发，与当日补发功能类似，但不是定时轮询。
异常消息导出
对于各种补发后仍失败的消息，为保证数据的完整性，提供导出功能做后续处理。
性能测试
由于投产后预期消息发送量很大，预估约1亿笔以上，所以对性能要求较高。
参考预估交易量，根据二八原则(80%的交易量发生在20%的时间内)，估算投产后系统的TPS约7000左右。参考该系统前次性能测试指标，我们将通过标准定位2000，测试、生产TPS比例1：3.5。而测试环境资源与生产资源比例约为1：16，远大于TPS的测试生产比例，因此我们认为达到该标准即可满足生产系统性能要求。
在进行了基准测试、负载测试及混合场景测试后，消息服务在测试环境TPS达到了2000以上，并且系统资源都在合理范围内。
总结
Kafka是比较成熟的消息系统，为网关系统的消息服务提供了基础，但Kafka偶尔会出现假死现象，导致消息阻塞。本次原本计划尝试模拟假死现象，但与项目开发人员以及Kafka支持人员讨论了解到，暂时无法模拟该场景，这也是本次留下的遗憾。
