Spring Cloud Config的那些臭毛病

使用Spring Cloud做微服务开发的小伙伴肯定对Spring Cloud Config不陌生，对于微服务开发到一定规模或者一些服务经常涉及到修改配置的情况，Spring Cloud也给我们提供了很好的配置外部化的工具Spring Cloud Config，也就是把所有服务的所需要的所有配置集合到一处并使用一个微服务来管理，来避免改配置而频繁上线。一切看起来都挺美好，但真正使用了Spring Cloud Config也遇到了一些莫名其妙的臭毛病，这里给大家罗列一些自己遇到的坑或者一些比较好的做法，希望大家能借鉴。

修改默认的配置缓存目录/temp

实践过Spring Cloud Config的小伙伴可能遇到和我一样的问题，使用了Spring Cloud Config的外部配置的微服务有时会拿不到配置导致启动异常，查看Spring Cloud Config的日志只是说“The local repository is dirty. Resetting it to origin/master.”，但是紧接着打印“Could not reset to remote for master (current ref=refs/remotes/origin/master), remote: https://github.com/haozi4go/cloud-config.git”,对于local repository is dirty是由于Spring Cloud Config将从git上拉取的配置缓存在了/temp目录下，但linux机器会不定时清理这个目录，最终导致各个微服务从配置微服务拿不到配置(如果配置微服务实例很多时，这种问题会很难排查)。对于这个问题可以修改basedir来避免这个问题，如下

spring:
  cloud:
    config:
      server:
        git:
          basedir: /opt/yourconfigrepo

设置强制从Git拉取配置

对于上各问题，虽然修改了配置的Git目录，但也同样不能避免其他情况会损坏Spring Cloud Config的本地Git仓库，为保险起见请设置以下配置

spring:
  cloud:
    config:
      server:
        git:
          force-pull: true

配置启动拉取Git配置

如果配置了错误个Git URl，配置微服务不会完整启动，从而使得其他业务微服务从配置微服务拉取配置失败。为了避免这种情况，建议配置clone-on-start为true，从而能及早地在配置微服务启动时就发现错误。

spring:
  cloud:
    config:
      server:
        git:
          clone-on-start: true

避免使用API密钥

使用默认的凭证链或IAM角色(实例配置文件凭证)

始终在多个配置微服务间进行负载均衡

配置对于各个微服务都是至关重要的，如果业务微服务无法获取配置，则服务将无法正常启动。

重写RetryOperationsInterceptor来控制配置客户端重试获取配置

由于配置客户端如果无法从配置微服务获得配置，则会挂起或关闭，可以考虑重写RetryOperationsInterceptor来控制配置客户端重试获取配置。