来源：
《微服务架构实战160讲》
Apollo配置中心
1 解决的问题
2 场景
如AB测试：测试新功能时，少量beta用户进行测试新功能，即走上面一条线的逻辑，如果反馈好，就将ab_test_flag设置为false，所有用户都可以在beta上进行，走新功能，即新功能正式启用
开关驱动开发：
如Git flow：使用开关驱动开发，在主干Trunk上提交代码而不是开分支，减少分支数从而减少冲突（TBD开发），修改代码则使用Branch by Abstraction：
3 核心概念
应用（application）：有唯一标识 appId
环境（environment）：配置对应的环境，如DEV,FAT,UAT,PRO
集群（cluster）：一个应用下不同实例的分组
名字空间（namespace）：一个应用下不同配置的分组；会有不同的类型，进行私有或公有化，还可以继承；
配置项（item）：表示可配置项，支持 properties/ json/xml格式，分为私有配置和公有配置；
权限：分为系统管理员、创建项目者、项目管理员、普通用户
4 服务端架构
-
整体架构
图中红框为基本架构（Portal+PortalDB+Client+ConfigService+AdminService+ConfigDB），引入Eureka解决服务发现的问题，MetaServer是对Eureka简单的封装，解决跨语言的问题（Portal和Client直接去Eureka查询的话，只能使用Java），NginxLB解决Client和Portal如何找到MetaServer的问题（MetaServer有多个，负载均衡），用户只跟Portal交互 -
领域模型：一个APP可以有多个Cluster，一个Cluster可以有多个Namespace
-
权限模型
-
实时推送设计
-
上图中的ReleaseMassage实现：数据库充当队列
5 客户端架构
推拉结合双保险（实时推送失效时还有定期拉配置作为保障） 、在内存又配置了一份缓存、应用程序获取配置、更新通知
6 高可用
从服务端架构图可以看出SLB是关键，且每个组件都有多个实例，而DB出问题的话，ConfigService、AdminService、Portal做了一份缓存，达到高可用，一致性就无法保障了
7 监控
内置支持CAT，需要扩展的话可以使用InfluxDB、Prometheus
- 关键指标
接入应用数量
配置项数量
变更和发布数量
推送拉取次数(success/failure)
ConfigConfig：接口性能、GC、CPU