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.測試結果

從以上的測試結果來看，此次升級已完成，驗證通過。但這樣的方式需要整個研發組一起硬編碼，不易于維護，也增加了測試難度和未知風險。