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