微服务架构 | 2.1 使用 Spring Cloud Config 管理服务配置项

参考资料 ：

《Spring Microservices in Action》

《Spring Cloud Alibaba 微服务原理与实战》

《B站 尚硅谷 SpringCloud 框架开发教程 周阳》

SpringCloud Config 为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置；

特点 ：

@EnableConfigServer ：表明该服务是个 config 配置服务器；

@SpringBootApplication ：表明是一个 Spring Boot 应用；

本文从社区活跃度、产品特点、成功案例、产品缺点等维度，全方位对比Spring Cloud Config、Apollo、Nacos、Disconf、Spring Cloud Consul、Spring Cloud Zookeeper等几款Spring Cloud生态的配置服务器，帮助你选择合适的配置服务器。

一、Spring Cloud Config

GitHub地址

https://github.com/spring-cloud/spring-cloud-config ，Star数1178，官方组件，社区较活跃

开源厂商

Pivotal（Spring官方团队）

产品特点

演示环境

暂无

成功案例

N多，目前用Spring Cloud的大多团队都是用的Spring Cloud Config

缺点

二、Apollo

GitHub地址

https://github.com/ctripcorp/apollo ，Star数11169，社区很活跃

开源厂商

携程

产品特点

成功案例

携程、网易蜂巢、中国平安等，更多公司详见https://github.com/ctripcorp/apollo

演示环境

http://106.12.25.204:8070/

账号/密码：apollo/admin

缺点

暂未发现

三、Nacos

GitHub地址

https://github.com/alibaba/nacos ，Star数3820，社区非常活跃

开源厂商

阿里巴巴

产品特点

成功案例

阿里巴巴、虎牙直播、工商银行软件开发中心、爱奇艺等，更多公司详见https://github.com/alibaba/nacos/issues/273

演示环境

http://console.nacos.io/nacos/index.html

缺点

暂未发现明显缺点

四、Disconf

GitHub地址

https://github.com/knightliao/disconf ，Start数4505，社区活跃度一般

开源厂商

原百度员工，现在蚂蚁金服

产品特点

成功案例

百度、滴滴出行、顺丰、网易等，更多公司详见https://github.com/knightliao/disconf

缺点

最新的版本发布于两年前，有点久了。

五、Spring Cloud Consul

GitHub地址

https://github.com/spring-cloud/spring-cloud-consul ，Star数493，官方组件，社区较活跃

开源厂商

Pivotal（Spring官方团队）

产品特点

成功案例

暂未发现

演示环境

暂无

缺点

六、Spring Cloud Zookeeper

GitHub地址

https://github.com/spring-cloud/spring-cloud-zookeeper ，Star数330，官方组件，社区较活跃

开源厂商

Pivotal（Spring官方团队）

产品特点

演示环境

暂无

成功案例

暂未发现

缺点

其他

如果使用的是Spring Cloud Kubernetes，或者将Spring Cloud应用部署在Kubernetes环境中，还可以选择ConfigMap，这种方式就笔者了解，业界这么玩的还不多，暂时不分析了。已经将Spring Cloud Kubernetes列入博客19年更新名单中了，敬请期待。

结论

阅读《Spring微服务实战》笔记

项目地址： https://gitee.com/liaozb1996/spring-cloud-in-action

配置管理原则：

Spring Cloud Config 后端存储：文件系统、Git

标注引导类：

配置服务器配置：

创建配置文件：

访问配置：

客户端配置：

spring-cloud-config-client 依赖

boostrap.properties

刷新属性：

服务发现至关重要的原因：

传统服务位置解析（DNS+负载均衡器）的缺点：

服务发现实现组件：

构建 Eureka 服务：

标注引导类：

单机模式配置 ：

每次注册服务都需要等待30秒，因为 eureka 需要连续接收 3 个心跳包才能使用该服务。

缓存注册表后，客户端每隔30秒会重新到 eureka 刷新注册表。

服务注册：

解决多网卡问题：

通过API获取注册表信息：（设置请求头 Accept:application/json ）

http://localhost:8761/eureka/apps

http://localhost:8761/eureka/apps/organization

与 Ribbon 交互的客户端：

当使用二方包时需要在引导类添加 @EntityScan ：

配置 RestTemplate：

DiscoveryClient：

支持 Ribbon 的 RestTemplate：

Feign：

OpenFeign 依赖：

Feign 会在运行时动态生成代理对象：

远程调用包括对远程资源和远程服务的调用。

远程调用会遇到两个问题：

四种客户端弹性模式：

为什么客户端弹性模式很重要：

客户端弹性模式提供了三种构建能力：

在引导类启动断路器：

配置属性手册： https://github.com/Netflix/Hystrix/wiki/Configuration

使用 Hystrix 默认配置对远程调用进行管理：

超时配置： execution.isolation.thread.timeoutInMilliseconds

配置后备策略：后备方法必须在同一类中并且具有相同的方法签名

配置舱壁：

Hystrix 断路的策略：

Hystrix 有三个级别的配置：

类级别配置：

Hystrix 有两个隔离策略：

如果使用 TREAD 策略，并且要将父线程的上下文传递到子线程中，需要自定义 HystrixConcurrencyStrategy

Zuul 提供的功能：路由映射、构建过滤器

依赖：zuul、eureka-client

标注引导类：

zuul 配置：

​

Zuul路由映射机制：

查询路由： http://localhost:8080/actuator/routes

调用服务： http://localhost:8080/license/license/1 （第一个 license 是服务ID，/license/1 是请求路径）

使用服务发现手动映射路由：

添加前缀：

手动配置静态路由：前面都是基于 eureka 上的服务id进行路由映射的，而这里是直接配置URL

Git + http://localhost:8080/actuator/refresh （POST）

Zuul 使用 Hystrix 和 Ribbon

Zuul 支持三种过滤器类型：前置过滤器、后置过滤器、路由过滤器

前置过滤器：向通过网关的请求添加 tracking-id

这里使用了 Zuul 的 RequestContext：

Zuul 不允许直接修改请求头部，这里通过 addZuulRequestHeader 添加头部信息，在调用远程服务会自动合并

为了方便应用获取 tracking-id，这里使用 Filter 获取请求头信息并映射到 UserContext 中：

为了在服务间调用传播 tracking-id 这里需要定义一个 和 RestTemplate：

项目中 license 会远程调用 orgnization，这里需要在两个微服务配置 Filter

---