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