Spring Cloud Config 高可用:传统模式

最近在部署项目上测试环境的时候，由于数据库ip变更导致启动失败，所以进行项目改造，加入了Config配置中心。

临时抱佛脚的在《Spring Cloud 微服务实战》上面找到了快速入门，依葫芦画瓢的把项目改造好了。

当时Config Client配置中使用的是uri的形式直接指定：

spring:
  cloud:
    config:
      uri: http://config:14000/
      label: master

那如果Config配置中心要高可用，是不是用逗号分隔，继续往后面添加地址呢?

抱着问题继续往书的后面寻找答案，发现并不是。

书中提到Config配置中心高可用有俩种模式：

1. 服务模式

服务模式大家可能比较清楚，就是将Config配置中心也作为服务注册到eureka中，Config Client的配置改为：

spring:
  cloud:
    config:
      discovery:
        enabled: true
        service-id: config-server
      label: master
eureka:
  client:
    serviceUrl:
      defaultZone:http:eureka:2001/eureka

这种模式的好处很明显，service-id只是指定了Config配置中心的服务名称，启动多个服务就形成了集群，非常方便。

但是坏处在于需要加入eureka配置，eureka中心如果有变动，就需要重新打包，最好的情况也得重启才能更新。

2. 传统模式

最终我在项目中也是选择了传统模式，因为传统模式能够弥补服务模式中eureka动态更新的问题，而且由于初次改造是选择的uri的形式配置，使用传统模式则不需要对服务有任何的配置更改。

这是书上给的传统模式的结构图，无非就是在Config配置中心和各个服务的中间加了一个负载均衡器，以此实现Config配置中心的高可用。

那就很简单了，这里我用nginx来做软负载。

启动俩个配置中心，分别是11111端口和11112端口（由于没有注册到eureka，只能看启动日志了）：

再就是配置Nginx（这里只贴出了http模块的内容）：

http {
    include       mime.types;
	default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
	upstream config_server {
		server 192.168.1.157:11111;
		server 192.168.1.157:11112;
	}
	server {
        listen       8999;
        server_name  192.168.1.157;
		location / {
           proxy_pass http://config_server;
		   proxy_set_header Host $host;
        }	
    }
}

配置内容就不解释了，照这样设置好后，启动Nginx，多次访问http://192.168.1.157:8999/application-name/profile/lable

从俩个Config配置中心的控制台日志就能看出，使用了轮询机制依次访问。

PS：这里记录一个小坑，Nginx配置中如果不配置：

proxy_set_header Host $host;

就无法成功负载，原因还不清楚。