一个不断迭代的系统，最终都会变得越来越复杂，后来者不敢轻易大改，只能修修补补，直到这个系统服务的业务结束它的生命。
最近维护的一个系统，眼看着它从很简单明了的结构，演变到今天，变成一个超级庞大的系统，即使作为系统的始作俑者，也依然只敢不断添加辅助功能修复bug，而不敢大改。
这个系统最开始只是一个数据转发功能，将上游的 Kafka 转发到下游的 Kafka。
后面发现我们希望能沉淀上游 Kafka 数据到集群中，以便于数据分析，于是就根据上游 Kafka 的逻辑完成了一套实时数据转成离线文件的系统。
在完成上述系统后，我们发现上游 Kafka 经常会传一些历史数据过来，而不是单纯的最新消息，于是就需要改造逻辑，设定时间期限，将历史数据过滤掉。
改完后呢，我们又发现下游使用 Kafka 的人反馈说，会出现丢数据的情况，为了证明消息转发的可靠性，我们会将上游Kafka消息转发时沉淀一份数据到数据库里，并且每天定时拉取下游Kafka一定周期范围的记录去进行比对，如果出现遗漏会发到另一份的RocketMQ，弥补缺失数据，从而保证转发的可靠性。
下游 Kafka 为了业务上一些逻辑，会选择沉淀一段时间的数据到数据库里，去做临时的分析。
同时业务发现Kafka的传输可能出现重复，为了保证幂等，就需要将Kafka消息的唯一ID短暂的存储在Redis里，以确保临时数据库使用数据的唯一性。
过了一段时间，发现下游 Kafka 到临时数据库可能会出现数据缺失的情况，于是就要将离线文件沉淀到关系型数据库里，供业务辅助查询。
这里还不考虑业务的迭代，不同业务对Kafka消息的独特处理、对于业务日志的处理、每一步的数据校验。最后，这个业务系统演变了一个超级大的系统，每一个点都不能轻易动弹。
除非所有业务都消失了，否则这个系统估计只能不断修修补补。
