前言
在我们公司，配置中心采用的是携程开源的Apollo。由于我之前只接触过Nacos，因此决定记录下我的学习过程。
Apollo工作原理
模块介绍
以下是Apollo的架构概览，我们将从底层向上逐层解析：
- ConfigDB：负责存储配置数据。
- Config Service：提供配置读取和推送服务，服务于Apollo客户端，支持多实例，需要在Eureka中注册以保持服务心跳。
- Admin Service：提供配置修改和发布功能，服务于Apollo Portal（管理界面），同样支持多实例，并在Eureka中注册。
- Eureka：提供服务注册与发现功能，目前为了简化部署，Eureka与Config Service共存于同一JVM进程。
- Meta Server：封装Eureka的服务发现接口。
- Client：通过域名访问Meta Server获取Config Service服务列表（IP+Port），然后直接通过IP+Port访问服务，Client端实现负载均衡和错误重试。
- Portal：通过域名访问Meta Server获取Admin Service服务列表（IP+Port），直接通过IP+Port访问服务，Portal端同样实现负载均衡和错误重试。
执行流程
- Apollo启动时，Config/Admin Service会自动向Eureka服务注册中心注册，并定期发送心跳以保持连接。
- Apollo Client和Portal通过配置的Meta Server域名，通过软件负载均衡器分配到特定的Meta Server。
- Meta Server作为Eureka Client，从Eureka获取Config Service和Admin Service的服务信息。
- 若Meta Server获取Config Service和Admin Service（IP+Port）失败，将进行重试。
- 成功获取服务信息后，Apollo Client通过Config Service为应用提供配置获取和实时更新功能；Apollo Portal管理端通过Admin Service提供配置的新增、修改和发布功能。
基本概念
- application (应用)
实际使用配置的应用，Apollo客户端在运行时需要识别当前应用，以便获取相应的配置。关键标识：appId。 - environment (环境)
配置所对应的环境，Apollo客户端在运行时需要识别当前应用所处的环境，以获取正确的配置。关键标识：env。 - cluster (集群)
应用下不同实例的分组，例如，可以将上海机房的应用实例分为一个集群，北京机房的应用实例分为另一个集群。关键标识：cluster。 - namespace (命名空间)
应用下不同配置的分组，可以将namespace视作文件，不同类型的配置存放于不同的文件中，例如数据库配置文件、RPC配置文件、应用自身的配置文件等。关键标识：namespaces。 - 关系图如下：
项目管理
部门管理
Apollo默认有两个部门。若需添加新部门，可在系统参数中进行修改。进入系统参数页面，输入key查询现有的部门设置：organizations。
修改value值以添加新部门，例如添加一个微服务部门：
[{"orgId":"TEST1","orgName":"样例部门1"},{"orgId":"TEST2","orgName":"样例部门2"},{"orgId":"micro_service","orgName":"微服务部门"}]
创建项目
- 打开Apollo主页，点击“创建应用”：
- 输入相关信息，包括部门、应用AppId、应用名称和应用负责人：
- 授予用户管理服务权限，点击“授权”：
