场景
日常业务中有些如状态、码表我们一般可以通过定义常量的方式来处理，如接口code状态码这些一般不会变动，且不受其他因素影响。但是有一些多变更的配置如邮件接收人、数据库配置等等，一些会跟随环境变化的，如线下、线上不同，tst、release不同，每个项目不同的配置，这些我们不能硬编码到常量中，通常是从配置文件中获取。如常用的.env、.property等等。
我们还可以将这些配置项存入到DB中或者其他KV存储中，也是可以区分环境的，现在出现配置中心了，这提供给我们另一种解决方案，Apollo分布式配置中心，凡是带上分布式之后就显得相当高大上了。
Apollo带来的优势
- 统一管理不同环境、不同集群的配置
- 版本发布管理
- 配置修改实时生效（热发布）
- 权限管理、发布审核、操作审计
Apollo架构
组成部分
ConfigService ：是提供client获取配置服务的
AdminService：是提供管理员更新、写入配置用的
Portal: 提供给client做负载均衡用的
中间部分是Apollo自身保证高可用的架构，包括Eureka注册中心、metaService代理服务
使用步骤
- 下载Apollo包
- 导入相关sql
- 修改demo.sh数据库配置
- 启动服务
访问8070查看Admin端
hyperf中使用Apollo
- 安装相关依赖 hyperf/config-apollo
- 修改相关配置，根据自己的apollo配置来获取
启动客户端，看到已经拉取了相关配置
我们在业务中直接获取就可以了
client的实现原理
启动client时会创建一个configFetch进程或者协程根据配置间隔去发送http请求apollo-server获取配置。
configFetcher进程
worker协程
如果发现配置有变更，则会更新到config
hyperf这里获取配置请求了configService 的 config/{appId}/{clusterName}/{namespace:.+}接口，而没有请求官网文档中指定的 /notifications/v2。这里需要注意这一点。
关于配置变更的原理
当管理员修改配置并发布后，AdminService会创建一条releaseMessage，ConfigService监控变更之后就会同步给client了。所以这里client调用server需要每次对比releaseKey的，如果key发生了变更说明配置变更了。
写在最后：
从开发使用者的角度看，Apollo提供的根据Environment、Cluster、Namespace 进行区分配置的功能是十分方便的，拥有web端的热发布功能也是相当实用。
他不管分布式还是啥，最终配置项还是存入了DB，这跟我们原始解决方案归宿一致
但是人家将这个组件做的相当完善、相当丰富这是我们所需要学习的，包括它的设计思想、架构方案等等。
相关文档：
Apollo架构介绍：https://mp.weixin.qq.com/s/-hUaQPzfsl9Lm3IqQW3VDQ
官网： https://github.com/ctripcorp/apollo/wiki/Apollo
相关代码：
https://github.com/nobody05/hyperf_study