【配置中心】——配置中心选型

【配置中心】——配置中心选型

什么是配置中心

不使用配置中心

没有采用独立的配置中心,每次修改配置参数只能通过手动修改配置文件的方式,然后再重启重启重启,而且机器又是多台,这种方式无疑是非常低下的,而且极容易出错。

何为配置中心？

由IT基础框架推出的统一配置管理产品。基于该配置中心产品，您可以在DevOps、微服务等场景下极大地减轻配置管理的工作量，增强配置管理的服务能力。

功能

通过提供配置变更、配置推送、历史版本管理、灰度发布、配置变更审计等配置管理操作，配置中心帮助您集中管理所有生产环境中的配置，降低分布式系统中管理配置的成本，并降低因错误的配置变更带来可用性下降甚至发生故障的风险。

基本实现原理

1、主动拉取

当需要读取相关配置的时候客户端主动去服务端拉取，保存到缓存中，定时去服务端拉取，更新缓存中的数据

2、被动推送

利用消息的发布订阅，当服务端数据发生变化主动告知客户端，然后客户端主动更新缓存中的数据

怎么选配置中心

开源软件选取原则

1、聚焦能否满足业务（实用性）

2、聚焦是否已经经受市场考验（可靠度）

3、聚焦迭代进度、文档的完整性（使用性）

4、聚焦社区活跃性以及关注度（发展性）

5、聚焦运维成本（价格成本）

配置中心使用现状

之前使用配置中心Config-Toolkit能实现配置文件热部署的效果，但是存在如下问题

1、权限系统不够完善

2、没有数据人员变更记录

3、多环境数据维护困难

对新配置中心的选型要求

1、支持配置修改实时生效

2、统一管理多环境，便于多环境数据维护

3、完善的权限系统

4、数据变更完整记录，同时支持数据回滚

5、支持多语言种类java/php

6、支持自定义改造

开源配置中心介绍

1、Disconf

2014年7月百度开源，具备配置的管理能力，但是已经停止维护

2、Spring Cloud Config

Spring Cloud生态组件，与Spring Cloud体系无缝整合

3、Apollo

携程开源，具有规范的权限，流程治理等特性

4、Nacos

阿里巴巴开源，同样可以用于DNS和RPC的服务发现

功能概念对比

1、配置实时生效

当配置变更的时候，配置中心需要将配置实时推送到应用客户端

Apollo和Nacos配置推送基于HTTP长轮询，客户端和配置中心建立HTTP长联接，当配置变更的的时候，配置中心把配置推送到客户端。

Spring Cloud Config原生不支持配置的实时推送，需要依赖Git的WebHook、Spring Cloud Bus和客户端/bus/refresh端点:

•基于Git的WebHook，配置变更触发server端refresh

•Server端接收到请求并发送给Spring Cloud Bus

•Spring Cloud Bus接到消息并通知给客户端

•客户端接收到通知，请求Server端获取最新配置

整体比较下来，Nacos和Apollo在配置实时推送链路上是比较简单高效的，Spring Cloud Config的配置推送引入Spring Cloud Bus，链路较长，比较复杂。

2、权限管理

Spring Cloud Config依赖Git的权限管理能力，GitHub可以分为Write、Read、Admin，权限相对完整。

Apollo通过项目维度配置权限，一个项目的owner可以授权给其他用户修改和发布的权限，同时权限支持接入ldap认证

Nacos目前还不具备权限管理能力

3、灰度发布

配置的灰度发布是配置中心比较重要的功能，当配置的变更影响比较大的时候，需要先在部分应用实例中验证配置的变更是否符合预期，然后再推送到所有应用实例。

Spring Cloud Config支持通过/bus/refresh端点的destination参数来指定要更新配置的机器，不过整个流程不够自动化和体系化

Apollo可以直接在控制台上点灰度发布指定发布机器的IP，接着再全量发布，做得比较体系化。Nacos目前发布到0.9版本，还不支持灰度发布。

4、版本管理&回滚

当配置变更不符合预期的时候，需要根据配置的发布版本进行回滚。

Spring Cloud Config、Apollo和Nacos都具备配置的版本管理和回滚能力，可以在控制台上查看配置的变更情况或进行回滚操作。

Spring Cloud Config通过Git来做版本管理，更方便些。

5、多环境&多集群

配置中心常常需要涉及多环境或者多集群，将开发环境和生产环境分开，多集群保证稳定性——都支持

Spring Cloud Config支持Profile的方式隔离多个环境，通过在Git上配置多个Profile的配置文件，客户端启动时指定Profile就可以访问对应的配置文件。多集群可以通过搭建多套Config Server，Git使用同一个Git的多个仓库，来实现物理隔离。

Apollo也支持多环境，在控制台创建配置的时候就要指定配置所在的环境，客户端在启动的时候指定JVM参数ENV来访问对应环境的配置文件。搭建多套集群，Apollo的控制台和数据更新推送服务分开部署，控制台部署一套就可以管控多个集群

Nacos通过命名空间来支持多环境，每个命名空间的配置相互隔离，客户端指定想要访问的命名空间就可以达到逻辑隔离的作用。 Nacos控制台和后端配置服务是部署在一起的，可以通过不同的域名切换来支持多集群。

6、部署结构

Spring Cloud Config包含config-server、Git和Spring Cloud Bus三大组件。

config-server提供给客户端获取配置;

Git用于存储和修改配置;

Spring Cloud Bus通知客户端配置变更;

Apollo分为MySQL，Config Service，Admin Service，Portal四个模块：

MySQL存储Apollo元数据和用户配置数据;

Config Service提供配置的读取、推送等功能，客户端请求都是落到Config Service上;

Admin Service提供配置的修改、发布等功能，Portal操作的服务就是Admin Service;

Portal提供给用户配置管理界面;

Nacos部署需要Nacos Service和MySQL：

Nacos对外提供服务，支持配置管理和服务发现;

MySQL提供Nacos的数据持久化存储;

Nacos的部署结构比较简单，运维成本较低。Apollo部署组件较多，运维成本比Nacos高。Spring Cloud Config生产高可用的成本最高。

综上所述，考虑功能以及维护成本，以及目前使用数据量级，决定使用apollo作为新的配置中心。

Apollo客户端设计

1、通过客户端和服务端保持长连接，1s以内

2、客户端还会定时从Apollo配置中心服务端拉取应用的最新配置 默认频率是5分钟一次

3、客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中

4、客户端会把从服务端获取到的配置在本地文件系统缓存一份

5、应用程序可以从Apollo客户端获取最新的配置、订阅配置更新通知

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。