企业官网建设流程全解析

最近需要对新对接的需求进行测试(别人已经写好了，我需要进行后续的功能测试)，但是让人恼火的是，由于从仓库克隆的本地项目的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：一方库、二方库、三方库区别如下表

总结

配置方式除了这里列的几种外，还有其他的(如properties、命令行等)，每种配置方式各有特点，可以根据具体的应用场景和需求选择合适的配置方式。