Apollo介绍和入门

雪芙花2023-09-14 12:53

文章目录

Apollo介绍

配置中心介绍

  • 分布式系统环境下，给其他服务提供配置文件的管理，统一管理各种应用配置的一个基础服务组件

apollo介绍

Apollo（阿波罗）是携程开源的一款可靠的分布式配置管理中心，它能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景

主流配置中心

目前市面上用的比较多的配置中心有:

  1. Spring Cloud Config
    1. 2014年9月开源，Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合。
    2. GitHub地址
      1. https://github.com/spring-cloud/spring-cloud-config
  2. Nacos
    1. 2018年6月，阿里开源的配置中心，也可以做DNS和RPC的服务发现。
    2. GitHub地址
      1. https://github.com/alibaba/nacos
  3. Apollo
    1. 2016年5月，携程开源的配置管理中心
    2. 能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端
    3. 并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
    4. GitHub地址
      1. https://github.com/apolloconfig

功能特性对比

功能点 Spring Cloud Config Apollo Nacos
配置实时推送 支持 支持(HTTP长轮询1s内) 支持(HTTP长轮询1s内)
版本管理 支持 支持 支持
灰度发布 支持 支持 不支持
权限管理 支持(依赖Git) 支持 不支持
多语言 只支持Java 主流语言，提供了Open API 主流语言，提供了Open API
  • 总结
    • Spring Cloud Config 与 Apollo类似，但只支持 Java，所以不用 Spring Cloud Config
    • Nacos 不支持 灰度发布 和 权限管理，所以不用 Nacos

Apollo简介

  • Apollo 是 一个 分布式配置中心的解决方案
  • Apollo 包括
    • 服务端
      • 服务端基于 Spring Boot 和Spring Cloud 开发
    • 客户端
      • Java客户端不依赖任何框架
  • Apollo 特性：
    • 统一管理不同环境，不同集群的配置
      • 提供了一个Apotal界面来管理
    • 热发布
      • 用户在Apollo修改完配置并发布后
      • 客户端能实时(1秒)接收到最新的配置，并通知到应用程序
    • 版本发布管理
      • 所有的配置发布都有版本概念
      • 从而可以方便地支持配置的回滚
    • 灰度发布
      • 支持配置的灰度发布
        • 比如点了发布后，只对部分应用实例生效
        • 等观察一段时间没问题后再推给所有 应用实例

入门

简单的执行流程

  • 四个对象：
    • 配置中心
    • 客户端
    • 应用程序
    • 本地文件缓存
  • 执行流程

1、在Apollo配置中心修改配置

2、应用程序通过Apollo客户端从配置中心拉取配置信息

