1、服務端原理
客戶端啓動，把配置文件，配置項存到倉庫，等到服務端啓動，從服務端拉取數據；服務端更新，則通過zk通知客戶端，客戶端知道更新後，會從服務端拉取最新的配置文件，如果更新的是redis配置，則需要寫回調函數重啓redis，不寫，則要重啓項目；更新其它的一些參數不需要重啓項目；另外zk最好配成集羣模式，這樣可以做到高可用，一個主服務端掛了，會選舉另外一個從的作爲主服務端。
2、部署
需要的軟件mysql(存放一些初始化數據)、tomcat(存放服務端的動態文件)、nginx(存放服務端的靜態文件)、zookeeper(存放客戶端的註冊信息)、redis(存放用戶的登錄、登出信息)
請參考：https://www.cnblogs.com/aslongas/p/6680546.html
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無法攔截得到，這樣就無法統一處理這些配置。一旦出現這種情況，“非一致性讀問題”就會產生。