5.4 违背设计模式实现

如果不从全局的升级改造考虑，仅仅是升级自己的系统，那么最快的方式是添加if…else，把Redis集群的使用添加进去。再通过在接口中添加一个使用的Redis集群类型，判断当下调用Redis时应该使用哪个集群。

可以说这样的改造非常不好，因为这样会需要所有的研发人员改动代码升级。不仅工作量非常大，而且可能存在非常高的风险。这里为了对比代码结构，会先用这种方式升级Redis集群服务。

5.4.1 工程结构

在这个工程结构中只有两个类，一个是定义缓存使用的接口CacheService，另一个是它的实现类CacheServiceImpl。因为这里选择的是在接口中添加集群类型，判断使用哪个集群，所以需要重新定义接口，并实现新的集群服务类。

5.4.2 if…else实现需求

这种方式的代码升级并不复杂，看上去也比较简单。主要包括如下内容：

·给接口添加Redis集群使用类型，以控制使用哪套集群服务。

·如果类型是1，则使用EGM集群；如果类型是2，则使用IIR集群。这在各方法中都有所体现。

·因为要体现出Redis集群升级的过程，所以这里保留了单体Redis的使用方式。如果用户传递的redisType是不存在的，则会使用RedisUtils的方式调用Redis服务。这也是一种兼容逻辑，兼容升级过程。

5.4.3 测试验证

接下来通过JUnit单元测试的方式验证升级集群后的接口服务。

1.单元测试

2.测试结果

从以上的测试结果来看，此次升级已完成，验证通过。但这样的方式需要整个研发组一起硬编码，不易于维护，也增加了测试难度和未知风险。