最近需要对新对接的需求进行测试(别人已经写好了，我需要进行后续的功能测试)，但是让人恼火的是，由于从仓库克隆的本地项目的yml文件中没有应用相关的配置，比如服务名、端口等信息，且在Apollo没有相关的权限，所以还需要申请权限，走流程，才能找到对应的应用信息。
因为之前做的项目，应用的基本信息(应用名、端口等)都直接在配置在项目resources目录下的yml文件中，所以，能很快拼接处对应controller的url，由此想到，到底哪些信息是需要在Apollo配置，哪些配置在yml文件，哪些需要定义常量/枚举进行配置？
配置方式的区别
1、yml文件
具有层次分明、结构清晰的特点，特别适合配置这些需要组织和分类的信息
2、Apollo
通过将这些配置项集中管理，可以实现配置的动态更新，无需重启服务即可生效，极大地提升了系统的灵活性和可维护性
3、常量类/枚举类
配置信息集中管理，便于维护和修改，避免硬编码带来的问题。可以根据功能划分常量类，如缓存相关常量放在CacheConsts类下，系统配置相关常量放在ConfigConsts类下。
配置方式的范畴
1、yml文件
1.1.适合配置在yml文件中的信息
- 基础配置信息：服务器端口号、应用名称、日志级别
- 数据库连接配置：数据库URL、用户名密码、连接池配置
- 缓存配置：缓存启用状态、缓存过期时间
- 环境相关配置：多环境配置、开发环境配置
- 第三方服务配置：API密钥(如external.api.key: abc123)、服务地址(如external.service.url: https://api.example.com)
- 业务配置：功能开关(如feature.new-ui.enabled: true)、业务参数(如business.timeout: 5000)
2、Apollo
2.1.哪些配置项适合放在Apollo
- 环境相关：不同环境（如开发、测试、生产）下的数据库连接地址、端口、用户名、密码等
- 服务间通讯配置：微服务之间的调用地址、超时时间、重试次数等
- 第三方服务配置：如第三方API的访问地址、密钥、Token等
- 业务配置：业务开关、功能开关、活动配置等
- 缓存配置：Redis、Memcached等缓存服务的连接信息、缓存过期时间等
- 日志配置：日志级别、日志输出路径、日志格式等
- 安全相关配置：JWT密钥、OAuth2配置、权限控制配置等
- 定时任务配置：定时任务的执行时间、频率等
- 客户端配置：客户端需要动态获取的配置项，如接口地址、参数等
2.2.哪些配置项不适合放在Apollo
- 敏感信息
数据库密码、API密钥、OAuth Token等敏感配置信息应避免直接存储在配置中心，建议使用加密存储或通过安全的密钥管理服务进行管理。
- 与特定环境强绑定的配置
某些配置项可能与特定的硬件环境或操作系统相关，例如特定服务器的路径、端口等，这类配置更适合通过环境变量或本地配置文件来管理
- 频繁变更且无业务意义的配置
一些仅用于调试或临时测试的配置项，如日志级别、调试开关等，如果变更频率极高且对业务无直接影响，可以考虑不纳入配置中心。
- 与应用启动强相关的配置
如应用的启动参数、JVM参数等，这些通常在应用启动时就需要确定，不适合通过配置中心动态加载。
- 非动态配置项
一些在应用生命周期中不会发生变化的配置，如应用的版本号、应用名称等，这些配置更适合在构建时固化到应用中。
- 性能敏感的配置
对于需要极低延迟访问的配置项，如某些缓存策略、连接池大小等，如果配置中心的访问延迟影响性能，可能需要考虑本地缓存或直接硬编码。
3、常量类/枚举类
3.1 适合配置在常量中的信息
- 基础配置信息：文件路径和文件名配置、API接口地址和访问路径
- 业务逻辑常量：业务状态码和状态描述、业务开关标识、功能模块标识、业务规则相关的数值常量
- 系统配置参数：系统默认值(超时时间、重试次数)、缓存配置参数、线程池大小配置
- 枚举类型常量：适用于在固定范围内变化且带有延伸属性的值，如状态枚举、类型枚举等
- 复用性高的配置：
- 跨应用共享的常量，放置在二方库中
- 应用内共享常量，放置在一方库中
- 包内或类内共享的常量
PS：一方库、二方库、三方库区别如下表
| 库类型 | 来源 | 适用场景 | 使用方式 |
| 一方库 | 本项目内部 | 项目内模块复用 | 模块依赖 |
| 二方库 | 公司内部其他项目 | 公司内代码复用 | 配置pom文件 |
| 三方库 | 公司外部 | 使用成熟开源库 | 配置pom文件 |
总结
配置方式除了这里列的几种外，还有其他的(如properties、命令行等)，每种配置方式各有特点，可以根据具体的应用场景和需求选择合适的配置方式。
