Apollo（阿波罗）是携程框架部研发并开源的一款生产级的配置中心产品，它能够集中管理应用在不同环境、不同集群的配置，配置修改后能实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
1.1.1.1 基础模型
如下图所示：
- 用户在配置中心对配置进行修改并发布
- 配置中心通知Apollo客户端有配置更新
- Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用
1.1.1.2 架构模块
如下图所示：
- Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端
- Admin Service提供配置的修改、发布等功能，服务对象时Apollo Portal（管理界面）
- Config Service和Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳
- 在Eureka之上还有一层Meta Server用于封装Eureka的服务发现接口
- Client通过域名访问Meta Server获取Config Service服务列表（IP+Port），然后直接通过IP+Port访问服务，同时在Client侧会做负载均衡、错误重试
- 为了简化部署，实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM中
1.1.1.3 各模块概要介绍
1.1.1.3.1 Config Service
- 提供配置获取接口
- 提供配置更新推送接口（基于Http long polling）
- 服务端使用Spring DeferredResult实现异步化，从而大大增加长连接数量
- 目前使用tomcat embed默认配置是最多10000个连接
- 接口服务对象时Apollo客户端
1.1.1.3.2 Admin Service
- 提供配置管理接口
- 提供配置修改、发布等接口
- 接口服务对象是Portal
1.1.1.3.3 Meta Server
- Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port）
- Client通过域名访问Meta Server获取Config Service服务列表）（IP+Port）
- Meta Server从Eureka获取Config Service和Admin Service的服务信息，相当于是一个Eureka Client
- 增设一个Meta Server的角色主要是为了封装服务发现的细节，对Portal和Client而言，永远通过一个Http接口获取Admin Service和Config Service的服务信息，而不需要关系背后实际的服务注册和发现组件
- Meta Server只是一个逻辑角色，在部署时和Config Service是在一个JVM进程中的，所以IP、端口和Config Service一致
1.1.1.3.4 Eureka
- 基于Eureka和Spring Cloud Netflix提供服务注册和发现
- Config Service和Admin Service会向Eureka注册服务，并保持心跳
- 目前Eureka在部署时和Config Service是在一个JVM进程中的
1.1.1.3.5 Portal
- 提供Web界面供用户管理配置
- 通过Meta Server获取Admin Service服务列表）（IP + Port），通过IP+Port访问服务
- 在Portal侧做负载均衡、错误重试
1.1.1.3.6 Client
- Apollo提供的客户端程序，为应用提供配置获取、实时更新等功能
- 通过Meta Server获取Config Service服务列表（IP+Port），通过IP+Port访问服务
- 在Client侧做负载均衡、错误重试
在配置中心中，一个重要的功能就是配置发布后实时推送到客户端。如下图所示：
- 用户在Portal操作配置发布
- Portal调用Admin Service的接口操作发布
- Admin Service发布配置后，发送ReleaseMessage给各个Config Service
- Config Service收到ReleaseMessage后，通过对应的客户端
1.1.2.1 发送ReleaseMessage的实现方式
Admin Service在配置发布之后，需要通知所有的Config Service有配置不发，从而Config Service可以通知对应的客户端来拉取最新的配置。如下图所示：
从概念上来说，这是一个典型的消息使用场景，Admin Service作为producer发出消息，各个Config Service作为consumer消费消息。通过一个消息组件（Message Queue）就能很好的实现Admin Service和Config Service解耦。
Apollo为了减少外部依赖，没有采用外部的消息中间件，而是通过数据库实现的一个简单的消息队列。
实现方式如下：
- Admin Service在配置发布后会往ReleaseMessage表插入一条消息记录，消息内容就是配置发布的AppId+Cluster+Namespace，具体请看DatabaseMessageSender
- Config Service有一个线程会每秒扫描一次ReleaseMessage表，看看是否有新的消息记录，具体请看ReleaseMessageScanner
- Config Service如果发现有新的消息记录，那么就会通知到所有的消息监听器（ReleaseMessageListener），如NotificationControllerV2，消息监听器的注册过程可以查看ConfigServiceAutoConfiguration
- NotificationControllerV2得到配置发布的AppId+Cluster+Namespace后，会通知对应的客户端
1.1.2.2 Config Service通知客户端的实现方式
NotificationControllerV2在得知有配置发布后通知客户端的实现方式如下：
- 客户端会发起一个Http请求到Config Service的notifications/v2接口，也就是NotificationControllerV2，具体请看RemoteConfigLongPollService
- NotificationControllerV2不会立即返回结果，而是通过Spring DeferredResult把请求挂起
- 如果在60秒内没有该客户端关系的配置发布，那么会返回Http状态码304给客户端
- 如果有该客户端关心的配置发布，NotificationController会调用DeferredResult的setResult方法，传入有配置变化的namespace信息，同时该请求会立即返回。客户端从返回的结果中获取到配置变化的namespace后，会立即请求Config Service获取该namespace的最新配置。
如下图所示：
- 客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。（通过Http Long Polling实现）
- 客户端还会定时从Apollo配置中心服务端拉取应用的最新配置
- 这是一个fallback机制，为了防止推送机制失效导致配置不更新
- 客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304
- 定时频率默认为5分钟拉取一次，客户端也可以通过在运行时指定System Property：apollo.refreshInterval来覆盖，单位为分钟
- 客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中
- 客户端会把从服务端获取到的配置在本地文件系统缓存一份
- 在遇到服务不可用时，或网络不通时，依然能从本地恢复配置
- 应用程序可以从Apollo客户端获取最新的配置、订阅配置更新通知
1.2.1.1 基础模型
如下图所示：
- 用户在配置中心对配置进行修改并发布
- 配置中心通知Apollo客户端有配置更新
- Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用
1.2.1.2 界面概览
如下图所示：
上图是Apollo配置中心中一个项目的配置首页：
- 在页面左上方的环境列表模块展示了所有的环境和集群，用户可以随时切换
- 页面中央展示了两个namespace的配置信息，默认按照表格模式展示、编辑。用户可以切换到文本模式，以文件形式查看、编辑
- 页面上可以方便进行发布、回滚、灰度、授权、查看更改历史和发布历史等操作
1.2.1.3 添加/修改配置项
用户可以通过配置中心界面方便的添加/修改配置项，如下图所示：
1.2.1.4 发布配置
通过配置中心发布配置：
1.2.1.5 客户端获取配置（Java API样例）
配置发布后，就能在客户端获取到了，以Java为例，获取配置的示例代码如下：
1.2.1.6 客户端监听配置变化
在某些场景下，应用还需要在配置变化时获得通知，比如数据库连接的切换等，所以Apollo还提供了监听配置变化的功能，Java示例代码如下：
1.2.1.7 Spring集成样例
Apollo和Spring可以很方便地集成，只需要标注@EnableApolloConfig后就可以通过@Value获取配置信息了：
- application
- 这个很好理解，就是实际使用配置的应用，Apollo客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置
- 每个应用都需要有唯一的身份表示：appId，需要在客户端配置
- environment
- 配置对应的环境，Apollo客户端在运行时需要知道当前应用处于哪个环境，从而可以获取应用的配置
- 环境和代码无关，同一份代码部署在不同的环境就应该能够获取到不同环境的配置
- 所以环境默认是通过读取机器上的配置（server.properties中的env属性）指定的
- cluster
- 一个应用下不同实例的分组，比如典型的可以按照数据中心分，把上海机房的应用实例分为一个集群，把北京机房的应用实例分为另一个集群
- 对不同的cluster，同一个配置可以有不一样的值，比如zookeeper地址
- 集群默认是读取机器上的配置（server.properties中的idc属性）指定的
- namespace
- 一个应用下不同配置的分组，可以简单把namespace类比为文件，不同类型的配置放在不同的文件中，如数据库配置文件，RPC配置文件，应用自身的配置文件等
- 应用可以直接读取到公共组件的配置namespace，比如DAL、RPC等
- 应用也可以通过继承公共组件的配置namespace来对公共组件的配置做调整，如DAL的初始数据库连接数
1.2.2.2 自定义Cluster
比如我们有应用在A数据中心和B数据中心都有部署，那么如果希望两个数据中心的配置不一样的话，我们可以通过新建cluster来解决。
1.2.2.2.1 新建Cluster
新建Cluster只有项目的管理员才有权限，管理员可以在页面左侧看到“添加集群”按钮：
点击后就进入到集群添加页面，一般情况可以按照数据中心来划分集群，比如SHAJQ、SHAOY等，不过也支持自定义集群，比如可以为A机房的某一台机器和B机房的某一台机器创建一个集群，使用一套配置：
1.2.2.2.2 在Cluster中添加配置并发布
集群添加成功后，就可以为该集群添加配置了，添加配置上面已经介绍过了，不在赘述。
1.2.2.2.3 指定应用实例所属的Cluster
Apollo会默认使用应用实例所在的数据中心作为Cluster，所以如果两者一致的话，不需要配置。如果cluster和数据中心不一致的话，那么就需要通过System Property方式来指定运行时cluster：
- -Dapollo.cluster=SomeCluster
- apollo.cluster为全小写
1.2.2.3 自定义Namespace
如果应用有公共组件供其他应用使用，就需要通过自定义namespace来实现公共组件的配置。
1.2.2.3.1 新建Namespace
以hermes-producer为例，需要先新建一个namespace，新建namespace只有项目的管理员才有权限，管理员可以在页面左侧看到“添加Namespace”按钮：
点击后就进入namespace添加页面，Apollo会把应用所属的部门作为namespace的前缀：
1.2.2.3.2 关联到环境和集群
Namespace创建完，需要窜则在哪些环境和集群下使用：
1.2.2.3.3 在Namespace中添加配置项
接下来在这个创建的namespace下添加配置项：
添加完成后就能在FX.Hermes.Producer的namespace看到这个配置：
1.2.2.3.4 发布namespace的配置
1.2.2.3.5 客户端获取Namespace配置
对自定义namespace的配置获取，稍有不同，需要程序传入namespace的名字。Java示例代码如下：
1.2.2.3.6 客户端监听Namespace配置变化
Java示例代码如下：
1.2.2.3.7 Spring集成样例
官方的Github上有多种部署方式（Quick Start或者Docker方式部署Quick Start）、分布式部署等。我在这里就只介绍分布式部署的Docker部署了。
- 服务端基于Spring Boot，理论上支持所有Linux发行版
- JDK1.8
- MySQL，要求5.6.5+版本
- 如果基于Docker的话，以上环境都可以不用，但是系统需要Docker引擎
分布式部署的时候，apollo-configservice和apollo-adminservice需要把自己的IP和端口注册到Meta Server（apollo-configservice本身）。
Apollo客户端和Portal会从Meta Server获取服务的地址（IP+端口），然后通过服务地址直接访问。
需要注意的是，apollo-configservice和apollo-adminservice是基于内网设计的，所以出于安全考虑，不要将apollo-configservice和apollo-adminservice直接暴露在公网。
所以如果实际部署的机器有多块网卡（如docker），或者存在某些网卡的IP是Apollo客户端和Portal无法访问，就需要在apollo-configservice和apollo-adminservice中做相关配置来解决连通性问题。
2.1.2.1 忽略某些网卡
可以分别修改apollo-configservice和apollo-adminservice的start.sh，通过JVM System Property传入-D参数，也可以通过系统环境变量传入，如下是把docker0和veth开头的网卡在注册到Eureka时忽略掉。
通过JVM参数配置示例：
获取环境变量配置示例：
2.1.2.2 指定要注册的IP
可以分别修改apollo-configservice和apollo-adminservice的startup.sh，通过JVM传入-D参数，也可以通过系统环境变量传入，如下，是指定注册的IP为1.2.3.4
通过JVM参数配置示例：
通过系统环境变量配置示例：
2.1.2.3 指定要注册的URL
可以分别修改apollo-configservice和apollo-adminservice的startup.sh，通过JVM传入-D参数，也可以通过系统环境变量传入。如下示例是会指定注册的URL为
JVM参数配置示例：
通过系统环境变量配置示例：
Apollo的唯一依赖是数据库，所以需要先把数据库准备好，然后根据实际情况进行部署。
Apollo服务端共需要两个数据库：ApolloPortalDB和ApolloConfigDB。
需要注意的是ApolloPortalDB只需要在生产环境部署一个即可，而ApolloConfigDB需要在每个环境部署一套。
SQL文件可以在其GitHub上下载：https://github.com/ctripcorp/apollo/tree/master/scripts/sql
Apollo 1.7.0版本开始默认上传Docker镜像到Docker Hub。
获取镜像：
启动镜像：
获取镜像：
启动镜像：
获取镜像：
启动镜像：
- APOLLO_PORTAL_ENVS：可选配置，对应ApolloPortalDB中的apollo.portal.envs配置项，如果没有在数据库中配置的话，可以通过此环境变量配置
- DEV_META/PRO_META：可选配置。配置对应环境的Meta Service地址，以${ENV}_META命名，如果在ApolloPortalDB库中配置了apollo.portal.meta.services配置，则以数据库为准。
启动容器成功后，可以正常访问就表示没有问题了。
配置项统一存储在ApolloPortalDB.ServerConfig表中，也可以通过 管理员工具 - 系统参数 页面进行配置
2.3.1.1 apollo.portal.envs：可支持的环境列表
默认值是dev，如果portal需要管理多个环境的话，以逗号分隔即可（大小写不敏感），如：
修改完需要重启生效。
需要注意以下几点：
- 一套Portal可以管理多个环境，但是每个环境都需要独立部署一台Config Service，Admin Service和ApolloConfigDB
- 只在数据库添加环境是不起作用的，还需要为apollo-portal添加新增环境对应的meta server（后面介绍）
2.3.1.2 apollo.portal.meta.servers：各环境Meta Service列表
Apollo Portal需要在不同的环境访问不同的meta service（apollo-configservice）地址，所以需要提供这些信息。例如：
修改完需要重启生效。
2.3.1.3 organizations：部门列表
Portal中新建APP都需要选择部门，所以需要在这里配置可选的部门信息。例如：
2.3.1.4 superAdmin：Portal超级管理员
超级管理员拥有的所有权限，需要谨慎设置。默认是apollo（默认用户）。
2.3.1.5 consumer.token.salt
如果会使用开放平台API的话，可以设置一个token salt，如果不适用，可以忽略。
2.3.1.6 wiki.address
portal上“帮助”链接的地址，默认是Apollo github的wiki首页，可自行设置。
2.3.1.7 admin.createPrivateNamespace.switch
是否允许项目管理员创建private namespace，true允许，false不允许。
2.3.1.8 emergencyPublish.supported.envs
配置允许紧急发布的环境列表，多个env以英文逗号分隔。
当config service开启一次发布只能有一个人修改开关（namespace.lock.switch）后，一次配置发布只能是一个人修改，另一个人发布。为了避免紧急情况时无法发布配置，可以配置此项允许某些环境可以操作紧急发布，即同一个人可以修改并发布配置。
2.3.1.9 configView.memberOnly.envs
只对项目成员显示配置信息的环境列表，多个env以英文逗号分隔。
2.3.1.10 role.create-application.enabled：是否开启创建项目权限控制
默认为false，所有用户都可以创建项目。如果设置为true，那么只有超级管理员和拥有创建项目权限的账号可以创建项目。
2.3.1.11 role.manage-app-master.enabled：是否开启项目管理员分配权限控制
默认为false，所有项目的管理员可以为项目添加/删除管理员。
2.3.1.12 admin-service.access.tokens：设置apollo-portal访问各环境apollo-adminservice所需的access token
如果对应环境的apollo-adminservice开启了访问控制，那么需要在此配置apollo-portal访问该环境apollo-adminservice所需的access token。否则会访问失败
2.3.2.1 eureka.service.url：Eureka服务URL
配置项统一存储在ApolloConfigDB.ServerConfig表中，需要注意每个环境的ApolloConfigDB.ServerConfig都需要单独配置，修改完一分钟实时生效。
不适用于基于Kubernetes原生服务发现场景。
不管是apollo-configservice还是apollo-adminservice都需要向eureka服务注册，所以需要配置eureka服务地址。而apollo-configservice本身就是一个eureka服务，所以需要填入apollo-configservice的地址即可，如有多个，用逗号分隔（不要忘了/eureka后缀）。
例如：
在FAT环境的表中配置为：
注意，需要填写本环境全部的eureka服务地址，因为eureka需要互相复制注册信息。
2.3.2.2 namespace.lock.switch：一次发布智能有一个人修改开关，用于发布审核
这是一个功能开关，如果为true的话，那么一次配置发布只能是一个人修改，另一个发布。生产环境建议开启此项
2.3.2.3 config-service.cache.enabled：是否开启配置缓存
这是一个功能开关，如果配置为true的话，config service会缓存加载过的配置信息，从而加快后续配置获取性能。
默认为false。
2.3.2.4 item.key.length.limit：配置项key最大长度限制
默认为128
2.3.2.5 item.value.length.limit：配置项value最大长度限制
默认为20000
2.3.2.6 admin-service.access.control.enabled：配置apollo-adminservice是否开启访问控制
适用于1.7.1及以上版本。
默认为false，如果位true，那么apollo-portal就需要正确访问该环境的access token，否则访问会被拒绝
2.3.2.7 admin-service.access.tokens：配置允许访问apollo-adminservice的access token列表
适用于1.7.1及以上版本。
如果该配置项为空，那么访问控制不会生效。如果允许多个token，token之间以英文逗号分隔。
Java使用Apollo上面其实很多都介绍了，使用起来很简单。我这里使用Spring Boot进行介绍。
首先注入相关依赖：
然后在配置文件中指定相关参数：
- app.id：指定应用的名称。对应的Apollo中的应用名称
- apollo.meta：meta地址
指定好以后，使用注解@EnableApolloConfig开启Apollo配置：
然后使用就使用@Value即可。在此不多做介绍了。
到此这篇Apollo配置中心页面长什么样（apollo配置中心使用）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/qkl-jr/48858.html