客戶端啟動，把配置文件，配置項存到倉庫，等到服務端啟動，從服務端拉取數據；服務端更新，則通過zk通知客戶端，客戶端知道更新後，會從服務端拉取最新的配置文件，如果更新的是redis配置，則需要寫回調函數重啟redis，不寫，則要重啟項目；更新其它的一些參數不需要重啟項目；另外zk最好配成集群模式，這樣可以做到高可用，一個主服務端掛了，會選舉另外一個從的作為主服務端。

2、部署

需要的軟件mysql(存放一些初始化數據)、tomcat(存放服務端的動態文件)、nginx(存放服務端的靜態文件)、zookeeper(存放客戶端的註冊信息)、redis(存放用戶的登錄、登出信息)

3、性能測試

壓測工具：Jmeter

disconf和spring cloud config server，經壓力測試，disconf的容錯性、並發更高，有管理界面， 配置略復雜；spring cloud config性能較低，需要很多優化，並且需要同時掌握spring cloud的各個組件，才能更好的優化。

4、局限性

1、修改mysql等服務器的配置，不能馬上生效，必須重新啟動項目，要生效的話，必須要寫回調函數，增加編程的復雜性。

• 2、配置文件類、配置項所在的類、回調函數類 都必須是JavaBean，並且它們的”scope” 都必須是singleton的。用戶標註配置時略有些不習慣。目前註解是放在get方法之上的，而不是放在域上。

• 3、註解放在get方法上，一般情況下是沒有問題的。但是對於”call self”的方法調用，AOP無法攔截得到，這樣就無法統一處理這些配置。一旦出現這種情況，“非一致性讀問題”就會產生。

disconf(二):服務端使用總結