Apollo库表及逻辑结构

一、App、Cluster、Namespace、AppNamespace创建

1. 流程

通过portal进行操作，（controller->service->publishEvent->通过listener调用到AdminService）->映射到admin侧

 

在 Apollo 的架构中，一个环境( Env ) 对应一套 Admin Service 和 Config Service 。
而 Portal Service 会管理所有环境( Env ) 。因此，每次创建 App 后，需要进行同步。

或者说，App 在 Portal Service 中，表示需要管理的 App 。而在 Admin Service 和 Config Service 中，表示存在的 App 。

2. AppNamespace vs. Namespace

关系图如下：

数据流向如下：

1. 在 App 下创建 AppNamespace 后，自动给 App 下每个 Cluster 创建 Namespace 。
2. 在 App 下创建 Cluster 后，根据 App 下每个 AppNamespace 创建 Namespace 。
3. 可删除 Cluster 下的 Namespace 。

总结来说：

1. AppNamespace 是 App 下的每个 Cluster 默认创建的 Namespace 。
2. Namespace 是 每个 Cluster 实际拥有的 Namespace 。

二、Item、commit

Item ，配置项，是 Namespace 下最小颗粒度的单位。在 Namespace 分成五种类型：properties yml yaml json xml 。其中：

• properties ：每一行配置对应一条 Item 记录。
• 后四者：无法进行拆分，所以一个 Namespace 仅仅对应一条 Item 记录。

1. 流程

如上。

每一次item的创建对应一个commit的创建

三、namespaceLock

本文分享 Admin Service 锁定 Namespace 。可通过设置 ConfigDB 的 ServerConfi的 "namespace.lock.switch" 为 "true" 开启。效果如下：

• ???? 一次配置修改只能是一个人
• ???? 一次配置发布只能是另一个人

也就是说，开启后，一次配置修改并发布，需要两个人。

默认为 "false" ，即关闭。

在release的操作时用到

四、发布配置

通过portal进行操作，（controller->service->调用到AdminService）->映射到admin侧