Apollo基本概念
Apollo是一款可靠的分布式配置管理中心，能够集中化管理应用不同环境，不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限，流程治理等特性，适用于微服务配置管理场景。
服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器。
Apollo支持4个维度管理Key-Value格式的配置：
1. Application (应用)
2. Environment (环境)
3. Cluster (集群)
4. Namespace (命名空间)
配置基本概念
配置有以下几个属性：
1. 配置是独立于程序的只读变量
配置首先是独立于程序的，同一份程序在不同的配置下会有不同的行为。
其次，配置对于程序是只读的，程序通过读取配置来改变自己的行为，但是程序不应该去改变配置。
常见的配置有：Thread Pool Size、Buffer Size、Request Timeout等。
2. 配置伴随应用的整个生命周期
配置贯穿于应用的整个生命周期，应用在启动时通过读取配置来初始化，在运行时根据配置调整行为。
3. 配置有多种加载方式
配置也有多种加载方式，常见的有程序内部hard code, 配置文件，环境变量，启动参数，基于数据库等等。
4. 配置需要治理
权限控制
由于配置能改变程序的行为，不正确的配置甚至能引起灾难，所以对配置的修改必须有比较完善的权限配置。
不同环境、集群配置管理
同一份程序在不同的环境（开发，测试，生产）、不同的集群（如不同的数据中心）经常需要有不同的配置，所以需要有完善的环境、集群配置管理。
框架类组件配置管理
还有一类比较特殊的配置 - 框架类组件配置，比如CAT客户端的配置。
虽然这类框架类组件是由其他团队开发、维护，但是运行时是在业务实际应用内的，所以本质上可以认为框架类组件也是应用的一部分。
这类组件对应的配置也需要有比较完善的管理方式。
Apollo的优点
1. 统一管理不同环境、不同集群的配置
Apollo提供了一个统一界面集中式管理不同环境、不同集群、不同命名空间的配置。
同一份代码部署在不同的集群，可以有不同的配置，比如zookeeper的地址等。
通过命名空间可以很方便地支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖。
2. 配置修改实时生效（热发布）
用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序。
3. 版本发布管理
所有的配置发布都有版本配置，从而更方便地支持配置的回滚。
4. 灰度发布
又称金丝雀发布。指在黑与白之间可以平滑过度的一种发布方式。在其上进行A/B testing. 一部分用户继续使用产品特性A，一部分用户使用产品特性B，如果用户对B没有反对意见，那么逐步扩大范围，将用户切到B上来。
支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例。
5. 权限管理、分布审核、操作审计
应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。
所有的操作都有审计日志，可以方便地追踪问题
6. 客户端配置信息监控
可以在界面上方便地看到配置在被哪些实例使用
7. 提供Java和.NET原生客户端
8. 提供开放平台API
Apollo自身提供了比较完善的统一配置管理界面，提供多环境，多数据中心配置管理、权限、流程治理等特性。不过Apollo出于通用性考虑，不会对配置的修改做过多限制，只要符合基本的格式就能保存，不会针对不同的配置值进行针对性的检验，如数据库用户名，密码，redis服务地址等。
对于这类应用配置，Apollo支持应用方通过开放平台API在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制。
9. 部署简单
配置中心作为基础服务，可用性要求非常高，这就要求Apollo对外部依赖尽可能地少
目前唯一的外部依赖是MySQL，所以部署非常简单，只要安装好Java和MySQL就可以让Apollo跑起来
Apollo还提供了打包脚本，一键就可以生成所有需要的安装包，并且支持自定义运行时参数
apollo使用方法参考如下
https://www.apolloconfig.com/#/zh/usage/apollo-user-guide
基础模型
testing
1. 用户在配置中心对配置进行修改并发布
2. 配置中心通知Apollo客户端有配置更新
3. Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用
架构模块
testing
1. Config service提供配置的读取、推送等功能，服务对象是Apollo客户端。
2. Admin service提供配置的修改、发布等功能，服务对象是Apollo Portal（界面管理）
3. Config service和Admin service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳。
4. 在Eureka之上我们加了一层Meta Server用于封装Eureka的服务发现接口。
5. Client通过域名访问Meta Server获取Config Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Client侧会做load balance、错误重试。
6. Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Portal侧会做load balance、错误重试。
7. 为了简化部署，实际上会把Config service, Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中。
网友评论