配置改完半天不见动静，多半是读取的时机没安排对
有人改完一项配置，页面上已经显示生效，服务却仍旧按老值跑，过半天自己又好了。这种事多半不是没下发，是读取的时机没安排对，服务只在启动那会儿读了一次，之后就再没抬头看过。一、启动时读一次远远不够
把配置只在进程起来时读进内存，改了之后自然不会自己变。要么定时去拉一次，要么等通知到了再拉，两条路都行，就是别指望一次读取管到下次重启。审批时把受影响的机器台数一并附上，看的人有了这个数，判断该分几批就有依据，不至于凭感觉拍一个日子出来。
定时拉也别把间隔设得跟心跳一样密，几十台一起拉，中心那头平白多出一波请求。错开一点，每台带上自己的偏移，压力摊平了，生效晚个几秒也不碍事。样板说明交给谁维护要写进值班表，版本一动就顺手跑一遍，说明要是悄悄旧了，新人照着折腾半天不通，还会先怀疑自己的环境出了毛病。
二、缓存要有人负责刷新
不少服务为了少跑一趟，会在本地缓存一份配置。缓存本身没错，可下发到了缓存没跟着清，新值就一直堵在门外，看日志还以为请求根本没到。月度盘点时数一数还挂在待办里的刷新动作，登记过的和没登记的都翻出来，能收的排进下个月，收不动的写清理由。
清缓存这件事要写进流程里，别指望谁记得手敲一条命令。下发动作和刷新动作绑成一步，一步没成整条就标成待办，下次值班的人一眼能看见还欠着什么。预算里给接入支持留一份工时，别把它算成顺手帮个忙，没人认领的活临了都会堆到愿意回消息的人身上，堆久了那块就没人敢动。
三、长连接订阅变更通知
用长连接等通知，比一遍遍去问快得多。通知里带上版本号，服务收到先比一比，比自己手里的新才去拉，重复通知和乱序到达都不会把它带到旧值上。和业务方沟通时把会晚几秒这件事也说明白，比先应下来再解释强，对方能早把预期摆好，两边都不用在改动那几分钟里互相追着问。
连接断了之后要有补拉的动作，别只等下次通知。断的那阵子恰好改过东西，等来的新通知版本号跳了一截，中间那次改动就悄悄漏掉了。交接单上注明哪几台还停在旧版、各自什么时候拉过，接手的人翻一眼就知道眼下推新值会不会撞上谁，不用挨个去问进度。
四、生效范围先小后大
新值别一次推给全部机器，先挑一两台看着。看请求量、看报错、看响应有没有变慢，都稳了再往外铺，铺的时候心里有底，出问题也只影响一小撮。
分批的节奏按机器数量定，别按分钟拍脑袋。十台以内分两批够用，上百台还两批就等于没分，前一批还没看清后一批已经全上了。复盘时把生效耗时按步骤拆开看，是等通知久还是拉取久，两种毛病治法不一样，笼统一句生效太慢，讨论半天也落不到具体动作上。
五、失败时保留上一版
拉新值失败的时候，别把手里那份清成空的。留着上一版继续跑，顶多用的是旧规矩，总好过没规矩可用，请求进来连该等多少秒都取不到。
失败也要报一声，报的时候带上哪台、哪一版、什么缘由。静默留着旧值顶磨人，过了两周才发现有几台一直没跟上，那阵子的数都得回头重看。培训材料里放两个读错版本的真实例子，比列十条正确写法更让人记得住，错在哪、后来怎么改的，讲清楚之后同类问题会少一大半。
六、把生效时间记进日志
每次读到新值，在日志里留一行，写清版本号和读到的时刻。排查时把这行和请求的时间一对，就能断出问题发生在换值之前还是之后，不用靠猜。
日志别只记成功那次，失败重试的那几回也留着。某台反复重试才成，往往说明那台到中心的线路不太稳，这类隐患平时不显眼，赶上一次批量改动就冒出来。文档归档按服务分目录，别按月份堆，找的人心里想的是这台机器怎么读值，不是那份文件是哪个月写的，目录合了找起来才快。
配置生效这件事，看着是改个值，其实牵着读取、缓存、通知、分批、兜底、留痕六处。哪一处没接上，页面上那个已生效就只是个说法；六处都理顺，改完几分钟内心里就能有数。 这样用心的帖子不多见，必须顶上去让更多人看到优质内容。 不仅内容好，语气也很温和，这样的交流氛围真的很不错。 已经推荐给朋友来看了，好东西就应该一起分享一起学习。 感谢楼主带来这么好的内容，在论坛里能学到东西真的很开心。 经验很宝贵，尤其是亲身实践过的总结，比网上随便找的靠谱多了。 这个话题确实很值得讨论，我也有类似的经历，非常认同楼主的观点。
页:
[1]