配置中心-Apollo

2019/10/01 Chenxin

配置服务主要有携程Apollo、百度Disconf、阿里ACM,目前以Apollo用户量最大.适用场景,多用于微服务,与K8S结合好.

携程Apollo

https://github.com/ctripcorp/apollo

Apollo - A reliable configuration management system.

Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器。

Java客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot环境也有较好的支持。

.Net客户端不依赖任何框架，能够运行于所有.Net运行时环境。

百度Disconf

https://github.com/knightliao/disconf

Disconf - Distributed Configuration Management Platform(分布式配置管理平台).

百度disconf是一套完整的基于zookeeper的分布式配置统一解决方案。一个分布式环境中，同类型的服务往往会部署很多实例。这些实例使用了一些配置，为了更好地维护这些配置就产生了配置管理服务。通过这个服务可以轻松地管理成千上百个服务实例的配置问题。专注于各种「分布式系统配置管理」的「通用组件」和「通用平台」, 提供统一的「配置管理服务」.

主要目标

部署极其简单：同一个上线包，无须改动配置，即可在多个环境中(RD/QA/PRODUCTION) 上线.

部署动态化：更改配置，无需重新打包或重启，即可实时生效.

统一管理：提供web平台，统一管理多个环境(RD/QA/PRODUCTION)、多个产品的所有配置.

核心目标：一个jar包，到处运行.

阿里ACM

https://help.aliyun.com/product/59604.html?spm=a2c4g.11186623.6.540.29a137332X3Muy 阿里云文档(ACM文档)

应用配置管理 ACM 是一款在分布式架构环境中对应用配置进行集中管理和推送的产品。

利用 ACM，您可以在微服务、DevOps、大数据等场景下极大减轻配置管理的工作量，并增强配置管理的服务能力。

应用配置管理 ACM（Application Configuration Management）前身为淘宝内部配置中心 Diamond，现已作为 Nacos 的配置中心模块开源。

应用场景:在应用生命周期管理中，开发人员通常会将应用中需要变更的一些配置项或者元数据从代码中分离出来，放在单独的配置文件中管理，这些单独管理的内容就称为应用配置。这种分离应用配置的方法是管理应用变更的常见手段之一。发布应用后，运维人员或最终用户可以通过调整配置来适配环境，或调整应用程序的运行行为。

ACM 是面向分布式系统的配置中心。凭借配置变更、配置推送、历史版本管理、灰度发布、配置变更审计等配置管理工具，ACM 能帮助您集中管理所有应用环境中的配置，降低分布式系统中管理配置的成本，并降低因错误的配置变更带来可用性下降甚至发生故障的风险。

比较

目前大多认为 Apollo优于Disconf优于ACM.

Apollo

参考

https://github.com/ctripcorp/apollo

架构说明

参考: https://github.com/ctripcorp/apollo/wiki/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进程中

基本概念解析

参考:

https://github.com/ctripcorp/apollo/wiki/Apollo使用指南

 https://github.com/ctripcorp/apollo/wiki/Apollo核心概念之"namespace"

https://github.com/ctripcorp/apollo/wiki/Apollo配置中心介绍

application (应用)

这个很好理解，就是实际使用配置的应用，Apollo客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置

每个应用都需要有唯一的身份标识 -- appId，我们认为应用身份是跟着代码走的，所以需要在代码中配置，具体信息请参见Java客户端使用指南。

environment (环境)

配置对应的环境，Apollo客户端在运行时需要知道当前应用处于哪个环境，从而可以去获取应用的配置

我们认为环境和代码无关，同一份代码部署在不同的环境就应该能够获取到不同环境的配置

所以环境默认是通过读取机器上的配置（server.properties中的env属性）指定的，不过为了开发方便，我们也支持运行时通过System Property等指定，具体信息请参见Java客户端使用指南。

集群

通过添加集群，可以使同一份程序在不同的集群（如不同的数据中心）使用不同的配置

如果不同集群使用一样的配置，则没有必要创建集群

Apollo默认会读取机器上/opt/settings/server.properties文件中的idc属性作为集群名字，如SHAJQ（金桥数据中心）、SHAOY（欧阳数据中心)

在Portal的项目内,创建的集群名字需要和机器上server.properties中的idc属性一致.(这里指的应该是部署应用程序所在的机器吧?)

Namespace

一个应用下不同配置的分组，可以简单地把namespace类比为文件，不同类型的配置存放在不同的文件中，如数据库配置文件，RPC配置文件，应用自身的配置文件等

应用可以直接读取到公共组件的配置namespace，如DAL，RPC等

应用也可以通过继承公共组件的配置namespace来对公共组件的配置做调整，如DAL的初始数据库连接数

灰度

A,B,C客户端机器.

配置项 timeout=20.

灰度为A机器保持默认主版本参数timeout=20,B,C机器为timeout=30.

运行一段时间,观察效果,再逐步将所有机器发布30.

安装与部署

参考

https://github.com/ctripcorp/apollo/wiki/分布式部署指南分布式部署指南

机器配置说明(规划配置)

portal 192.168.143.130 portal+portalDB

dev 192.168.143.131 config+admin+configDB

pro 192.168.143.132 config+admin+configDB

JDK安装

cd /opt;

wget http://13.251.64.203:18081/jdk-8u181-linux-x64.tar.gz

tar xzvf jdk-8u181-linux-x64.tar.gz

mv /opt/jdk1.8.0_181 /usr/local/jvm

修改/etc/profile文件,添加:

cat >> /etc/profile << EOF

export JAVA_HOME=/usr/local/jvm

export JRE_HOME=${JAVA_HOME}/jre

export CLASSPATH=.