配置中心：Apollo

来源：
《微服务架构实战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