应有关部门要求，公司内部通知更改地址库的一些地址信息，对国家最新的一些地址更改做出相应正确的调整，如：上海更改为上海市，XXX县改为XXX区
按照正常逻辑来看，大家都会认为数据库改一下就好了。
真正实践的时候会发现并不是想象中那么简单。
不同的部门或者项目组可能维护着不同的地址数据库，为了解决这个问题，地址库查询服务被归拢为公共服务，提供接口对内外提供服务。
当执行sql更改地址成功上线后，问题就来了。
-
问题一： 某核心业务在调用接口查询地址的时候对地址进行了缓存，巧合的是因为历史原因这个缓存在redis里没有设置超时时间，这就使得存在缓存的数据是不会被更新到的，这数据就存在差异了。
-
问题二： 某后台管理系统里有读取省市区的配置信息进行不同区域的配置，并且配置结果存储在不同的配置表里，这里导致的问题就是，虽然地址库更改了，但是有原来的配置页面读取和写入的省市区数据还是以前的结果，这就导致了配置的突然失效。
涉及到更改这种基础数据的时候还是要仔细一点，另外一个很重要的就是测试没有完全覆盖到这种情况，不说完全覆盖，我们开发自己本身的单元测试用例都没有，没法对项目本身做简单的自测，业务过于广，接口太稀疏，没有收拢，零散分布在不同的地方甚至重复造轮子，测试人员本身也不知道该测哪些地方，有哪些地方涉及到了更改基础地址库会有影响。
我自己也思考了下，这类问题能改进的地方：
- 对接口进行收拢，不要重复的造轮子，不过这需要一个站在高处的人去做代码审查，甚至主导重构一些小模块，保证项目的精简
- 基础服务应该统一，不要分的太散，更不能允许每一个项目组都维护一个基础服务表。
- 不能因为要完成一件事情而去做，做完了就不管了，有时候问题并不会在刚改的时候就出现，是有潜伏期的。