微服务配置中心，为什么要引入微服务的配置中心，它在微服务中起到一个什么作用，我们来想一想，如果我们在微服务中没有配置中心会是一个什么情况，其实很多公司在一开始都没有配置中心这个概念，开发人员把配置放在配置文件里面，没有一个固定的格式，还有一个如果这些格式在上线之后要去修改它，周期会比较的长，如果碰到一些故障响应很不灵活，涉及到要去改配置，重新发布，这个时间将会非常的长。另外，我们的服务如果没有一套配置系统，那么谁去修改了配置没有审计公司，到时候我们要去追溯系统的配置被何人何事调整过将会很困难。那么这就是集中式配置中心将要解决的问题。

有哪些东西可以作为配置？

比方说，数据库连接Url，缓存连接url字符串，数据库的用户名，密码都可以作为配置的字符串，除此之外，还有一些可以动态调整的参数，比方说，客户端的超时设置，限流的筏值，还有一个业务的开关，比方说某个功能只是针对某个地区用户，还有某个功能只在大促的时段开放，如果这种需要通过静态的方式去配置或者发布的方式去配置，那么响应速度是非常慢，可能对业务存在风险，如果有一套集中式的配置中心，只需要相关人员在配置中心动态去调整参数，就基本上可以实时或准实时去调整相关对应的业务。所以配置中心在微服务中算是一个举足轻重的组件。

配置中心可以简单的理解为一个服务模块，开发人员或运维人员可以通过界面对配种中心进行配置，下面相关的微服务连接到配置中心上面就可以实时连接获取到配置中心上面修改的参数。更新的方式一般有两种

• pull模式，服务定时去拉取配置中心的数据
• push模式，服务一直连接到配置中心上，一旦配置有变成，配种中心将把变更的参数推送到对应的微服务上

这两种做法其实各有利弊

• pull可以保证一定可以拉取得到数据，pull一般采用定时拉取的方式，即使某一次出现网络没有拉取得到数据，那在下一次定时器也将可以拉取得到数据，最终保证能更新得到配置。
• push也有好处，避免pull定时器获取存在时延，基本可以做到准实时的更新，但push也存在问题，如果有网络抖动，某一次push没有推送成功，将丢失这次配置的更新。

目前比较流行的配种中心开源组件有springcloud-Config，百度的disconf，阿里的diamond，还有携程的apollo，杨波老师之前是在携程工作过，所以主推的是apollo这套系统。

apollo配置中心

也是一个服务器，也带有对应的客户端，它的特色在于客户端，客户端有一个缓存机制，每次拉取成功后，会把数据保存在缓存机制中，甚至爬客户端的缓存丢失，客户端还可以将缓存sync在本地文件缓存，这样的设计非常的巧妙，就算apollo的配置中心挂掉了，或者客户端的服务重启了，但是因为本地缓存还存在，还可以使用本地缓存继续对外提供服务，从这点来看apollo的配置中心在高可用上考虑还是比较周到的。

另外一点，配置中心有两种获取配置数据的方式，一种pull，一种push，两者各有有点，apollo把两者的优点进行了结合，开发或运维人员在配置中心进行修改，配置中心服务将实时将修改推送push到apollo的客户端，但考虑到可能由于某些网络抖动没有推送成功，客户端还具备了定时向apollo服务端拉取pull数据的功能，就算推送没成功，但是只要一定时间周期，客户端还是会主动去拉取同步数据，保证能把最终配置同步到服务中。这个也是apollo在高可用方面上非常有特色的设计。