前言
公司里面使用的配置中心是携程开源的Apollo，之前我只使用过Nacos，遂记载一放学习过程。
Apollo工作原理
模块介绍
上图就是Apollo的总体设计，从下往上挨个分析：
- ConfigDB用于存储各种配置
- Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端，多实例，必要注册到Eureka中保持心跳检测
- Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（管理界面），多实例，必要注册到Eureka中保持心跳检测
- Eureka提供服务注册和发现，为了简朴起见，目前Eureka在部署时和Config Service是在一个JVM进程中
- Meta Server用于封装Eureka的服务发现接口
- Client通过域名访问Meta Server获取Confifig Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Client侧会做load balance、错误重试
- Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Portal侧会做load balance、错误重试
实行流程
- Apollo启动后，Config/Admin Service会主动注册到Eureka服务注册中心，并定期发送保活心跳；
- Apollo Client和Portal管理端通过配置的Meta Server的域名地址经由Software Load Balancer(软件负载平衡器)举行负载平衡后分配到某一个Meta Server；
- Meta Server从Eureka获取Config Service和Admin Service的服务信息，相称于是一个Eureka Client；
- Meta Server获取Config Service和Admin Service（IP+Port）失败后会举行重试；
- 获取到正确的Config Service和Admin Service的服务信息后，Apollo Client通过Config Service为应用提供配置获取、实时更新等功能；Apollo Portal管理端通过Admin Service提供配置新增、修改、发布等功能。
基本概念
- application (应用)
现实使用配置的应用，Apollo客户端在运行时必要知道当前应用是谁，从而可以去获取对应的配置。关键字：appId
- environment (情况)
配置对应的情况，Apollo客户端在运行时必要知道当前应用处于哪个情况，从而可以去获取应用的配置。关键字：env
- cluster (集群)
一个应用下不同实例的分组，比如典型的可以按照数据中心分，把上海机房的应用实例分为一个集群，把北京机房的应用实例分为另一个集群。关键字：cluster
- namespace (定名空间)
一个应用下不同配置的分组，可以简朴地把namespace类比为文件，不同类型的配置存放在不同的文件中，如数据库配置文件，RPC配置文件，应用自身的配置文件等。关键字：namespaces
关系图如下所示：
项目管理
部门管理
apollo 默认部门有两个。要增长自己的部门，可在体系参数中修改，进入体系参数，输入key查询已存在的部门设置：organizations
修改value值来添加新部门，下面添加一个微服务部门：- [{"orgId":"TEST1","orgName":"样例部门1"},{"orgId":"TEST2","orgName":"样例部门2"},{"orgId":"micro_service","orgName":"微服务部门"}]
- 打开apollo主页，点击创建应用：
- 输入相干信息，包括部门、应用AppId、应用名称和应用负责人
- 将项目授予用户管理服务的权限，点击授权
- 使用zhangsan账号登岸，就可以看到能管理的应用了
删除项目
如果要删除整个项目，点击右上角的管理员工具，再点击删除应用、集群。
起首查出压迫删除的项目是，然后点击删除应用：
配置管理
发布配置
- 通过表格模式添加：
- 通过文本模式批量添加：
- 最后点击右上角发布按钮发布配置。
修改配置
找到必要修改的配置项，举行修改
修改完举行提交，之后在重新发布配置。
删除配置
与上面一样，删除配置后重新发布。
设置私有Namespace
Namespace同样也可以当作一个配置文件，以rocketmq配置为例，添加“spring-rocketmq” Namespace配置rocketmq相干信息。
设置公共Namespace
在项目开发中，有一些配置可能是通用的，我们可以通过把这些通用的配置放到公共的Namespace中，如许其他项目要使用时可以直接添加必要的Namespace。
添加配置
- 新建一个common-template项目
- 添加公共Namespace：spring-boot-http
- 添加配置项并发布
关联公共Namespcae
创建完公共定名空间之后，必要将项目举行关联才气使用。
打开之前创建的account-service项目，点击左侧的添加Namespace，再添加Namespace：
若是当前项目必要的配置与公共配置中提供的不一样，也可以根据需求覆盖定制配置。
读取配置
读取某个集群的配置，必要启动应用时在VM option指定详细的应用、情况和集群。
-Dapp.id=应用名称
-Denv=情况名称
-Dapollo.cluster=集群名称
-D情况_meta=meta地址
详细实例如下：- ‐Dapp.id=account‐service
- ‐Denv=DEV
- ‐Dapollo.cluster=SHAJQ
- ‐Dapollo.meta=http://localhost:8080
在配置中心中，一个重要的功能就是配置发布后实时推送到客户端。下面我们扼要看一下这块是怎么设计实现的：
- 用户在Portal操作配置发布
- Portal调用Admin Service的接口操作发布
- Admin Service发布配置后，发送ReleaseMessage给各个Config Service
- Config Service收到ReleaseMessage后，通知对应的客户端
源码分析
发送ReleaseMessage
Admin Service在配置发布后，必要通知所有的Config Service有配置发布，从而Config Service可以通知对应的客户端来拉取最新的配置。
从概念上来看，这是一个典型的消息使用场景，Admin Service作为producer（生产者）发出消息，各个Config Service作为consumer（消费者）消费消息。通过一个消息队列组件（Message Queue）就能很好的实现Admin Service和Config Service的解耦。
在实现上，考虑到Apollo的现实使用场景，以及为了尽可能淘汰外部依赖，Apollo没有接纳外部的消息中间件，而是通过数据库实现了一个简朴的消息队列。
详细实现如下：
- Admin Service在配置发布后会往ReleaseMessage表插入一条消息记载，消息内容就是配置发布的AppId+Cluster+Namespace：
消息发送类：DatabaseMessageSende
- Config Service有一个线程会每秒扫描一次ReleaseMessage表，看看是否有新的消息记载。
消息扫描类：ReleaseMessageScanner
- Config Service如果发现有新的消息记载，那么就会通知到所有的消息监听器
- 有一个类叫NotifificationControllerV2，当它得到配置发布的AppId+Cluster+Namespace后，会通知对应的客户端。
- 客户端会发起一个Http请求到Config Service的 notifications/v2 接口NotificationControllerV2
- NotificationControllerV2不会立即返回效果，而是把请求挂起。考虑到会有数万客户端向服务端发起长连，因此在服务端使用了async servlet(Spring DeferredResult)来服务Http Long Polling请求。
- 如果在60秒内没有该客户端关心的配置发布，那么会返回Http状态码304给客户端。
- 如果有该客户端关心的配置发布，NotificationControllerV2会调用DeferredResult的setResult方法，传入有配置变革的namespace信息，同时该请求会立即返回。客户端从返回的效果中获取到配置变革的namespace 后，会立即请求Config Service获取该namespace的最新配置。
- 除此之外，客户端还会定时从Apollo配置中心服务端拉取应用的最新配置，防止推送机制失效导致配置不更新，提升了可用性，默认定时拉取频率是5分钟。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
