您的位置: 首页  >  文章  >  配置中心篇：微服务体系中为什么引入配置中心？集中式配置中心的作用和原理

配置中心篇：微服务体系中为什么引入配置中心？集中式配置中心的作用和原理

分类: 文章 • 2024-04-13 11:41:15

本文采取的配置中心为Apollo，携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境，不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。

微服务体系，采用的为SpringCloud

一、问题

1.微服务体系中为什么引入配置中心--apollo？

随着业务的发展、微服务架构的升级，服务的数量、程序的配置日益增多（各种微服务、各种服务器地址、各种参数），传统的配置文件方式和数据库的方式已无法满足开发人员对配置管理的要求：

  • 安全性：配置跟随源代码保存在代码库中，容易造成配置泄漏
  • 时效性：修改配置，需要重启服务才能生效
  • 局限性：无法支持动态调整：例如日志开关、功能开关

因此，我们需要配置中心来统一管理配置。

那选用什么样的配置中心？根据无数前人的坑和发明创造，总结

Apollo：
Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。

XDiamond：
全局配置中心，存储应用的配置项，解决配置混乱分散的问题。名字来源于淘宝的开源项目diamond，前面加上一个字母X以示区别。

Qconf：
QConf 是一个分布式配置管理工具。 用来替代传统的配置文件，使得配置信息和程序代码分离，同时配置变化能够实时同步到客户端，而且保证用户高效读取配置，这使的工程师从琐碎的配置修改、代码提交、配置上线流程中解放出来，极大地简化了配置管理工作。

Disconf：
专注于各种「分布式系统配置管理」的「通用组件」和「通用平台」, 提供统一的「配置管理服务」

SpringCloudConfig：
Spring Cloud Config为分布式系统中的外部配置提供服务器和客户端支持。

好吧，很多很多的开源框架，接下来我们一个一个的分析，并且基于我们的需求做一下对比

Apollo 支持回滚、支持灰度 支持跨集群不同环境的配置隔离 客户端轮询 支持｜
Disconf 不支持 支持不同环境配置隔离 基于ZK推送｜不支持｜
XDiamond 不支持 支持不同环境配置隔离 基于ZK推送 支持
Qconf 不支持 支持不同环境配置隔离 基于ZK推送 不支持
SpringCloudConfig 依赖于git仓库 不支持 基于spring-cloud-bus和webhook实现

2.apollo-集中式配置中心的作用和原理

作用：

正是基于配置的特殊性，所以Apollo从设计之初就立志于成为一个有治理能力的配置发布平台，目前提供了以下的特性：

  • 统一管理不同环境、不同集群的配置

    • Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。
    • 同一份代码部署在不同的集群，可以有不同的配置，比如zookeeper的地址等
    • 通过命名空间（namespace）可以很方便地支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖

  • 配置修改实时生效（热发布）

    • 用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序

  • 版本发布管理

    • 所有的配置发布都有版本概念，从而可以方便地支持配置的回滚

  • 灰度发布

    • 支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例

  • 权限管理、发布审核、操作审计

    • 应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。
    • 所有的操作都有审计日志，可以方便地追踪问题

  • 客户端配置信息监控

    • 可以在界面上方便地看到配置在被哪些实例使用

  • 提供Java和.Net原生客户端

    • 提供了Java和.Net的原生客户端，方便应用集成
    • 支持Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties，方便应用使用（需要Spring 3.1.1+）
    • 同时提供了Http接口，非Java和.Net应用也可以方便地使用

  • 提供开放平台API

    • Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。不过Apollo出于通用性考虑，不会对配置的修改做过多限制，只要符合基本的格式就能保存，不会针对不同的配置值进行针对性的校验，如数据库用户名、密码，Redis服务地址等
    • 对于这类应用配置，Apollo支持应用方通过开放平台API在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制

  • 部署简单

    • 配置中心作为基础服务，可用性要求非常高，这就要求Apollo对外部依赖尽可能地少
    • 目前唯一的外部依赖是MySQL，所以部署非常简单，只要安装好Java和MySQL就可以让Apollo跑起来
    • Apollo还提供了打包脚本，一键就可以生成所有需要的安装包，并且支持自定义运行时参数

2.apollo配置中心的原理

架构设计

配置中心篇：微服务体系中为什么引入配置中心？集中式配置中心的作用和原理

 

上图简要描述了Apollo的总体设计，我们可以从下往上看：

  • Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端
  • Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（管理界面）
  • Config Service和Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳
  • 在Eureka之上我们架了一层Meta Server用于封装Eureka的服务发现接口
  • Client通过域名访问Meta Server获取Config Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Client侧会做load balance、错误重试
  • Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Portal侧会做load balance、错误重试
  • 为了简化部署，我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中

工作原理：

配置中心篇：微服务体系中为什么引入配置中心？集中式配置中心的作用和原理

上图简要描述了Apollo客户端的实现原理：

  1. 客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。
  2. 客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。
    • 这是一个fallback机制，为了防止推送机制失效导致配置不更新
    • 客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified
    • 定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。
  3. 客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中
  4. 客户端会把从服务端获取到的配置在本地文件系统缓存一份
    • 在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置
  5. 应用程序从Apollo客户端获取最新的配置、订阅配置更新通知

 

 

参考资料：

 

apollo配置中心介绍：https://github.com/ctripcorp/apollo/wiki/Apollo%E9%85%8D%E7%BD%AE%E4%B8%AD%E5%BF%83%E4%BB%8B%E7%BB%8D

apollo分布式部署指南：https://github.com/ctripcorp/apollo/wiki/%E5%88%86%E5%B8%83%E5%BC%8F%E9%83%A8%E7%BD%B2%E6%8C%87%E5%8D%97

java客户端使用指南：

https://github.com/ctripcorp/apollo/wiki/Java%E5%AE%A2%E6%88%B7%E7%AB%AF%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%97

相关推荐