笔记本做网站要什么好,邢台市刚刚发生的事,pc端手机网站 viewport 自适应,北京效果好的网站推广文章目录 Apollo介绍配置中心介绍apollo介绍主流配置中心功能特性对比 Apollo简介 入门简单的执行流程Apollo具体的执行流程Apollo对象执行流程分步执行流程 核心概念应用#xff0c;环境#xff0c;集群#xff0c;命名空间企业部署方案灰度发布全量发布 配置发布的原理发送… 文章目录 Apollo介绍配置中心介绍apollo介绍主流配置中心功能特性对比 Apollo简介 入门简单的执行流程Apollo具体的执行流程Apollo对象执行流程分步执行流程 核心概念应用环境集群命名空间企业部署方案灰度发布全量发布 配置发布的原理发送ReleaseMessageConfig Service通知客户端客户端读取设计 Apollo介绍
配置中心介绍
分布式系统环境下给其他服务提供配置文件的管理统一管理各种应用配置的一个基础服务组件 apollo介绍
Apollo阿波罗是携程开源的一款可靠的分布式配置管理中心它能够集中化管理应用不同环境、不同集群的配置配置修改后能够实时推送到应用端并且具备规范的权限、流程治理等特性适用于微服务配置管理场景
主流配置中心
目前市面上用的比较多的配置中心有:
Spring Cloud Config 2014年9月开源Spring Cloud 生态组件可以和Spring Cloud体系无缝整合。GitHub地址 https://github.com/spring-cloud/spring-cloud-config Nacos 2018年6月阿里开源的配置中心也可以做DNS和RPC的服务发现。GitHub地址 https://github.com/alibaba/nacos Apollo 2016年5月携程开源的配置管理中心能够集中化管理应用不同环境、不同集群的配置配置修改后能够实时推送到应用端并且具备规范的权限、流程治理等特性适用于微服务配置管理场景。GitHub地址 https://github.com/apolloconfig
功能特性对比
功能点Spring Cloud ConfigApolloNacos配置实时推送支持支持(HTTP长轮询1s内)支持(HTTP长轮询1s内)版本管理支持支持支持灰度发布支持支持不支持权限管理支持(依赖Git)支持不支持多语言只支持Java主流语言提供了Open API主流语言提供了Open API
总结 Spring Cloud Config 与 Apollo类似但只支持 Java所以不用 Spring Cloud ConfigNacos 不支持 灰度发布 和 权限管理所以不用 Nacos
Apollo简介
Apollo 是 一个 分布式配置中心的解决方案Apollo 包括 服务端 服务端基于 Spring Boot 和Spring Cloud 开发 客户端 Java客户端不依赖任何框架 Apollo 特性 统一管理不同环境不同集群的配置 提供了一个Apotal界面来管理 热发布 用户在Apollo修改完配置并发布后客户端能实时(1秒)接收到最新的配置并通知到应用程序 版本发布管理 所有的配置发布都有版本概念从而可以方便地支持配置的回滚 灰度发布 支持配置的灰度发布 比如点了发布后只对部分应用实例生效等观察一段时间没问题后再推给所有 应用实例
入门
简单的执行流程
四个对象 配置中心客户端应用程序本地文件缓存 执行流程
1、在Apollo配置中心修改配置
2、应用程序通过Apollo客户端从配置中心拉取配置信息
用户通过Apollo配置中心修改或发布配置后会有两种机制来保证应用程序来获取最新配置:
一种是Apollo配置中心会向客户端推送最新的配置;另外一种是Apollo客户端会定时从Apollo配置中心拉取最新的配置
通过以上两种 机制共同来保证应用程序能及时获取到配置。
Apollo具体的执行流程 Apollo对象
Config Service 配置的读取和推送客户端通过 Config Service 读取配置 Admin Service 配置的修改发布Portal 通过 Admin Service 将配置写到ConfigDB数据库中 Eureka 注册中心 服务注册和发现记录 Config Service 和 Admin Service 的信息 IP地址端口等 方便客户端和Portal 的访问 Meta Server 在Eureka 之上架了一层Meta Server用于封装Eureka的服务发现接口 Meta Server从Eureka获取Config Service和Admin Service的服务信息相当于是一个Eureka Client
执行流程
客户端读取配置流程 通过域名访问Meta Server获取Config Service服务列表(IPPort而后直接通过IPPort访问服务 修改配置的流程 Portal通过域名访问Meta Server获取Admin Service服务列表(IPPort)而后直接通过IPPort访问服务 Ps: 为了简化部署我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程 中
分步执行流程
Apollo启动后 Config/Admin Service会自动注册到Eureka服务注册中心并定期发送保活心跳。 Apollo Client和Portal管理端通过配置的Meta Server的域名地址 经由Software Load Balancer**(软件负载均衡** **器)进行负载均衡后分配到某一个Meta** Server Meta Server从Eureka获取Config Service和Admin Service的服务信息相当于是一个Eureka ClientMeta Server获取Config Service和Admin Service(IPPort)失败后会进行重试 获取到正确的Config Service和Admin Service的服务信息后Apollo Client通过Config Service为应用提供配置获取、实时更新等功能;Apollo Portal管理端通过Admin Service提供配置新增、修改、发布等功能
核心概念
应用环境集群命名空间 应用 就是实际使用配置的应用 Apollo客户端在运行时需要知道当前应用是谁从而可以去获取对应的配置 关键字: appId 环境 配置对应的环境 Apollo客户端在运行时需要知道当前应用处于哪个环境从而可以去获取应用的配置 关键字: env 集群 一个应用下不同实例的分组比如典型的可以按照数据中心分 把上海机房的应用实例分为一个集群把北京机房的应用实例分为另一个集群。 关键字:cluster 关系 应用 -- 环境 -- 集群 应用 工程项目应用分环境 具体环境下边 由于部署的集群不同导致配置的不同 北京和上海数据库的地址不同虽然都是生产环境 命名空间 一个应用下不同配置的分组 配置通过key,value 存储 通过namespace对我们的配置项进行分类管理 不同类型的配置存放在不同的文件中 数据库配置文件RPC配置文件应用自身的配置文件 在添加配置的时候要记得对配置项进行分类 公共和私有 有共用的情况公共命名空间可以继承 有5个工程都会连接数据库数据库的配置就共用了就可以建一个公共的命名空间(例如数据库的连接) 生产环境里面的命名空间可以继承公共的命名空间生产环境就可以直接拿到数据库的连接 可以在生产环境中再做个性化定义
企业部署方案
在企业中常用的部署方案为:
Apollo-adminservice 发布配置和Apollo-configservice 查询配置两个服务 分别在线上环境(pro)仿真环 境(uat)和开发环境(dev)各部署一套并且还要建立不同的 apolloconfigdb 因为配置信息在不同的数据库当中 Apollo-portal做为管理端 管理界面只部署一套 统一管理上述三套环境。 通过一个portal管理界面连接访问不同的生产环境
具体如下图所示: 灰度发布
定义 灰度发布是指在黑与白之间能够平滑过渡的一种发布方式。在其上可以进行A/B testing 即让一部分用户继续用 产品特性A一部分用户开始用产品特性B如果用户对B没有什么反对意见那么逐步扩大范围把所有用户都迁 移到B上面来。 Apollo实现的功能 对于一些对程序有比较大影响的配置 可以先在一个或者多个实例生效观察一段时间没问题后再全量发布 配置。 对于一些需要调优的配置参数 可以通过灰度发布功能来实现A/B测试。可以在不同的机器上应用不同的配 置不断调整、测评一段时间后找出较优的配置再全量发布配置。
全量发布
灰度发布测试完成后全量发布
配置发布的原理
参考链接 https://www.iocoder.cn/categories/Apollo/
用户在Portal操作配置发布Portal调用Admin Service的接口操作发布Admin Service发布配置后发送ReleaseMessage给各个Config ServiceConfig Service收到ReleaseMessage后通知对应的客户端
发送ReleaseMessage
通过数据库实现了一个简单的消息队列
具体实现方式如下: Admin Service在配置发布后会往ReleaseMessage表插入一条消息记录 消息内容就是配置发布的AppId****ClusterNamespace源码 消息发送类: DatabaseMessageSendehttps://github.com/ctripcorp/apollo/blob/master/apollo-biz/src/main/java/com/ctrip/framework/apollo/biz/message/DatabaseMessageSender.java Config Service有一个线程会每秒扫描一次ReleaseMessage表 看看是否有新的消息记录源码 消息扫描类:ReleaseMessageScannerhttps://github.com/ctripcorp/apollo/blob/master/apollo-biz/src/main/java/com/ctrip/framework/apollo/biz/message/ReleaseMessageScanner.java Config Service如果发现有新的消息记录那么就会通知到所有的消息监听器 1. 然后调用消息监听类的handleMessage方法: NotificationControllerV2 https://github.com/ctripcorp/apollo/blob/master/apollo-configservice/src/main/java/com/ctrip/framework/apollo/configservice/controller/NotificationControllerV2.java NotificationControllerV2得到配置发布的AppIdClusterNamespace后会通知对应的客户端 Config Service通知客户端
上面描述了NotificationControllerV2是如何得知有配置发布的
NotificationControllerV2在得知有配置发布通知到客户端
客户端会发起一个Http请求到Config Service的 notifications/v2 接口 NotificationControllerV2
客户端发送请求类:RemoteConfigLongPollService
NotificationControllerV2不会立即返回结果而是把请求挂起。考虑到会有数万客户端向服务端发起长连接 因此在服务端使用了async servlet(Spring DeferredResult)来服务Http Long Polling请求。 如果在60秒内没有该客户端关心的配置发布那么会返回Http状态码304给客户端。如果有该客户端关心的配置发布 NotificationControllerV2会调用DeferredResult的setResult方法传入有 配置变化的namespace信息同时该请求会立即返回。客户端从返回的结果中获取到配置变化的namespace 后会立即请求Config Service获取该namespace的最新配置。
客户端读取设计
除了之前介绍的客户端和服务端保持一个长连接从而能第一时间获得配置更新的推送外客户端还会定时从
Apollo配置中心服务端拉取应用的最新配置。
这是一个备用机制为了防止推送机制失效导致配置不更新客户端定时拉取会上报本地版本所以一般情况下对于定时拉取的操作服务端都会返回304 - Not Modified定时频率默认为每5分钟拉取一次客户端也可以通过在运行时指定System Property:apollo.refreshInterval 来覆盖单位为分钟
