目前公司内部微服务架构基础设施建设中,技术选型以Spring Cloud技术为主,也被大家俗称作“全家桶”。
因其具备微服务架构体系中所需的各个服务组件,比如服务注册发现(如Spring Cloud Eureka、Zookeeper、Consul)、API网关路由服务(Spring Cloud Zuul),客户端负载均衡(Spring Cloud Ribbon,Zuul默认集成了Ribbon)、服务容错保护(Spring Cloud Hystrix),消息总线 (Spring Cloud Bus)、分布式配置中心(Spring Cloud Config)、消息驱动的微服务(Spring Cloud Stream)、分布式链路跟踪服务(Spring Cloud Sleuth)。
本篇主要围绕其中一个组件 分布式配置中心展开讨论。
Spring Cloud Config配置中心介绍&架构
在微服务架构体系中配置中心是比较重要的组件之一,Spring Cloud官方自身提供了Spring Cloud Config分布式配置中心,由它来提供集中化的外部配置支持,它分为客户端和服务端两个部分。其中服务端称作配置中心,是一个独立的微服务应用,用来连接仓库(如Git、Svn)并未客户端提供获取配置的接口;而客户端是各微服务应用,通过指定配置中心地址从远端获取配置内容,启动时加载配置信息到应用上下文中。因Spring Cloud Config实现的配置中心默认采用了Git来存储配置信息,所以版本控制管理也是基于Git仓库本身的特性来支持的 。对该组件调研后,主要采用基于消息总线的架构方式,架构图如下所示:
基于消息总线的配置中心架构中需要依赖外部的MQ组件,如Rabbit、Kafka 实现远程环境事件变更通知,客户端实时配置变更可以基于Git Hook功能实现。同时架构图中看到最右侧,有一个 Self scheduleing refresher 这个是我在实践中自己新增的一个扩展功能,目的是当依赖的消息组件出现问题时,此时如果Git仓库配置发生了变更,会导致部分或所有客户端可能无法获取到最新配置,这样就造成了客户端应用配置数据无法达到最终一致性,进而引起线上问题。
Self scheduleing refresher是一个定时任务,默认5分钟执行一次,执行时会判断本地的Git仓库版本与远程Git仓库版本如果不一致,则会从配置中