目录

一、问题背景

二、问题分析

        1、配置文件空档期的问题

一、问题背景

JAVA的Properties工具有两种写配置文件的方式，一种是覆盖，一种是追加。

但是动态配置文件一般需要进行创建或更新，不会选择追加内容，所以只能选择进行配置文件的load+store，来进行配置文件的覆盖操作，以保证配置文件的正确性。

而Properties在进行覆盖操作时，配置文件会存在空档期，因为在配置文件的store之前，需要将配置文件进行清空，再将新的配置写入配置文件，这是它的实现方式。

如果配置的内容比较少，那么这个操作会比较快，程序很难命中空档期。但是像某些大的应用，配置文件会比较大，如果配置的更新比较频繁，则会有一定概率命中空档期，读取到的配置文件内容为空。

二、问题分析

1、配置文件空档期的问题

首先这个避免不了，这个是properties的原生逻辑，但是这个正常使用不会发生问题，几百K甚至几M的配置文件，也能在多少毫秒内更新完成。此外，正常情况下使用方也会有躺平操作，如果获取不到配置文件的内容，都会选择保持原有的配置内容，就不会出现问题。

我为了保证配置文件的写入顺序，对配置文件的key进行了排序操作(properties里面是个hashTable，数据是无序的)，排序之后会影响写入性能，文件的空档期就会放大。

其他组件碰上了，就可能引起问题。

在zuul2里面，与后端进行通信的组件是netflix开源的ribbon。

这个组件名气还是比较大的，曾集成进入springcloud体系被众多程序员熟悉，它的能力这里不再赘述。

在它的loadbanace源码包中，会对配置文件进行热加载，但是它针对后端服务器列表(client.ribbon.listOfServers)提供的默认加载逻辑并不是躺平操作，也就是说，如果它加载到空档期了，那么它拿到的值就是个空，并且，会把自己的后端服务器列表配置置为空。(这个可能是基于ribbon对于性能的考虑做的实现)

两者一碰撞，就会导致zuul出现 502(Bad Gateway)。

ribbon热加载serverless源码：

zuul2集成ribbon选择server，服务器列表为空，则抛出502：

最后的优化方法还是选择不做排序，尽量以最快的方式写入配置，同时在其他位置进行补偿，尽量避免由于配置更新问题出现502。