Apollo 配置中心-规范 Beta

版本号	制定团队	更新日期	备注
0.0.1	软件开发组	2022-8-13	初版草拟

概述

为什么需要规范？

提高效能、降低出错风险、便于问题排查

目前的问题

命名没有明确的规律规范
配置分散在各个地方，想查看一个配置，不知道有没有配置，在哪个命名空间里面
没有统一分类，配置不方便复用
缺少使用指南

Apollo 核心概念介绍

配置：

配置是独立于程序的只读变量

配置首先是独立于程序的，同一份程序在不同的配置下会有不同的行为。
其次，配置对于程序是只读的，程序通过读取配置来改变自己的行为，但是程序不应该去改变配置。

环境 ENV 介绍：

DEV 开发环境
UAT User Acceptance Test environment 用户验收测试环境
FAT Feature Acceptance Test environment 功能验收测试环境/特性验收测试环境
PRO 生产环境

数据中心 IDC /机房/集群 cluster：

同一环境可以有多个集群，每个集群的配置是由差异的；比如，我们的生产环境有国内和海外两个数据中心，那么其中的数据库配置肯定是不一样的。

最重要的理解 Namespace 概念：

Namespace 是配置项的集合，类似于一个配置文件的概念。

Namespace 类型有三种：

私有类型
公共类型
关联类型（继承类型）

Namespace 分类梳理

application （私有配置，自定义配置）

调优参数 solar-tuning（优先级是否应该调高）

微服务

Nacos solar-nacos
...

基础功能配置（MVC配置、mybatis 配置之类）

solar-base

扩展功能配置

solareye-ext

权限认证

shiro

数据源（RDB mysql、tidb，ES ck ignite）

缓存 redis

中间件

rabbitmq - kafka
oss （对象存储）minio
分布式定时任务 xxl-job

监控

metrics

第三方 api 配置

规范

命名规范

项目名称

【建议】和 app_id 保持一致

app_id

【建议】iSolar 平台：solar-{APP_SHORT_NAME}

AppId是应用的唯一身份标识，Apollo客户端使用这个标识来获取应用自己的私有Namespace配置。

namespace 命名

【建议】以固定前缀加中间件全名命名，如 solareye-redis、solareye-tidb、solareye-clickhouse，solareye-elasticsearch 等

自定义配置项命名

【建议】solareye.business.key.* 如

配置规范

【建议】统一使用 properties 格式的配置文件

【建议】自定义公共类型的 Namespace，需要申请审核

【建议】及时清理不再需要的配置

【建议】自定义配置项增加详细的备注和说明（作用，影响）

使用规范

统一使用 spring-boot 集成的方式

<!--配置中心连接地址-->
<dependency>
  <groupId>com.ctrip.framework.apollo</groupId>
  <artifactId>apollo-client</artifactId>
  <version>${apollo-client.version}</version>
</dependency>

meta-server 配置

resources 目录 apollo-env.properties 配置文档，内容固定如下：

dev.meta=http://sv-apollo-config-dev.kube-public:8080
fat.meta=http://sv-apollo-config-fat.kube-public:8080
uat.meta=http://sv-apollo-config-uat.kube-public:8080
pro.meta=http://sv-apollo-config-pro.kube-public:8080

应用内 application.properties 配置，参考如下：

app.id=solareye-xxx
apollo.bootstrap.enabled=true
apollo.bootstrap.namespaces=application,solareye-tuning,solareye,solareye-dff,cloud-erp,metrics-erp,shiro
# 把日志相关的配置也放在Apollo管理
# put apollo initialization before logging system initialization
apollo.bootstrap.eagerLoad.enabled=true

Namespace 顺序，建议参照分类顺序，注意靠左优先级高。

运维管理规范

理论上每个人应该使用不同的账号，不同的权限，目前可能没有必要；

配置变更发布确认机制：

【强制】生产环境配置禁止同一个人修改并发布配置；

使用指南

对一个新项目而言，不需要太多的配置，只需要新建项目，配置 application name，app-id，关联需要的必要的 namespace 就可以运行。

本地开发配置

1. IDEA 配置 VM Option

-Dapollo.configService=http://host:port -Denv=DEV -Didc=default

2. 配置文件配置

C:\opt\settings\server.properties

env=DEV
apollo.configService=http://aopllo_ip:port
idc=default

如何新建&增加配置项？

申请创建公共 Namespace，并进行关联
关联公共 Namespace，覆盖其中需要修改的配置
在已有 Namespace 中添加，比如 application
创建私有 Namespace

参考官方文档：www.apolloconfig.com/#/zh/usage/…

DEV 环境的配置同步到其它环境？提供方法截图： // TODO

添加集群的方法 // TODO

常见问题 & 最佳实践

1. 本地多人调试的环境隔离问题：

场景示例：同项目多个开发人员需要使用不同的 MQ 配置

github.com/apolloconfi…

有一个办法可以实现你的目标：

在apollo创建一个公共namespace，比如local.properties，配置为空并发布
应用中引用该公共namespace并确保排序位于其它namespace之前，由于该namespace没有任何配置，所以对应用不会有任何影响
在代码中resources下放一个META-INF/config/local.properties文件，在里面写入要覆盖的配置即可
打包或提交代码时设置忽略该文件即可

该方式能工作的原因是在Apollo中有预埋逻辑，会去尝试读取该文件作为namespace配置的补充，详细可以参考DefaultConfig.java

本地开发模式（需要先缓存线上配置文件）

Apollo客户端还支持本地开发模式，这个主要用于当开发环境无法连接Apollo服务器的时候，比如在邮轮、飞机上做相关功能开发。

在本地开发模式下，Apollo只会从本地文件读取配置信息，不会从Apollo服务器读取配置。

官方文档说明

第三种方式，利用灰度功能，指定实例的方式。

第四种方式，新增单独的集群 cluster

Apollo 动态修改日志级别

参考案例：

github.com/apolloconfi…

一些问题

基础 core 包里面的一些非必要依赖可以改为非必填，增加默认值或条件注解，防止依赖报错

考虑增加一个公共 Feign 配置（使用 gateway 则可能不需要）配置各个服务不同环境的Feign调用地址，按照统一的格式配置，便于统一管理。

考虑是否需要实现 apollo-client-starter 统一版本，封装常用的功能，比如日志级别自动刷新；

重构开关统一配置，solareye.message.listQuery.refactor.enable=true 粗粒度，细粒度

配置项关联了公共 Namespace，在 default 集群覆盖了此配置，在 k8s 集群未覆盖配置，那么 k8s 集群上的节点会获取到哪个配置？

Namespace 关联了公共 Namespace，但是只有 default 集群关联了，k8s 集群没有关联，那么 k8s 集群上的节点会获取到什哪个配置？

如何在项目启动时打印所有的配置项（类似 nacos）? 不太安全，不建议