分布式配置中心spring cloud config（背景、原理、应用技巧）

一、背景

分布式与微服务的应用深入，配置项的繁琐引出分布式配置中心技术。首先回顾分布式与微服务的基本思路，用户量的增加引入了分布式技术，不断进行针对性扩容。

微服务是在简单分布式架构上的一个升级，每个微服务有自己的数据库，是插拔式灵活系统，同时可复用能力不断增加。微服务框架具备高可用（插拔式）、资源合理分配（分服务部署投入）、人尽其才（模块间低耦合接口封装多语言协作）、加快部署（docker）

简单讲述docker的基本原理

基于微服务的多级容灾思路：
互联网应用基本上分为用户应用端、业务接口端、数据端。应用灾难主要有如下几种情况：
1.app端无法链连接至业务接口端，所以需要在app本地做好缓存机制。
2.应用接口端无法连接至数据库集群，所以需要在业务接口端做好业务数据缓存。
3.数据库服务会出现崩溃的情况，所以需要做好主从复制与切换。

二、spring cloud config原理

从纸面上来说微服务开发主要分为dubbo系列与springcloud系列，前者更像是高级玩家，通过自己的双手去发掘高性能的产品，后者是一站式解决方案，更均衡。分布式配置的国内产品呈现百花齐放，如果你使用dubbo，下面几种分布式配置方案会是你的菜（diamond\disconf\apollo）。个人推荐apollo，详细对比如下图。

下面简单讲解一下springcloud的分布式配置，sc的分布式配置牛批在使用git/svn等现有*，拥有完善的版本管理与文件管理机制，多香啊！从应用中可以发现，自然是c/s架构的产品，服务端去管控公共配置文件与分类配置，客户端去获取想要的配置文件，而客户端自然就是咱们写的微服务模块了。

简单使用如下：

三、应用技巧

1.分布式配置中心集群思路（服务发现+负载均衡）

2.服务庞大的配置文件的分目录管理

3.用户登录权限（使用版本管理权限机制）

4.配置文件的加密传输

5.配置文件的动态刷新
动态刷新主要有客户端主动获取与服务端主动推两大类方式，客户端主动取主要使用@RefreshScope注解，然后访问客户端刷新接口即可；服务端主动推送分为手工推送与定时推送，手工推送访问服务端刷新接口即可，定时推送使用hook，原理与定时脚本无异。当然深究可以使用消息中间件，如果你的系统有必要的话。客户端主动取存在的意义在于测试分布式配置文件的正确型，服务端主动推，是推送至所有微服务，这点需要理解。