用户通过Apollo配置中心修改或发布配置后，会有两种机制来保证应用程序来获取最新配置:

  1. 一种是Apollo配置中心会向客户端推送最新的配置;
  2. 另外一种是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服务列表(IP+Port
    • 而后直接通过IP+Port访问服务
  • 修改配置的流程
    • Portal通过域名访问Meta Server获取Admin Service服务列表(IP+Port)
    • 而后直接通过IP+Port访问服务
  • Ps:
    • 为了简化部署，我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程 中

分步执行流程

  1. Apollo启动后
    1. Config/Admin Service会自动注册到Eureka服务注册中心 ，并定期发送保活心跳。
  2. Apollo Client和Portal管理端通过配置的Meta Server 的域名地址
    1. 经由Software Load Balancer **(软件负载均衡** **器)进行负载均衡后分配到某一个 Meta** Server
  3. Meta Server从Eureka获取Config Service和Admin Service的服务信息，相当于是一个Eureka Client
  4. Meta Server获取Config Service和Admin Service(IP+Port)失败后会进行重试
    1. 获取到正确的Config Service和Admin Service的服务信息后
    2. Apollo Client 通过Config Service 为应用提供配置获取、实时更新等功能;
    3. 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实现的功能
    • 对于一些对程序有比较大影响的配置
      1. 可以先在一个或者多个实例生效 ，观察一段时间没问题后再全量发布 配置。
    • 对于一些需要调优的配置参数
      1. 可以通过灰度发布功能来实现A/B测试。
      2. 可以在不同的机器上应用不同的配 置，不断调整、测评一段时间后找出较优的配置再全量发布配置。

全量发布

  • 灰度发布测试完成后，全量发布

配置发布的原理

  1. 用户在Portal操作配置发布
  2. Portal调用Admin Service的接口操作发布
  3. Admin Service发布配置后，发送ReleaseMessage给各个Config Service
  4. Config Service收到ReleaseMessage后，通知对应的客户端

发送ReleaseMessage

  • 通过数据库实现了一个简单的消息队列

具体实现方式如下:

  1. Admin Service在配置发布后会往ReleaseMessage表插入一条消息记录

    1. 消息内容就是配置发布的AppId****+Cluster+Namespace
    2. 源码：
      1. 消息发送类: DatabaseMessageSende
      2. https://github.com/ctripcorp/apollo/blob/master/apollo-biz/src/main/java/com/ctrip/framework/apollo/biz/message/DatabaseMessageSender.java

  2. Config Service有一个线程会每秒扫描一次ReleaseMessage表

    1. 看看是否有新的消息记录
    2. 源码：
      1. 消息扫描类:ReleaseMessageScanner
      2. https://github.com/ctripcorp/apollo/blob/master/apollo-biz/src/main/java/com/ctrip/framework/apollo/biz/message/ReleaseMessageScanner.java

  3. Config Service如果发现有新的消息记录，那么就会通知到所有的消息监听器

    2. 然后调用消息监听类的handleMessage方法: NotificationControllerV2

  4. NotificationControllerV2得到配置发布的AppId+Cluster+Namespace后，会通知对应的客户端

Config Service通知客户端

上面描述了NotificationControllerV2是如何得知有配置发布的

NotificationControllerV2在得知有配置发布通知到客户端：

  1. 客户端会发起一个Http请求到Config Service的 notifications/v2 接口 NotificationControllerV2

客户端发送请求类:RemoteConfigLongPollService

  1. NotificationControllerV2不会立即返回结果，而是把请求挂起。
  2. 考虑到会有数万客户端向服务端发起长连接， 因此在服务端使用了async servlet(Spring DeferredResult)来服务Http Long Polling请求。
    1. 如果在60秒内没有该客户端关心的配置发布，那么会返回Http状态码304给客户端。
    2. 如果有该客户端关心的配置发布
      1. NotificationControllerV2会调用DeferredResult的setResult方法
      2. 传入有 配置变化的namespace信息，同时该请求会立即返回。
      3. 客户端从返回的结果中获取到配置变化的namespace 后，会立即请求Config Service获取该namespace的最新配置。

客户端读取设计

除了之前介绍的客户端和服务端保持一个长连接，从而能第一时间获得配置更新的推送外，客户端还会定时从

Apollo配置中心服务端拉取应用的最新配置。

  • 这是一个备用机制，为了防止推送机制失效导致配置不更新
  • 客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified
  • 定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property:apollo.refreshInterval 来覆盖，单位为分钟
相关推荐
小吴编程之路5 小时前
MySQL 索引核心特性深度解析：从底层原理到实操应用
数据库·mysql
～莫子5 小时前
MySQL集群技术
数据库·mysql
凤山老林6 小时前
SpringBoot 使用 H2 文本数据库构建轻量级应用
java·数据库·spring boot·后端
就不掉头发6 小时前
Linux与数据库进阶
数据库
与衫6 小时前
Gudu SQL Omni 技术深度解析
数据库·sql
咖啡の猫6 小时前
Redis桌面客户端
数据库·redis·缓存
oradh6 小时前
Oracle 11g数据库软件和数据库静默安装
数据库·oracle
what丶k7 小时前
如何保证 Redis 与 MySQL 数据一致性？后端必备实践指南
数据库·redis·mysql
_半夏曲7 小时前
PostgreSQL 13、14、15 区别
数据库·postgresql
把你毕设抢过来7 小时前
基于Spring Boot的社区智慧养老监护管理平台（源码+文档）
数据库·spring boot·后端
热门推荐
01GitHub 镜像站点02OpenClaw 使用和管理 MCP 完全指南03本地部署 OpenClaw + DeepSeek-R1 完全指南04Qwen3.5 开源全解析：从 0.8B 到 397B，代际升级 + 全场景选型指南05OpenClaw 飞书机器人不回复消息？3 小时踩坑总结06OpenClaw macOS 完整安装与本地模型配置教程（实战版）07得物前端部门，没了08OpenClaw 连接飞书完整指南：插件安装、配置与踩坑记录09Window 10部署openclaw报错node.exe : npm error code 12810OpenClaw 接入 QQ Bot 完整实践指南