一、创建App

1、设计要点

• App 在 Portal Service 中，表示需要管理的 App 。而在 Admin Service 和 Config Service 中，表示存在的 App 。
• 创建 App 的默认 Namespace (命名空间) “application” 。对于每个 App ，都会有一个默认 Namespace 。

2、问题

2.1、如何将下图关联起来

二、创建Namespace

1、设计要点

类似于 App 的创建，AppNamespace 也存在跨系统同步的一致性问题。但是，目前暂未提供补偿机制，如果 Portal 创建 AppNamespace 成功，而调用远程 Admin Service 失败，则会出现不一致的情况。

三、关联Namespace

1、设计要点

2、问题

2.1、关联Namespace与创建namespace的关联关系
2.2、private namespace、public namespace、关联namespace 的关系

公用类型和关联类型的判定，差异点仅仅是 Namespace 和 其对应的 AppNamespace 的 appId 是否一致。

• 若一致，就是公用类型。
• 若不同，就是关联类型。

四、配置拉取

1、设计要点

1、RemoteConfigRepository ，定时轮询Config Service 的配置读取/configs/{appId}/{clusterName}/{namespace:.+}接口。
2、RemoteConfigLongPollService ，长轮询Config Service 的配置变更通知/notifications/v2接口。

• 当有新的通知时，触发 RemoteConfigRepository ，立即轮询 Config Service 的配置读取 /configs/{appId}/{clusterName}/{namespace:.+} 接口。

3、一个 Namespace 对应一个 RemoteConfigRepository 。多个 RemoteConfigRepository ，注册到全局唯一的 RemoteConfigLongPollService 中。

五、配置编辑、发布

1、配置编辑

2、配置发布

设计要点

• 若之前有灰度发板记录，自动将主干合并到子 Namespace ，并进行一次子 Namespace 的发布。

六、灰度发布

1、创建灰度

设计要点

• 分支和灰度等价
• 子 Namespace 和 父 Namespace 无任何数据字段上的关联。

2、配置灰度规则

设计要点

对于一个子 Namespace 仅对应一条有效灰度规则 GrayReleaseRule 记录。每次变更灰度规则时，标记删除老的灰度规则，新增保存新的灰度规则。
变更灰度配置完成后，会发布一条 ReleaseMessage 消息，以通知配置变更

3、灰度（分支）发布

设计要点

• 灰度发布，对客户端是透明无感知的

七、Apollo 客户端启动都做了哪些事情？

Apollo配置中心-ConfigRepository初始化 - SequenceDiagram.org.pdf

八、

九、有意思的设计

1、限流设计

2、容灾设计

3、降级设计

4、故障避让算法

指数避让算法：ExponentialSchedulePolicy

5、changeLog（Commit）如何设计？